Closed Bug 402771 Opened 14 years ago Closed 14 years ago

improve dialog UE for web-based protocol handling

Categories

(Core Graveyard :: File Handling, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dmosedale, Assigned: dmosedale)

References

Details

(Whiteboard: [proto])

Attachments

(1 file, 1 obsolete file)

Right now, even URIs which have a system default handler (e.g. the local Skype application registers a handler for skype: URIs) pop up the content dispatch chooser and ask the user if they want to use that application or select another.
This seems bad.

We could address this by making any protocol which has a system default handler always use that by default.  This would have the disadvantage of making protocols where we do have web-based handlers less discoverable.

It was pointed out in the security review, that if you accept a registration for 
a new web-based protocol, chances are pretty good that you're going to want to use it, even if you've been using the system default up until now.

Currently, the "always ask" attribute pops up the dialog with the "Remember my choice for skype links" checkbox unchecked.  We could add another behavior (not yet sure about the best code architecture for this) which pops up that dialog with the checkbox checked, and resets a handlerInfo to this behavior everytime the set of web-based handlers changes for a given protocol.  This would typically include Firefox version updates, at least in the cases where they inject new web-based handlers into the profile.

We might be able to get away with not adding another possible state to the preferences menu, but just displaying "always ask" for this case, even though it's really "ask once".

Thoughts?
Flags: blocking1.9?
Whiteboard: [proto]
For the local application case, the dispatch dialog replaces a security dialog intended to prevent exploitation of rarely-used local apps.  So I don't think we can just get rid of it.  Making it "ask once" (checking the "remember" box by default) might be ok.
Priority: -- → P2
Priority: P2 → P1
The logic here, per beltzner, is that 

a) if it's really that scary, we shouldn't be doing it at all, in large part because:
b) people tend to just click through dialogs (the "Whatever button" effect)*

* I do, however, seem to remember seeing a reference to a paper not too long ago claiming that in fact these sorts of dialogs do deter a fairly significant number of non-technical users from doing scary stuff, so one could imagine reasonable arguments against the above.

I don't have a terribly strong opinion here, because I think cogent arguments can be made either way, and I don't have a great feel for what's ultimately "best".

The current plan is to simply remove the warning functionality.  I'm pretty sure we discussed that at the review, but it sounds like I didn't communicate it sufficiently clearly.  Doing this will simplify the already complex code somewhat.


The dialog was added (in bug 258802) without a specific security-related reason, so I was wrong in comment 1.  I guess I'm ok with just removing it, then.

What do other browsers do nowadays?
Duplicate of this bug: 403100
>Currently, the "always ask" attribute pops up the dialog with the "Remember my
>choice for skype links" checkbox unchecked.  We could add another behavior (not
>yet sure about the best code architecture for this) which pops up that dialog
>with the checkbox checked

In terms of the user experience: I am in favor of this approach since it feels like a good balance between discoverability (user sees that they can now select a web-based handler) and streamlining the interaction in the future (remember my choice is checked by default).
(In reply to comment #0)
> Currently, the "always ask" attribute pops up the dialog with the "Remember my
> choice for skype links" checkbox unchecked.  We could add another behavior (not
> yet sure about the best code architecture for this) which pops up that dialog
> with the checkbox checked, and resets a handlerInfo to this behavior everytime
> the set of web-based handlers changes for a given protocol.  This would
> typically include Firefox version updates, at least in the cases where they
> inject new web-based handlers into the profile.

Echoing Alex's +1 for the behaviour. An added nice-to-have would be that we order the list of applications as per his mockup, which is to say:

 - when dialog appears first for a protocol, list the default system handler first and selected by default (if it exists)
 - on subsequent dialog appearances, list handlers in MRU fashion with last used selected
Flags: blocking1.9? → blocking1.9+
Keywords: uiwanted
This patch creates a hasNewEntry attribute for nsIHandlerInfo.  This gets set when new web handlers get injected as the handler service starts up, as well as when a new web-based handler app registration is accepted.

When a given protocol handler is accessed, if hasNewEntry is set, and protocol handling dialog will appear.  Except when this handler has already been explicitly set by the user to always ask, the "remember my choice for XXX links" checkbox will default to checked.  If the user presses "Accept", the hasNewEntry state is cleared, if they "Cancel", it is left untouched.

