1302137 - Our new permission prompts are practically modal! Make them "passive confirmation UI" again.

Status: RESOLVED WONTFIX

(Firefox :: Site Permissions, defect)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: One suggestion for what a shrinking prompt might look like.

I like our recent redesign of permissions for many reasons, but they're practically modal, which is bad.

(While perhaps not technically modal, they're so big they're impractical to ignore, to the point where continuing to operate the page underneath is a real challenge, so come on, they're modal.)

I can't say it better than roc in his excellent 2011 blog [1] which I hope everyone has read many times, where he says:

  "Long ago we learned that modal requests --- interrupting the application with a warning, and forcing the user to OK/Cancel before proceeding any further --- was ineffective for security, because users quickly learn to OK such warnings without even reading them. An alternative approach is "passive confirmation UI": for example, UI appears requesting a permission, but the user can ignore it and continue using the application, so users who don't read the message are less likely to grant permission by default. Firefox's geolocation permission UI is a good example of this."

Our new UX has lost this spirit in its design, which I'll paraphrase as "Here, user! Here's some additional functionality you can turn on for this site whenever you want, if you want, or not, whatevs." It offered the user a richer (optional!) experience in exchange for trusting this site with more of their stuff, with enticement, not pressure. The not-having-to-answer part was intrinsic in this power dynamic between user and site.

Because make no mistake, this is a PITA for web developers, but users - individuals - come first in the w3c "Priority of Constituencies" for the web [1], and the Mozilla manifesto [3].

The reason we dropped this was that our *implementation* of "passive confimation UI", which roc referred to in 2011, was flawed in two regards:

 1. People thought the prompt was gone when it went away.
 2. Web developers expected some form of notification from what looked like dismissal.

These were UX challenges we could have solved, and still can solve, to avoid what are effectively modal dialogs. As proof of that (and only that) I offer up a mockup screenshot of what I'll call the "shrinking permission prompt" could look like.

It solves (1) by never fully going away, it just shrinks enough to let users continue their work if they indicate lack of interest.

It solves (2) by not falsely implying dismissal.

Modal dialogs also exacerbate permission spamming, so let's bring back Firefox's traditional defense against this (which frankly the redesign has made worse). There changes to the API are needed for this.

[1] http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html
[2] https://www.w3.org/TR/html-design-principles/#priority-of-constituencies
[3] https://www.mozilla.org/en-US/about/manifesto/

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Sorry, I meant "There are NO changes to the API needed for this."

Comment 2

[Tanvi Vyas[:tanvi]]

I also do not like making permission prompts model.  It interrupts the user and forces them to make a decision they may not want to be bothered with at the moment.  I understand that we don't want to the prompt to be dismissed if they user clicks outside of it (because then a user may dismiss it before they had a chance to see it), but if the user has seen it and doesn't want to answer, they should be able to click X to make it go away for the moment.  At that point, Firefox may send back a temporary deny to the website or it may do nothing.

I believe there is going to be some user testing around this.

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

> I believe there is going to be some user testing around this.

The UR team published their results:
https://medium.com/firefox-ux/user-study-new-privacy-permissions-panel-223e61cc7545

Users generally understood the dismissal of the prompt as denial of the request, so there is no evidence that there is value in not providing feedback to the web site immediately. Therefore there can be no doubt that our implementation still considers users are the top priority.

The modality of the prompt is a separate issue and roc's argument ("Long ago we learned that modal requests [...] were ineffective for security") may have been valid in some contexts (e.g. Windows UAC prompts), but is debatable in this specific context as the modality in this case is not the same, as comment 0 correctly points out. I'm happy to continue the discussion about how to make it better, but the UX team's reaction to the shrinking prompt idea wasn't too warm back when we had discussed it. I can bring it up again and report back.

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Any update on this from the UX team?

Try to modify and run this fiddle in 52 vs 53: http://jsfiddle.net/jib1/srn9db4h/

In 52:
1. Click to edit the JavaScript (the permission prompt gets out of the way).
2. Edit it and click Run (the permission prompt reappears, you click "Allow", and Tada!)

In 53:
1. The permission prompt is covering the edit area, so hit "Don't Allow" since you're not ready.
2. Edit the JavaScript and click Run.
3. You'll get "NotAllowedError: The request is not allowed by the user agent or the platform in the current context."
4. Locate and hover over the gray camera icon near the url: "You have blocked your camera for this website".
5. Click the gray camera icon.
6. Hit the (X) next to "Use the microphone  Blocked temporarily"
7. Hit the (X) next to "Use the camera      Blocked temporarily"
8. Click anywhere else (the page info drop-down gets out of the way, revealing the Run button)
9. Click Run (the permission prompt reappears, you click "Allow", and Tada!)

The key to the shrinking prompt (attachment 8790320 [details]) is that it preserves the current model without any of the earlier problems, and at the same time reduces the modal annoyance significantly.

Yes, I could have hit "Allow" in 53 step 1, but to me that just proves roc was right, and that his concerns are still valid.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

I believe the plan still remains to ship 53, collect user feedback and course correct if necessary. I have focused on a different project lately, so pdol would be a better person to ping for that feedback in the future.

Comment 6

[Peter Dolanjski [:pdol]]

(In reply to Panos Astithas [:past] (please needinfo?) from comment #5)
> I believe the plan still remains to ship 53, collect user feedback and
> course correct if necessary. I have focused on a different project lately,
> so pdol would be a better person to ping for that feedback in the future.

This is still the plan.  Adding jsavory (UX) to consider the proposal in (attachment 8790320 [details]).

Comment 7

[Florian Quèze [:florian]]

(In reply to Panos Astithas [:past] (please needinfo?) from comment #5)
> I believe the plan still remains to ship 53, collect user feedback and
> course correct if necessary.

Right, if we course correct, that will be based on the feedback collected after releasing 53, and UX will then iterate on designs. I don't expect us to implement the proposal in this bug, but it's part of the feedback UX can take into account. 

That said, the use case described in this bug is very specific to a developer workflow, so it may be better supported by a devtools feature.

Comment 8

[Johann Hofmann [:johannh]]

I'd like to add that implementing this suggestion is a non-trivial amount of work equivalent to the permission prompt refresh we just finished (minus the work on permission internals of course). As Florian said, the outlined problem is an edge case that only affects people working on permission prompts. We're scrambling to maintain permission prompts with other projects coming up, it's unthinkable to implement and most of all support a feature like the shrinking permission prompt.

I agree with the wontfix, clearing the ni for jsavory accordingly.

Comment 9

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Study 2 observes that "More participants in the “X” group selected “X” this time", but fails to explain why. The study's conclusion (that there's no difference) is not supported by participants' behavior, only by their inability to explain it.

Based on their behavior, I'd say there's a perceived difference.

Also, why the difference from Study 1? What's now suddenly attractive about this hardly-visible and tricky-to-hit "X"?

My best guess is participants weren't ready to make a choice, or even commit to reading the words thrown at them. They just wanted it gone. Fearful of making a decision without knowing the consequence, the "X" is a more attractively neutral and noncommittal "Not now" to them. That's why they chose it in greater numbers than in study 1.

In other words, "X" means: "I don't want to decide anything now", and explicitly NOT "I don't want this site to request my location no matter what I'll lose out on later".

By overloading "Don't Allow" with both of these meanings, we can no longer distinguish between these two user intents.

The study also never confronted participants with the consequences of their actions. It should have led them to the T-mobile store locator page, and record their reaction when the site can't ask them for their location, because it is temporarily blocked from doing so.

Ask them how they feel about their choice now, and if they feel the browser understood their intent correctly earlier.

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Interestingly, the unchecked "[ ] Remember this decision" box gives the wrong assurance about hitting "Don't Allow" in this case.