Block plugins to prevent fingerprinting through plugins (such as Flash)

[SwartzCr]

Is it possible for privacy badger to prevent fingerprinting via Flash and the like? Can we make these things click to play? Also maybe block navigator.plugins?

[max-l]

I'm curious of how prevention of fingerprinting is done, it seems like a very hard thing to do.

[gunesacar]

Here's WIP for blocking Adobe Flash: https://github.com/EFForg/privacybadgerchrome/compare/master...gunesacar:plugin_control

It exposes a binary switch on the PB's options page and uses chrome.contentSettings API. Can be tested on: https://www.adobe.com/software/flash/about/

This is basically not much different than exposing Chrome's internal settings on PB's Options page, but in addition, PB could enforce a default setting (e.g. block Flash). Currently it reads user's setting from Chrome (does not block by default.)

It just supports blocking Flash at the moment, but can be easily extended to other plugins.

I could add some automated tests but first would like to see if you like the idea or not. Also note that, as of v42 they removed the "click to play" option but user can play the Flash videos when the setting is to "block" plugins.

[cooperq]

I think this is a great idea, I haven't had a chance to test it yet but I think it's exactly what we want! I say go for it. Does it seem like this is possible in firefox as well?

[gunesacar]

Thanks, and yes, this should be possible in Firefox, given that there are addons such as Flashblock, doing exactly what we want.

[cooperq]

I say run with it then. This would be an excellent feature! :+1:

[gunesacar]

Do you think PB should block Flash by default? Even if we block, users can still right click the blocked Flash elements and run them (i.e. blocking is a bit like click-to-play). I'd definitely prefer blocking by default, but I think you guys should decide.

Perhaps, if PB starts blocking Flash in the next version, this should be clearly communicated to users, e.g. on the firstRun page or popup?

[pde]

This sort of feature can easily create a lot of confusion. We had the same result from disabling search suggestions by default. I don't think we should deploy such experience-breaking things by default, but maybe we can offer them as easy/prominent options at the end of the onboarding process? (It's a pity we didn't flag this while drafting the script...)

What we probably could do by default is block third party flash embeds. The ratio of good outcome to breakage is way better there.

On Wed, Jun 17, 2015 at 04:12:36PM -0700, gunesacar wrote:

Do you think PB should block Flash by default? Even if we block, users can still right click the blocked Flash elements and run them (i.e. blocking is a bit like click-to-play). I'd definitely prefer blocking by default, but I think you guys should decide.

Perhaps, if PB starts blocking Flash in the next version, this should be clearly communicated to users, e.g. on the firstRun page or popup?

---

Reply to this email directly or view it on GitHub: https://github.com/EFForg/privacybadgerchrome/issues/360#issuecomment-112977295

Peter Eckersley pde@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993

[gunesacar]

I agree with the confusion point of view.

Here's a mock up of a possible solution, where PB won't do anything by default: https://jsfiddle.net/482f2n6k/2/embedded/result/

If the user enables blocking, it'll block a selection of greylisted plugins (e.g. Flash, Silverlight, Java, EME etc.). The user will still be able to selectively disable PB's blocking for a specific plugin.

Let me know what you think.

What we probably could do by default is block third party flash embeds. The ratio of good outcome to breakage is way better there.

Let me look into this later, currently I can't see a clean way of doing this with the content settings API. We can set domain specific rules each time a third-party frame is created. But there's not way to unset a specific rule. May end up really messy.

[gunesacar]

Instead of exposing three possible plugin settings of Chrome ("Allow," "Block," "Detect and run important plugin content") we could just have simpler Block? Yes/No switches: Something like: https://jsfiddle.net/jys3qLnv/4/ Yes: block the plugin No: clear the setting for this plugin (user's plugins settings in Chrome will take over)

I thought "Detect and run important plugin content" would block invisible Flash objects, but apparently it cannot. samy.pl/evercookie was still able to set Flash cookies with that setting on. So I'm not sure if it's worth having, given the confusion it may cause.

[cooperq]

I'm okay with this UI, provided that we don't block anything by default. I would also maybe say block and allow instead of 'yes' and 'no', I think it is more clear that way.

[gunesacar]

Here's the WIP branch for plugin control: https://github.com/EFForg/privacybadgerchrome/compare/014b6833457a98cbc1475ff861db581adbf98857...gunesacar:plugin_control

The branch should work for straightforward blocking, but I need to work a bit more to handle edge cases like when PB is deactivated for a site, or when the user has some site-specific exceptions for plugins.

Another design decision to make is the following: should PB allow blocking of all the installed plugins? We could just display some greylisted plugins that may be used for tracking. But this would require compiling of such a list and if there's some exotic plugin that we've never heard of, we won't be able to give the opportunity to block it.

Your feedback is highly appreciated, though I'll be away from keyboard until July 6th.

[cooperq]

Thanks Gunes, I agree we would need to hanlde edge cases like pb being deactivated and such. This looks good so far, but I haven't tested it yet. I will soon!

[gunesacar]

Unfortunately, it turned out that the contentSettings API has some serious limitations for this task. Most importantly, we cannot read exceptions set by the user ( chrome://settings/contentExceptions#plugins) and our plugin blocking rules override user's exceptions.

Although I found a hackish way around, it'll only work for users who blocked plugins globally. Just imagine a user trying to whitelist a page to watch videos, it'll be a UX nightmare!

Also I found a bug in the API that crashes Chromium (https://crbug.com/511825). Even if we could find a way around the shortcomings, this bug would block this work.

Here's the latest snapshot: https://github.com/EFForg/privacybadgerchrome/compare/7e3015719a47410d25e68c377ef7a035c05c3f4c...gunesacar:plugin_control

I think that'd be an efficient solution compared to parsing DOM to search for Flash objects, but for now , this approach seems like a dead end to me.

Unfortunately I'll busy next month(s) to look into alternatives. Just in case someone else wants to look into this.

[jawz101]

Flash is pretty much dead, right?

[cowlicks]

Related https://github.com/nfriedly/Javascript-Flash-Cookies

[ghostwords]

Chrome plans to disable Flash by default (effectively removing it for 99.99% of users) by default by 2019 and remove it entirely by 2020: https://www.chromium.org/flash-roadmap#TOC-Flash-Disabled-by-Default-Target:-Chrome-76---July-2019-.

Closing as "wontfix".