1317846 - privacy.resistFingerprinting set to True breaks Flash content Firefox 50

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[b1883900]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20100101

Steps to reproduce:

Starting in Firefox 50, when privacy.resistFingerprinting is set to true, Flash content no longer loads correctly as it now does not recognize that Flash Player is even installed.

Confirmation of this affecting additional users http://www.ghacks.net/2016/11/15/firefox-50/#comment-4032625


Actual results:

Sites now direct one that Flash Player needs to be installed.


Expected results:

Flash Player should be recognized and load content as it did before Firefox 50 with privacy.resistFingerprinting set to True.

Comment 1

[Loic]

It's by design, see bug 1281963.

Comment 2

[Benjamin Smedberg]

:huseby could you resolve this WFM if appropriate or indicate what should happen here?

Comment 3

[Dave Huseby [:huseby]]

:bsmedberg as Loic indicated, this is by design.  The pref resistFingerprinting is exactly as it says, it is resisting fingerprinting by servers and client-side JS. Flash content and the flash plugin circumvent many of the other anti-fingerprinting defenses in Firefox. When it is enabled, the flash mime types are hidden and therefore firefox does not load the flash plugin. I agree that this is less than ideal, but since resistFingerprinting is off by default, it won't affect default Firefox behavior.

As part of the Tor uplift negotiation, we agreed that anything that broke expected/default behavior would be behind a pref and pref'd off by default. Increasing anonymity and privacy in Firefox requires turning on some prefs which will break some things. Instead of refusing these patches, we're taking them and letting the end user decide their right balance between privacy and compatibility.

If you have any further concerns, please talk to :dveditz as he is now driving the uplift.

Comment 4

[Benjamin Smedberg]

Dave, I want somebody who understands this project to resolve this bug. It sounds like you're saying this should be WORKSFORME/WONTFIX, but I'm not certain.

Comment 5

[Daniel Veditz [:dveditz]]

If this was breaking default Firefox users we would need to address it. If a user opts-in to this non-default setting for privacy reasons this is the expected result.

There's no default pref setting, so the default value "false" comes from code:
https://dxr.mozilla.org/mozilla-central/source/dom/base/nsContentUtils.cpp#589

Personally I wouldn't have wrapped all the various anti-fingerprinting schemes into a single pref setting. More granular control will surprise fewer people if future behavior changes are swept into the same pref. But the people who want it and did the work to implement it found a simpler switch served their users better than potentially forgetting to flip a pref or two.

Comment 6

[b1883900]

Based on the above comments it doesn't sound like it but perhaps it doesn't hurt to ask.  

Is it possible to get the benefits of setting privacy.resistFingerprinting to True but also allow Flash content in some way when desired (another setting/preference somewhere, click to activate, etc.)?

If not, might that be something that could be done in the future?  Or will this be all or nothing only?

Thanks.

Comment 7

[Dave Huseby [:huseby]]

It seems like the "hide mime types" patch in Bug 1281963 could have its own pref so that resist fingerprinting could be turned on but not that one.  however, that means that resist fingerprinting won't actually do all we can to resist fingerprinting.  It's Dan's call on this and it sounds like he's pushing for less prefs, not more.

Comment 8

[b1883900]

I hope it is okay to ask this here also since it concerns the same privacy.resistFingerprinting True setting.

My Firefox 50 updated itself to enable multi-processes and I noticed that setting privacy.resistFingerprinting to True also now breaks drop down menus from working correctly when they did in Firefox 50 when multi-processes were disabled due to an add on.

With privacy.resistFingerprinting set to true clicking on a drop down menu also immediately registers a click on whereever the mouse happens to be on when the menu appears.  For example, https://bugzilla.mozilla.org/query.cgi.  Clicking on the product drop down arrow immediately selects either calendar or Android Background Services.  The only way to get them to work correctly is to click and hold until the mouse can be moved out of the way to a selection.

Is this function by design also?  That the true setting is blocking something from working but intentionally as part of what that setting does?

Comment 9

[Benjamin Smedberg]

b1883900, *if* those dropdown menus are Flash, then this is the correct bug (and probably expected fallout). But if some other aspect of resistFingerprinting caused this, you should use a separate bug.