[sugar] Clicking links (was Re: sugar roadmap)

[Jameson "Chema" Quinn]

On Fri, Apr 11, 2008 at 2:16 PM, Benjamin M. Schwartz <
bmschwar at fas.harvard.edu> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Eben Eliason wrote:
> | In fact, this exploit could happen even without a launcher service.
> | Any activity that wants to could write the users private data to the
> | disk in a URL format, as an object, and give it a fun preview image.
> | When the later discovers and becomes curious about it, she'll open it
> | and send out her private data to whatever site the other activity
> | wanted.  Is there something in place to prevent this that I'm unaware
> | of?
>
> I would argue that there is no way around this, and that it should not be
> seen as an exploit.  Users must understand that any object produced by an
> activity instance can potentially contain any information available to
> that instance at that time.
>
> The best we can do is to show the user which instances have written data
> in each object, and which objects those instances had access to.  That
> list is the list of all private data that could potentially be enclosed in
> each object.  This is relevant not only to HTTP access but also to
> Sharing.
>

What you are describing is a clear position, but it does not sound like
bitfrost to me. The bitfrost paradigm is that security is maintained without
any "users must understand" requirements. This could be maintained if:

1. There is a "private" attribute of journal objects.

2. Journal objects which are "private" are encrypted at some time before
being backed up (possibly before being written to fs).

3. Journal objects which are "private" will not open with any P_NETWORK
activity  except the same one which created them (or will open with a
special P_NETWORK-crippled, zero-configuration instance of that activity).
(Yes, "the same activity which created them" needs better definition, I
would accept "bundles signed by the same key" personally but that is another
discussion)

4. All objects created by non-P_NETWORK activities are "private" by default.

5. There is of course some way in the journal for a user to remove the
"private" flag from an object.

At that point, "the way to open another activity is to send the user to an
instance in the journal to click it open" is perfectly compatible with
security.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080411/8846b2f2/attachment-0001.htm