If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Plugin blocks need to include a link

RESOLVED FIXED in 2014-07

Status

()

Toolkit
Blocklisting
P2
normal
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: Benjamin Smedberg, Assigned: magopian)

Tracking

unspecified
2014-07
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
In the plugin block UI, the current UI for blocked plugins is something like this:

* Go to a page which uses the plugin
* See that it's blocked, open the doorhanger
* Doorhanger shows that the plugin is vulnerable. If the plugin is marked as having an update, we show a "Check for Updates..." link.

This link currently directs people to the generic plugincheck page, on which you have to click another button, hope that plugincheck has information which matches our blocklist, and then follow another link to get to a download page.

Instead, each plugin blocklist item ought to provide a direct link to an appropriate site:

* For plugins with a known newer version, the link should go directly to the vendor's download page
* For insecure plugins with no available update, the link should go to a SUMO page explaining the issue.

I can think of two ways to implement this:

A. Include the URL in the blocklist XML and follow it directly from the browser
B. Follow a well-known URL scheme to addons.mozilla.org and redirect from there. I think this solution is preferable. So e.g. the browser would navigate to

https://addons.mozilla.org/%LOCALE%/%APP%/blocked/%blockID%/redirect
or https://addons.mozilla.org/%LOCALE%/%APP%/blocked-redirect/%blockID%

I think option B is preferable. In any case, Jorge this is important for the doorhanger rewrite now scheduled for FF24. Who can help implement this on the AMO side?
(Reporter)

Updated

5 years ago
Flags: needinfo?(jorge)
Most of the time we'll be pointing to the Flash or Java install pages, so I would prefer that we do the following:

1) If the blocklist provides a URL, use it.
2) Otherwise, if it's a known plugin (Flash, Java, Silverlight, maybe others), use hardcoded URLs provided in Firefox.
3) Otherwise, point to the plugincheck page.

I think redirecting through AMO would make this harder to maintain and implement in the first place, so I would recommend against it.

Wraithan has helped us with blocklist bugs in the past, so maybe he can help implement this. All we would need to add is a URL textbox for plugin block entries. The URL would end up as a node in the plugin block XML. If the textbox is empty, there would be no node. For example:

> <pluginItem  blockID="p85">
>   <match name="filename" exp="JavaPlugin2_NPAPI\.plugin" />
>   <versionRange  minVersion="0" maxVersion="13.6.0" severity="0">
>   </versionRange>
>   <url>http://www.java.com/inc/BrowserRedirect1.jsp?locale=en<url/>
> </pluginItem>
Flags: needinfo?(jorge)
OS: Windows 7 → All
Hardware: x86_64 → All
(Reporter)

Comment 2

5 years ago
I very much do not want to hardcode installer URLs in the product; they have changed over time.

The reason I suggested the redirect scheme is because it makes testing this on trunk easier and also gives us some metrics on how often these links are being used. But if you want to include them directly in the blocklist data, that's fine too, and I'll just add some basic telemetry to measure the usage.
Jorge - what do you want to do here?  It sounds like putting an <input> on the blocklist page and adjusting the XML output will work?

Benjamin - I assume a change to the XML format won't break any clients?
Flags: needinfo?(jorge)
(In reply to Wil Clouser [:clouserw] from comment #3)
> Jorge - what do you want to do here?  It sounds like putting an <input> on
> the blocklist page and adjusting the XML output will work?

Yes.

> Benjamin - I assume a change to the XML format won't break any clients?

The Add-ons Manager shouldn't break because of XML tags it can't recognize. We've added new stuff to blocklist items in the past.

The real question here is whether we still want to do this, since we haven't blocked many plugins in the recent past.
Flags: needinfo?(jorge) → needinfo?(benjamin)
(Reporter)

Comment 5

3 years ago
Yes, we still want this. We will continue blocking old versions of common plugins as well as minority plugins as we discover security issues with them, and we want to be able to offer an in-product experience that leads directly to the update page for the plugin.
Flags: needinfo?(benjamin)
There is some background on what blocklisting is at https://wiki.mozilla.org/Blocklisting on  the administration at https://wiki.mozilla.org/Blocklisting/Admin and the XML format at https://wiki.mozilla.org/Extension_Blocklisting:Code_Design .  For this bug we are specifically talking about plugins so you can ignore anything about graphics cards, add-ons, etc.

The blocklisted plugins are managed at https://addons-dev.allizom.org/en-US/admin/models/blocklist/blocklistplugin/ .

The blocklist itself is consumed by Firefox at, for example, https://blocklist-dev.allizom.org/blocklist/1/1/1/ .

This bug is about:

1) Add a field to the database which will hold a URL and ensure it's editable in the management scaffolding

