Squeak in commercial projects

> -----Original Message-----
> From: [hidden email] [mailto:beginners-
> [hidden email]] On Behalf Of Jens Pall
> Sent: Tuesday, March 06, 2007 2:09 AM
> To: Squeak Beginners
> Subject: [Newbies] Squeak in commercial projects
>
> Hi
>
> How can I use Squeak in a commercial closed source project (whole image)?
>
> How about upgrades? I want to be able to send an upgrade to the customer
> which only contains the changed code.
>
> Thanks,
> JP
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

> Hi JP,
>
> This is not an easy question.  There are a number of things that you need to
> consider.  First you need to decide how secure the update needs to be.  If
> you are not worried about security then you have a much easier job and many
> more options.  In general Squeak is not secure, but it is also not less
> secure then many other tools that are sent to end users.
>
> So first answer some questions.
>
> Is your system likely to be used by people that are interested in cracking
> the system?

> Ron Teitelbaum
> President / Principal Software Engineer
> US Medical Record Specialists
> www.usmedrec.com
> Squeak Cryptography Team Leader
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:beginners-
>> [hidden email]] On Behalf Of Jens Pall
>> Sent: Tuesday, March 06, 2007 2:09 AM
>> To: Squeak Beginners
>> Subject: [Newbies] Squeak in commercial projects
>>
>> Hi
>>
>> How can I use Squeak in a commercial closed source project (whole image)?
>>
>> How about upgrades? I want to be able to send an upgrade to the customer
>> which only contains the changed code.
>>
>> Thanks,
>> JP

> Ron Teitelbaum wrote:
>> Hi JP,
>> This is not an easy question.  There are a number of things that  
>> you need to
>> consider.  First you need to decide how secure the update needs to  
>> be.  If
>> you are not worried about security then you have a much easier job  
>> and many
>> more options.  In general Squeak is not secure, but it is also not  
>> less
>> secure then many other tools that are sent to end users.
>> So first answer some questions.
>> Is your system likely to be used by people that are interested in  
>> cracking
>> the system?
>
> Some of the end-users might try this but most of them will not.  
> They just want a system that works and does its job. We are working  
> with partners who are distributing our software and I know that  
> some of them will try to open up the software, modify it and, in  
> some cases, try to sell it as their own if it is easy to get at the  
> source. If the source is not available and it is a bit hard to get  
> access to the developing interface then I believe this risk is  
> greatly reduced.
>
>> Does your system have access to network facilities that attach to  
>> other
>> installations of your system?
>
> Yes. This is a distributed networked application. It lives and  
> breathes on the network.
>
>> Are you concerned that someone might try to build a patch and  
>> upload that
>> code to your system installations?  (i.e. spyware, worms, viruses)
>
> Well, not really. Our installations mainly run on private WAN  
> networks owned by the customer but you never know what malicious  
> internal users might do. We plan on being able to run this over the  
> Internet where this is a major concern but will try to limit it by  
> using secure network connections.
>
>> Are you trying to prevent users from using features of your system  
>> without
>> authorization?  (i.e. Try before you buy?)
>
> Yes. We must be able to issue licenses for using features of the  
> system.
>
>> There are no easy answers but I do believe it is a very interesting
>> discussion.
>
> It indeed is and one that needs to be addressed if Squeak is to be  
> seriously considered as a commercial vehicle. It has huge potential  
> in that area if the proper hooks are in place.
>
> As a side note I might mention that our current system is  
> implemented in C++ and, if it turns out to be possible with respect  
> to the topic of this thread, we are seriously considering porting  
> it to Squeak. Croquet will also play a major role as the  
> monitoring / management tool.
>
>> Ron Teitelbaum
>> President / Principal Software Engineer
>> US Medical Record Specialists
>> www.usmedrec.com Squeak Cryptography Team Leader
>>> -----Original Message-----
>>> From: [hidden email]  
>>> [mailto:beginners-
>>> [hidden email]] On Behalf Of Jens Pall
>>> Sent: Tuesday, March 06, 2007 2:09 AM
>>> To: Squeak Beginners
>>> Subject: [Newbies] Squeak in commercial projects
>>>
>>> Hi
>>>
>>> How can I use Squeak in a commercial closed source project (whole  
>>> image)?
>>>
>>> How about upgrades? I want to be able to send an upgrade to the  
>>> customer
>>> which only contains the changed code.
>>>
>>> Thanks,
>>> JP

