Security for launching from URL

[Eben Eliason]

On Mon, Jul 7, 2008 at 4:59 PM, Noah Kantrowitz <noah at coderanger.net> wrote:
> On Jul 7, 2008, at 12:52 PM, Eben Eliason wrote:
>
>> On Fri, Jul 4, 2008 at 6:42 PM, Ivan Krstić
>> <krstic at solarsail.hcs.harvard.edu> wrote:
>>>
>>> That said, the URI handler approach should be used sparingly. It's one
>>> thing to allow starting an audio player by clicking an MP3 link in the
>>> browser, and another to arbitrarily execute code (e.g. through an
>>> execution environment such as Pippy or eToys) from a web page with a
>>> single click. While Bitfrost is designed to mitigate the side effects
>>> of arbitrary code execution, it's very unwise to make it trivial for
>>> the user to trigger such execution unknowingly.
>>
>> I really don't see anything wrong with injecting a modal alert,
>> displayed by Sugar, into this process if we must.  Clicking on an mp3
>> in Browse would reveal this alert, and ask for confirmation that the
>> user wishes to open it.  It would, of course, offer a list of
>> activities which support its mime-type (assuming there are more than
>> one).  It could potentially include a way to set the default handler
>> as well, such that the next time it is revealed for the same mime-type
>> a different default is chosen.  I recognize that we try at all costs
>> to eliminate this form of dialog, but I also recognize that we might
>> not want to allow an activity to arbitrarily launch other activities
>> without the user's consent.
>
> Repetitive modal dialogs are useless bordering on harmful when was the last
> time you read an IE dialog carefully.

In my post I acknowledged this fact, and I certainly remain cognizant
of it.  We've tried very hard to prevent them.  However, if the cost
of eliminating them completely is to prevent making this type of
inter-activity functionality work smoothly, I'll go for the dialog.
Basically, my reasoning in this circumstance is that the modal dialog
is actually a /better/ user experience than being dumped into the
Journal and left to fend for yourself (not knowing which button to
press, etc.)

Additionally, I think that the dialog is slightly less awful for two
reasons.  First, it will likely be the case that kids will simply
click OK or press enter instinctively anytime they explicitly click on
a link or button with the intent of launching something else.
However, I would expect them to think twice about it if they were
automatically presented with one or many of these dialogs without
taking an action to reveal it, which is a primary reason we need it at
all.  Second, I think we can actually mitigate the level of awful by
providing other useful actions, taking it a step above "Did you really
mean to do that thing you told me to? [yes] [no]" dialogs.  In
addition to the "Cancel this launch operation" and "Yes, really launch
this URI with the default activity" buttons, we can offer "Launch this
URI with a non-default activity", "Keep object pointed to by URI in my
Journal" (for non-local URIs), and "Show object pointed to by URI in
my Journal" (for local URIs).  Finally, the possibility of adding a
"Edit the object pointed to by this URI such that it updates in the
activity I'm launching it from" option could make it much more
powerful in the future.

I think that a variety of useful user-facing options for how to handle
this will make the dialog less like an arbitrary
just-click-ok-and-curse-this-machine-for-asking-me-useless-questions
type of experience.

- Eben