Closed Bug 561177 Opened 14 years ago Closed 13 years ago

Remove countdown from add-on install dialog

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: jboriss, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

mock of proposed dialog
61.98 KB, image/png
Details 
and in-line entered add-ons

(only countdown for external sites, and even then a whitelist would be great)
Component: Plugins → Installer: XPInstall Engine
Product: addons.mozilla.org → Core
QA Contact: plugin-listings → xpi-engine
Okay I'm just very, very roughly guessing what component that could be in. CCing mossop: This is not an AMO request, the install countdown is in-client.
We have spoken to dveditz about this previously and I think the general take was this:

We already have a whitelist for which sites are even allowed to just pop open an install dialog. For those sites it is presumably safe to not use a countdown. For other sites users have to go through the "Allow" button to even see the dialog so again a countdown seems unnecessary.

So I think we can get rid of this. Dan?
Component: Installer: XPInstall Engine → Add-ons Manager
Product: Core → Toolkit
QA Contact: xpi-engine → add-ons.manager
Version: unspecified → Trunk
Jesse was one of the main proponents for having this in the first place
This delay is intentional, it plays the role of an "Are you sure?" prompt. Therefore I expect this bug will be resolved WONTFIX by respect to the plain-vanilla toolkit-as-distributed. (But I'm not the one who decides this.)

The delay can optionally be removed by means of one of the very many functions of the "MR-Tech Toolkit" extension (for Firefox, Thunderbird, SeaMonkey, Sunbird, and maybe others), or IIUC of its (less powerful or less bloated depending on POV) predecessors, "Nightly Tester Tools" and "Local Install". (Personally I prefer to keep the delay enabled in all cases, but other people — other choices.)
OS: Mac OS X → All
Hardware: x86 → All
The delay was added due to UI race conditions (see bug 162020), so removing the delay for AMO is pretty close to letting AMO  install an addon without permission from the user.  I don't think we trust AMO that much:

* AMO is a complex site that may have XSS, CSRF, clickjacking, or backend holes.
* AMO includes many addons that may have security flaws, and old versions of addons that do have security flaws.

Instead, we should find ways to make installation less annoying that don't make it less safe.  See bug 416605 and bug 363142 for some ideas.

For in-client installs (not using the AMO web site), see bug 359475.
(In reply to comment #5)
> * AMO is a complex site that may have XSS, CSRF, clickjacking, or backend
> holes.

I think when we discussed this idea with dveditz, we mentioned the idea of a post-install hash check that would verify the add-on that was downloaded is the add-on that is hosted on AMO based on the GUID and version read from install.rdf.

If there are backend holes discovered in AMO, we'll have bigger problems than add-ons not having a countdown dialog.


> * AMO includes many addons that may have security flaws, and old versions of
> addons that do have security flaws.

AMO would only use the dialog-less install for reviewed add-ons. All other add-ons would get the normal dialog (without the countdown).
Isn't there an about:config pref for this?
We talked about this in the Add-ons Manager meeting again today and want to push on this for Firefox 4.

* The yellow bar makes the countdown irrelevant for sites not whitelisted.

* Sites that are whitelisted have been trusted by the user and aren't likely to have a "click as fast as possible" game to trick the user. Additionally, very few sites should be added to whitelists now, as yellow bar only offers Allow Once functionality.

The experience of installing add-ons is severely hampered by this countdown timer and the folks working on Add-ons Manager redesign do not see a reason to keep it. If there is a legitimate reason that is not covered by the two points above, please comment ASAP.
Summary: Remove 3 second countdown when downloading add-ons from addons.mozilla.org → Remove countdown from add-on install dialog
> The yellow bar makes the countdown irrelevant for sites not whitelisted.

No, it just means attackers have to convince you to make one more keystroke or click.  That's not very hard.

> Sites that are whitelisted have been trusted by the user

Not to the point that the entire AMO frontend should be part of Firefox's attack surface at all times.

Retaining the security dialog but removing its delay would leave the security-usability tradeoff in a place that doesn't seem pareto-optimal.  (What's the point of having a dialog if it doesn't protect users from anything?)

* Putting back a delay of 1s, like I suggested in bug 416605, would remove most of the security hurt without removing much of the usability benefit.

* Removing the dialog entirely for AMO would give even more usability benefit.

If we could be careful with the attack surface we present, I might be ok with the latter, but we don't have time for it in Firefox 4.  We'd need the browser and AMO to cooperate somehow to prevent various types of clickjacking, and that's a very hard problem.  And we'd need to ensure only a small part of AMO is part of the attack surface.

For Firefox 4, I think all we have time for is lowering the delay to match what other browsers use.
There is also the possibility of malicious sites executing something like window.open("amourl"), in which case, the user won't be protected from these kinds of attacks unless the add-on is reviewed quickly.
(In reply to comment #9)
> > The yellow bar makes the countdown irrelevant for sites not whitelisted.
> 
> No, it just means attackers have to convince you to make one more keystroke or
> click.  That's not very hard.

Can you describe this further? Are you saying they would trick the user into clicking Allow in the yellow bar by just asking them to do so? If that's the case, they can just ask the user to click Install Now in the xpinstall dialog too.

> > Sites that are whitelisted have been trusted by the user
> 
> Not to the point that the entire AMO frontend should be part of Firefox's
> attack surface at all times.

The only thing the countdown prevents is drive-by installs. We're not proposing to remove any confirmation at all in this bug, just to remove the countdown. If AMO's frontend was compromised through XSS or some other client-side vulnerability, the only way the countdown saves us is if the attacker makes it look like AMO wants you to play a speed clicking game.
(In reply to comment #10)
> There is also the possibility of malicious sites executing something like
> window.open("amourl"), in which case, the user won't be protected from these
> kinds of attacks unless the add-on is reviewed quickly.

Can you explain this further? I don't understand the concern. The whitelist is based on the URL you're on, not the URL of the .xpi file.
(In reply to comment #11)
> (In reply to comment #9)
> > > The yellow bar makes the countdown irrelevant for sites not whitelisted.
> > 
> > No, it just means attackers have to convince you to make one more keystroke or
> > click.  That's not very hard.
> 
> Can you describe this further? Are you saying they would trick the user into
> clicking Allow in the yellow bar by just asking them to do so? If that's the
> case, they can just ask the user to click Install Now in the xpinstall dialog
> too.

I'm talking about a bug 162020-style attack that involves both the yellow bar and the dialog.  Something where the user decides to click somewhere and then press Enter -- the click happens to land on the yellow bar button and the Enter accepts the dialog.

> > > Sites that are whitelisted have been trusted by the user
> > 
> > Not to the point that the entire AMO frontend should be part of Firefox's
> > attack surface at all times.
> 
> The only thing the countdown prevents is drive-by installs. We're not proposing
> to remove any confirmation at all in this bug, just to remove the countdown. If
> AMO's frontend was compromised through XSS or some other client-side
> vulnerability, the only way the countdown saves us is if the attacker makes it
> look like AMO wants you to play a speed clicking game.

The "speed clicking game" was just an example.  An attacker could come up with something more convincing based on ordinary web annoyances (dhtml popups, having to log in, having to agree to a ToS) and interactions (scrolling).

Removing the delay is effectively removing the confirmation in an attack scenario, while leaving the confirmation in the non-attack scenario.  The same goes for requiring multiple clicks, more or less.

It's not just XSS I'm concerned about.  I'm also concerned about clickjacking, where the attacker's site redirects to AMO, or closes a tab covering AMO, at just the right time.  It's very hard for a web site to defend against this kind of thing, and an AMO that can essentially install extensions without user permission would have very high stakes.
Attached image mock of proposed dialog — 
This is a mock of what we want the new dialog to look like. This should address a number of your concerns, as:

* once the dialog opens, clicking anywhere not on it will close it
* if a tab was opened/closed, it would disappear

If that is not sufficient in itself, you are okay with reducing the countdown to 1 second?
You raise a good point, which is that if AMO is allowed to pop the dialog, it needs to be non-modal or one-per-click to prevent dialog-spamming attacks.  Non-modal is probably the way to go.

Changing from a dialog to a panel doesn't take care of my other concerns, but keeping a 1s delay would.  (I think 1s is ok, but I'd like to have Johnath and dveditz on board, and know what other browsers do.)

Comments on the panel:

  * Please make the background opaque, so the site can't inject additional things into the panel.

  * I wish the dialog/panel wasn't so full of site-supplied pieces (icon, extension name, author, hostname (to some extent)).  There's a lot of room for sites to try to make the dialog/panel misleading, like in
http://www.squarefree.com/2010/07/14/untrusted-text-in-security-dialogs/ .

  * I'm having trouble thinking of a good button label.  "Install" would be good in that users know that installing untrusted software is dangerous, but "Install" is also the button label in many updaters.  "Add to Firefox" or "Install Add-on" makes it sound less dangerous than installing new software.
(In reply to comment #15)
>   * Please make the background opaque, so the site can't inject additional
> things into the panel.
> 
Faaborg says these are only 10% transparent, but can we keep it consistent with the other doorhanger styles and then if we find it's possible to get something to look like it's part of the message, go from there? Any problems found would be problems for all the other notifications/requests as well (e.g., geolocation).

>   * I wish the dialog/panel wasn't so full of site-supplied pieces (icon,
> extension name, author, hostname (to some extent)).  There's a lot of room for
> sites to try to make the dialog/panel misleading, like in
> http://www.squarefree.com/2010/07/14/untrusted-text-in-security-dialogs/ .
> 
I don't know what to do to improve this. Everything we're displaying is in the current add-on install dialog. I'd rather show as much as we can to help the user make a decision than tell them "You're installing the add-on packaged as: [my-extension.xpi]".

>   * I'm having trouble thinking of a good button label.  "Install" would be
> good in that users know that installing untrusted software is dangerous, but
> "Install" is also the button label in many updaters.  "Add to Firefox" or
> "Install Add-on" makes it sound less dangerous than installing new software.

This another usability concern, as Install sounds like you are installing a full software package that will appear in Add/Remove Programs and install other crap all over your computer. That's why we moved away from "Install" buttons on AMO years ago.

In the interest of trying my best to get the new dialog in for feature freeze in 2 weeks, I'm willing to go with the 1 second countdown as it's certainly a big improvement. You are okay with 1 second, correct?
Note that in healthy, focused human subjects (I'm assuming this is the target audience for Firefox :-), there is a 100-300 milisecond latency between visual stimulus and a voluntary motor response. 

This means that if you allow any security-sensitive UI elements to be displayed and immediately clicked within that timeframe, you could be just as well allowing this action by default - users have little or no recourse, and can be attacked fairly reliably. Bug 583175 demonstrates one such attack on a similar UI feature.

So, the 5-second delay indeed seems sort of pointless given that the site already needs to be whitelisted, but some delay may be advisable if you consider this dialog to serve any purpose to begin with. 

I strongly suspect that a 500-1000 ms refocus delay is a good idea. I can see why this may frustrate some users, so perhaps an animation is better than a static delay: if a window loses focus, roll back all in-window prompts; and unroll them, with a fade-in animation, when focus is restored.

Currently, Firefox is very inconsistent here (no delay for some prompts, 5 seconds for add-ons, and under 1 second for opening downloaded files), so cleaning this up wouldn't hurt. Not that other browsers do better, of course.
(In reply to comment #16)
> This another usability concern, as Install sounds like you are installing a
> full software package that will appear in Add/Remove Programs and install other
> crap all over your computer. That's why we moved away from "Install" buttons on
> AMO years ago.

Something Installed this way can do exactly that! Maybe AMO's policies generally prevent it, but an install from a site that's pushing the boundaries (let alone malicious) can spread out all over on first run, or download an additional binary package and install that.

There is no sandbox, users are INSTALLING fully-privileged software on their computer. JetPack is a different model, but even there as it has evolved the restrictions are really at the policy level, not technological.

> In the interest of trying my best to get the new dialog in for feature freeze
> in 2 weeks, I'm willing to go with the 1 second countdown as it's certainly a
> big improvement. You are okay with 1 second, correct?

I can live with 1 second.

(In reply to comment #17)
> Currently, Firefox is very inconsistent here (no delay for some prompts, 5
> seconds for add-ons, and under 1 second for opening downloaded files), so
> cleaning this up wouldn't hurt. Not that other browsers do better, of course.

When these delays were first added everyone was supposed to use the security.dialog_enable_delay pref, currently defaulting to 2000 (milliseconds), for consistency and user control (should the user opt for 0 delay).

The install dialog is actually one of the few that uses this tunable delay value. It counts down in half-seconds to appear more active, and starts +1 so it can change immediately on focus. It may seem like forever, but it's only 2 seconds.

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js#57
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js#143
Okay, I've filed bug 588266 for implementation of the new doorhanger notification with a 1 second delay. I'm still trying to get this in time for feature freeze next week but we'll see.

Tiny things like the button text can continue to be discussed/changed; I just want to get the big work finished as soon as we can.

I think this bug should stay around as I still want to discuss what can be done to remove the countdown completely in the future, but I'm currently low on debate energy and am saving what little I have for the comments sure to be posted in that bug :)
(In reply to comment #19)
> I think this bug should stay around as I still want to discuss what can be done
> to remove the countdown completely in the future,

You want to remove the countdown or the delay? When the delay was originally added there was no countdown, and the lack of a clickable button mystified people. The countdown was added to address a real UI problem.

So is this bug
   a) design an alternate solution to the usability problems caused
      by focus delay, or
   b) remove focus delay ?
(In reply to comment #20)
> (In reply to comment #19)
> > I think this bug should stay around as I still want to discuss what can be done
> > to remove the countdown completely in the future,
> 
> You want to remove the countdown or the delay? When the delay was originally
> added there was no countdown, and the lack of a clickable button mystified
> people. The countdown was added to address a real UI problem.
> 
> So is this bug
>    a) design an alternate solution to the usability problems caused
>       by focus delay, or
>    b) remove focus delay ?

Perhaps two problems should be addressed in this bug:

1. No delay, nor countdown, nor even permission to install dialog, should occur on AMO.  Woo, there goes over 80% of these cases.

2. On other, untrusted sites, we look for a solution that does not involve a countdown.  Perhaps the best that can be for now is a 1 second delay, as fligtar proposes in Comment 16.  That's certainly a  huge UX improvement compared to the current state.
(In reply to comment #8)
> We talked about this in the Add-ons Manager meeting again today and want to
> push on this for Firefox 4.

How about Firefox 5?
(In reply to comment #22)
> How about Firefox 5?

We should not do this before bug 645699 hasn't been fixed.
(In reply to comment #22)
> (In reply to comment #8)
> > We talked about this in the Add-ons Manager meeting again today and want to
> > push on this for Firefox 4.
> 
> How about Firefox 5?

Find an owner and maybe, but since we are talking about replacing the install experience anyway (https://wiki.mozilla.org/Extension_Manager:Projects:Add-on_Installation) it probably makes more sense to wait for that, and that definitely won't be coming until at least Firefox 6.
"Remove countdown from add-on install dialog" is WONTFIX, even if restricted to https://addons.mozilla.org/. See my earlier comments in this bug.

There are alternative ways to make add-on installation from AMO smoother. It might be sensible to create a metabug for that goal.

* Bug 363142, find an alternative to a delay
     (extremely hard)

* Bug 416605, reduce the delay from 2s to 1s
     (currently WONTFIX; requires serious lab research)

* Bug 646602, give AMO a way to install addons without a security prompt
     (hard, requires extensive discussion between security+UX+AMO teams, but it's possible we will end up with something that is both smoother and more secure than what we have today)

* Bug 643020, whatever it's going to propose

Btw, https://wiki.mozilla.org/Extension_Manager:Projects:Add-on_Installation seems to be missing a "UI design security review" milestone and an "implementation security review" milestone.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
In reply to comment #26
...and in addition, some extensions (among which "Nightly Tester Tools" which currently supports Firefox 4 etc., and "MR-Tech Toolkit" which is more powerful but not yet completely up to Firefox 4 level) include a setting to remove the addon-install wait completely (at the user's own risk, of course; I use these extensions but I keep the standard delay).

Maybe leave this bug as WONTFIX and regard it as extension fodder?
Any extensions that provide UI for disabling the delay, without clearly explaining what kind of attack it opens up, should be removed from AMO.  From the screenshots, it looks like MR-Tech Toolkit does not make it clear and only asks that users "know what they're doing" :(
Sigh @ https://mxr.mozilla.org/addons/search?string=security.dialog_enable_delay

The good news is that if we manage to fix bug 646602, users won't be so tempted to shoot themselves in the foot.
I don't think the arguments against removing the countdown in this bug fit with the Firefox 4 flow of add-on installs.

Go to cooliris.com in Firefox 4 and hit the download button, and the following will happen:
1. A doorhanger will come down and ask if you want to allow the site to install the add-on. Clicking anywhere except on the allow button will dismiss it. The doorhanger button placement will vary depending on which toolbar buttons the user has placed to the left of the location bar.

2. If you do click Allow, the add-on will begin downloading, which will take close to a second even with extremely small add-ons. The time it will take for the add-on to download varies by user.

3. The xpinstall dialog will come up.

Jesse, can you design a game that would trick a user into installing an add-on without realizing it under those circumstances? I would argue that any proof of concept conceived would be so complicated and implausible it could not justify putting all of our users through this annoyance any longer, especially with the tools we have to block websites and add-ons.

Any attacker could much more easily convince someone to install an add-on by claiming it will give them free Farmville money than getting this to work.
Attacking the workflow requires one click (doorhanger) and one keypress (Enter).  Trivial to attack with something like bug 162020 comment 3.  The download time isn't a security measure, and can be hidden by pre-downloading or simple distraction.  Customizable toolbars aren't a security measure, and most users don't move buttons around.

The gullibility of some users is irrelevant to whether we should give up on making Firefox a secure web browser.
Part of the problem with the current delay is that it's serial with the download, and happens after the download.  If the dialog appeared immediately after the choice to install the extension, with Firefox downloading the extension in the background while the dialog was displayed, it would be less of a problem.

For this to work with signed extensions, I think the web site would have to say who signed the extension.  Then Firefox would bail if the code-signing signature failed to match.
(We'd also need to think about what UI to show if the user clicks "Install" before the download finishes.)
The download could easily be artificially made to take longer than it actually does. The point is to make the delay unnoticeable to the user. Making what appears to be the download actually be the delay accomplishes this.

The fact that click + Enter is enough is a design flaw. No dialog box should default to the less secure option. And no dialog box should accept input faster than a human can see the box. Every dialog should have a 300ms minimum delay for both keyboard and touchpad input.

Also, I'd propose that any keyboard shortcuts should require the Alt key, which is both the default on Windows, and much harder to trick people into using. Just underline the appropriate key, and anyone who uses the keyboard accessibility features of Windows should know what to do. (As far as I know, no other OS forces keyboard accessibility of dialogs.) It definitely should not be as simple as pressing one alphanumeric key.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: