Closed Bug 1120996 Opened 9 years ago Closed 9 years ago

[UX] Reconsider add-on installation flow

Categories

(Firefox :: General, defect, P4)

36 Branch
x86
All
defect
Points:
5

Tracking

()

RESOLVED FIXED
Iteration:
41.1 - May 25

People

(Reporter: phlsa, Assigned: designakt)

References

Details

(Whiteboard: [hijacking][ux][fxsearch])

Attachments

(1 file, 10 obsolete files)

With add-on signing becoming more rigorous, we can make the flow for approved add-ons easier. At the same time, we need UI for when an add-on gets blocked.
Flags: firefox-backlog+
Iteration: --- → 38.1 - 26 Jan
Points: --- → 5
Flags: qe-verify-
Status: NEW → ASSIGNED
Attached image preliminary-new-Add-on-Process.jpg (obsolete) —
First UX-draft on the new flow as discussed today. 
- additional case sideload will be covered. 
- unsigned allowed at first will be covered.
- switching tab during process will be covered.
- copy and Icons will be refined.
Attached file preliminary-new-Add-on-Process.pdf (obsolete) —
Additional flows have been added.

- [:matej] please let's talk about how to refine the copy.

- [:shorlander] please let's talk about refining the icons and UI.

- flow needs to be approved.
Flags: needinfo?(shorlander)
Flags: needinfo?(matej)
Dave, is it possible that there might occur an error that might stop the addon installation?
This might be another state I have to cover.
Flags: needinfo?(dtownsend)
Some special cases/questions came up during our ux design review session:
 - Why do we do side-load at all, as it seems to be more danger than advantage? And how is sideloading used?
mossop: Other applications on the system use it to integrate with Firefox. We provide the option because frankly we are in an arms race, either we give them a controlled way to integrate or the apps do it anyway in a more user hostile manner. The signing requirement is partly aimed at adding another layer of control to what can sideload.

 - Is the 3sec timer before installing an addon needed as a security feature, can we go without it?
mossop: Yes, to avoid clickjacking, we're probably going to need to do a security review for removing it.

 - If the addon is certified, is there still a reason to need user-confirmation to install? Or is it enough that the user clicked install/download on the website?
mossop: That would be a question for the security team to answer.

