363142 - Replace delay in security dialogs with something else

Status: NEW

(Core :: Security, enhancement)

Description

[Jesse Ruderman]

I'm starting to rethink the "delay" solution I pushed for in bug 162020.  It wastes the time of users who install a lot of extensions, and it might not be as secure as we thought.


Exploits may be possible because:

1. The user might not be looking at the screen because...
  * He's new to typing.
  * He just started learning the dvorak keyboard layout.
  * He's playing the "press every letter key on your keyboard where the letter does not completely enclose any empty space" game.
  * He's been asked to type the first paragraph on page 42 of a book (or game manual) in order to convince the site that he owns a copy.

2. A site might intentionally make the screen very busy as part of a game.  If the user has a high-resolution screen or multiple screens, he might not notice the dialog at all, even though it has focus.

3. The delay violates http://www.w3.org/TR/UAAG10/guidelines.html#tech-time-independent, suggesting that it might not protect disabled users adequately.

4. Some people published instructions for disabling the delay using about:config.  Many users follow the instructions because they are annoyed by the delay do not understand the risks.


I think it's possible to make the UI both more secure in the face of clever attackers and more efficient for users who install many extensions.  The basic idea is to require a positive action from the user, in the form of a reserved keyboard shortcut or browser UI.  Here are some more specific ideas for how that could be done:

(A) Change the dialog so to install an extension, you must press Ctrl+Shift+E.  This wouldn't need much of a delay.

(B) A hybrid of (A) and the current dialog, where you can press Ctrl+Shift+E at any time, or wait a second or three for the "Install" button to become enabled and then click on it.

(C) Only show the installation dialog after the user clicks a button in an information bar.  (This is probably not ideal for security -- a site might be able to convince you to click where the information bar is about to appear, then press spacebar.)

(D) Only show the installation dialog after the user takes some positive action.  For example, the information bar could say "This site is requesting that you install an extension.  Press Ctrl+Shift+E to install it".  Pressing Ctrl+Shift+E would then show the installation dialog.


With both (C) and (D), I imagine that whitelisting would become part of the installation dialog itself.  For example, the dialog could simply say "You have not installed an extension from www.squarefree.com before", or if could have a checkbox labeled "Let me install extensions from www.squarefree.com".  This would fix bug 252830.

One advantage of the current solution (the delay) is that it forces some users to read the dialog.  But it would be even better to figure out a way to avoid having users see security dialogs as something "in their way" when they're on a malicious site.  I think (D) accomplishes that goal better than the current whitelisting UI.

I wonder if any of these solutions would also make sense for the dialog for downloading executable files that will be added in bug 249951.

Comment 1

[Aaron Leventhal]

Well, the timeout feature doesn't make sense for a screen reader user. It's confusing for that group because the text is changing inside a disabled button, which is very creative but highly irregular.

Comment 2

[Benjamin Smedberg]

I'm not sure I understand what sequence of events you're worried about. Are you worried about websites in the whitelist or not in the whitelist?

Comment 3

[Jesse Ruderman]

For the XPI dialog, this is only a major problem for whitelisted sites.  But other equally important security dialogs (e.g. signed script asking for privs) do not share the whitelisting thing.  Also, I believe that whitelisting was designed as an anti-annoyance feature rather than a blank check for sites to install anything at will.

Comment 4

[Daniel Veditz [:dveditz]]