Note that the dialog now always defaults to having the existing preferred application selected.
Attachment #288740 - Flags: ui-review?(beltzner)
Attachment #288740 - Flags: superreview?(mconnor)
Attachment #288740 - Flags: review?(cbiesinger)
Whiteboard: [proto] → [proto] [has patch] [needs ui-r, r, sr]
(In reply to comment #3)
> The dialog was added (in bug 258802) without a specific security-related
> reason, so I was wrong in comment 1.  I guess I'm ok with just removing it,
> then.

On the other hand, http://www.neilturner.me.uk/2004/Sep/12/external_protocol_whitelisting.html claims that external protocol whitelisting was added partly in response to the shell: issue (bug 250180), which was solved by blacklisting shell:.
Sorry I missed the initial comment. We can't just launch local protocol handlers willy-nilly just because some web page has a link to one. We added the confirmation for a reason, and having it mitigated problems in the last several months of URI-based attacks.

mailto: and http: were whitelisted because they're such common and usually safe schemes, and unfortunately those are exactly the ones affected by the invalid-%-escape WinXP+IE7 bug.

If IE had taken a similar approach the firefoxurl: thing wouldn't have been a problem for us, instead of becoming an emergency 2.0.0.5 issue. MS is considering adding a confirmation dialog before launching external handlers, or maybe just the uncommon ones like us.

Because we took this approach Firefox, unlike IE, could not be directly used to exploit Trillian and Skype when the double-quote command-line exploits came out.  (Because of mailto: they could exploit Thunderbird, and that had plenty enough functionality for attackers -- we fixed the entire class of bugs by escaping double-quotes in FF2.0.0.6)

I'm all for giving the user the ability to say "I use this all the time, stop bugging me" for given handlers, but given the many "URL Protocols" registered on a typical Windows box, many of which have no business being exposed to the internet, we need to put up a speedbump for never or rarely used schemes.

Unless we want to simply block them and require the user to configure them through options/prefs for each one they want to use. In that case I'm fine letting users use those with no further interruptions.
In fact I might prefer an infobar/popup-blocking approach to the current modal dialog -- making the default action that we don't load the content rather than a potentially unsafe click-through that can be used to DoS users or browbeat them into clicking yes. But maybe that will make it too hard for users to figure out their iTunes links.
Using an infobar would make registered protocols harder to use from the Web than registered file types, which would be odd.  Registering a protocol is much closer to saying "please expose me to the internets" than registering a file type is.
(In reply to comment #8)
> On the other hand,
> http://www.neilturner.me.uk/2004/Sep/12/external_protocol_whitelisting.html
> claims that external protocol whitelisting was added partly in response to the
> shell: issue (bug 250180), which was solved by blacklisting shell:.

Note that the current proposal/patch effectively makes everything unknown whitelisted, but leaves the blacklisting intact, so users would still be protected from the shell: attack.

(In reply to comment #9)

> If IE had taken a similar approach the firefoxurl: thing wouldn't have been a
> problem for us, instead of becoming an emergency 2.0.0.5 issue. 

Depending on how many people we think treat the current dialog as a "whatever" button.

> I'm all for giving the user the ability to say "I use this all the time, stop
> bugging me" for given handlers, but given the many "URL Protocols" registered
> on a typical Windows box, many of which have no business being exposed to the
> internet, we need to put up a speedbump for never or rarely used schemes.

It would certainly be easy enough to make hasNewEntry be set by default for any local handler that hasn't been seen before; and it doesn't seem horribly onerous.  This would effectively be leaving whitelisting in place, and would require some different UI which actually talks about a warning; the current one does not.

> Unless we want to simply block them and require the user to configure them
> through options/prefs for each one they want to use. 

This seems user-hostile.  I'm against this.

(In reply to comment #10)
> In fact I might prefer an infobar/popup-blocking approach to the current modal
> dialog -- making the default action that we don't load the content rather than
> a potentially unsafe click-through that can be used to DoS users or browbeat
> them into clicking yes. But maybe that will make it too hard for users to
> figure out their iTunes links.

This seems like a pretty tall barrier to me.

(In reply to comment #11)
> Using an infobar would make registered protocols harder to use from the Web
> than registered file types, which would be odd.  Registering a protocol is much
> closer to saying "please expose me to the internets" than registering a file
> type is.

True, although it's not the user registering a protocol, but some local app doing so on the user's behalf.

I'm interested in jonath's thoughts here; adding him to the CC.
Keywords: uiwanted
(In reply to comment #12)
> > If IE had taken a similar approach the firefoxurl: thing wouldn't have been
> > a problem for us, instead of becoming an emergency 2.0.0.5 issue. 
> 
> Depending on how many people we think treat the current dialog as a "whatever"
> button.

Except that an attack can't be silent, so word gets out quickly and tempers the attack. Because there's something users can do to avoid becoming a victimpress articles focus on what they should do, and of course most focus is on the buggy exploitable app rather than Mozilla. And if we have this speed-bump between the web and the exploitable app but other browsers do not this will reinforce the message "you're better off using Firefox".

> It would certainly be easy enough to make hasNewEntry be set by default for
> any local handler that hasn't been seen before; and it doesn't seem horribly
> onerous.  This would effectively be leaving whitelisting in place,

But only the first time you see one? For most handlers I want Firefox to ask every time. If I'm expecting the external handler request I'll approve it, but otherwise it's a pretty good flag that something suspicious is going on.

> > Unless we want to simply block them and require the user to configure them
> > through options/prefs for each one they want to use. 
> 
> This seems user-hostile.  I'm against this.

If they can't use it, they can't get hacked by it. :-)


> (In reply to comment #10)
> > In fact I might prefer an infobar/popup-blocking approach to the current modal
> > dialog -- making the default action that we don't load the content rather than
> > a potentially unsafe click-through that can be used to DoS users or browbeat
> > them into clicking yes. But maybe that will make it too hard for users to
> > figure out their iTunes links.
> 
> This seems like a pretty tall barrier to me.
> 
> (In reply to comment #11)
> > Registering a protocol is much closer to saying "please expose me to the
> > internets" than registering a file type is
> True, although it's not the user registering a protocol, but some local app
> doing so on the user's behalf.

It's _close_ to saying "expose me", except for the ones that were not designed to be exposed and all the ones the user has no idea are there and wouldn't want exposed if they knew.

For example, I might occasionally use callto: (launches NetMeeting on Windows) for prearranged conferencing, but if I'm a TOR user I don't want any random site being able to initiate a NetMeeting callback to the specified URL. NetMeeting callto: URIs might be 100% hackproof and I still don't want someone else controlling when I make that connection.
Yeah, it seems to me that there are at least 3 different scenarios here that are relevant:

 - protocols like mailto:, where I use them all the time, don't want to be prompted every time
 - protocols like skype:, where I am aware of them and their consequences, and may or may not want to be prompted
 - protocols like firefoxurl:, where I was unaware of their existence, and don't know what is going on

AIUI, the approach dmose is suggesting is that we:

 - Dialog them
 - With an "Always do this for future skype: links" checkbox (which defaults unchecked)
 - Reset that flag whenever the available set of handlers for a protocol grows, which should be rare, and likely means the user is actively thinking about changing how they are handled

I think this deals nicely with the mailto: class of protocols, because it lets me turn off nagging and fast path common stuff, but also means that if I decide to start using GMail instead of Thunderbird, I get the prompt again, which I probably should.

I think it deals nicely with the skype: class of protocols, because the result of that action will be surprising to me if I wasn't expecting it, and if the browser did nothing to indicate it might be coming.  If I'm not a technical person, and use skype rarely, clicking a link and seeing skype start loading might feel very much like something bad is happening, my computer's been taken over, what-have-you.  OTOH, if I am a skype-savvy teen or something, I'll turn off the warning, and skype becomes another mailto.

In the case where something untoward is happening, I think dveditz is right that having that dialog there does give us a way to build an attack-mitigation message around "don't click that box and you'll be fine.  Hooray that it didn't do anything automatically!"  The dialog on its own might not be enough to scare people off naively, and in a case like the firefoxurl one, the app being launched is one they probably trust, so in reality the proposed approach will not eliminate the risk of bad protocol handling, but again, it at least gives us something to educate about while an incident is live.

This assumes that I am understanding the proposed behaviour correctly in all cases, though.  :)
OK, I'm finding dveditz' argumentation convincing.  In particular, I hadn't thought of the callto: privacy example.  However, this is only different from a mailto: if implementors don't prompt before actually making the call.  The general case for mailto: is that all implementors do prompt rather than just immediately sending.

(In reply to comment #14)
>  - protocols like skype:, where I am aware of them and their consequences, and
> may or may not want to be prompted

This is an interesting example, because regular skype users are likely to be aware of the general consequence of making a call, but may not be considering the privacy implications when they check the checkbox.

> AIUI, the approach dmose is suggesting is that we:
> 
>  - Dialog them
>  - With an "Always do this for future skype: links" checkbox (which defaults
> unchecked)

I was actually suggesting that they default to checked, meaning they'd only be shown once unless the user explicitly unchecked them.

However, what you propose is essentially identical to faaborg's original design.

I think the interesting thing here is that we can't know the implications of any particular system registered protocol handler a priori, so after giving this more thought, the "not on the whitelist defaults to unchecked" (i.e. what you and faaborg suggest) seems more responsible to me, while not being horribly onerous.
Whiteboard: [proto] [has patch] [needs ui-r, r, sr] → [proto] [has patch] [needs feedback beltzner]
Attachment #288740 - Flags: superreview?(mconnor)
Attachment #288740 - Flags: review?(cbiesinger)
Comment on attachment 288740 [details] [diff] [review]
add "show once" behavior at appropriate times, v1

ui-r=beltzner with the following change:

 - default the "[ ] Always use" checkbox to off
 - always reset the "[ ] Always use" checkbox to off when a new protocol handler has been added (I think it already does this)

I've been taking too long writing the big reply to a lot of the points brought up here, just unblocking dmose (he and I have talked) and will circle around to fully respond later today (I hope!)
Attachment #288740 - Flags: ui-review?(beltzner) → ui-review+
Whiteboard: [proto] [has patch] [needs feedback beltzner] → [proto] [needs new patch]
This patch:

* goes back to the existing behavior of never pre-checking the alwaysAsk box
* moves the system default handler to first in the list
* automagically selects the last-used handler and ensures that it's in view, as per beltzner's earlier request

Carrying forward ui-r.
Attachment #288740 - Attachment is obsolete: true
Attachment #290638 - Flags: ui-review+
Attachment #290638 - Flags: review?(gavin.sharp)
Whiteboard: [proto] [needs new patch] → [proto] [needs review]
> - default the "[ ] Always use" checkbox to off

I'm concerned that this will worsen our first run experience (I suppose technically second run) for all the users who hate that they see this dialog every time, but don't take the effort to select the always use checkbox.  Kind of a less extreme version of when people hated the flashing 12 on their VCRs. 
(In reply to comment #18)
> I'm concerned that this will worsen our first run experience (I suppose
> technically second run) for all the users who hate that they see this dialog

Yes, I understand that, and that's why back in comment 1 and comment 6 I advocated for the same behaviour. However, follow-up comments (see comment 14 as a good example) convinced me that creating a situation where a user can get stuck launching a third-party app for some random protocol after hitting "OK" the first time.

I agree that it's sub-par, but the security concern has merit, here, and the "don't show me this again" pattern is pretty commonplace if, indeed, annoying.

We could try to special-case certain protocols where we know that the user will likely *always* want to use the same handler (ie: emial), but then we get inconsistent behaviour. So at the end of the day, leaving the box unchecked was the best option.

(this is basically the follow-up I'd promised earlier, fwiw)
Whiteboard: [proto] [needs review] → [proto] [needs review gavin]
Attachment #290638 - Flags: review?(gavin.sharp) → review+
Checked in.
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: uiwanted
Resolution: --- → FIXED
Whiteboard: [proto] [needs review gavin] → [proto]
Attachment #290638 - Attachment description: improve ue, v2 → improve ue, v2 (checked in)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.