> From: Jens Pall
> Sent: Tuesday, March 06, 2007 3:10 PM
>
> Ron Teitelbaum wrote:
> > Hi JP,
> >
> > This is not an easy question.  There are a number of things that you
> need to
> > consider.  First you need to decide how secure the update needs to be.
> If
> > you are not worried about security then you have a much easier job and
> many
> > more options.  In general Squeak is not secure, but it is also not less
> > secure then many other tools that are sent to end users.
> >
> > So first answer some questions.
> >
> > Is your system likely to be used by people that are interested in
> cracking
> > the system?
>
> Some of the end-users might try this but most of them will not. They
> just want a system that works and does its job. We are working with
> partners who are distributing our software and I know that some of them
> will try to open up the software, modify it and, in some cases, try to
> sell it as their own if it is easy to get at the source. If the source
> is not available and it is a bit hard to get access to the developing
> interface then I believe this risk is greatly reduced.
>
> > Does your system have access to network facilities that attach to other
> > installations of your system?
>
> Yes. This is a distributed networked application. It lives and breathes
> on the network.
>
> > Are you concerned that someone might try to build a patch and upload
> that
> > code to your system installations?  (i.e. spyware, worms, viruses)
>
> Well, not really. Our installations mainly run on private WAN networks
> owned by the customer but you never know what malicious internal users
> might do. We plan on being able to run this over the Internet where this
> is a major concern but will try to limit it by using secure network
> connections.
>
> > Are you trying to prevent users from using features of your system
> without
> > authorization?  (i.e. Try before you buy?)
>
> Yes. We must be able to issue licenses for using features of the system.
>
> > There are no easy answers but I do believe it is a very interesting
> > discussion.
>
> It indeed is and one that needs to be addressed if Squeak is to be
> seriously considered as a commercial vehicle. It has huge potential in
> that area if the proper hooks are in place.
>
> As a side note I might mention that our current system is implemented in
> C++ and, if it turns out to be possible with respect to the topic of
> this thread, we are seriously considering porting it to Squeak. Croquet
> will also play a major role as the monitoring / management tool.
>
> > Ron Teitelbaum
> > President / Principal Software Engineer
> > US Medical Record Specialists
> > www.usmedrec.com
> > Squeak Cryptography Team Leader
> >
> >
> >> -----Original Message-----
> >> From: [hidden email] [mailto:beginners-
> >> [hidden email]] On Behalf Of Jens Pall
> >> Sent: Tuesday, March 06, 2007 2:09 AM
> >> To: Squeak Beginners
> >> Subject: [Newbies] Squeak in commercial projects
> >>
> >> Hi
> >>
> >> How can I use Squeak in a commercial closed source project (whole
> image)?
> >>
> >> How about upgrades? I want to be able to send an upgrade to the
> customer
> >> which only contains the changed code.
> >>
> >> Thanks,
> >> JP
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

> Brad Fuller wrote:
>> Jens Pall wrote:
>>> Hi
>>>
>>> How can I use Squeak in a commercial closed source project (whole
>>> image)?
>>
>> Have you seen how to lock down?
>> http://wiki.squeak.org/squeak/518
>>
>
> Yes, I've seen bits and pieces of the lock down procedure but haven't
> been able to successfully lock an image (haven't tried very hard
> though).

> Jens Pall wrote:
>
> This is a step inn the right direction but I'm a bit concerned
>> about upgrades. How would I ship an upgrade without sending the whole
>> image again? Can I somehow export the new/changed bytecode and import
>> it at the customer's site?
>
> Can you not employ a similar procedure as squeaksource? Make your own
> mini SqueakMap that points only to your repo?
>
> Or put a friendly frontend to Monticello pointing to your repo only?
> Maybe you could also send update alerts if the person is online to
> remind them to update.