2) Expose the field in the XML as <infoURL>.  The field shouldn't show up if it's empty or null.  Make sure the URL is XML escaped.

3) Update the XML documentation at https://wiki.mozilla.org/Extension_Blocklisting:Code_Design

Marking this as a P2 because it will be a significant improvement to the experience of end users and anything we do on our end is going to lag behind release by, I assume, at least 12 weeks so it can land in the platform.
Priority: -- → P2
Target Milestone: --- → 2014-07
(Assignee)

Comment 7

3 years ago
PR: https://github.com/mozilla/olympia/pull/141

If I understand correctly, this infoURL field will be used by firefox itself in a future release?
(Assignee)

Updated

3 years ago
Assignee: nobody → mathieu
(In reply to Mathieu Agopian [:magopian] from comment #7)
> PR: https://github.com/mozilla/olympia/pull/141
> 
> If I understand correctly, this infoURL field will be used by firefox itself
> in a future release?

Yes.
Benjamin, is there a bug to add support this new field on the client side?
Flags: needinfo?(benjamin)
(Assignee)

Comment 10

3 years ago
Fixed in https://github.com/mozilla/olympia/commit/a9a69b60e3d3bb73caacab5541f265d60a7b0b38
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
STR:
1) Go to https://addons-dev.allizom.org/en-US/admin/models/blocklist/blocklistdetail/add/
2) Scroll down to Blocklist Plugin: #1 
3) Verify that there's an info URL field.
4) Enter Min, Max, Filename, Severity, and Info URL (possible values (without quotes): "Java 7 Update 25", "Java 7 Update 28", "JavaAppletPlugin\.plugin", "1", "http://java.com/en/download/installed.jsp").
5) Scroll back to the top and enter Name, Why and Who (anything is fine).
6) Save.
7) Go to https://addons-dev.allizom.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/33.0a1/Firefox/20140710030200/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/nightly/Darwin%2013.3.0/default/default/invalid/invalid/0/
8) In the XML output you should see something like
<pluginItem blockID="p459"><match name="filename" exp="JavaAppletPlugin\.plugin"/><versionRange minVersion="Java 7 Update 25" maxVersion="Java 7 Update 28" severity="1"></versionRange><infoURL>http://java.com/en/download/installed.jsp</infoURL></pluginItem>

Comment 12

3 years ago
Followed those steps and obtained this in the XML output.
<pluginItem blockID="p572"><match name="filename" exp="JavaAppletPlugin\.plugin"/><versionRange minVersion="Java 7 Update 25" maxVersion="Java 7 Update 28" severity="1"/></pluginItem>

Closing.
Status: RESOLVED → VERIFIED
That output doesn't include the infoURL node, however.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 14

3 years ago
Please note that from what I know, the blocklist is cached. Is there a way to regenerate it for sure?
I guess the best way to make sure the blocklist got regenerated is th check the "lastupdate" attribute at the very top of the xml file?
It's cached, because it took a while for the entry to appear. But I don't see any reason why a partial entry should appear, and it's been hours since it was created.

FWIW, the "lastupdate" is currently set to 1405014077000
(Assignee)

Comment 16

3 years ago
Is there a way to force the regeneration of the blocklist.xml file? I'm trying to understand why the info url wouldn't appear there, while it works perfectly fine locally :/
clouserw should know a way to kick the cache.
Caching is only for an hour (see the cache-control header).  Jason is looking to see if we need to restart the service on update to get the new code.
Flags: needinfo?(jthomas)
Jason fixed this up.  I had to add an infoURL to the above plugin, but if you load https://blocklist-dev.allizom.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/33.0a1/Firefox/20140710030200/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/nightly/Darwin%2013.3.0/default/default/invalid/invalid/0/ now you'll see:

> <pluginItem blockID="p459">
>   <match name="filename" exp="JavaAppletPlugin\.plugin"/><versionRange minVersion="Java 7 Update 25" maxVersion="Java 7 Update 44" severity="0" vulnerabilitystatus="1">
>   <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
>     <versionRange minVersion="17.0" maxVersion="*"/>
>   </targetApplication></versionRange>
>   <infoURL>http://micropipes.com/</infoURL>
> </pluginItem>
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Flags: needinfo?(jthomas)
Resolution: --- → FIXED

Updated

3 years ago
Flags: needinfo?(benjamin)

Updated

3 years ago
Flags: needinfo?(benjamin)
(Reporter)

Updated

3 years ago
Blocks: 1038145
(Reporter)

Comment 20

3 years ago
Client work filed as bug 1038145, (the current in-tree code comments refer to this bug).
Flags: needinfo?(benjamin)
Comment hidden (spam)
tracking-b2g: backlog → ---
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.