755557 - support blocklisting flash versions

Status: VERIFIED FIXED

(Firefox Graveyard :: Webapp Runtime, enhancement, P1)

Description

[Jason Smith [:jsmith]]

Tracker bug for implementing support for blocklisting flash versions in the desktop web runtime against a specified blocklist. See https://wiki.mozilla.org/Blocklisting for the requirements in regards to blocklisting for flash plugins.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Simplifying summary, as this doesn't need to be a meta-bug, since there are currently no dependent bugs.

Comment 2

[Jason Smith [:jsmith]]

Nominating for k9o - flash is a P1 requirement in the web runtime, so we'll need to support blocklisting.

Comment 3

[Jason Smith [:jsmith]]

In executing the test https://bugzilla.mozilla.org/show_bug.cgi?id=754080#c8, I have confirmed that we do not support blocklisting of old flash versions in the web runtime. After completing the setup steps identified in that comment for blocklist.xml to block a subset of flash versions with an old version of flash in the blocklist installed on my machine, I did the following:

1. Installed Mozilla QA WebRT Tester at https://apps.mozillalabs.com/appdir/
2. Go to firefox --> plugins --> flash
3. Opened sample-swf-video-10s.swf and test_swf_embed.html

Expected Result: 

The swf files should not be executed within the plugin, as flash is currently blocked. 

Actual Result:

Both swf files played in the blocked adobe flash version.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

There are a few pieces here:

* enabling the blocklist
* keeping the blocklist updated
* letting the user override soft-blocks

Enabling the blocklist looks as simple as setting one or more of a small set of preferences:

http://hg.mozilla.org/mozilla-central/annotate/79262a88881d/browser/app/profile/firefox.js#l46

That could also suffice to keep the blocklist updated.  But it isn't clear how the runtime would let users override soft-blocks.  The user interface for interacting with the blocklist in Firefox is Add-ons Manager, which we wouldn't want to replicate in the runtime.

One option would be for the runtime to reuse the Firefox profile's blocklist, f.e. by copying the latest version of it to the webapp's profile on webapp startup.  Then we could direct users to Firefox when they want to override a soft-block.

Or we could decide not to let users override soft-blocks in the runtime, so all blocks in the runtime are hard-blocks.

I'm leaning toward the latter, since it isn't clear that it's important to override soft-blocks in the runtime the way it's valuable to do so in the browser.  But cc:ing mossop for his thoughts.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #4)
> There are a few pieces here:
> 
> * enabling the blocklist
> * keeping the blocklist updated
> * letting the user override soft-blocks
> 
> Enabling the blocklist looks as simple as setting one or more of a small set
> of preferences:
> 
> http://hg.mozilla.org/mozilla-central/annotate/79262a88881d/browser/app/
> profile/firefox.js#l46
> 
> That could also suffice to keep the blocklist updated.  But it isn't clear
> how the runtime would let users override soft-blocks.  The user interface
> for interacting with the blocklist in Firefox is Add-ons Manager, which we
> wouldn't want to replicate in the runtime.

I'm sure you don't want to re-use the add-ons manager UI in the runtime, but the API it uses is available to you so it'd be reasonably simple to have it controlled off a checkbox, button, whatever you decide is best. The only tricky part is that there is no way to get the "flash" plugin to enable, unlike extensions plugins don't have reliable unique identifiers. You'd have to get a list of all the plugins and enumerate through them to find the one that looks like flash (probably using a regexp on the name/description, that's what the blocklist uses anyway).

Comment 6

[Myk Melez [:myk] [@mykmelez]]

(In reply to Dave Townsend (:Mossop) from comment #5)
> I'm sure you don't want to re-use the add-ons manager UI in the runtime, but
> the API it uses is available to you so it'd be reasonably simple to have it
> controlled off a checkbox, button, whatever you decide is best. The only
> tricky part is that there is no way to get the "flash" plugin to enable,
> unlike extensions plugins don't have reliable unique identifiers. You'd have
> to get a list of all the plugins and enumerate through them to find the one
> that looks like flash (probably using a regexp on the name/description,
> that's what the blocklist uses anyway).

Bug 755554 will disable other plugins, so implementing an interface to override a soft-block might be even simpler.

But it still isn't clear to me that the use cases we intend to enable via the webapp runtime require us to enable users to override a soft-block.  And I think we can separate these concerns, landing code to enable the blocklist, without the ability to override its blocks, and then iterating on an interface (if any) for overriding it.

So I have filed bug 763783 about an interface for overriding a soft-block and will focus this bug on enabling the blocklist.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: enable blocklist in runtime

Here's a patch that enables the blocklist.  After running an app against a version of Firefox with the patch, and with logging enabled, the following messages appeared in my console:

*** Blocklist::notify: Requesting https://addons.mozilla.org/blocklist/3/[e-mail]/16.0a1/Webapp%20Runtime/20120611143819/Darwin_x86_64-gcc3/en-US/default/Darwin%2011.4.0/default/default/1/1/new/
*** Blocklist::_loadBlocklist: no XML File found
*** Blocklist state for Shockwave Flash changed from 0 to 0
*** Blocklist state for Java Applet Plug-in changed from 0 to 0

And a blocklist.xml full of information showed up in the app's profile.  And some prefs appeared in the profile's prefs.js file:

user_pref("app.update.lastUpdateTime.blocklist-background-update-timer", 1339463575);
user_pref("extensions.blocklist.pingCountTotal", 2);
user_pref("extensions.blocklist.pingCountVersion", 2);

So I think this patch is sufficient.  But I haven't actually tested that the blocklist works, as I don't know how to get my hands on a blocklisted version of Flash.  I did, however, push this to try, so folks who do have a blocklisted version of Flash can test it out:

https://tbpl.mozilla.org/?tree=Try&rev=b5fc108ff2b1


Note that I didn't include extensions.blocklist.detailsURL, which appears to be used only by Firefox's interface.  But I did include extensions.blocklist.itemURL, which is used by nsBlocklistService.js and thus seems necessary, even if the runtime itself doesn't use those URLs.

Comment 8

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Hmm, the blocklist service should be smarter about re-fetching the same data for every profile. Filed bug 763812.

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 632101 [details] [diff] [review]
patch v1: enable blocklist in runtime

Review of attachment 632101 [details] [diff] [review]:
-----------------------------------------------------------------

(Driveby review!)

(In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> Note that I didn't include extensions.blocklist.detailsURL, which appears to
> be used only by Firefox's interface.

It's also used by the blocklist dialog (part of the Add-ons Manager), which shows when an addon/plugin is first blocked. So it should be included.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v2: adds detailsURL

(In reply to Blair McBride (:Unfocused) from comment #9)
> It's also used by the blocklist dialog (part of the Add-ons Manager), which
> shows when an addon/plugin is first blocked. So it should be included.

Ah, indeed!  Here's the same patch with detailsURL added in.

Comment 11

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 632411 [details] [diff] [review]
patch v2: adds detailsURL

Review of attachment 632411 [details] [diff] [review]:
-----------------------------------------------------------------

(Dave's traveling, so I'll steal this outright.)

Comment 12

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 632411 [details] [diff] [review]
patch v2: adds detailsURL

Thanks Blair!

https://hg.mozilla.org/integration/mozilla-inbound/rev/1e001480c3da

Comment 13

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/1e001480c3da

Comment 14

[Jason Smith [:jsmith]]

Is this working? The prefs indicated in the patch aren't showing up when I install a web app. I just tried installing Mozilla QA WebRT Tester from apps.mozillalabs.com/appdir, and no blocklist.xml was ever downloaded. Checking the prefs, I don't see a mention of some the prefs in this patch:

user_pref("browser.cache.disk.capacity", 1048576);
user_pref("browser.cache.disk.smart_size.first_run", false);
user_pref("extensions.blocklist.pingCountVersion", 0);
user_pref("extensions.bootstrappedAddons", "{}");
user_pref("extensions.lastAppVersion", "16.0a1");
user_pref("extensions.lastPlatformVersion", "16.0a1");
user_pref("extensions.shownSelectionUI", true);
user_pref("gfx.direct3d.prefer_10_1", true);
user_pref("network.cookie.prefsMigrated", true);
user_pref("places.history.expiration.transient_current_max_pages", 104858);
user_pref("webapprt.firstrun", true);

Comment 15

[Myk Melez [:myk] [@mykmelez]]

The prefs set in the patch for this bug are default prefs, so they won't show up in the prefs.js file in the profile for an app.

I enabled extension logging by setting the extensions.logging.enabled pref in the profile for an app:

user_pref("extensions.logging.enabled", true);

Then I started the app from a console window and let it run (blocklist updates don't happen immediately on startup).  After a few minutes, I saw these messages in my console:

*** Blocklist::notify: Requesting https://addons.mozilla.org/blocklist/3/[e-mail]/16.0a1/Webapp%20Runtime/20120620065138/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/default/Darwin%2011.4.0/default/default/1/1/new/
*** Blocklist::_loadBlocklist: no XML File found
*** Blocklist state for Shockwave Flash changed from 0 to 0
*** Blocklist state for QuickTime Plug-in 7.7.1 changed from 0 to 0
*** Blocklist state for Java Applet Plug-in changed from 0 to 0
*** Blocklist state for AmazonMP3DownloaderPlugin changed from 0 to 0
*** Blocklist state for Flip4Mac Windows Media Plugin 2.3.6  changed from 0 to 0
*** Blocklist state for Silverlight Plug-In changed from 0 to 0
*** Blocklist state for iPhotoPhotocast changed from 0 to 0
*** Blocklist state for Musicnotes changed from 0 to 0
*** Blocklist state for MoveNetworks Quantum Media Player changed from 0 to 0
*** Blocklist state for RealPlayer Plugin.plugin changed from 0 to 0

And a blocklist.xml file showed up in my profile.  I'm not familiar with how the blocklist is applied to plugins, so I haven't tested to see if plugins are actually being blocklisted, but the blocklist is definitely being updated (or at least downloaded and stored locally the first time).

Comment 16

[Jason Smith [:jsmith]]

Verified on Nightly. Saw the blocklist.xml file get downloaded and modified the severity of flash's block to 3 (hard block). As a result, flash was entirely blocked on the runtime (e.g. trying to open a swf file required a download, which is the expected behavior if flash is hard blocked).