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

[Eben Eliason]

On Fri, Apr 11, 2008 at 3:52 PM, Jameson Chema Quinn
<jquinn at cs.oberlin.edu> wrote:
>
>
>
> On Fri, Apr 11, 2008 at 1:37 PM, Eben Eliason <eben.eliason at gmail.com>
> wrote:
> >
> > On Fri, Apr 11, 2008 at 11:15 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> > >
> > >  On 11.04.2008, at 07:12, Eben Eliason wrote:
> > >  > On Fri, Apr 11, 2008 at 10:03 AM, Jameson Chema Quinn
> > >  > <jquinn at cs.oberlin.edu> wrote:
> > >  >> I'm assuming that the data would only go one way. In that case, the
> > >  >> permission would be, an app without P_NETWORK would not be able to
> > >  >> request
> > >  >> opening of apps with P_NETWORK. No new permissions needed, just
> > >  >> careful
> > >  >> attention to the ones we have.
> > >  >
> > >  > Sorry, I'm not sure I understand this particular requirement.  The
> > >  > activity launched will be completely isolated from that which
> > >  > requested it.  Why would we need to make this statement hold?  If I
> > >  > have, for instance, chosen to trust my web browser to use P_NETWORK,
> > >  > then why should it matter that it was asked to launch by something
> > >  > that didn't?
> > >
> > >
> > >  Because a malicious activity could encode a private document as URL
> > >  and have the browser go to that URL, which would send it to any server
> > >  on the internet.
> >
> > Well, isn't that interesting.  You have a point, there, and I don't
> > see any good way around it.
> >
> >
>
> One way would be to launch an instance of Browse without P_NETWORK (and, of
> course, with a virgin configuration, which was deleted after running). You
> could view your document locally, and P_NETWORK would not be violated.
>
> If, in fact, this use case is considered important enough to be worth the
> effort. I'd say that watching P_NETWORK as I suggested originally would be a
> good enough first-pass solution that probably we'd never get a second pass.

I think that opening a non-local URL is an equally desired use case.
Passing links to friends via chat, or wanting to click them from
within documents such as Write or downloaded pdfs is going to happen a
lot.

Ben's suggestion, in my mind doesn't really solve the exploit brought
up earlier in my mind, but merely passes it off.  The Journal is in no
better position to convey whether or not the link that the object
represents is malicious or not.  In fact, I don't see a way around
this at all, except perhaps to show some kind of "caution" message
when an activity which does *not* have P_NETWORK privileges attempts
to launch one that does, but I doubt that would really be of benefit
to the kids.

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?

- Eben


>
> >
> >
> > Well, perhaps a permission is in fact needed then.  Of course, I still
> > see that there could be worth in a service which allows activities to
> > launch others.  Perhaps the Develop activity eventually wants to
> > launch an SVG editor for its icon.  Perhaps Write wants to be able to
> > embed links to other projects (as was initially mentioned as the use
> > case) for writing tutorials.  I'm not sure how to accomplish this.
> >
> > - Eben
>
> Note that these use-cases can be done with the P_NETWORK scheme - assuming
> that, instead of writing your tutorials in Write, you do it in Blog (which
> may indeed by a special case of Browse), which makes more sense anyway.
> (Yes, I am proposing a url format for activity launching - this is safe,
> since the originating app would have P_NETWORK.)
>
> Jameson
>
>