Security for launching from URL

[Bert Freudenberg]

Am 07.07.2008 um 23:22 schrieb 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.


At the risk of being ignored again I still think a menu instead of a  
dialog would be less intrusive.

- Bert -