Closed
Bug 873093
Opened 12 years ago
Closed 11 years ago
Plugin blocks need to include a link
Categories
(Toolkit :: Blocklist Policy Requests, defect, P2)
Toolkit
Blocklist Policy Requests
Tracking
()
RESOLVED
FIXED
2014-07
People
(Reporter: benjamin, Assigned: magopian)
References
Details
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•12 years ago
|
Flags: needinfo?(jorge)
Comment 1•12 years ago
|
||
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•12 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.
Comment 3•11 years ago
|
||
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)
Comment 4•11 years ago
|
||
(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•11 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)
Comment 6•11 years ago
|
||
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
Updated•11 years ago
|
Target Milestone: --- → 2014-07
Assignee | ||
Comment 7•11 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•11 years ago
|
Assignee: nobody → mathieu
Comment 8•11 years ago
|
||
(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.
Comment 9•11 years ago
|
||
Benjamin, is there a bug to add support this new field on the client side?
Flags: needinfo?(benjamin)
Assignee | ||
Comment 10•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 11•11 years ago
|
||
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•11 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
Comment 13•11 years ago
|
||
That output doesn't include the infoURL node, however.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 14•11 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?
Comment 15•11 years ago
|
||
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•11 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 :/
Comment 17•11 years ago
|
||
clouserw should know a way to kick the cache.
Comment 18•11 years ago
|
||
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)
Comment 19•11 years ago
|
||
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
Closed: 11 years ago → 11 years ago
Flags: needinfo?(jthomas)
Resolution: --- → FIXED
Updated•11 years ago
|
Flags: needinfo?(benjamin)
Updated•11 years ago
|
Flags: needinfo?(benjamin)
Reporter | ||
Comment 20•11 years ago
|
||
Client work filed as bug 1038145, (the current in-tree code comments refer to this bug).
Flags: needinfo?(benjamin)
Updated•9 years ago
|
tracking-b2g:
backlog → ---
Updated•9 years ago
|
Product: addons.mozilla.org → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•