Closed Bug 1047247 Opened 10 years ago Closed 9 years ago

[UX] Add-on Manager should give a distinctive look to unsigned add-ons

Categories

(Toolkit :: Add-ons Manager, enhancement, P1)

enhancement
Points:
5

Tracking

()

RESOLVED FIXED
Iteration:
41.1 - May 25

People

(Reporter: dveditz, Assigned: designakt)

References

Details

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

Attachments

(2 files, 4 obsolete files)

Add-ons which are unsigned or have invalid signatures should be given a distinctive look in the Add-on manager. This should happen whether or not we have disabled the add-on (which depends on a pref setting). I imagine we can re-use the styling used for vulnerable plugins but with different error/warning text.
We need some UX mockups for the following states being handled in the add-ons manager UI:

* Revoked cert (similar or maybe the same as a blacklisted add-on)
* Unsigned/invalid cert (add-ons that haven't been updated, or that have been packaged incorrectly/not approved by Mozilla)
* Corrupted signature (add-ons that were originally OK, but have been modified/hacked and thus are now no longer considered "safe" to enable)

dveditz has more detail about when these situations would occur and possible edge cases.
QA Whiteboard: [qa-]
Flags: firefox-backlog+
Summary: Add-on Manager should give a distinctive look to unsigned add-ons → [UX] Add-on Manager should give a distinctive look to unsigned add-ons
Invalid certificate & corrupted signature should probably be considered the same from a user perspective. That distinction in the UI would over-complicate things. (though, it should say the details somewhere) A smart malware creator wouldn't try to release an addon with a corrupted signature knowing it'd be blocked; they'd re-sign with a bogus cert and try and pass it off as good. I argue that for newly installed addons, both invalid & corrupted should get the same UI. For addons already installed at the time of implementation of this, unaccepted certs should probably be treated similar to unsigned so users know it's not anything new.
Whiteboard: [ux]
Points: --- → 5
QA Whiteboard: [qa-]
Flags: qe-verify-
Depends on: 1038072
Assignee: nobody → mjaritz
Status: NEW → ASSIGNED
Iteration: --- → 40.1 - 13 Apr
Blocks: 1149657
No longer blocks: signed-addons
Blocks: 1149702
No longer blocks: 1149657
[Tracking Requested - why for this release]:

First two stages of add-ons signing work are targeted at Firefox 39.
Yesterday in our add-on ux meeting we briefly talked about the different cases, how we can differentiate them and what we can do for the user. I recall that we will for the first version probably treat all cases the same, but in further versions might have potential to help the user in certain cases. (either by healing the add-on ourselfs, or giving the user a clear hint to what they might do. - replace, reload, alternatives) Only with possible different action for the users, it is helpful to differentiate cases.
Could you please give me feedback on what is possible there?
Flags: needinfo?(dveditz)
Flags: needinfo?(dtownsend)
Iteration: 40.1 - 13 Apr → 40.2 - 27 Apr
(In reply to Markus Jaritz [:maritz] from comment #4)
> Yesterday in our add-on ux meeting we briefly talked about the different
> cases, how we can differentiate them and what we can do for the user. I
> recall that we will for the first version probably treat all cases the same,
> but in further versions might have potential to help the user in certain
> cases. (either by healing the add-on ourselfs, or giving the user a clear
> hint to what they might do. - replace, reload, alternatives) Only with
> possible different action for the users, it is helpful to differentiate
> cases.
> Could you please give me feedback on what is possible there?

For the first version at least all we should be targeting is displaying a note in the add-on list that the add-on is unsigned (or whatever term we decide to use) so users know why they can't enable the add-on. This is similar to the blocklist/incompatible cases you can see in the screenshot here:

https://www.dropbox.com/s/nr99782t3h692ym/Screenshot%202015-04-14%2008.44.50.png?dl=0

Ideally we'd reuse the same styling both for consistency and ease of implementation.
Flags: needinfo?(dtownsend)
Ditto Dave.

For the future I don't think we need to worry about "self-heal" -- that will come with its own UI if it needs it. I'm not sure what "hints" we would ever be able to reasonably give users--I don't believe we could ever reasonably maintain a list of "If you have broken this, try that", although maybe if enough people have a particular broken add-on it would be worth add-ing as a self-heal recipe.

We do have a couple of different broken states though, and possible solutions differ. Even if we don't directly suggest fixes in the product making a note of the different error cases might help with tech/community support.

UNSIGNED - either old or a dev version. Nothing for the average user to do. Motivated users could potentially fork the add-on and get their fork signed. Developer types could run a dev build and flip the pref to get it working again.

CORRUPT (valid but broken signature) - if it came that way I'm not sure what users could do (other than worry about a MITM or hacked site). If it was at one point good and then became broken possibly some local malware is trying to modify it: re-installing might fix the problem. It would be possible for users to get a dev build and flip the pref but inadvisable for this state so it is worth making the distinction.
Flags: needinfo?(dveditz)
Blocks: 1120996
No longer blocks: 1120996
Blocks: 1148403
Thank you for the screenshot Dave. Staying consistent is the way to go. The current styling however does not really match the new add-ons manager style. I will consolidate with visual design on that and see what we can do to add our 2 new cases without getting too colorful.

Dave, will all these cases remain once we have signed add-ons? 
Or are we replacing the red ones with our signed cases?

As Daniel describes it, two separate cases might help the users:

- "[Add-on Name] has been disabled as it has not been reviewed."
- "[Add-on Name] has been disabled as it has been corrupted."
- "[Add-on Name] has been disabled as it has been corrupted. Update now" (if we know form where to re-install but can not do that automatically)

and for pref set to allow un-reviewed:
- "[Add-on Name] has not been reviewed. Use with caution. More Information"
Flags: needinfo?(dtownsend)
(In reply to Markus Jaritz [:maritz] from comment #7)
> Thank you for the screenshot Dave. Staying consistent is the way to go. The
> current styling however does not really match the new add-ons manager style.
> I will consolidate with visual design on that and see what we can do to add
> our 2 new cases without getting too colorful.
> 
> Dave, will all these cases remain once we have signed add-ons? 
> Or are we replacing the red ones with our signed cases?

It's really your call whether you want to add new cases or merge the unsigned case into one of the others. It will certainly still be true that as well as being unsigned add-ons can be incompatible or blocklisted.
Flags: needinfo?(dtownsend)
Attached image 150417_Addons_Warnings.jpg (obsolete) —
All possible warnings/notifications addons can have.
Dave: If we can automatically update addons with broken signatures we would not need the corrupted state. Is this possible?
Did I miss any states? If not, I ask Matej to check the copy.

Michael, please comment on the visual design.
Flags: needinfo?(mmaslaney)
Flags: needinfo?(dtownsend)
(In reply to Markus Jaritz [:maritz] from comment #9)
> Created attachment 8594029 [details]
> 150417_Addons_Warnings.jpg
> 
> All possible warnings/notifications addons can have.
> Dave: If we can automatically update addons with broken signatures we would
> not need the corrupted state. Is this possible?

As we mentioned in the meeting there will always be cases that we can't fix in this way but we should push off attempts to fix broken add-ons to later work. It sounded like we were generally agreed on just displaying the same unverified message for both cases.
Flags: needinfo?(dtownsend)
(In reply to Markus Jaritz [:maritz] from comment #9)
> Created attachment 8594029 [details]
> 150417_Addons_Warnings.jpg
> 
> All possible warnings/notifications addons can have.
> Dave: If we can automatically update addons with broken signatures we would
> not need the corrupted state. Is this possible?
> Did I miss any states? If not, I ask Matej to check the copy.
> 
> Michael, please comment on the visual design.

Looks good, Markus. I would suggest removing the inner gradients from the status icons.
Flags: needinfo?(mmaslaney)
Attached image 150421_Addons_Warnings.jpg (obsolete) —
Updated Add-On Warning Messages. (removed corrupted case, as discussed last friday)
Micheal, do you have the assets you commented on. I just used the assets currently used in the browser. Please update the visual design as you see fit.
(current .sketch file: http://cl.ly/1D0M3s3f3v09) Thank you.
Attachment #8594029 - Attachment is obsolete: true
Flags: needinfo?(mmaslaney)
Attached image 150422_Addons_Warnings.jpg (obsolete) —
Updated with new icon styles and modified strings.
Attachment #8595464 - Attachment is obsolete: true
Attached image 150422_Addons_Warnings.jpg (obsolete) —
Updated with new icon styles and modified strings.
Attachment #8596150 - Attachment is obsolete: true
Whiteboard: [ux] → [ux][fxsearch][searchhijacking]
Priority: -- → P1
Iteration: 40.2 - 27 Apr → 40.3 - 11 May
Comment on attachment 8596160 [details]
150422_Addons_Warnings.jpg

please review new add-on warning style
Attachment #8596160 - Flags: ui-review?(shorlander)
updated unverified add-on warning (when pref is set to allow unverified)
Attachment #8596160 - Attachment is obsolete: true
Attachment #8596160 - Flags: ui-review?(shorlander)
Attachment #8601334 - Flags: ui-review?(shorlander)
See Also: → 1162500
Rank: 10
Whiteboard: [ux][fxsearch][searchhijacking] → [hijacking][ux][fxsearch]
Iteration: 40.3 - 11 May → 41.1 - May 25
Comment on attachment 8601334 [details]
150505_Addons_Warnings.jpg

LGTM
Attachment #8601334 - Flags: ui-review?(shorlander) → ui-review+
Thanks for the review. With that we are done here.
Dave, how should I provide assets for visual design (especially the background, the warning/error icons and the default add-on icon) & is there anything else you need to implement the visual design?
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to Markus Jaritz [:maritz] (UX) from comment #20)
> Thanks for the review. With that we are done here.
> Dave, how should I provide assets for visual design (especially the
> background, the warning/error icons and the default add-on icon) & is there
> anything else you need to implement the visual design?

There isn't anything new in this design so there were no assets to be added. If there are changes to be made that I'm missing file a new bug and attach the appropriate assets there.
(In reply to Dave Townsend [:mossop] from comment #21)
> (In reply to Markus Jaritz [:maritz] (UX) from comment #20)
> > Thanks for the review. With that we are done here.
> > Dave, how should I provide assets for visual design (especially the
> > background, the warning/error icons and the default add-on icon) & is there
> > anything else you need to implement the visual design?
> 
> There isn't anything new in this design so there were no assets to be added.
> If there are changes to be made that I'm missing file a new bug and attach
> the appropriate assets there.

Filed bug 1169679 to follow up on the visual design aspects.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: