[Etoys] Key generation

[Andreas Raab]

Hi Guys -

I just had a chat with Scott about the issues of key generation etc. It 
is important to understand what this mechanism is good for to understand 
what to do about it. So here is some history: In the early days of this 
mechanism at Disney we were concerned about someone slipping some code 
into a project file, get you to click on it and cause some harm. We 
decided to draw a line by using the sandbox model which disables access 
to files, disallows saving the image etc.

However, one of the issues that we (thought we) needed to deal with was 
how to determine whether to run in trusted or in sandboxed mode. We 
decided to do that by each machine generating its own private/public key 
pair and simply sign all projects. This allows us to determine when we 
load a project whether it was created on the machine and kick in the 
sand box if needed.

That was the theory. The praxis turned out differently. If there is a 
single thing that I feel we got really, really right for dealing with 
security was to enable the ability for users to drag and drop content 
from the OS onto Squeak and have it accept it even in sandboxed mode. 
Because of that mechanism, we really *never* had a need to run in 
trusted mode since anything an eToy user would ever do with files can be 
represented by drag and drop.

On OLPC we should draw the appropriate consequences from that 
experience. In short that means that the sandbox should simply always be 
on. And if we turn on the sandbox then we don't need any signing. 
However, since we're so close to the deadline I wouldn't recommend 
trying to get this done for this build. What I would recommend is the 
following:

* For this build only: Ship with a precomputed Squeak.keys file. The 
implication is that the machines in this build are indeed vulnerable to 
attacks if you load an eToy from an external source but since exposure 
of BTest-1 will be so limited I don't expect that to be a problem at all 
(basically all I expect people to do in reality is to show off the 
tutorial and examples).

* Right after the deadline: Turn on the sand box and turn off all the 
other security checks. There is really no reason for those if we're 
always running in the sandbox.

* Some time later: Figure out what the logical equivalent to the DnD 
interaction on OLPC would be. This depends largely on OLPC's view on how 
applications/activities exchange data; it could just be the clipboard.

Cheers,
   - Andreas