Security for launching from URL
bert at freudenbergs.de
Mon Jul 7 18:01:29 EDT 2008
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
>>>> of arbitrary code execution, it's very unwise to make it trivial
>>>> 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
>>> 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-
>>> 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
> type of experience.
At the risk of being ignored again I still think a menu instead of a
dialog would be less intrusive.
- Bert -
More information about the Devel