1321947 - can't dismiss doorhanger asking for installation permission

Status: VERIFIED FIXED

(Toolkit Graveyard :: Notifications and Alerts, defect)

Description

[Albert Scheiner [:alberts]]

Attachment: ecosia.org-with-doorhanger.png

After clicking the "Add to Firefox" button underneath the search field on https://www.ecosia.org/# the doorhanger to allow the installation for the extension pops up.
Problem is it only has one option "Allow", no "x" to close it, clicking out side doesn't close it either anymore since bug 1004061 got implemented.

I think this particular doorhanger is just missing the second button "Don't allow"

Comment 1

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: Bug 1321947 - Add "Don't Allow" button to add-on installation permission doorhanger to make it dismissible.

Review commit: https://reviewboard.mozilla.org/r/97342/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/97342/

Comment 2

[Florian Quèze [:florian]]

The code in the patch looks good, but I'm not sure about the UX. If we add a "Don't Allow" button, I think the wording of the text in the notification should be changed too because "Nightly prevented this site from asking you to install software on your computer." is neither a question or a request.

I thought this was a duplicate because I know we already discussed that the panels used for the add-on install flow need improvement soon, but I couldn't find a similar bug.

Needinfo on Panos either to find the right bug this is a duplicate of, or as a reminder to discuss this this week.

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

That string is used twice:
1) For this case if an addon gets installed from a host different than addons.mozilla.org
2) If the user directly calls an url from the location bar (always blocked).
Suggestion: "This site wants to ask you to install software on your computer."

Comment 4

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

I think this is another case of an implicit Not Now that I incorrectly removed. The patch makes sense to me, but I defer to Florian for review. If you want to debate strings and UX, ping Markus Jaritz or Michelle Heubusch.

Comment 5

[Albert Scheiner [:alberts]]

This might be a naive question, but isn't it a bit an overkill to have a doorhanger asking me to allow a site to ask me if I allow to install an add-on, just to get another doorhanger right after actually asking if I allow the installation of the add-on?

Comment 6

[Florian Quèze [:florian]]

Comment on attachment 8816791 [details]
Bug 1321947 - Add "Don't Allow" button to add-on installation permission doorhanger to make it dismissible.

https://reviewboard.mozilla.org/r/97342/#review99806

r=me on the code here as it looks reasonable, but I would really like UX to have a look at the install flow here, as I share the question/concern in comment 5.

Not sure if we should land this temporarily or wait for an answer from UX. I guess if we get close to the end of the cycle we should land before this merges to aurora, as the current UI looks broken.

Comment 7

[Florian Quèze [:florian]]

