In the »Add On Signing Team Notes« google-doc it is mentioned that for Firefox 39 (June 30 release) the users will be warned when installing/using unsigned add-ons. What will be the steps behind that and how will this be presented to the user. How many signed vs unsigned addons will there be at that time? What is the motivation behind telling the user? What can/should the user do when seeing this warning? (Stop using the addon? Ignore it? Know that they now use an unsafe addon? …)

Isn't this just the "click uncertified (current)" line here: https://bug1120996.bugzilla.mozilla.org/attachment.cgi?id=8560498? I filed bug 1148021 for implementing that in the install flow.

Yes, this bug is about the warning users get when installing an addon, and the warning they get for using uncertified addons. As I understand we have decided to accelerate the process so that users will not be warned, but rather told that the unsigned addons they are using have been disabled. A Message for such action should best not appear to any user as we hopefully have most frequently used addons certified by the time this becomes active. However we can do our best to communicate to the user why their addons are disabled, where to get signed addons (as Amy suggested), or even suggest possible replacements within the message itself. I attached a draft for such a message for us to have a discussion about what we can do. Dave, can we implement such a message for 39 and where can it be places? Is about:addons the right place? Do we need to show the message before we load any other tabs? (Will mentioned that users might rely on addons blocking something and that this might be a security issue for them if we load tabs without a certain addon being active.) Amy, Matej, how can we best communicate to the user why their addons are no longer working? I assume users that will get this message will not be happy that their addons are suddenly not working any longer. Therefore, besides offering replacement we might give them a reason in form of a short text. (see attachment for my first draft.)

Hi Markus -- Here are a few edits from me: Uncertified add-ons have been deactivated The following add-ons have been deactivated because they are not certified as safe to use in Firefox. You can install the suggested replacements below or find others at addons.mozilla.org. Learn more about our efforts to help keep you safe online.

Update based on the new copy.

Sorry for the delay in chiming in. Matej's copy is great. The only thing I would add is perhaps a message and link for the developer of the uncertified add-on. Since we don't have their email addresses and have limited means to reach them outside the product, it's possible that many of them will find out here.

Amy, what would you want this message to communicate? And where should it link to?

Perhaps a link somewhere in box labeled "Some Uncertified Add-on" that says, "Are you the developer of this add-on?" and link to https://wiki.mozilla.org/Addons/Extension_Signing

(In reply to Markus Jaritz [:maritz] from comment #2) > Created attachment 8585476 [details] > 150330_Unsigned_Addons_Blocked_Message.png > > Yes, this bug is about the warning users get when installing an addon, and > the warning they get for using uncertified addons. > As I understand we have decided to accelerate the process so that users will > not be warned, but rather told that the unsigned addons they are using have > been disabled. > > A Message for such action should best not appear to any user as we hopefully > have most frequently used addons certified by the time this becomes active. > However we can do our best to communicate to the user why their addons are > disabled, where to get signed addons (as Amy suggested), or even suggest > possible replacements within the message itself. > > I attached a draft for such a message for us to have a discussion about what > we can do. This is looking good but we're going to need to defer the part about listing alternative add-ons. We have no way to do that right now. > Dave, can we implement such a message for 39 and where can it be places? Is > about:addons the right place? Do we need to show the message before we load > any other tabs? (Will mentioned that users might rely on addons blocking > something and that this might be a security issue for them if we load tabs > without a certain addon being active.) From the email thread this can't necessarily happen immediately on startup as we have to do some work to check the signing status of the installed add-ons, we also want to use this to be re-used so that in the future if we detect an add-on has become unsigned we can disable and warn the user. So we want to just pop open an about:addons tab in that case? An alternative would be a notification bar saying that some add-ons have been disabled with a button to open this UI in the add-ons manager if they want the details, that way it doesn't get in the way of the user. A challenge here is that we may want the user to restart their browser so we can actually disable the extensions properly, not sure how important it is to work that in. As for whether this is doable by 39, that is going to be difficult but that's true of this whole project so...

I think this also needs a separate section on the left so the user can switch back to extensions when they want to.

[Tracking Requested - why for this release]: First two stages of add-ons signing work are targeted at Firefox 39.

Tracking this for 39+ since it's aiming to launch with 39.

(In reply to Dave Townsend [:mossop] from comment #10) > This is looking good but we're going to need to defer the part about listing > alternative add-ons. We have no way to do that right now. OK, so we can only refer the user to AMO to find replacement on their own… That is not a good experience. > From the email thread this can't necessarily happen immediately on startup > as we have to do some work to check the signing status of the installed > add-ons, we also want to use this to be re-used so that in the future if we > detect an add-on has become unsigned we can disable and warn the user. So we > want to just pop open an about:addons tab in that case? So far I did not consider the case that this will might appear repeatedly. This is a far more difficult scenario that we might work on after finishing this first round of warnings. So far I expected this to be a rather important warning for users that have uncertified add-ons on their system. It might appear a a safety feature, but it will definitely annoy users if we just open something, and deactivate something they potentially have been using. But if we do, we can not hide this message. Without any option to offer any help (e.g. offer alternatives) this will even be worse. > An alternative would be a notification bar saying that some add-ons have > been disabled with a button to open this UI in the add-ons manager if they > want the details, that way it doesn't get in the way of the user. This might be an alternative. Currently I am leaning towards more prominent placement with the hope that not a lot of users need to see that, unless they have some really bad add-ons on their system. > A challenge here is that we may want the user to restart their browser so we > can actually disable the extensions properly, not sure how important it is > to work that in. Wow. Better not integrate that for the first version. It will add one more step of annoyance. Can we just deactivate it the next time the user closes the browser?

(In reply to Markus Jaritz [:maritz] from comment #14) > (In reply to Dave Townsend [:mossop] from comment #10) > > This is looking good but we're going to need to defer the part about listing > > alternative add-ons. We have no way to do that right now. > > OK, so we can only refer the user to AMO to find replacement on their own… > That is not a good experience. > > > > From the email thread this can't necessarily happen immediately on startup > > as we have to do some work to check the signing status of the installed > > add-ons, we also want to use this to be re-used so that in the future if we > > detect an add-on has become unsigned we can disable and warn the user. So we > > want to just pop open an about:addons tab in that case? > > So far I did not consider the case that this will might appear repeatedly. > This is a far more difficult scenario that we might work on after finishing > this first round of warnings. Ok, but we need that warning for Firefox 39 and I'm not sure how it differs. In both cases we have detected add-ons that are uncertified and have to disable them and tell the user about it. > So far I expected this to be a rather important warning for users that have > uncertified add-ons on their system. It might appear a a safety feature, but > it will definitely annoy users if we just open something, and deactivate > something they potentially have been using. But if we do, we can not hide > this message. > Without any option to offer any help (e.g. offer alternatives) this will > even be worse. This isn't really any different to the existing situation where we disable add-ons that are no longer compatible with the application. > > An alternative would be a notification bar saying that some add-ons have > > been disabled with a button to open this UI in the add-ons manager if they > > want the details, that way it doesn't get in the way of the user. > > This might be an alternative. Currently I am leaning towards more prominent > placement with the hope that not a lot of users need to see that, unless > they have some really bad add-ons on their system. > > > > A challenge here is that we may want the user to restart their browser so we > > can actually disable the extensions properly, not sure how important it is > > to work that in. > > Wow. Better not integrate that for the first version. It will add one more > step of annoyance. Can we just deactivate it the next time the user closes > the browser? We can, but if we're concerned that these add-ons are malicious in nature then we're opening the user up to additional risk by not restarting.

After UX review I updated the design to start with a small notification. If we need to consider suggesting restart, we could do so in the notification bar next to learn more. However I do not see that we need to force the user to restart as Mike Connor mentioned, it is likely that users have been living with this add-ons for a long time already. So one more restart might not do much harm. Micheal: Can you please give me a UI review for the design. I started based on the styling from bug 989469. Matej: Can you please review copy of the refined design.

(In reply to Markus Jaritz [:maritz] from comment #16) > Created attachment 8587647 [details] > 150402_Unsigned_Addons_Blocked_Message.jpg > > After UX review I updated the design to start with a small notification. If > we need to consider suggesting restart, we could do so in the notification > bar next to learn more. However I do not see that we need to force the user > to restart as Mike Connor mentioned, it is likely that users have been > living with this add-ons for a long time already. So one more restart might > not do much harm. > Micheal: Can you please give me a UI review for the design. I started based > on the styling from bug 989469. > Matej: Can you please review copy of the refined design. This looks good though we're not going to have the styling from bug 989469 in time unfortunately. I'd still suggest that instead of highlighting the extensions panel on the left we add a new temporary section to use. This list can contain things other than extensions, currently experiments but possibly themes as well.

Comment on attachment 8586071 [details] 150331_Unsigned_Addons_Blocked_Message.png Looking good. One nit pick, I would add some additional space between the header and copy of the first paragraph.

(In reply to Dave Townsend [:mossop] from comment #17) > This looks good though we're not going to have the styling from bug 989469 > in time unfortunately. I'd still suggest that instead of highlighting the > extensions panel on the left we add a new temporary section to use. This > list can contain things other than extensions, currently experiments but > possibly themes as well. I can update with current style if needed. First I want to get the flow right and define the strings. Dave: is this what you suggested? If we not only have extension-add-ons that will be deactivated, but also want to show deactivated themes and experiments (what are those experiments? And how can I see them?), then we need a top level entry as you suggested.

(In reply to Markus Jaritz [:maritz] from comment #19) > Created attachment 8589162 [details] > 150407_Unsigned_Addons_Blocked_Message.jpg > > (In reply to Dave Townsend [:mossop] from comment #17) > > This looks good though we're not going to have the styling from bug 989469 > > in time unfortunately. I'd still suggest that instead of highlighting the > > extensions panel on the left we add a new temporary section to use. This > > list can contain things other than extensions, currently experiments but > > possibly themes as well. > > > I can update with current style if needed. First I want to get the flow > right and define the strings. Dave: is this what you suggested? > If we not only have extension-add-ons that will be deactivated, but also > want to show deactivated themes and experiments (what are those experiments? > And how can I see them?), then we need a top level entry as you suggested. This looks good. Experiments are a special kind of add-on that we automatically install on certain users to test out new features and get data back about how they use them. Not sure how you can test one yourself specifically, apparently I have an old one installed on my profile still: https://www.dropbox.com/s/xmajchsswj09fv4/Screenshot%202015-04-07%2009.49.31.png?dl=0 Did you want the Uncertified Add-ons section to display permanently as long as the user has uncertified add-ons? Here are the options that should be doable: 1. The uncertified add-ons section is always visible even if empty. 2. If the user has uncertified add-ons then the section is visible. 3. Normally invisible but when the notification appears and they click the section appears and remains open until the next time the user visits the add-ons manager (see the recent updates section for an example). 4. As 3 but disappears as soon as the user switches to another section, like the search section. The good news is that we're no longer targeting 39 for this so if we can get the final UX answers in bug 989469 then we should be able to have the new styling in place too.

I'm concerned about the "certified as safe to use" language -- I can guarantee we will sign add-ons that are unsafe and even some that turn out to be malicious. I don't mind the "certified" part as long as we're vague about what that means ("certified by Mozilla as genuine"). I don't think it would be too mysterious to users to simply say they are "unsigned": factually true and that wording is used more and more. "Safe to use" invites trouble when they aren't, and invites challenge along the lines of "who are you to say what's safe? My anti-virus says it's not malicious, that's good enough for me."

I'm not keen on a separate Add-on Manager category for uncertified add-ons, gives them too much prominence. Can't we just stick them at the bottom of the list like we do with other disabled add-ons? Their color will make them stand out, and we could group them separately from user-disabled ones if color alone isn't enough.

(In reply to Markus Jaritz [:maritz] from comment #16) > Created attachment 8587647 [details] > 150402_Unsigned_Addons_Blocked_Message.jpg > > After UX review I updated the design to start with a small notification. If > we need to consider suggesting restart, we could do so in the notification > bar next to learn more. However I do not see that we need to force the user > to restart as Mike Connor mentioned, it is likely that users have been > living with this add-ons for a long time already. So one more restart might > not do much harm. > Micheal: Can you please give me a UI review for the design. I started based > on the styling from bug 989469. > Matej: Can you please review copy of the refined design. I would just change the CTA for developers: If you're a developer interested in certifying your add-on, please read our manual. Thanks.

(In reply to Daniel Veditz [:dveditz] from comment #21) > I'm concerned about the "certified as safe to use" language -- I can > guarantee we will sign add-ons that are unsafe and even some that turn out > to be malicious. I don't mind the "certified" part as long as we're vague > about what that means ("certified by Mozilla as genuine"). I don't think it > would be too mysterious to users to simply say they are "unsigned": > factually true and that wording is used more and more. > > "Safe to use" invites trouble when they aren't, and invites challenge along > the lines of "who are you to say what's safe? My anti-virus says it's not > malicious, that's good enough for me." I can understand that we are at risk if we say something is safe and are uncertain if we can keep up with that promise. If we tell users (hopefully not too many) that we have turned of some of their add-ons, I feel that we ought to give them an explanation of why we did so. The more vague that is the less understanding for our behavior we can expect. I hope Matej can help us out with that wording. (sorry to bug you again so soon.) Maybe it is as easy as: "… they are not certified to use in Firefox." but that is up to you native speakers. Concerning the terms "certified" and "signed" that are currently used as kind of synonymous: I have the feeling that certified might be easier understandable for non-technical users. Again, that decision is up to you native speakers. But we definitely need to use one of these terms consistently. Daniel Veditz [:dveditz] from comment #22) > I'm not keen on a separate Add-on Manager category for uncertified add-ons, > gives them too much prominence. Can't we just stick them at the bottom of > the list like we do with other disabled add-ons? Their color will make them > stand out, and we could group them separately from user-disabled ones if > color alone isn't enough. I had such a version at first, as I understood that uncertified add-ons is a subgroup of extensions, and yes, they need not to be too prominent. But as apparently we can also have uncertified full themes we would have some in this list as well. So to have one place to direct to from the notification we show in some cases we need a screen that lists all uncertified add-ons. This resulted in the separate category, that of course will only be visible if there are any. - Maybe we can even consider removing uncertifed add-ons after a certain period of time. As we will continue certifying add-ons and now will release this feature later, we can hope that not too many people might see that warning.

(In reply to Markus Jaritz [:maritz] from comment #24) > (In reply to Daniel Veditz [:dveditz] from comment #21) > > I'm concerned about the "certified as safe to use" language -- I can > > guarantee we will sign add-ons that are unsafe and even some that turn out > > to be malicious. I don't mind the "certified" part as long as we're vague > > about what that means ("certified by Mozilla as genuine"). I don't think it > > would be too mysterious to users to simply say they are "unsigned": > > factually true and that wording is used more and more. > > > > "Safe to use" invites trouble when they aren't, and invites challenge along > > the lines of "who are you to say what's safe? My anti-virus says it's not > > malicious, that's good enough for me." > > I can understand that we are at risk if we say something is safe and are > uncertain if we can keep up with that promise. If we tell users (hopefully > not too many) that we have turned of some of their add-ons, I feel that we > ought to give them an explanation of why we did so. The more vague that is > the less understanding for our behavior we can expect. I hope Matej can help > us out with that wording. (sorry to bug you again so soon.) > > Maybe it is as easy as: "… they are not certified to use in Firefox." but > that is up to you native speakers. If we want to keep it more vague, we could say "The following add-ons have been disabled because they are not certified by Firefox." Would that work?

(In reply to Markus Jaritz [:maritz] from comment #19) > Created attachment 8589162 [details] > 150407_Unsigned_Addons_Blocked_Message.jpg > Micheal could you please comment on the visual design of uncertified add-ons in the add-on manager. Especially on the background. These add-ons are geyed out to indicate that they are not active, and have a red gradient to indicate that they have not been reviewed by Mozilla (meaning we do not know if they are safe, quite possibly not). Whats your thoughts on that? Any suggestions, especially in combination with the other ways to mark entries in the add-on manager… Thanks.

Kev, please keep me posted on copy progress on the warning and I will update as soon as I hear back. Yesterday we discussed showing the notification in most cases, but only for 15s. Text should be neutral. Further explanation of why we deactivated will be on the learn more page. We tended towards using "reviewed" over "certified" or "signed" and to communicate that we do not know if we can trust (but not actively talk about not trusting) - and you wanted to further consolidate copywriters on that.

Here's what I'm thinking for the final bits. - What do people think of "verified" vs. "reviewed"? I think that's the word I most prefer, because it captures the meaning of addon signing, and also for the review process. e.g. Firefox has verified that addon has passed the AMO review process (as intent, I'm not suggesting we write that in there). If we feel "reviewed" is more appropriate, I'm ok there. - For the warning infobar we should simply state "One or more installed addons cannot be verified, and have been disabled" This covers reviews and signing, and we go deeper through the "Learn More" button, and would cover the upgrade and side-load cases. - Infobar will display for 15s the first time after the upgrade that enables AMO or when sideloaded addons are detected. Is there any intent to display this again if no action is taken by the user? *** Assumption - The addon manager will warn of unsigned addons for manual installs at the time of install, and won't call the infobar ever (e.g. once enforcement starts, installation of unsigned extensions shouldn't be possible) *** - Rather than having a summary view for addons that have been disabled specifically (the uncertified addons tab), can we simply display the extensions tab, and call out the addons that are unverified there with the stronger treatment? If/when we start signing themes and/or other addons, we could change the addons-manager to display some type of notifier when a category of addons has a disabled component in it. I'm not sure how complicated the extra view is, along with the logic required to display it, but it feels like more complexity than is necessary. - Similarly, rather than displaying the "unverified addons have been disabled" text in a summary tab, does it make more sense to display that information in each category when there are items that have been disabled? (e.g. keep the information persistent until the addon is updated or removed, wherever and whenever applicable, so users can understand the decision we've taken and why whenever there is a disabled addon present, and can get more information on actions available).

(In reply to Kev Needham [:kev] from comment #28) > Here's what I'm thinking for the final bits. > > - What do people think of "verified" vs. "reviewed"? I think that's the word > I most prefer, because it captures the meaning of addon signing, and also > for the review process. e.g. Firefox has verified that addon has passed the > AMO review process (as intent, I'm not suggesting we write that in there). > If we feel "reviewed" is more appropriate, I'm ok there. WFM > - Infobar will display for 15s the first time after the upgrade that enables > AMO or when sideloaded addons are detected. Is there any intent to display > this again if no action is taken by the user? *** Assumption - The addon > manager will warn of unsigned addons for manual installs at the time of > install, and won't call the infobar ever (e.g. once enforcement starts, > installation of unsigned extensions shouldn't be possible) *** I don't think we should display the warning at all when sideloaded add-ons are detected. If an another app injects an unsigned add-on into Firefox the user doesn't need to be prompted about it. > - Rather than having a summary view for addons that have been disabled > specifically (the uncertified addons tab), can we simply display the > extensions tab, and call out the addons that are unverified there with the > stronger treatment? If/when we start signing themes and/or other addons, we > could change the addons-manager to display some type of notifier when a > category of addons has a disabled component in it. I'm not sure how > complicated the extra view is, along with the logic required to display it, > but it feels like more complexity than is necessary. Currently signing is restricted to extensions and experients. I imagine that it is unlikely that anyone would get an unsigned extension so we could do this and we're planning on calling out unsigned add-ons in the extensions list anyway. But people can have a lot of add-ons and so the particular add-on(s) may be scrolled out of view. In terms of code it is not very difficult to add the new view, particularly if it is just displaying a list of add-ons using the same styling as they would have in the extensions list anyway. > - Similarly, rather than displaying the "unverified addons have been > disabled" text in a summary tab, does it make more sense to display that > information in each category when there are items that have been disabled? > (e.g. keep the information persistent until the addon is updated or removed, > wherever and whenever applicable, so users can understand the decision we've > taken and why whenever there is a disabled addon present, and can get more > information on actions available). The styling of warning bars on extensions allows for a learn more link. I think I'd rather see that in the regular lists rather than a big header that reduces the available space for the list a lot. It could also be a bit janky to add that header in when we detect there are unsigned add-ons since getting that info is asynchronous.

(In reply to Dave Townsend [:mossop] from comment #29) > I don't think we should display the warning at all when sideloaded add-ons > are detected. If an another app injects an unsigned add-on into Firefox the > user doesn't need to be prompted about it. I understood that as displaying when an app modifies an existing add-on. But maybe we can automatically repair such a case. > > - Rather than having a summary view for addons that have been disabled > > specifically (the uncertified addons tab), can we simply display the > > extensions tab, and call out the addons that are unverified there with the > > stronger treatment? If/when we start signing themes and/or other addons, we > > could change the addons-manager to display some type of notifier when a > > category of addons has a disabled component in it. I'm not sure how > > complicated the extra view is, along with the logic required to display it, > > but it feels like more complexity than is necessary. > > Currently signing is restricted to extensions and experients. I imagine that > it is unlikely that anyone would get an unsigned extension so we could do > this and we're planning on calling out unsigned add-ons in the extensions > list anyway. But people can have a lot of add-ons and so the particular > add-on(s) may be scrolled out of view. > > In terms of code it is not very difficult to add the new view, particularly > if it is just displaying a list of add-ons using the same styling as they > would have in the extensions list anyway. As long as we only have extensions signed, we can have a link to a filtered list with explanation directly in the extensions view. (as shown on this older mock: https://bug1148403.bugzilla.mozilla.org/attachment.cgi?id=8587647) This seams to be the least intrusive. See https://bugzilla.mozilla.org/show_bug.cgi?id=1047247#c9 for a summary of all possible warnings for add-ons. Including unverified addons with text suggestions. (Will not need the line with the question-mark as discussed in our meeting)

(In reply to Markus Jaritz [:maritz] from comment #30) > (In reply to Dave Townsend [:mossop] from comment #29) > > I don't think we should display the warning at all when sideloaded add-ons > > are detected. If an another app injects an unsigned add-on into Firefox the > > user doesn't need to be prompted about it. > > I understood that as displaying when an app modifies an existing add-on. But > maybe we can automatically repair such a case. Ah yeah if it is that case then I agree with displaying. > > > - Rather than having a summary view for addons that have been disabled > > > specifically (the uncertified addons tab), can we simply display the > > > extensions tab, and call out the addons that are unverified there with the > > > stronger treatment? If/when we start signing themes and/or other addons, we > > > could change the addons-manager to display some type of notifier when a > > > category of addons has a disabled component in it. I'm not sure how > > > complicated the extra view is, along with the logic required to display it, > > > but it feels like more complexity than is necessary. > > > > Currently signing is restricted to extensions and experients. I imagine that > > it is unlikely that anyone would get an unsigned extension so we could do > > this and we're planning on calling out unsigned add-ons in the extensions > > list anyway. But people can have a lot of add-ons and so the particular > > add-on(s) may be scrolled out of view. > > > > In terms of code it is not very difficult to add the new view, particularly > > if it is just displaying a list of add-ons using the same styling as they > > would have in the extensions list anyway. > > As long as we only have extensions signed, we can have a link to a filtered > list with explanation directly in the extensions view. (as shown on this > older mock: > https://bug1148403.bugzilla.mozilla.org/attachment.cgi?id=8587647) > This seams to be the least intrusive. In terms of code complexity that might be more complex but probably not by much. What I dislike about it is that it makes it look like those are your only extensions, how do you get back to the full list? Click the already highlighted extensions tab?

(In reply to Dave Townsend [:mossop] from comment #31) > (In reply to Markus Jaritz [:maritz] from comment #30) > > (In reply to Dave Townsend [:mossop] from comment #29) > > As long as we only have extensions signed, we can have a link to a filtered > > list with explanation directly in the extensions view. (as shown on this > > older mock: > > https://bug1148403.bugzilla.mozilla.org/attachment.cgi?id=8587647) > > This seams to be the least intrusive. > > In terms of code complexity that might be more complex but probably not by > much. What I dislike about it is that it makes it look like those are your > only extensions, how do you get back to the full list? Click the already > highlighted extensions tab? Clicking the tab again should bring you back, but I would also add a link/button on top saying "show all add-ons" as shown in the linked mock.

(In reply to Dave Townsend [:mossop] from comment #31) > (In reply to Markus Jaritz [:maritz] from comment #30) > > (In reply to Dave Townsend [:mossop] from comment #29) > > > I don't think we should display the warning at all when sideloaded add-ons > > > are detected. If an another app injects an unsigned add-on into Firefox the > > > user doesn't need to be prompted about it. > > > > I understood that as displaying when an app modifies an existing add-on. But > > maybe we can automatically repair such a case. > > Ah yeah if it is that case then I agree with displaying. Just wanted to follow-up and make sure we're clear. These are the cases where we will be automatically disabling already installed add-ons because they don't meet the signing requirements: 1. First run of Firefox that requires signing 2. On startup when we have detected that an add-on has changed. 3. During runtime when a periodic scan detects that an add-on has been changed. It sounds like we are saying we will display the doorhanger in all those cases. There is another case: 4. If the user flips the pref to make signing required (and we aren't ignoring the pref) we will disable any unsigned add-ons. I was expecting that we would just not display anything in this case, it doesn't seem worth the work for about:config twiddlers to be told that we've enforced what they asked us to.

Key, you mentioned on Friday that you will comment once more to summarize what the final state will be. If you have anything to add please do so as I will update the flows to the latest tomorrow morning (Central European Time).

So, by my read of the last few comments and discussion, decisions are as follows (note also two additional items at end): - We'll use "verified" vs. any other descriptor, because it captures the meaning of addon signing, and also for the review process. e.g. Firefox has verified that addon has passed the AMO review process (as intent, I'm not suggesting we write that in there). - For the warning infobar we should simply state "One or more installed addons cannot be verified, and have been disabled" This covers reviews and signing, and we go deeper through the "Learn More" button, and would cover the upgrade and side-load cases. - Displaying the tooltip warning on firstrun in the main window only when we detect (for the first time) installed addons that are unsigned or cannot be validated against the signature presented. Two main use cases are 1) when a user is updated to a version of Firefox that enforces addon signing and 2) when an addon has been modified and/or corrupted. - An infobar warning will not be presented when a user flips the pref to enable validation enforcement ina build so equipped. The assumption will be that the user would know to view the disabled addons in the addon manager (or go there as needed). - Displaying the tooltip warning the main window when we detect during a periodic scan that an installed addon(s) that was verified can no longer be validated against the signature presented at startup. Main use case is detection and disabling of addon(s) that have been corrupted/modified during a current session. - Clicking the "Learn More" button in the warning above will bring the user to a list of the addon(s) that have been disabled, along with narrative explaining what happened, and what actions a user can take. (see comment below, as well) - The header in the filtered list will not be displayed in the regular "show all extensions" listing. The "Learn more" link on addons disabled because they can't be verified will link to help documentation which includes. New Items - In the filtered list we present to the user when addons are disabled, should more emphasis be put on the "show all addons" button to mitigate user confusion on "where's my other addons" OR should we consider a flow that explains the actions taken and paths to the user but only shows the addons, and would require using a "Next" button to take them to the list of full addons where they can take action? - For corrupted addons, Firefox will attempt to re-install a known good version of the addon, or present an option to the user to attempt a repair (I kind of like the latter, because it prevents the introduction of the loop, but we'd also need to make sure we can explain to the user if the repair can't happen - It probably makes sense to add a "contact developer" link for the disabled addons in the list if we can. Makes it easier for users to reach out/notify developers

(In reply to Kev Needham [:kev] from comment #35) > - It probably makes sense to add a "contact developer" link for the disabled > addons in the list if we can. Makes it easier for users to reach out/notify > developers Right now I think we could link to the AMO profile for the developer but that is about it and all that has is potentially a homepage so I don't think we can usefully do this quickly and so would like to defer that to a later date if we really want it.

(In reply to Dave Townsend [:mossop] from comment #36) > (In reply to Kev Needham [:kev] from comment #35) > > - It probably makes sense to add a "contact developer" link for the disabled > > addons in the list if we can. Makes it easier for users to reach out/notify > > developers > > Right now I think we could link to the AMO profile for the developer but > that is about it and all that has is potentially a homepage so I don't think > we can usefully do this quickly and so would like to defer that to a later > date if we really want it. Not a blocker, but a nice to have... and yeah, I was making a bad assumption on using info in the addon manifest, which is not be the smartest thing. Deferred, and will think on it a bit; would like to be able to provide some kind of conduit for users to contact addon developers as well (or realize it's not Fx). More for Learn More.

Updated the UI to the latest comments. To finalize strings please comment on google doc. (Matej, please give us feedback once more) https://docs.google.com/a/mozilla.com/document/d/1r_KdSfOms3uwNJjWykSBusMjUHwqR1uw0r5H-gG_4k8/edit?usp=sharing (In reply to Kev Needham [:kev] from comment #35) > > - The header in the filtered list will not be displayed in the regular "show > all extensions" listing. The "Learn more" link on addons disabled because > they can't be verified will link to help documentation which includes. I plan to link to an updated version of the add-on SUMO. (Bug 1149506) Is that the documentation you had in mind? > - In the filtered list we present to the user when addons are disabled, > should more emphasis be put on the "show all addons" button to mitigate user > confusion on "where's my other addons" OR should we consider a flow that > explains the actions taken and paths to the user but only shows the addons, > and would require using a "Next" button to take them to the list of full > addons where they can take action? Showing the add-ons without any possible action only to then continue in a next step and having to remember which to take action on, will be more effort for the user. Micheal, do you have an idea how we visually can put more emphasis on the "show all" button within the new InContent-Pref style? I can only think of the Tabs, but that is too much. (about:preferences#advanced) (current .sketch file: http://cl.ly/3g453Q0r2V2c) > - For corrupted addons, Firefox will attempt to re-install a known good > version of the addon, or present an option to the user to attempt a repair > (I kind of like the latter, because it prevents the introduction of the > loop, but we'd also need to make sure we can explain to the user if the > repair can't happen If we can not automatically repair it, we should treat it as a normal unverified add-on we for those already say that users should find replacement on AMO. (I do not see a reason to provide the users with an unclear option to repair.) > - It probably makes sense to add a "contact developer" link for the disabled > addons in the list if we can. Makes it easier for users to reach out/notify > developers I frequently heard that we do not have e-mail addresses of a lot of add-on developers. And the ones we have addresses of - I assume - have been informed by us that we will start with add-on signing soon.

> > - The header in the filtered list will not be displayed in the regular "show > > all extensions" listing. The "Learn more" link on addons disabled because > > they can't be verified will link to help documentation which includes. > > I plan to link to an updated version of the add-on SUMO. (Bug 1149506) Is > that the documentation you had in mind? Yes. > Showing the add-ons without any possible action only to then continue in a > next step and having to remember which to take action on, will be more > effort for the user. Micheal, do you have an idea how we visually can put > more emphasis on the "show all" button within the new InContent-Pref style? > I can only think of the Tabs, but that is too much. > (about:preferences#advanced) > (current .sketch file: f.cl.ly/items/451H2E0m...) Agreed. Primary concern is "where's my other addons", so emphasis on the button would be good, or rename the header text to something like "The Following Addons Have Been Disabled" since it's a specific list, and the text would make it clearer you're showing a subset of your installed addons. > > - For corrupted addons, Firefox will attempt to re-install a known good > > version of the addon, or present an option to the user to attempt a repair > > (I kind of like the latter, because it prevents the introduction of the > > loop, but we'd also need to make sure we can explain to the user if the > > repair can't happen > > If we can not automatically repair it, we should treat it as a normal > unverified add-on we for those already say that users should find > replacement on AMO. (I do not see a reason to provide the users with an > unclear option to repair.) Biggest concern I have is introducing a loop, particularly if there's a service daemon on the machine which constantly updates/tries to repair everytime it's replaced. So long as we're confident we won't affect things negatively in repair attempts, it's good. > > - It probably makes sense to add a "contact developer" link for the disabled > > addons in the list if we can. Makes it easier for users to reach out/notify > > developers > > I frequently heard that we do not have e-mail addresses of a lot of add-on > developers. And the ones we have addresses of - I assume - have been > informed by us that we will start with add-on signing soon. Ok. Something to take aside and see if there's something we can get better info on for devs and community at large. Will defer and treat as a separate problem.

(In reply to Kev Needham [:kev] from comment #35) > - For corrupted addons, Firefox will attempt to re-install a known good > version of the addon, or present an option to the user to attempt a repair > (I kind of like the latter, because it prevents the introduction of the > loop, but we'd also need to make sure we can explain to the user if the > repair can't happen Missed this. I'm going to say right now that we can't do this for 40. I need to spend some time this week making sure we have bugs on all the stuff that we're pushing off to "later"

My revisions and comments are in the gdoc. Let me know if you have any questions.

Updated flow. Some strings have not been finalized. Matej, Kev can you please do a final check. Thank you.

(In reply to Markus Jaritz [:maritz] from comment #42) > Created attachment 8596164 [details] > 150422_Unsigned_Addons_Blocked_Message.jpg > > Updated flow. Some strings have not been finalized. Matej, Kev can you > please do a final check. Thank you. Commented. Thanks.

final flow, final strings.

Comment on attachment 8598783 [details] 150428_Unsigned_Addons_Blocked_Message.jpg Final OK :)

Dave, is this implemented? Is there a way to test it? Thanks.

(In reply to Markus Jaritz [:maritz] (UX) from comment #46) > Dave, is this implemented? Is there a way to test it? Thanks. It is implement. You'll need to have a signed add-on installed and enable xpinstall.signatures.required. Then exit Firefox and modify the add-ons files in the profile directory (<profile>/extensions/<addon-id>, if it is an XPI instead of a directory just add a new file to the XPI). Then start Firefox and you should see the notification.