463374 - Plugin blocklisting needs to present upgrade path

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Daniel Veditz [:dveditz]]

bug 455906 added much improved blocklisting, including user notification (see screen shots in bug) and support for severity levels (warn, full block). This should help with our reluctance to block actively-exploited but popular plugins (bug 436348, bug 445256).

However, the UI presents users with a confusing choice, neither of which is really what they want. "We've blocked Flash. Click OK for no YouTube, or uncheck the disable box to stay vulnerable." In addition, the generic wording "known to cause stability or security problems" might encourage users to gamble that it's stability issues and that they'll be OK.

What's missing is an upgrade path from this dialog, and in the vast majority of forseeable plugin blocklisting cases there will be an updated version of the plugin that fixes the problem.

I think in most cases we don't have links to appropriate binary downloads so the most likely action would be to click a link or button to open the vendor's site. At the very least that means the blocklist file format will have to be expanded to contain the link we want to present.

Comment 1

[Daniel Veditz [:dveditz]]

The plugin-finder service (PFS) does present an upgrade path for users, but that only kicks in when they visit a page with a blocked plugin. That's too far removed from the blocklisting UI to help -- most users probably won't know or think about that option when trying to decide whether to leave the plugin disabled or not and so may still make the unfortunate choice to override our blocklisting.

Explaining PFS on the blocklisting announcement dialog might be one way of resolving this bug. Not a great way, but if we can't get some kind of directed path worked into the dialog then it'd be better than nothing.

Comment 2

[Jennifer Morrow [:Boriss] (UX)]

Attachment: addon needs update and one is available from popup

Daniel - Definitely the screenshots on bug 455906 are appropriate only if there is no known update that will fix the hard/soft block problem.  When there is an update available, the ideal way to fix the problem would be to allow the user to download it completely from popup here.  This may not be possible in all scenarios - I think we're checking up on the legal issues here.  I'm attaching a screenshot in the style of bug 455906 for the scenario when an update is downloadable from the popup.

Comment 3

[Dave Townsend [:mossop]]

The real problem is that the PFS doesn't really support what you want it to. We cannot search for an update for a plugin. All we can do is retrieve a plugin that supports a given mimetype. This may or may not be a newer version of the same plugin.

There were some plans to improve the PFS that mconnor was working on, but I haven't seen any signs that these will make 3.1. And last I heard those plans would not help this case, in fact they would hinder it. Even if we wanted to update the PFS to support pure updates it would be complicated to achieve, likely including broadcasting to Mozilla all of the details of the bad plugin you have installed so that we can look up what the appropriate update is.

The UI needs a significant amount of thought and will become far more complex than it already is, and it is already IMO too complicated. Options include searching for updates before displaying the initial screen, in which case we have to give the user the option of installing the update, not installing the update and disabling or neither for each add-on that is warned about. Then of course if the update fails you have to think about what to do then, re-ask about disabling? You could punt the update check till after a user has made a decision as Boriss' UI shows, but it doesn't seem right to ask users if they want to block the add-on and then telling them that an update is available.

With the amount of work that would be needed for making the PFS work as required, for just defining the UI let alone implementing it, I don't believe there is justification for blocking 1.9.1 for this, but deferring judgement till I speak to some of the other drivers.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Dave's instincts are right; not blocking.

Comment 5

[Benjamin Smedberg]

Dave, I'd really like to get this for 1.9.3, is that compatible with your other plans?

Comment 6

[Dave Townsend [:mossop]]

(In reply to comment #5)
> Dave, I'd really like to get this for 1.9.3, is that compatible with your other
> plans?

Yes, very much something I'd like to see done for then

Comment 7

[Jim Mathies [:jimm]]

wontfix - related to plugin ux.