(In reply to Albert Scheiner [:alberts] from comment #5)
> This might be a naive question, but isn't it a bit an overkill to have a
> doorhanger asking me to allow a site to ask me if I allow to install an
> add-on, just to get another doorhanger right after actually asking if I
> allow the installation of the add-on?

Markus, could you please have a look at this install flow and check if there's a reason for keeping the first doorhanger?

Comment 9

[Tanvi Vyas[:tanvi]]

When a user installs an addon that is not signed or not through AMO, we purposefully want to show them two prompts.  The first prompt is to let them know they are installing software that is unknown to and not verified by Mozilla.  The user should be able to easily dismiss/deny that prompt and not feel the urge to click "Allow" to get rid of it.  If allow is the only option, or even the primary option, that incentivizes users to click it.

The addon flow should not necessarily mirror the rest of the permission prompts.  We need to dive deeper into this flow and revamp it.  But until that is done, we should be careful that the permission prompt changes don't affect the existing flow we have.

I propose that the Deny option be the primary action.  

Also, Florian notes that the copy may need to be revised.  Right now it says:
"Nightly prevented this site from asking you to install software on your computer".  The only option in Nightly 53 is "Allow". The options should be something like "Keep blocking/preventing" and "Unblock".  UX or Michelle can probably help with the wording.

Needinfo'ing Dan to also take a look at this.

Comment 10

[Johann Hofmann [:johannh]]

(In reply to Tanvi Vyas [:tanvi] from comment #9)
>
> I propose that the Deny option be the primary action.  
>

No, I don't think we should do that. Literally all other doorhangers have the "Allow" action as primary and "Deny" as secondary, deviating from that pattern here would definitely confuse users and IMO lead more people to accidentally allow.

We're planning to map the ESC key to the secondary action in bug 1320719 (following said convention, to not further complicate the API) and that would also not really help us there. :)

Comment 11

[Tanvi Vyas[:tanvi]]

Since the risk involved in allowing installation is much greater than the risk involved in allowing a website to access some data, perhaps the UI shouldn't follow the UI for the rest of the permission prompts.  Perhaps the addon installation flow should look and feel different than the UI for allowing geolocation or mic access to a website.

Comment 12

[Albert Scheiner [:alberts]]

(In reply to Tanvi Vyas [:tanvi] from comment #9)
> When a user installs an addon that is not signed or not through AMO, we
> purposefully want to show them two prompts.  The first prompt is to let them
> know they are installing software that is unknown to and not verified by
> Mozilla.

Maybe that should be somehow reflected in the request. "This site wants to install unverified software ..." And alink with more information. That would Al's differentiate the first prompt more from the second one.

Comment 13

[Johann Hofmann [:johannh]]

(In reply to Tanvi Vyas [:tanvi] from comment #11)
> Since the risk involved in allowing installation is much greater than the
> risk involved in allowing a website to access some data, perhaps the UI
> shouldn't follow the UI for the rest of the permission prompts.  Perhaps the
> addon installation flow should look and feel different than the UI for
> allowing geolocation or mic access to a website.

I understand why you want to reverse the buttons, but I claim doing so will actually be harmful and misleading. You're worried about users making an intuitive choice without reading the label, but we already trained users that the grey button is the "Deny" choice and the blue button is the "Allow" choice. Those users will likely choose the grey button if they want to deny the request.

In addition to that, you're weakening the general UI convention that we've been using in all other doorhangers. Let's please keep this UI consistent. As soon as we start adding exceptions we severely detriment the user experience and intuitiveness. We also create a precedent for other people to further evaluate the button order based on their priorities. We only get more inconsistency from this.

Also I really doubt if this is even as "higher risk" as you claim. Even if some people end up going with the blue choice without thinking about it, this notification is not the final step before the addon actually gets installed.

Comment 14

[Daniel Veditz [:dveditz]]

We here in this bug are talking about "installation" and we know what "installation" means. Users who see these dialogs are not thinking "MALWARE ON MY MACHINE", they assume that since it's easy and the browser is letting the web site ask they must be safe goodies. THEY ARE NOT. There is no way to tell that the offered add-on has been reviewed or not (generally not). If malicious add-ons get reported we can blocklist them to prevent future installs, but there will be hundreds or thousands of victims before that. Malicious addons are not always obvious. Most of them are "Trojans" in the true sense: offering (and fulfilling) some desired feature on the surface while stealing data or injecting ads undetected for quite a while.

The First Doorhanger here is IMHO an abomination that should never have existed. NEVER. We have a whitelist of sites allowed to install software, the ability to edit that list, and a pref to turn it off and allow all sites to install. This is exactly equivalent to the Android setting to allow installation from other stores and the phone doesn't prompt you to enable other stores every time some site tries to give you an APK (and iOS doesn't even give you that freedom). Sites that have something worthwhile to offer can tell users how to add that site to the whitelist i(we have UI for it, it's not an "about:config" operation), and the burden of doing so can communicate to users what a stupid and foolish risk they are taking if they don't trust that site to have their best interests at heart.

That dialog doesn't actually say what it means. What it means is

    We don't trust this site and don't think you should install software from it
    [Pwn me anyway]

Why are we giving the user that choice? In the current incarnation the _only_ choice. If the site isn't whitelisted they should get nothing. Maybe something in the site control center 'Permission' block if you want to make it a little easier for users, but still not too discoverable.

We should consider removing this ability from insecure sites entirely. Even if the target add-on is signed there's no way to know that the add-on the user gets from clicking the link is the one the site intended it to get.

Comment 15

[Florian Quèze [:florian]]

(In reply to Daniel Veditz [:dveditz] from comment #14)
> Sites that have something worthwhile to offer
> can tell users how to add that site to the whitelist i(we have UI for it,
> it's not an "about:config" operation)

Where is this UI? Are you referring to the "Install Add-ons" row of the Permissions tab in Page Info? (ironically it took me a while to find this... even though I'm the person who implemented it at the time!)

Comment 16

[Markus Jaritz [:designakt] (UX)]

[:florian] [:flo] from comment #7)
> Markus, could you please have a look at this install flow and check if
> there's a reason for keeping the first doorhanger?

Yes there is and Tanvi explained it in detail.

As I understand from that bug the problem is a missing button on a doorhanger for extensions that come from 3rd party sites. I think the reasons for this doorhanger, as well as it's pros and cons have been discussed in detail.
I suggest using this bug for its initial purpose of getting the "don't allow" option back and with that bring the install-flow back to the state it has been in since a few years.

Any further issue on the broader topic of reducing the risk 3rd party installs pose are worth their own bug and should be worked on separately to improve security.
On such bug https://bugzilla.mozilla.org/show_bug.cgi?id=1232664 proposes to enable installing specific AMO-hosted extensions from white-listed 3rd party sites (like Chromes does) to provide a safer alternative for third-party hosted installs without taking away the possibility from developer to promote their own extension on their own sites.

Comment 17

[Florian Quèze [:florian]]

(In reply to Florian Quèze [:florian] [:flo] from comment #15)
> (In reply to Daniel Veditz [:dveditz] from comment #14)
> > Sites that have something worthwhile to offer
> > can tell users how to add that site to the whitelist i(we have UI for it,
> > it's not an "about:config" operation)
> 
> Where is this UI? Are you referring to the "Install Add-ons" row of the
> Permissions tab in Page Info? (ironically it took me a while to find this...
> even though I'm the person who implemented it at the time!)

Ah, I guess you meant the first 'Exceptions' button in about:preferences#security

Comment 18

[Florian Quèze [:florian]]

(In reply to Markus Jaritz [:designakt prev :maritz] (UX) from comment #16)

> As I understand from that bug the problem is a missing button on a
> doorhanger for extensions that come from 3rd party sites.

Well, that's the most visible problem. But I think it's more the last straw that broke the camel's back. This prompt is broken UI. If we really want to keep it, we should rephrase the strings in it so that they make sense with "Allow" "Don't Allow" buttons. But if we do have Allow/Don't Allow buttons there, it'll really be a click through thing that users won't read, and Tanvi's concerns aren't addressed.

After reading comment 14, I think a better solution would be to remove that prompt completely, and just show in the UI that something was blocked. I would suggest a crossed through add-on icon in the identity block (like we do when the user persistently denied a camera request). Clicking that icon should open the control center, with a message saying add-on installs from this site are blocked, with a link to open the dialog to manage exceptions. Clicking that link would do the same thing as clicking the 'Exceptions' button on about:preferences#security. There, the user would have to type (or copy/paste) the hostname of the site, so it would be a pretty explicit user action that can't really be done by accident (unlike clicking through the current prompt).

Thoughts?

Comment 19

[Markus Jaritz [:designakt] (UX)]

I agree that this is not the best UI and that we can do better. It seams there are plenty of ideas how to improve third party installs. What I do not understand is why this glitch with the disappeared button can not be fixed before we address the deeper issues.
Scott can you please help on how to best re-phrase the third-party-install-permission dialog to be answered with "Allow" / "Don't Allow". Thanks.

On the general issue of 3rd party installs we need to know if we want to enable them or not. Or where in between we want to land. Your proposal is basically blocking 3rd party installs for most people, which is a big change to the current implementation and should be discussed with the broader add-ons team.
I would like Kev to weigh in on this topic, as that general policy on third party installs seams to be more a PM questions.

Comment 20

[Johann Hofmann [:johannh]]

(In reply to Markus Jaritz [:designakt prev :maritz] (UX) from comment #19)
> I agree that this is not the best UI and that we can do better. It seams
> there are plenty of ideas how to improve third party installs. What I do not
> understand is why this glitch with the disappeared button can not be fixed
> before we address the deeper issues.

Well there is a patch with r+ (and I'm pretty sure Aryx knows how to land it), so we should just do that and open a new bug with the previous discussion. :)

Comment 21

[sdevaney]

What about some copy like so...

This website wants to install unverified software. This may pose a risk to your system. 

[Allow]   |   [Deny]

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ac2a8c26314e
Add "Don't Allow" button to add-on installation permission doorhanger to make it dismissible. r=florian

Comment 23

[Johann Hofmann [:johannh]]

Following up on our IRC discussion, we decided to go ahead and land this, since the discussion does not really present a viable short-term alternative to just fix this problem in time for 53.

Feel free to make new bugs to replace this UI entirely. :)

Comment 24

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/ac2a8c26314e

Comment 25

[Emil Ghitta, QA [:emilghitta]]

I’ve reproduce the issue described in comment 0 using and affected build: Firefox Nightly 53.0a1(Build Id:20161203030204).

I have verified that the issue is not reproducible using Firefox 53.0b1(Build Id:20170307064827) and Firefox latest Nightly 55.0a1(Build Id:20170310030205) using Windows 10 64bit, Mac 10.11.6 and Ubuntu 16.04 64bit.