dveditz: can you please comment on these issues and have a look at the flow from a security perspective. Thanks.
Flags: needinfo?(dveditz)
Had a meeting with Markus today and we worked on copy edits to the flow.
Flags: needinfo?(matej)
Attached file preliminary-new-Add-on-Process.pdf (obsolete) —
Updated the attachment to reflect our copy-changes.
Attachment #8551954 - Attachment is obsolete: true
Attachment #8552725 - Attachment is obsolete: true
Attachment #8553942 - Attachment mime type: application/x-download → application/pdf
Attachment #8553942 - Attachment description: preliminary-new-Add-on-Process.pdf - updated copy → preliminary-new-Add-on-Process.pdf
(In reply to Markus Jaritz [:maritz] from comment #5)
>  - Is the 3sec timer before installing an addon needed as a security
> feature, can we go without it?

It's not a 3 second timer, security.dialog_enable_delay is currently set to 1 second. The countdown is dumb and draws negative attention, and counting in 1/2 second increments (+1, yay fenceposts) makes people think it's longer than it is (as it did for you, for instance).

The delay itself is necessary to solve lured-click attacks as originally described in bug 162020, but also many variant proofs of concept attacks scattered throughout bugzilla.
Taking at stab at the other questions:
> If the addon is certified, is there still a reason to need user-confirmation to install?
> Or is it enough that the user clicked install/download on the website?

Even if we have reviewed an add-on as OK for its purpose, those purposes might be harmful or unwanted by the user and we must ask them. It could be an old known-vulnerable version of something, for instance, and we can't afford to stuff the blocklist with every old version of everything just in case some bad guy tries to make someone install it.

You say the user clicked on "THE website". On AMO users click on a big obvious install button, and we have the space and expectation that the user have the opportunity to read an add-on's privacy policy before starting an install. When we allow installs from other sites there is no way to enforce the same; we need to at least give a user a chance to cancel if they click on a disguised link. (Actually there is a solution to the privacy policy problem: we could require that those links be in the reviewed-and-signed install manifest. But we'd still have to have a dialog to stop and give the user the opportunity to read the policy or cancel the install if they didn't like the policy.)

The attached install flows seem to be missing some cases. And I'm not quite sure what you mean by "3rd party"--is that hosted on a 3rd party or signed by a 3rd party?

You also seem to have done away with the install confirmation dialog for installs triggered by AMO. I understand the desire to make a nicer experience but it's dangerous. That means if there's ever a simple website flaw on AMO such as XSS (and they come up from time to time) a bad guy could force any install on someone without any chance to protect themselves by canceling the unexpected action. As a user it gives me a sense of security knowing sites can't just stuff things in my browser: if even a trusted site can't then none of them can. But I am admittedly not the average user, I actually like it and feel safe when my computer makes me enter the login password before programs can do dangerous things.

In any case, even if we do away with that on AMO we still need to design it for when other sites trigger installs. Also consider the case when a 3rd party site navigates to an AMO .xpi link (or opens one in a frame). That will trigger an install without the contents changing to AMO. Can we make sure that doesn't get a clickless UI flow?

Other than the "lightweight" variety, themes are not as innocuous as people think--they should get a confirmation step too. ESPECIALLY if they're triggered elsewhere than AMO.

The dialogs say things like "certified by Mozilla". We will almost certainly be issuing certificates to 3rd parties at some point for them to sign their own add-ons outside our review process (but under contractual conditions they will be responsible for). We obviously shouldn't say "certified by Mozilla" in those cases. The dialogs need to be flexible enough to use text from the actual certificate.
Flags: needinfo?(dveditz)
(In reply to Markus Jaritz [:maritz] from comment #4)
> Dave, is it possible that there might occur an error that might stop the
> addon installation?
> This might be another state I have to cover.

Yes, download errors or corrupt files are common. Here are the current error messages we use in the doorhanger: http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.properties#52
Flags: needinfo?(dtownsend)
Iteration: 38.1 - 26 Jan → 38.2 - 9 Feb
In addition to download errors or corrupt files, the add-on signing requirement will create additional failure modes. I expect at least at first lots of people will run into unsigned add-ons because folks also want to relax the requirement that add-on installs be triggered from whitelisted sites like AMO. (I recommend that we don't do that, or at least don't allow it until a release or two after we start requiring signed add-ons.)
(In reply to Daniel Veditz [:dveditz] from comment #8)
> (In reply to Markus Jaritz [:maritz] from comment #5)
> >  - Is the 3sec timer before installing an addon needed as a security
> > feature, can we go without it?
> 
> It's not a 3 second timer, security.dialog_enable_delay is currently set to
> 1 second. The countdown is dumb and draws negative attention, and counting
> in 1/2 second increments (+1, yay fenceposts) makes people think it's longer
> than it is (as it did for you, for instance).
> 
> The delay itself is necessary to solve lured-click attacks as originally
> described in bug 162020, but also many variant proofs of concept attacks
> scattered throughout bugzilla.

The delay happens after the download of the add-on. This is already a sort of dealy… Is the delay after that still necessary? And if so. Is it necessary to repeat the delay each time the window get focus again?

My idea it to combine the download and wait (as a sort of verify) into one dialog with a disabled install button. After download and verify (delay) the dialog would change to information about the typ of add-on (certified, prelim. cert., uncert.) and an active install button.
Iteration: 38.2 - 9 Feb → 38.1 - 26 Jan
Flags: needinfo?(dveditz)
(In reply to Daniel Veditz [:dveditz] from comment #11)
> In addition to download errors or corrupt files, the add-on signing
> requirement will create additional failure modes. I expect at least at first
> lots of people will run into unsigned add-ons because folks also want to
> relax the requirement that add-on installs be triggered from whitelisted
> sites like AMO. (I recommend that we don't do that, or at least don't allow
> it until a release or two after we start requiring signed add-ons.)

Therefore the plan is to let users install un-certified add-ons at first - with an intense warning. And only after some time completely deny install. ( as shown in my flow under: click uncertified (current) & click uncertified (future) )
(In reply to Daniel Veditz [:dveditz] from comment #9)
> Taking at stab at the other questions:
> > If the addon is certified, is there still a reason to need user-confirmation to install?
> > Or is it enough that the user clicked install/download on the website?
> 
> Even if we have reviewed an add-on as OK for its purpose, those purposes
> might be harmful or unwanted by the user and we must ask them. It could be
> an old known-vulnerable version of something, for instance, and we can't
> afford to stuff the blocklist with every old version of everything just in
> case some bad guy tries to make someone install it.

I will add a confirmation for signed add-ons.

> You say the user clicked on "THE website". On AMO users click on a big
> obvious install button, and we have the space and expectation that the user
> have the opportunity to read an add-on's privacy policy before starting an
> install. When we allow installs from other sites there is no way to enforce
> the same; we need to at least give a user a chance to cancel if they click
> on a disguised link. (Actually there is a solution to the privacy policy
> problem: we could require that those links be in the reviewed-and-signed
> install manifest. But we'd still have to have a dialog to stop and give the
> user the opportunity to read the policy or cancel the install if they didn't
> like the policy.)

Having a dedicated button that has to be used on 3rd party websites as well is a good idea. This could maybe also provide feedback on weather the add-on is already installed, or not…

> The attached install flows seem to be missing some cases. And I'm not quite
> sure what you mean by "3rd party"--is that hosted on a 3rd party or signed
> by a 3rd party?

In my flow 3rd party means 3rd party website. I was not aware that we will also allow 3rd parties to sign certificates. - if so, i can remove the "by mozilla" from the messages.
What cases, besides errors, are missing?
 
> You also seem to have done away with the install confirmation dialog for
> installs triggered by AMO. I understand the desire to make a nicer
> experience but it's dangerous. That means if there's ever a simple website
> flaw on AMO such as XSS (and they come up from time to time) a bad guy could
> force any install on someone without any chance to protect themselves by
> canceling the unexpected action. As a user it gives me a sense of security
> knowing sites can't just stuff things in my browser: if even a trusted site
> can't then none of them can. But I am admittedly not the average user, I
> actually like it and feel safe when my computer makes me enter the login
> password before programs can do dangerous things.
> 
> In any case, even if we do away with that on AMO we still need to design it
> for when other sites trigger installs. Also consider the case when a 3rd
> party site navigates to an AMO .xpi link (or opens one in a frame). That
> will trigger an install without the contents changing to AMO. Can we make
> sure that doesn't get a clickless UI flow?

I will add a confirmation for signed add-ons. Or who can help here in finding out if it is possible to separate these cases so that we can save on click on AMO?

> Other than the "lightweight" variety, themes are not as innocuous as people
> think--they should get a confirmation step too. ESPECIALLY if they're
> triggered elsewhere than AMO.

The themes installation flow is targeted on lightweight themes. Others will get the same flow as other add-ons.
 
> The dialogs say things like "certified by Mozilla". We will almost certainly
> be issuing certificates to 3rd parties at some point for them to sign their
> own add-ons outside our review process (but under contractual conditions
> they will be responsible for). We obviously shouldn't say "certified by
> Mozilla" in those cases. The dialogs need to be flexible enough to use text
> from the actual certificate.

If we can guarantee that certified add-ons are safe to use, we do not need to tell who signed it. I removed "by Mozilla".
Attached image preliminary-new-Add-on-Process.png (obsolete) —
modification after review with [:dveditz]
(delay before clicking install is necessary.)

missing:
- open security questions
- error messages
- multiple parallel side-loads
Attachment #8553942 - Attachment is obsolete: true
Iteration: 38.1 - 26 Jan → 38.2 - 9 Feb
(In reply to Markus Jaritz [:maritz] from comment #15)
> Created attachment 8556477 [details]
> preliminary-new-Add-on-Process.png
> 
> modification after review with [:dveditz]
> (delay before clicking install is necessary.)
> 
> missing:
> - open security questions
> - error messages
> - multiple parallel side-loads

In the mockups is "chromaticpixels.com" the name of the add-on being installed or the website installing, it's unclear. If it's the latter then we don't show the user the name of the extension they are installing until it is installed.

Can you clarify what the term "certified" means in these mockups? The "click preliminary certified" section shows a doorhanger saying that the add-on is uncertified which is confusing. I assume you mean it is signed but hasn't had full review. We should agree on terms to describe these with AMO, the information about the differences are here: https://addons.mozilla.org/en-US/developers/docs/policies/reviews

Calling uncertified add-ons malicious is too strong and I suspect some developers would take offense at that. Unverified or something else would make more sense here.
(In reply to Markus Jaritz [:maritz] from comment #12)
> The delay happens after the download of the add-on. This is already a sort
> of dealy… Is the delay after that still necessary? And if so. Is it
> necessary to repeat the delay each time the window get focus again?

Are we guaranteed the user will see the download progress, that it can't be covered by another window? (I doubt we can make that guarantee.)

The picture looks like a "door hanger" notification, and those typically go away (collapse) if something else gets focus or the user clicks somewhere. If that's what happens then that solves a lot of problems. We'd still need the intial delay, but we wouldn't need a delay for re-focus because the only way the door hanger was shown again was if the user has already clicked once on the collapse icon in the url bar. But you don't show this state so I'm not sure that's what happens.

> My idea it to combine the download and wait (as a sort of verify) into one
> dialog with a disabled install button. After download and verify (delay) the
> dialog would change to information about the typ of add-on (certified,
> prelim. cert., uncert.) and an active install button.

You may find that if you kill the look-at-me countdown timer users won't actually find the short delay noticeable or objectionable.

> Having a dedicated button that has to be used on 3rd party websites as well is a good idea.
> This could maybe also provide feedback on weather the add-on is already installed, or not…

For a legitimate site, that is absolutely a good design to use. We can't force a malicious site to do so, however: they'll use whatever they can to mislead people.

> In my flow 3rd party means 3rd party website. I was not aware that we will also allow 3rd
> parties to sign certificates. - if so, i can remove the "by mozilla" from the messages.

Only Mozilla can issue certificates and at first only Mozilla will sign install packages, but there is a plan (or at least the possibility) to issue certificates to partners so they can sign their own packages. In these cases the install packages will be completely unreviewed by Mozilla, but in theory we will have a business agreement with those partners that they won't do Bad Stuff. IMHO it would be best to say who has signed a package so users can tell the difference between Mozilla-reviewed and someone-else-reviewed packages.

> If we can guarantee that certified add-ons are safe to use, we do not need to tell who signed it.

We certainly cannot guarantee an add-on is safe to use. Mozilla-signed add-ons won't mean any more than is currently meant by AMO hosting today, namely that we've done our best to weed out malicious stuff (but we might make mistakes). Any add-on not signed by Mozilla will have even weaker guarantees: we thought those folks were OK at the time. We've seen lots of examples of formerly decent add-ons (and Chrome extensions) getting sold to people who were less upright. In the new signing system the certificate would no doubt be an asset that was part of the sale. Sure, we could revoke the certificate if we knew it was transferred, but would we find out before any damage was done?

If an add-on is signed by a name like Mozilla or Yahoo I'm sure most users would find that trustworthy. If it were signed by "Foo Emporium" all you know is that at one point Mozilla thought they knew who those people were.
Flags: needinfo?(dveditz)
Comment on attachment 8556477 [details]
preliminary-new-Add-on-Process.png

We shouldn't talk about unsigned addons being "malicious". They might be, or it just might be a developer's site and they forgot to use a developer mode version of Firefox. In developer mode we should use a warning type look, and we could say it was unreviewed and /might/ be malicious, but otherwise it's just unsigned. In release mode we're simply blocking the install so we don't have to give any judgements really, just tell people it's unsigned or corrupt.

Oh yes: there are several different reasons a file could be incorrectly signed. Do we want to tell people what they are? Might help support, might just confuse people (in which case we can leave the more specific error on the web console).
 * no signature at all  (legacy, unsupported)
 * signed with an unknown certificate (probably legacy)
 * signed with a revoked certificate  (evil)
 * broken signature (tampered/modified)  (evil, or just random corruption)

The "side-loading" case is quite different than what we currently do, which is put up a dialog showing the new ones and give users the opportunity to opt-in (by default we don't install them). The proposed notice won't work well if there's more than one (quite possible in a new Firefox install/profile). I'm also not sure if we need the restart at that point if users do opt-in since it asks pretty early. The current dialog has no space to tell users about who signed them, though.
(In reply to Markus Jaritz [:maritz] from comment #12)

> The delay happens after the download of the add-on. This is already a sort
> of dealy… Is the delay after that still necessary? And if so. Is it
> necessary to repeat the delay each time the window get focus again?
> 
> My idea it to combine the download and wait (as a sort of verify) into one
> dialog with a disabled install button. After download and verify (delay) the
> dialog would change to information about the typ of add-on (certified,
> prelim. cert., uncert.) and an active install button.

You can count the time taken during download and verification toward the 1s security delay, sure. So if the download takes 900ms, the button would only be disabled for the first 100ms.

But why delay showing the install button until after the download is finished? Why not show it right away (disabled for the first second)? The web site would have to tell us the verification status, and we'd have to consider the download "corrupt" if it lied, but that doesn't seem like a problem to me.
For add-ons that non-AMO sites want to install, please consider including a link to the extension's AMO page, along with its star rating.

  Mozilla says: prolly safe   <link to AMO policy>
  Users say: ★★★★☆            <link to AMO listing for the extension>

For sideloaded addons, you might as well show the AMO page itself, since you need something to put behind the doorhanger. Heck, why show the doorhanger at all when the AMO page has a juicy Install button on it?
(In reply to Jesse Ruderman from comment #20)
> For add-ons that non-AMO sites want to install, please consider including a
> link to the extension's AMO page, along with its star rating.
> 
>   Mozilla says: prolly safe   <link to AMO policy>
>   Users say: ★★★★☆            <link to AMO listing for the extension>
> 
> For sideloaded addons, you might as well show the AMO page itself, since you
> need something to put behind the doorhanger. Heck, why show the doorhanger
> at all when the AMO page has a juicy Install button on it?

This all assumes that the extension has a page on AMO which is less than likely for non-AMO install sources. Either way this is fine fodder for follow-up work.
Right now AMO policy lets addons do a number of objectionable things as long as they are disclosed and covered by the Privacy Policy linked on the AMO page. When we allow these same addons to be installed from elsewhere (which seems to be a requirement) they are divorced from that context and can harm users. Since the privacy policy is already part of the review process for such addons we should require the policy link to be part of the signed addon manifest, and provide a link to it (if there is one) from our built-in install flow.
Attached image preliminary-new-Add-on-Process.png (obsolete) —
Building on the current Add-On installation process I formulated a suggestion of how to unify the process:
Handling all installation process in one doorhanger that changes his content, instead of opening new dialogs for each step. In this process the doorhanger is connected to the tab the Add-On is downloaded from and forms a bridge between site-related and system-related aspects of the installation. 
Optional this can be extended by a button that can be used in AMO and third party sites to start installation and indicate the state of the Add-On (already installed, update, certified,…)
 
review of this suggestion resulted in security concerns and additional valuable feedback on how to improve and enrich the process.

this suggests the following next steps:
- agree to pursue the suggested installation process based on one continuous doorhanger (thereby optimize for most common case and extend to special cases)
- detail suggested installation process with security and engineering. (it’s function strongly depends on the detailed behavior of the doorhanger and timing to make it secure and fluid)
	- meet on Vidyo to align on the proposed process
	- integrate install-delay gracefully 
	- agree on terms / messages for different states of Add-Ons (signed, preliminary signed, unsigned) (and different signees)
	- show Add-On name and Author (Source?)
	- show Add-On privacy policy in doorhanger ?
	- unsigned Add-On: default to not install ?


- handle side loaded Add-Ons (especially multiple parallel side loads.) (default to not load it) - probably in design of about:addons (or about:preferences)
- create error messages
- finalize UI screen flows (doorhanger style does not match the currently used one)

next optional steps:
- design install button (and states) (for AMO and 3rd party)
- include AMO rating in installation process (if on AMO)
Attachment #8560498 - Flags: ui-review?(philipp)
Attachment #8556477 - Attachment is obsolete: true
Attached image AIP_certified_flow.gif (obsolete) —
As discussed on Friday with Philipp, a proposed flow of installing a certified add-on. (This might be better suited for a blog-post on add-ons)
Attachment #8561741 - Flags: feedback?(philipp)
Iteration: 38.2 - 9 Feb → 38.3 - 23 Feb
Iteration: 38.3 - 23 Feb → 39.1 - 9 Mar
Comment on attachment 8561741 [details]
AIP_certified_flow.gif

That looks like a great default flow. Having everything take place inside the same doorhanger makes the process a lot less jarring (plus: no modals!).

When we consider the various special cases we should make it a point to preserve the simplicity we have in this flow for the majority of cases.
Attachment #8561741 - Flags: feedback?(philipp) → feedback+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
There are still some issues and questions to be answered, we aren't done here.

In the mockups, what is "chromaticpixels.com" and the icon immediately next to it? I'm assuming it is the website (hostname only?) and its favicon but it doesn't match the website in the tab you show in the mockups.

You show the extension displaying its own startup page after our confirmation doorhanger. Did we decide on exactly how to do this? Do you want to defer extension startup until after the user dismisses the doorhanger, after a fixed amount of time ...

I'm still confused by what "uncertified" means in this UI. Looks like we show it in the case where it has been preliminarily reviewed by AMO? Those two things don't jive in my head.

There is a "???" in the uncertified line that needs filling in.

Is the intention to get rid of the install whitelist immediately or leave it in place until the signing requirements become hard (probably a questions for Dan).

Both me and Dan pointed out that we shouldn't be calling unsigned extensions malicious. We don't know if they are or not.

What should happen when the user closes the tab or even window in the middle of installation?

Is there a reason the doorhanger showing that an extension and a lightweight theme are installed are so different? Wouldn't it make sense to unify these?

Is the imagery shown here final? I ask because the buttons in the doorhangers look quite different to how things look elsewhere in Firefox. We're going to need design specs and imagery for implementation for all of this.
Status: RESOLVED → REOPENED
Flags: needinfo?(mjaritz)
Resolution: FIXED → ---
Can we file a new bug to track the rest of the work here?
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #27)
> Can we file a new bug to track the rest of the work here?

We can, I don't know what the benefit is to fragmenting the discussion though
Hello Dave, Gavin,
I have written some bugs to fragment the discussion in reasonable sub-topics. These are currently reviewed by Philipp and I will file them as soon as I get feedback.

To address your questions: I see this bug as setting a vision for what we want an optimum install to look like and agree on that. (Attachment #8561741 [details])
With that being achieved we can now focus on how we can implement this in detail (in close collaboration with engineering and security), and deal with all non-optimum install cases in a seperate bug. Where I see the second part as a separate discussion that will start with a focus on content, opposed to the first, that can deal with how we in detail implement one continuous doorhanger for most of addon installs.
Flags: needinfo?(mjaritz)
Blocks: 1139656
(In reply to Dave Townsend [:mossop] from comment #28)
> (In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #27)
> > Can we file a new bug to track the rest of the work here?
> 
> We can, I don't know what the benefit is to fragmenting the discussion though

New bugs for new work. Discussion "fragmentation" is not really a problem in practice - very easy to cross-reference and link bugs.
Iteration: 39.1 - 9 Mar → 39.2 - 23 Mar
Status: REOPENED → ASSIGNED
Iteration: 39.2 - 23 Mar → 39.3 - 30 Mar
Current basic install flow see attachment 8578019 [details] 
https://bugzilla.mozilla.org/attachment.cgi?id=8578019&action=edit
150316_All-Doorhanger-Add-On-Install.jpg
Iteration: 39.3 - 30 Mar → 40.1 - 13 Apr
Attached image 150331_All-Doorhanger-Add-On-Install.jpg (obsolete) —
Updated UI flow based on the current fast approach to block install of uncertified add-ons by default in 39.
Attachment #8560498 - Attachment is obsolete: true
Attachment #8561741 - Attachment is obsolete: true
Blocks: 1149654
No longer blocks: 1123918
No longer blocks: 1149654
Flags: needinfo?(shorlander) → needinfo?
Attached image 150402_All-Doorhanger-Add-On-Install.jpg (obsolete) —
Updated flow to reflect installs from local file system (drag&drop, addon manager, sideloaded).
Matej: Can you please review the copy again. Especially to see how we want to handle "This site …" as we also use it for installs/blocks originating from the local file system.
Flags: needinfo? → needinfo?(matej)
Looks good. Just a few thoughts:

• I would change the button that says "Restart Now" to just "Restart" 

• One string says "extension" instead of "add-on" (Firefox has prevented this site from installing an uncertified extension). Is that deliberate?

• Changes to the screen marked "new domain" — Are you sure you want to leave this page? If you do, the add-on will not be installed.

Thanks.
Flags: needinfo?(matej)
> If the add-on provides an own confirmation, this will be delayed by 2 seconds to ensure the user can see this confirmation.

How will you prevent add-ons from showing confirmations for the first 2 seconds? Will they not actually be installed until the "... has been installed successfully" thing has been visible for 2 seconds?
> If add-on-install tab is closed in the background, it will be focused to ask if the install should be canceled.

> New domain: The page is asking you to confirm that you want to leave

Please do not implement any such confirmation. The web may never fully recover from the mistake of adding onbeforeunload, but we should not make it worse by adding another way for web sites to pester users who are trying to leave. (See dependencies of https://bugzilla.mozilla.org/show_bug.cgi?id=eviltraps)

> On [verify] add-on the user will be pulled back to the tab verifying the add-on.

Again, this adds a new vector for annoying users, and one that won't be easy to fix if the API is only designed to support this flow.

I reiterate the last paragraph of comment 19. All these confusing and abuse-inviting states go away if we design the API and flow around the "Install" button being available quickly even for large add-ons.
(In reply to Jesse Ruderman from comment #36)
> > If add-on-install tab is closed in the background, it will be focused to ask if the install should be canceled.
> 
> > New domain: The page is asking you to confirm that you want to leave
> 
> Please do not implement any such confirmation. The web may never fully
> recover from the mistake of adding onbeforeunload, but we should not make it
> worse by adding another way for web sites to pester users who are trying to
> leave. (See dependencies of
> https://bugzilla.mozilla.org/show_bug.cgi?id=eviltraps)

You think sites will initiate long-running add-on installs in order to stop a user from leaving?

> > On [verify] add-on the user will be pulled back to the tab verifying the add-on.
> 
> Again, this adds a new vector for annoying users, and one that won't be easy
> to fix if the API is only designed to support this flow.

Note that this piece is no different to the add-on install flow we've had since before Firefox 1.0. Not saying that it is ideal but we aren't making things worse here.
(In reply to Jesse Ruderman from comment #36)
> > If add-on-install tab is closed in the background, it will be focused to ask if the install should be canceled.
>
> I reiterate the last paragraph of comment 19. All these confusing and
> abuse-inviting states go away if we design the API and flow around the
> "Install" button being available quickly even for large add-ons.

I think this is a great idea and can provide an even simpler add-on install flow. I see this as a good next step after implementing the certification process. I filed a bug for it: https://bugzilla.mozilla.org/show_bug.cgi?id=1153226
Attached image 150410_Add-on-Process-v0.10.jpg (obsolete) —
Updated flow with copy checked by :matej.
Final icons will be provided by :shorlander.
Flow is complete, warnings for installed add-ons are tracked in bug 1148403, and some follow up work can be found here: 1153226, 1153303 .
Attachment #8586113 - Attachment is obsolete: true
Attachment #8587657 - Attachment is obsolete: true
Attachment #8590925 - Flags: ui-review?(philipp)
> You think sites will initiate long-running add-on installs in order to stop a user from leaving?

Yes. Sites abuse onbeforeunload now and I see no reason this would be different.
(In reply to Jesse Ruderman from comment #40)
> > You think sites will initiate long-running add-on installs in order to stop a user from leaving?
> 
> Yes. Sites abuse onbeforeunload now and I see no reason this would be
> different.

So we would only block if an add-on download was in progress. This means the site has to keep an add-on downloading to stop a user navigating away. And remember sites can't even start an add-on download without the user clicking allow in the notification bar. beforeunload is an easy hack, this is way beyond that.
> And remember sites can't even start an add-on download without the user clicking allow
> in the notification bar.

Is that going to remain true? I hope so but people keep talking about wanting to remove it.
Comment on attachment 8590925 [details]
150410_Add-on-Process-v0.10.jpg

Looking good!
Icon question: will we modify the icon of uncertified add-ons somehow? In your mocks there's a red puzzle piece, but I assume that the add-on logo would actually show up there (which might not look threatening at all). This actually concerns all of the work on unsigned add-ons, but can be solved in a visual design bug (but should probably be indicated here as well).

Minor nit: I *think* some of your arrow colors don't match anymore ;)
Attachment #8590925 - Flags: ui-review?(philipp) → ui-review+
Iteration: 40.1 - 13 Apr → 40.2 - 27 Apr
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #43)
> Comment on attachment 8590925 [details]
> 150410_Add-on-Process-v0.10.jpg
> 
> Looking good!
> Icon question: will we modify the icon of uncertified add-ons somehow? In
> your mocks there's a red puzzle piece, but I assume that the add-on logo
> would actually show up there (which might not look threatening at all). This
> actually concerns all of the work on unsigned add-ons, but can be solved in
> a visual design bug (but should probably be indicated here as well).
> 
> Minor nit: I *think* some of your arrow colors don't match anymore ;)

I am planing to show an icon there, not the add-on logo. Icons for that have been created by shorelander and received this morning: http://people.mozilla.org/~shorlander/mockups/Add-ons-Install-Flow/Add-ons-Install-Flow.html

*will check the arrow-colors.
No longer depends on: 1047247, 1148403
Depends on: 1148403
Attached image 150415_Add-on-Process-v0.11.jpg (obsolete) —
Update following UI review (by :phlsa):
- updated arrow-colors

and visual design input (by :shorlander):
for visual design files see: 
http://people.mozilla.org/~shorlander/mockups/Add-ons-Install-Flow/Add-ons-Install-Flow.html

- provide icons for all cases (Kev: Do we want red or grey puzzle pieces for unreviewed?)
- less spacing between elements and text (to match default doorhanger style)
- alternative install add-on "learn more…" placement (to match default doorhanger style)
  (same for install uncertified add-on, and local install cases)
- bold add-on name in restart (to align with other doorhangers)
- rephrase error (remove url in string) (already shown in the line above)
- "learn more…" in serrate line in block add-on (to match default doorhanger style)

Depending on how we decide to phrase unreviewed/uncertified/unsigned will we need to modify most strings.

:shorlander will provide the individual icons here as well.
Attachment #8590925 - Attachment is obsolete: true
Flags: needinfo?(shorlander)
(In reply to Daniel Veditz [:dveditz] from comment #42)
> > And remember sites can't even start an add-on download without the user clicking allow
> > in the notification bar.
> 
> Is that going to remain true? I hope so but people keep talking about
> wanting to remove it.

I would very much like to leave out this interaction if we can. We do so on AMO already, and maybe we have another way to know that an add-on is legitimate before downloading it from a third-party-site as well…
:shorlander can you please updated the red unverified icons to be yellow as discussed, and provide the assets for the icons you created. Thank you.
:kev please review the unverified add-on install strings:
https://docs.google.com/document/d/1r_KdSfOms3uwNJjWykSBusMjUHwqR1uw0r5H-gG_4k8/edit#

I will then upload an updated flow and care about the sideloaded case Bug 1138898.
Flags: needinfo?(kev)
Whiteboard: [ux] → [ux][fxsearch][searchhijacking]
Priority: -- → P4
Iteration: 40.2 - 27 Apr → 40.3 - 11 May
Final interaction flow and strings.

Final icons and visual polish will be provided by Stephen (:shorlander)
http://people.mozilla.org/~shorlander/mockups/Add-ons-Install-Flow/Add-ons-Install-Flow.html
Attachment #8592908 - Attachment is obsolete: true
Flags: needinfo?(kev)
(In reply to Markus Jaritz [:maritz] from comment #48)
> Created attachment 8598797 [details]
> 150428_Add-on-Process-v0.12.jpg
> 
> Final interaction flow and strings.
> 
> Final icons and visual polish will be provided by Stephen (:shorlander)
> http://people.mozilla.org/~shorlander/mockups/Add-ons-Install-Flow/Add-ons-
> Install-Flow.html

We need the final icons as soon at possible, when can we expect them?
(In reply to Dave Townsend [:mossop] from comment #49)
> (In reply to Markus Jaritz [:maritz] from comment #48)
> > Created attachment 8598797 [details]
> > 150428_Add-on-Process-v0.12.jpg
> > 
> > Final interaction flow and strings.
> > 
> > Final icons and visual polish will be provided by Stephen (:shorlander)
> > http://people.mozilla.org/~shorlander/mockups/Add-ons-Install-Flow/Add-ons-
> > Install-Flow.html
> 
> We need the final icons as soon at possible, when can we expect them?

I am out until Wednesday on a research trip. So likely Thursday at the earliest.
Flags: needinfo?(shorlander)
Blocks: 1162584
Rank: 40
Whiteboard: [ux][fxsearch][searchhijacking] → [hijacking][ux][fxsearch]
Iteration: 40.3 - 11 May → 41.1 - May 25
(In reply to Dave Townsend [:mossop] from comment #49)
> (In reply to Markus Jaritz [:maritz] from comment #48)
> > Created attachment 8598797 [details]
> > 150428_Add-on-Process-v0.12.jpg
> > 
> > Final interaction flow and strings.
> > 
> > Final icons and visual polish will be provided by Stephen (:shorlander)
> > http://people.mozilla.org/~shorlander/mockups/Add-ons-Install-Flow/Add-ons-
> > Install-Flow.html
> 
> We need the final icons as soon at possible, when can we expect them?

There was a specific bug for the icon assets so I stuck them there: bug 1144599
No longer blocks: 1162584
Thank you for the design specs Stephen!
Flow and Visual Design done.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: