Last Comment Bug 755557 - support blocklisting flash versions
: support blocklisting flash versions
Status: VERIFIED FIXED
[blocking-webrtdesktop1+], [qa!]
:
Product: Firefox Graveyard
Classification: Graveyard
Component: Webapp Runtime (show other bugs)
: unspecified
: All All
: P1 enhancement
: Firefox 16
Assigned To: Myk Melez [:myk] [@mykmelez]
: Jason Smith [:jsmith]
:
Mentors:
Depends on:
Blocks: 763783
  Show dependency treegraph
 
Reported: 2012-05-15 15:53 PDT by Jason Smith [:jsmith]
Modified: 2016-03-21 12:39 PDT (History)
7 users (show)
jsmith: in‑moztrap-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch v1: enable blocklist in runtime (926 bytes, patch)
2012-06-11 18:42 PDT, Myk Melez [:myk] [@mykmelez]
blair: review-
Details | Diff | Splinter Review
patch v2: adds detailsURL (1015 bytes, patch)
2012-06-12 14:20 PDT, Myk Melez [:myk] [@mykmelez]
blair: review+
myk: checkin+
Details | Diff | Splinter Review

Description Jason Smith [:jsmith] 2012-05-15 15:53:49 PDT
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] 2012-05-25 16:18:28 PDT
Simplifying summary, as this doesn't need to be a meta-bug, since there are currently no dependent bugs.
Comment 2 Jason Smith [:jsmith] 2012-05-28 16:38:45 PDT
Nominating for k9o - flash is a P1 requirement in the web runtime, so we'll need to support blocklisting.
Comment 3 Jason Smith [:jsmith] 2012-05-28 18:05:25 PDT
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] 2012-05-28 23:18:22 PDT
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] 2012-05-30 10:07:03 PDT
(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] 2012-06-11 17:48:53 PDT
(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] 2012-06-11 18:42:07 PDT
Created attachment 632101 [details] [diff] [review]
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/webapprt@mozilla.org/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) 2012-06-11 19:53:52 PDT
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) 2012-06-11 20:03:10 PDT
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] 2012-06-12 14:20:29 PDT
Created attachment 632411 [details] [diff] [review]
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) 2012-06-12 20:59:39 PDT
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] 2012-06-13 08:51:23 PDT
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) 2012-06-13 13:28:39 PDT
https://hg.mozilla.org/mozilla-central/rev/1e001480c3da
Comment 14 Jason Smith [:jsmith] 2012-06-21 14:15:38 PDT
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] 2012-06-21 15:12:06 PDT
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/webapprt@mozilla.org/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] 2012-06-24 14:55:24 PDT
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).

Note You need to log in before you can comment on or make changes to this bug.