Shouldn't this bug be public? I don't see an exploit here, this is UI redesign (and as such you probably don't want it assigned to me!).

Comment 5

[Jesse Ruderman]

Comment 0 does mention some potential exploits, but I think this bug will benefit from being public, so I'm making it public.

Comment 6

[Scott Tankard]

I don't see a firm rejection of the checkbox option in bug 162020 (where it was originally brought up). May I ask why the timer option was favored?

A checkbox would require two distinct actions, whether with the keyboard or mouse, and would likely be no more annoying than the current timer mechanism.

We already do this for licenses; it may not get people to actually read the license, but it does guarantee they must stop to give it some consideration.

Comment 7

[Jesse Ruderman]

> I don't see a firm rejection of the checkbox option in bug 162020

Bug 162020 comment 9?

Comment 8

[Alex Faaborg [:faaborg] (Firefox UX)]

For extensions I actually think we should keep the timer since the user doesn't
install that many extensions, and extensions have a lot of privileges.  However
I think we should introduce some form of made up (but reasonable) reason why we
are waiting, and display a progress bar.  So for instance, say "checking
extension" and then have a progress bar that quickly moves from one end to
another.  The motion will also help capture the user's attention, and the main
problem with the timer interface here is that people can't figure out why they
are being asked to wait.

Here is my first attempt at a solution that doesn't rely on a timer for
downloads. based on this UI:

http://people.mozilla.com/~faaborg/files/shiretoko/unifiedContentHandlingi3.png

== mouse interactions ==

1) we monitor the location of the mouse cursor when the window is displayed,
and we are careful that the download button is never placed below the mouse
cursor (but is otherwise placed in the correct general area of the screen, not
a totally random position).

2) in the event that somehow 1 actually fails, we also design a special type of
button that won't accept mouse input if the cursor started within its region. 
So you must mouse into the button, and then down click.  If the mouse is
somehow within the region of the button when the button first draws, it draws
as disabled with the timer, and then re-enables when you mouse out of it (or
after 2500 miliseconds).

== keyboard interactions ==

For downloads we move the starting focus to the "remember my choice" checkbox. 
This is annoying in that the user needs to hit tab-enter each time, but they
can also get around the situation entirely by hitting enter-tab-enter (and
never be prompted again for that file type).

Comment 9

[Robert Kaiser]

(In reply to comment #8)
> I think we should introduce some form of made up (but reasonable) reason why we
> are waiting, and display a progress bar.  So for instance, say "checking
> extension" and then have a progress bar that quickly moves from one end to
> another.  The motion will also help capture the user's attention, and the main
> problem with the timer interface here is that people can't figure out why they
> are being asked to wait.

Why not just tell the truth and make it say "giving you time to read this dialog..." or something like that?

Comment 10

[Jesse Ruderman]

I don't like the progress bar idea.  We don't want to capture the user's attention on the timer if they'd otherwise be reading the text of the dialog, because (1) then they'll be annoyed at a timer they wouldn't have noticed otherwise and (2) they won't read the dialog text, which contains information that can help the user decide whether it is safe to install the extension.

The "random dialog location" idea rubs me the wrong way, and not just for the reasons in bug 162020 comment 3.  It's just so full of special cases added every time we think of a new attack -- what if you're already moving the mouse when the dialog appears, what about touchscreens?

For keyboard interactions, simply putting focus other than on the open button has the problems described in bug 162020 comment 9.

Comment 11

[Shawn Wilsher :sdwilsh]

(In reply to comment #10)
> I don't like the progress bar idea.  We don't want to capture the user's
> attention on the timer if they'd otherwise be reading the text of the dialog,
> because (1) then they'll be annoyed at a timer they wouldn't have noticed
> otherwise and (2) they won't read the dialog text, which contains information
> that can help the user decide whether it is safe to install the extension.
I think it's a safe assumption to make that most users don't read dialogs, and coming across as trying to force users to read it will just piss them off (and we do!).  The progress bar will still give them the opportunity to read the dialog, but not look like we are forcing them to read it.

Comment 12

[Michael Ryan]

How about have the user re-type a random string? Like a captcha, but just plain text.

1. Malicious websites could not exploit it.
2. No delay = removes the aforementioned accessibility issue.
3. People are already used to typing in captchas - this would be simple compared to those.

Comment 13

[chris hofmann]

> Why not just tell the truth and make it say "giving you time to read this
> dialog..." or something like that?

or maybe re-enforce some user education that clearly needed in these kinds of situations.

   ** installing software is a dangerous activity, proceeding with care **

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

I am definitely not the droid this bug is looking for.