> Brad Fuller wrote:
> > Jens Pall wrote:
> >
> > This is a step inn the right direction but I'm a bit concerned
> >> about upgrades. How would I ship an upgrade without sending the whole
> >> image again? Can I somehow export the new/changed bytecode and import
> >> it at the customer's site?
> >
> > Can you not employ a similar procedure as squeaksource? Make your own
> > mini SqueakMap that points only to your repo?
> >
> > Or put a friendly frontend to Monticello pointing to your repo only?
> > Maybe you could also send update alerts if the person is online to
> > remind them to update.
>
> But doesn't this imply that the source is downloaded, making it easy
> (easier) to hack the system? I could make the private Monticello
> connection secure, update the system and then delete the source... just
> thinking out loud.

> Blake wrote:
>> On Tue, 06 Mar 2007 12:10:00 -0800, Jens Pall <[hidden email]>  
>> wrote:
>>
>>> As a side note I might mention that our current system is implemented  
>>> in C++ and, if it turns out to be possible with respect to the topic  
>>> of this thread, we are seriously considering porting it to Squeak.  
>>> Croquet will also play a major role as the monitoring / management  
>>> tool.
>>  You may be able to do a partial port, and by keeping some sections in  
>> C++, be able to prevent theft.
>
> Can you elaborate a bit on this point? How would this prevent access to  
> the Smalltalk code in the image?

>> But doesn't this imply that the source is downloaded, making it easy
>> (easier) to hack the system? I could make the private Monticello
>> connection secure, update the system and then delete the source...  
>> just
>> thinking out loud.
>
> Yes - a Monticello package is just a zip file of source code. Sure,  
> you
> can make the transfer "secure" using SSL or whatever - and you can  
> apply
> it and throw it away

> From: Ron Teitelbaum
>
> Hi JP,
>
> OK before answering let me say that these are only suggestions and you are
> responsible for taking suggestions as suggestions.  In other words I can
> not
> be responsible for anything that goes wrong on your system, use my
> suggestions at your own risk.
>
> THE OPINION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> THE
> AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> CONNECTION
> WITH THE OPINION OR THE USE OR OTHER DEALINGS IN SOFTWARE.
>
> I'm sure all that goes without saying but now it is said.
>
> The first question you asked was: how does a system update itself?
>
> Here are the issues as I see them.
>
> 1) A system must be able to ensure that it is updating itself from a
> trusted
> location.
> 2) A system must be able to ensure that only the trusted system can ask it
> to update itself.
> 3) A system must be able to ensure that it can securely store an update
> location.
> 4) A system must be able to securely change the update location.
> 5) All communications must be encrypted.
> 6) A System must be able to verify patches before applying them.
> 7) A System must be able to automatically load the patch.
> 8) A System should be able to update without restarting the application.
> 9) A System must be able to report back success or failure of patch
> installation.
> 10) A System must be able to recover from a failed patch.
>
> Ok so basic caveat, I just made these up and I'm sure I left something
> out.
>
> The second question is how you can limit functionally in your system
> unless
> and until payment is received.
>
> 1) A system must be able to enable features for a single instance and
> prevent those features from being shared to other systems.
> 2) A system could be able to detect features being used inappropriately
> 3) A system could be able to periodically check for permission (trial
> software)
>
> Ok so since I ran out of time I'll try to take each point one at a time
> starting tomorrow.
>
> Does this list help the conversation?  Can you add to the list things that
> you think the system needs to do?
>
> Ron Teitelbaum
> President / Principal Software Engineer
> US Medical Record Specialists
> Squeak Cryptography Team Leader
>
>
>
> > From: Jens Pall
> > Sent: Tuesday, March 06, 2007 3:10 PM
> >
> > Ron Teitelbaum wrote:
> > > Hi JP,
> > >
> > > This is not an easy question.  There are a number of things that you
> > need to
> > > consider.  First you need to decide how secure the update needs to be.
> > If
> > > you are not worried about security then you have a much easier job and
> > many
> > > more options.  In general Squeak is not secure, but it is also not
> less
> > > secure then many other tools that are sent to end users.
> > >
> > > So first answer some questions.
> > >
> > > Is your system likely to be used by people that are interested in
> > cracking
> > > the system?
> >
> > Some of the end-users might try this but most of them will not. They
> > just want a system that works and does its job. We are working with
> > partners who are distributing our software and I know that some of them
> > will try to open up the software, modify it and, in some cases, try to
> > sell it as their own if it is easy to get at the source. If the source
> > is not available and it is a bit hard to get access to the developing
> > interface then I believe this risk is greatly reduced.
> >
> > > Does your system have access to network facilities that attach to
> other
> > > installations of your system?
> >
> > Yes. This is a distributed networked application. It lives and breathes
> > on the network.
> >
> > > Are you concerned that someone might try to build a patch and upload
> > that
> > > code to your system installations?  (i.e. spyware, worms, viruses)
> >
> > Well, not really. Our installations mainly run on private WAN networks
> > owned by the customer but you never know what malicious internal users
> > might do. We plan on being able to run this over the Internet where this
> > is a major concern but will try to limit it by using secure network
> > connections.
> >
> > > Are you trying to prevent users from using features of your system
> > without
> > > authorization?  (i.e. Try before you buy?)
> >
> > Yes. We must be able to issue licenses for using features of the system.
> >
> > > There are no easy answers but I do believe it is a very interesting
> > > discussion.
> >
> > It indeed is and one that needs to be addressed if Squeak is to be
> > seriously considered as a commercial vehicle. It has huge potential in
> > that area if the proper hooks are in place.
> >
> > As a side note I might mention that our current system is implemented in
> > C++ and, if it turns out to be possible with respect to the topic of
> > this thread, we are seriously considering porting it to Squeak. Croquet
> > will also play a major role as the monitoring / management tool.
> >
> > > Ron Teitelbaum
> > > President / Principal Software Engineer
> > > US Medical Record Specialists
> > > www.usmedrec.com
> > > Squeak Cryptography Team Leader
> > >
> > >
> > >> -----Original Message-----
> > >> From: [hidden email] [mailto:beginners-
> > >> [hidden email]] On Behalf Of Jens Pall
> > >> Sent: Tuesday, March 06, 2007 2:09 AM
> > >> To: Squeak Beginners
> > >> Subject: [Newbies] Squeak in commercial projects
> > >>
> > >> Hi
> > >>
> > >> How can I use Squeak in a commercial closed source project (whole
> > image)?
> > >>
> > >> How about upgrades? I want to be able to send an upgrade to the
> > customer
> > >> which only contains the changed code.
> > >>
> > >> Thanks,
> > >> JP
> >
> >
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

> From: Emilio Oca
>
> > Hello all,
> >
> > Nobody updated my list!  I guess this could mean two things either my
> list
> > is perfect, or nobody cares.  Please let me know if my comments are not
> > helpful so that I don't spend too much time on it.
> Please continue.
> I am just reading but it is useful and interesting so far.
>
> Emilio
>

> From: Bert Freudenberg
>
> On Mar 7, 2007, at 8:57 , [hidden email] wrote:
>
> > Hi!
> >
> > Just a note - decompiling from bytecodes is very easy in Squeak. The
> > only thing missing is the original indentation and any comments. But
> > everything else is there. Just so you know.
>
> Well, if you're really concerned about decompiling, just mangle the
> selectors. As long as you are not constructing Symbols at runtime
> (#asSymbol, #intern:) this works perfectly well. Same for class names
> and instance variable names.
>
> > Locking down the image is of course doable - so that you can't easily
> > get to the tools etc - but there are of course ways to go around that
> > too. For example, I guess you can use an image file analyzer (there is
> > at least one I think) or hack a VM to do stuff when the image is
> > loaded.
>
> Sure. But if the names are mangled this is about as much fun as
> reverse engineering machine code. No wait, the tool support is still
> better ;)
>
> >> But doesn't this imply that the source is downloaded, making it easy
> >> (easier) to hack the system? I could make the private Monticello
> >> connection secure, update the system and then delete the source...
> >> just
> >> thinking out loud.
> >
> > Yes - a Monticello package is just a zip file of source code. Sure,
> > you
> > can make the transfer "secure" using SSL or whatever - and you can
> > apply
> > it and throw it away
>
> Well, you certainly would want to encrypt and sign the patch. If you
> are *that* paranoid I'd not even use MC but just image segments.
>
> It's all a question of cost/value. I for one would be more concerned
> about preventing malicious code injection than the possibility of
> reverse engineering. But you have to weigh that yourself.
>
> - Bert -
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners