1333933 - Disable/spoof fingerprintable features when privacy.resistFingerprinting = true

Status: RESOLVED FIXED

(Core :: General, defect, P1)

Description

[Arthur Edelstein [:arthur]]

Tor Browser modifies various pref settings to protect against user fingerprinting. We would like to propose modifying Firefox's code so that these settings are automatically set when privacy.resistFingerprinting = true.

The implementation could directly alter the features concerned, (overriding the existing pref values), or perhaps it could set the pref values themselves.

Here is a list of Tor Browser's current fingerprinting-related pref settings. (A full list of Tor Browser prefs is at https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-45.7.0esr-7.0-1.))

pref("geo.enabled", false);
pref("browser.search.countryCode", "US"); // The next three prefs disable GeoIP search lookups (#16254)
pref("browser.search.region", "US");
pref("browser.search.geoip.url", "");
pref("browser.search.geoSpecificDefaults", false);

pref("webgl.min_capability_mode", true);
pref("webgl.disable-extensions", true);
pref("webgl.disable-fail-if-major-performance-caveat", true);
pref("dom.battery.enabled", false); // fingerprinting due to differing OS implementations
pref("dom.network.enabled",false); // fingerprinting due to differing OS implementations
pref("gfx.downloadable_fonts.fallback_delay", -1);
pref("general.appname.override", "Netscape");
pref("general.appversion.override", "5.0 (Windows)");
pref("general.oscpu.override", "Windows NT 6.1");
pref("general.platform.override", "Win32");
pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0");
pref("general.productSub.override", "20100101");
pref("general.buildID.override", "20100101");
pref("browser.startup.homepage_override.buildID", "20100101");
pref("general.useragent.vendor", "");
pref("general.useragent.vendorSub", "");
pref("dom.enable_performance", false);
pref("plugin.expose_full_path", false);
pref("browser.zoom.siteSpecific", false);
pref("intl.charset.default", "windows-1252");
pref("browser.link.open_newwindow.restriction", 0); // https://bugs.torproject.org/9881: Open popups in new tabs (to avoid fullscreen popups)
pref("dom.gamepad.enabled", false); // bugs.torproject.org/13023
pref("javascript.use_us_english_locale", true);
// pref("intl.accept_languages", "en-us, en"); // Set by Torbutton
// pref("intl.accept_charsets", "iso-8859-1,*,utf-8"); // Set by Torbutton
// pref("intl.charsetmenu.browser.cache", "UTF-8"); // Set by Torbutton
// Disable video statistics fingerprinting vector (https://bugs.torproject.org/15757)
pref("media.video_stats.enabled", false);
// Disable device sensors as possible fingerprinting vector (https://bugs.torproject.org/15758)
pref("device.sensors.enabled", false);
pref("dom.enable_resource_timing", false); // https://bugs.torproject.org/13024: To hell with this API
pref("dom.enable_user_timing", false); // https://bugs.torproject.org/16336: To hell with this API
pref("privacy.resistFingerprinting", true);
pref("dom.event.highrestimestamp.enabled", true); // https://bugs.torproject.org/17046: "Highres" (but truncated) timestamps prevent uptime leaks
pref("privacy.suppressModifierKeyEvents", true); // https://bugs.torproject.org/17009: Suppress ALT and SHIFT events"
pref("ui.use_standins_for_native_colors", true); // https://bugzilla.mozilla.org/232227
// Make Reader View users uniform if they really want to use that feature. See
// https://bugs.torproject.org/18950 for more details.
pref("browser.reader.detectedFirstArticle", true);
pref("reader.parse-on-load.enabled", false);
pref("privacy.use_utc_timezone", true);

Comment 1

[Thorin [:thorin]]

Hi Arthur

Some of these are TBB specific prefs (right?, I cannot find them on DXR): such as intl.accept_charsets, intl.charsetmenu.browser.cache, privacy.use_utc_timezone (is this last one necessary after https://bugzilla.mozilla.org/show_bug.cgi?id=1330890 lands?). Are you proposing to do introduce them to Firefox?

Some sections could do with more, eg GeoIP:
pref("intl.locale.matchOS", false);
pref("general.useragent.locale", "en-US");
pref("javascript.use_us_english_locale", true);

FYI: from FF52+ Battery Status API is only available in chrome/privileged code.

Not sure on something like browser.zoom.siteSpecific. That could severely hamper usability. I for one like my site specific remembered zoom levels.

How would this work with a user.js or cfg - i.e a user.js is trying to set the opposite value? What happens when privacy.resistFingerprinting is enabled, but you go to about:config and try to change a preference to the opposite value? Is the value shown in about:config going to always be a reliable value of what is actually used? What happens with say general.useragent.override eg UA extensions?

Comment 2

[Thorin [:thorin]]

general.useragent.override is an incomplete solution, as it only handles the string sent on the HTTP header. We should redefine the User-Agent for JavaScript code (navigator.userAgent) as well. See https://addons.mozilla.org/en-US/firefox/addon/user-agent-js-fixer/ which unfortunately is not e10s compliant. Maybe that's a bug someone can file: make navigator.userAgent use general.useragent.override.

Up until now, general.useragent.override has been an end user initiated decision, usually via an addon with options. If this is now suddenly brought to the forefront in options (https://bugzilla.mozilla.org/show_bug.cgi?id=1308340) then I think a built-in whitelist should be considered, eg mozilla AMO. i.e user goes to Options>Privacy>Use fingerprinting resistance and then suddenly wonders why he can't install certain extensions

Comment 3

[François Marier [:francois]]

(In reply to Arthur Edelstein [:arthuredelstein] from comment #0)
> Tor Browser modifies various pref settings to protect against user
> fingerprinting. We would like to propose modifying Firefox's code so that
> these settings are automatically set when privacy.resistFingerprinting =
> true.

Some of these prefs will affect the user experience in a big way (e.g. setting the language of the browser via intl.accept_languages) and may prevent us from exposing this setting to users or turning it on in Private Browsing.

Maybe instead of a boolean, privacy.resistFingerprinting should be an integer? For example:

0 = off
1 = basic anti-fingerprinting
2 = full anti-fingerprinting (TBB-level)

Then level 2 could flip all of the prefs mentioned in comment 0.

Comment 4

[Tim Huang[:timhuang]]

I think what Francois said in comment 3 is a good direction for us to implement fingerprinting resistance in Firefox. I believe that we will have less pushbacks when we try to expose this feature if we could provide a more flexible way to turn on anti-fingerprinting, just like what Francois proposed. But, we still need to sort out what's the scope of basic anti-fingerprinting is.

What do you think about this, Arthur?

Comment 5

[Arthur Edelstein [:arthur]]

(In reply to T im Huang[:timhuang] from comment #4)
> I think what Francois said in comment 3 is a good direction for us to
> implement fingerprinting resistance in Firefox. I believe that we will have
> less pushbacks when we try to expose this feature if we could provide a more
> flexible way to turn on anti-fingerprinting, just like what Francois
> proposed. But, we still need to sort out what's the scope of basic
> anti-fingerprinting is.
> 
> What do you think about this, Arthur?

I think this would not be beneficial. Here are my reasons:

1. Partial fingerprinting protection is not very useful if the remaining total entropy is large. In other words, the benefit of anti-fingerprinting measures is close to "all or nothing." I worry that a "partial fingerprinting" setting would not remove enough entropy and provide little or no benefit because the remaining entropy would be enough to identify many users.

2. Any anti-fingerprinting mode is bound to be a special mode for privacy-savvy users. For example, it could be that we activate fingerprinting protections in Private Browsing mode. I don't expect too much pushback for a privacy mode whose purpose is clearly communicated to users.

So I would strongly prefer to keep the pref as a boolean unless and until we discover it is absolutely necessary to make it an integer. I think the YAGNI principle applies -- I don't want to surrender to pushback before it happens. :)

(I should mention that "intl.accept_languages" is a special case for Tor Browser. We don't bind it to privacy.resistFingerprinting, but instead we prompt the users at startup to ask if they want to spoof their language to US English. See bug 1039069 comment 1.)

Comment 6

[Tim Huang[:timhuang]]

In my implementation, these prefs will be updated by nsRFPService, that it will observe the change of 'privacy.resistFingerprinting' and updates these prefs properly. Following is what it will do.

  1. When flipping 'privacy.resistFingerprinting' to true, the service will store
     original values under the pref branch 'privacy.resistFingerprinting.prefsCache.'
     if they have a user setting value.
  2. Set all prefs with values that can prevent browser fingerprinting.
  3. If someone modifies these prefs when 'privacy.resistFingerprinting' is on,
     the change will be effective. And the service will update cached pref values.
     So, the user setting value won't be affected during disabling fingerprinting
     resistance.
  4. When flipping 'privacy.resistFingerprinting' to false, the service will try
     to restore these prefs with cached values. If cached value doesn't exist,
     the service will restore it back to the default value.

In addition, the nsRFPService will change prefs when it is the first run if 'privacy.resistFingerprinting' is turned on by default.

Comment 7

[Tim Huang[:timhuang]]

Attachment: Bug 1333933 - Part 1: Making the nsRFPService can automatically modify prefs that are related to fingerprinting resistance when 'privacy.resistFingerprinting' is changed.

This patch modifies nsRFPService to allow it can change prefs automatically when
flipping 'privacy.resistFingerprinting'. The nsRFPService will store original
pref values and set them properly when enabling fingerprinting resistance. And
it will restore these prefs back when disabling. Following is what it will do.
  1. When flipping 'privacy.resistFingerprinting' to true, the service will store
     original values under the pref branch 'privacy.resistFingerprinting.prefsCache.'
     if they have a user setting value.
  2. Set all prefs with values that can prevent browser fingerprinting.
  3. If someone modifies these prefs when 'privacy.resistFingerprinting' is on,
     the change will be effective. And the service will update cached pref values.
     So, they won't be affected during disabling fingerprinting resistance.
  4. When flipping 'privacy.resistFingerprinting' to false, the service will try
     to restore these prefs with cached values. If cached value doesn't exist,
     the service will restore it back to default value.

In addition, the nsRFPService will change prefs when it is the first run if
'privacy.resistFingerprinting' is turned on by default.

Review commit: https://reviewboard.mozilla.org/r/140070/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/140070/

Comment 8

[Tim Huang[:timhuang]]

Attachment: Bug 1333933 - Part 2: Add a test case to test whether prefs can be modified and restored correctly when flipping 'privacy.resistFingerprinting'.

This patch add a test case for modification and restoration of fingerprinting
prefs when flipping 'privacy.resistFingerprinting'.

In addition, this patch also fixes some test cases that affect by prefs changes.

Review commit: https://reviewboard.mozilla.org/r/140072/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/140072/

Comment 9

[François Marier [:francois]]

Comment on attachment 8868466 [details]
Bug 1333933 - Part 1: Making the nsRFPService can automatically modify prefs that are related to fingerprinting resistance when 'privacy.resistFingerprinting' is changed.

https://reviewboard.mozilla.org/r/140070/#review143644

::: toolkit/components/resistfingerprinting/nsRFPService.cpp:265
(Diff revision 1)
>    const char* tzValue = PR_GetEnv("TZ");
>    if (tzValue) {
>      mInitialTZValue = nsCString(tzValue);
>    }
>  
> +  AddPrefModifier("geo.enabled", false);

Unless I'm missing something, the geo API already prompts users before releasing geolocation to content so it can't be used to fingerprint without the user's cooperation.

::: toolkit/components/resistfingerprinting/nsRFPService.cpp:277
(Diff revision 1)
> +  AddPrefModifier("general.useragent.locale", "en-US");
> +
> +  AddPrefModifier("webgl.min_capability_mode", true);
> +  AddPrefModifier("webgl.disable-extensions", true);
> +  AddPrefModifier("webgl.disable-fail-if-major-performance-caveat", true);
> +  AddPrefModifier("dom.battery.enabled", false);

That was removed in bug 1313580.

Comment 10

[Arthur Edelstein [:arthur]]

Comment on attachment 8868466 [details]
Bug 1333933 - Part 1: Making the nsRFPService can automatically modify prefs that are related to fingerprinting resistance when 'privacy.resistFingerprinting' is changed.

https://reviewboard.mozilla.org/r/140070/#review143674

Very nice! Minor corrections suggested below.

::: toolkit/components/resistfingerprinting/nsRFPService.cpp:88
(Diff revision 1)
> +  if (XRE_IsParentProcess() &&
> +      nsRFPService::IsResistFingerprintingEnabled()) {
> +    // If a user sets the pref value when fingerprinting resistance is enabled,
> +    // then we will update the cached pref as well. So, the user's setting will
> +    // not be affected during the disabling of fingerprinting resistance .
> +    DoPrefCopy(mPrefName, mCachedPrefName.get());

Suppose fingerprinting resistance is enabled, and the user manually flips the pref "webgl.min_capability_mode" (for example) from true to false and then back to true again. Then I think the pref should probably be removed from the cache, correct?

::: toolkit/components/resistfingerprinting/nsRFPService.cpp:298
(Diff revision 1)
> +    int32_t minorVerPos = appVersion.FindChar('.');
> +    int32_t minorVerLen = appVersion.Length() - minorVerPos;
> +
> +    appVersion.Replace(minorVerPos, minorVerLen, ".0");
> +    nsPrintfCString spoofedUA("Mozilla/5.0 (Windows NT 6.1; rv:%s) Gecko/20100101 Firefox/%s",
> +      appVersion.get(), appVersion.get());

It would be nice here to round the Firefox version even more to avoid leaking too much information. For example, show the most recent ESR version? Or round down to the nearest 10. (E.g., 40, 50, 60).

::: toolkit/components/resistfingerprinting/nsRFPService.cpp:332
(Diff revision 1)
> +  AddPrefModifier("ui.use_standins_for_native_colors", true); // https://bugzilla.mozilla.org/232227
> +  // Make Reader View users uniform if they really want to use that feature. See
> +  // https://bugs.torproject.org/18950 for more details.
> +  AddPrefModifier("browser.reader.detectedFirstArticle", true);
> +  AddPrefModifier("reader.parse-on-load.enabled", false);
> +

Here are a few more settings recently added in Tor Browser:
pref("media.webspeech.synth.enabled", false); // Bug 10283: Disable SpeechSynthesis API
pref("dom.webaudio.enabled", false); // Bug 13017: Disable Web Audio API
pref("dom.maxHardwareConcurrency", 1); // Bug 21675: Spoof single-core cpu
pref("dom.w3c_touch_events.enabled", 0); // Bug 10286: Always disable Touch API

::: toolkit/components/resistfingerprinting/nsRFPService.cpp:441
(Diff revision 1)
> +    }
> +  }
> +}
> +
> +void
> +nsRFPService::StartObserveFingerprintingPrefs()

I would suggest calling this StartObservingFingerprintingPrefs() or ObserveFingerprintingPrefs().

::: toolkit/components/resistfingerprinting/nsRFPService.cpp:487
(Diff revision 1)
>  
>      if (pref.EqualsLiteral(RESIST_FINGERPRINTING_PREF)) {
>        UpdatePref();
> +
> +      // This will happen during the initialization of pref system, we won't
> +      // update other prefs at this moment since this is not a mannul change

Typo (manual)

::: toolkit/components/resistfingerprinting/nsRFPService.cpp:510
(Diff revision 1)
> +      // If fingerprinting resistance is on after the profile is loaded and this
> +      // is not the firest run, we start to observe all fingerprinting prefs
> +      // for their changes.
> +      StartObserveFingerprintingPrefs();
> +    }
> +

When you call ModifyFingerprintingPrefs, it calls EnableRFP() on each pref which in turn calls RegisterObserver. But this seems to make StartObserveFingerprintingPrefs() redundant. (Or maybe I'm confused.)

Comment 11

[Arthur Edelstein [:arthur]]

Comment on attachment 8868467 [details]
Bug 1333933 - Part 2: Add a test case to test whether prefs can be modified and restored correctly when flipping 'privacy.resistFingerprinting'.

https://reviewboard.mozilla.org/r/140072/#review143682

Great to have these tests. Once you address the "webgl.min_capability_mode" example I brought up in Part 1, it would be nice to have a test for that case as well.

Thanks for your fantastic work on this!

::: browser/components/resistfingerprinting/test/browser/browser_prefs.js:49
(Diff revision 1)
> +  { name: "dom.event.highrestimestamp.enabled", value: true},
> +  { name: "privacy.suppressModifierKeyEvents", value: true},
> +  { name: "ui.use_standins_for_native_colors", value: true},
> +  { name: "browser.reader.detectedFirstArticle", value: true},
> +  { name: "reader.parse-on-load.enabled", value: false},
> +];

Please add extra prefs I mentioned in my review of Part 1.

Comment 12

[Thorin [:thorin]]

Legacy/Deprecated/Removed
- `dom.battery.enabled` (already pointed out by myself earlier, and now by Francois, Battery Status API is only available in chrome/privileged code).
- `dom.network.enabled` (this no longer exists AFAIK, I cannot find the ticket, it was around FF31 that it was removed).  MAYBE what you are after is `dom.netinfo.enabled`

TBB only prefs
- `privacy.suppressModifierKeyEvents`
- `intl.charset.default`

TBB only prefs, or Legacy/Deprecated/Removed (these are not in Firefox any more)?
- `general.productSub.override`, `general.useragent.vendor`, `general.useragent.vendorSub`
- `plugin.expose_full_path` (TBB already blocks Flash by not loading plugins)

Aww, hell no! :) 
- `browser.zoom.siteSpecific` - Why? Is there going to be any discussion on this. This is a deal breaker (maybe, see question)

Question
- How are lock_prefs handled? Will they be over-ridden by resistFingerprinting values?

Ramifications
 - UA strings - is anyone covering some sort of whitelist for AMO etc (there is some overlap here with  https://bugzilla.mozilla.org/show_bug.cgi?id=1333651 )

I know that the list of prefs flipped by privacy.resistFingerprinting is not finalized, but can we please not apply TBB only prefs to Firefox, can we not apply prefs that no longer exist or are used.

Prefs to consider:
- `media.navigator.enabled` ==> false // disable media device enumeration
- `media.ondevicechange.enabled` => false // disable MediaDevices change detection
- disable HTTP2 which allows new server side fingerprinting opportunities (this is disabled in TBB due to multiplexing and there is also "server push")
  `network.http.spdy.enabled` => false
  `user_pref("network.http.spdy.enabled.deps` => false
  `user_pref("network.http.spdy.enabled.http2` => false

Comment 13

[Thorin [:thorin]]

(In reply to Arthur Edelstein [:arthuredelstein] from comment #10)
> It would be nice here to round the Firefox version even more to avoid
> leaking too much information. For example, show the most recent ESR version?
> Or round down to the nearest 10. (E.g., 40, 50, 60).

I recommend most recent ESR for compatibility

> Here are a few more settings recently added in Tor Browser:
> pref("dom.maxHardwareConcurrency", 1); // Bug 21675: Spoof single-core cpu

`navigator.hardwareConcurrency` is spoofed as value 2 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1360039) since that is the most common Firefox metric (see https://metrics.mozilla.com/firefox-hardware-report/ ). Should `dom.maxHardwareConcurrency` not be the same?

Is anyone going to address the issue of the UA navigator.* spoofing items that are not fully spoofed? UA http header will not match JS's value when it queries navigator.userAgent. Or JS pulling the real values for say navigator.platform or navigator.oscpu. Not to mention some of these "spoofs" leak over iframes.

Comment 14

[Tim Huang[:timhuang]]

(In reply to Simon Mainey from comment #12)
> Legacy/Deprecated/Removed
> - `dom.battery.enabled` (already pointed out by myself earlier, and now by
> Francois, Battery Status API is only available in chrome/privileged code).
> - `dom.network.enabled` (this no longer exists AFAIK, I cannot find the
> ticket, it was around FF31 that it was removed).  MAYBE what you are after
> is `dom.netinfo.enabled`

Yes, it should be 'dom.netinfo.enabled'. Thank you for pointing this out.

> 
> TBB only prefs
> - `privacy.suppressModifierKeyEvents`
> - `intl.charset.default`

The 'intl.charset.default' was removed by Bug 910192. So I think we can drop this as well.

The 'privacy.suppressModifierKeyEvents' will be added in Bug 1222285 (Tor 17009). So, I think we can add this here. But, maybe we could also use 'privacy.resistFingerprinting' instead of this pref, like 'privacy.use_utc_timezone'. What do you think, Arthur?

> 
> TBB only prefs, or Legacy/Deprecated/Removed (these are not in Firefox any
> more)?
> - `general.productSub.override`, `general.useragent.vendor`,
> `general.useragent.vendorSub`

These three prefs have been removed. For now, productSub, vendor and vendorSub will always reply a fixed string. So, I think it is OK to remove them.

> - `plugin.expose_full_path` (TBB already blocks Flash by not loading plugins)
> 

Bug 661961 removes this pref. So, we should remove this as well.

> Aww, hell no! :) 
> - `browser.zoom.siteSpecific` - Why? Is there going to be any discussion on
> this. This is a deal breaker (maybe, see question)
> 

My concern is that the zoom level is going to be a fingerprintable factor if a website can know this by certain ways. So, if we want to provide a full anti-fingerprinting feature, then we should set this to false. However, you can still set it to true when 'privacy.resistFingerprinting' is on if you want to.

Arthur, do you have something to add on this?

> Question
> - How are lock_prefs handled? Will they be over-ridden by
> resistFingerprinting values?
> 

If the pref has been locked, then nsRFPService will not change the value since the pref system doesn't allow to. So the pref will remain intact when flipping 'privacy.resistFingerprinting'.

> Ramifications
>  - UA strings - is anyone covering some sort of whitelist for AMO etc (there
> is some overlap here with 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1333651 )
> 
> I know that the list of prefs flipped by privacy.resistFingerprinting is not
> finalized, but can we please not apply TBB only prefs to Firefox, can we not
> apply prefs that no longer exist or are used.
> 

It makes sense to me.

> Prefs to consider:
> - `media.navigator.enabled` ==> false // disable media device enumeration
> - `media.ondevicechange.enabled` => false // disable MediaDevices change
> detection
> - disable HTTP2 which allows new server side fingerprinting opportunities
> (this is disabled in TBB due to multiplexing and there is also "server push")
>   `network.http.spdy.enabled` => false
>   `user_pref("network.http.spdy.enabled.deps` => false
>   `user_pref("network.http.spdy.enabled.http2` => false

I think it will be good to take these prefs as well. Arthur, what do you think?

Comment 15

[Thorin [:thorin]]

Thanks Tim Huang .. also .. to add (and I have more, sticking to FP only, if you guys are interested) ...

`security.ssl.disable_session_identifiers`-> true// (hidden pref)

Comment 16

[Tim Huang[:timhuang]]

(In reply to Simon Mainey from comment #13)
> Is anyone going to address the issue of the UA navigator.* spoofing items
> that are not fully spoofed? UA http header will not match JS's value when it
> queries navigator.userAgent. Or JS pulling the real values for say
> navigator.platform or navigator.oscpu. Not to mention some of these "spoofs"
> leak over iframes.

I believe that 'general.useragent.override' will override navigator.userAgent. See [1]. For navigator.platform, 'general.platform.override' will do the job, see [2]. And 'general.oscpu.override' for 'navigator.oscpu', see [3].

you could use https://browserleaks.com/javascript to test them.

[1] http://searchfox.org/mozilla-central/source/dom/base/Navigator.cpp#1859
[2] http://searchfox.org/mozilla-central/source/dom/base/Navigator.cpp#1751
[3] http://searchfox.org/mozilla-central/source/dom/base/Navigator.cpp#468

Comment 17

[(no longer active)]

I don't think what the part 1 patch here is doing is a good idea at all.  Here are the problems I can see with it:

* This is being shoehorned on top of the prefs service.  For this example, if I run a build which is aware of privacy.resistFingerprinting.prefsCache.foo and then downgrade to a build before this patch landed, what would that build do?
* The implications of something being added to the list of prefs here in the future is unclear to me.  Even more importantly, the implications of something being *removed* from the list of prefs here is unclear to me.  For example what if I have an entry for privacy.resistFingerprinting.prefsCache.foo in my prefs.js in my profile directory and upgrade to a build which has removed the code to handle privacy.resistFingerprinting.prefsCache.foo?
* This code is way too complex!

Reading comment 0, it seems like the use case here is for the Tor Browser to use different values for a number of our prefs and prevent the user from changing the values of those prefs at runtime.  Do I understand that use case correctly?

If yes, this is something that the prefs service supports properly, we don't need to hack around it like this!  See nsIPrefBranch::LockPref() and friends.  The short solution would be to ensure that the prefs in question have prohibitive defaults as opposed to permissive defaults, and grant them Firefox and Fennec (and Thunderbird and SeaMonkey) specific permissive overrides and then lock the prefs in the Tor Browser...

(Also, FWIW, it would really help if the patch that implements the code part of this is kept separate from the patch that lists the prefs in question, since those will require very different types of reviews...)

Comment 18

[(no longer active)]

Comment on attachment 8868466 [details]
Bug 1333933 - Part 1: Making the nsRFPService can automatically modify prefs that are related to fingerprinting resistance when 'privacy.resistFingerprinting' is changed.

https://reviewboard.mozilla.org/r/140070/#review144722

Clearing the review flag for now because I don't think this is the right implementation strategy.

Comment 19

[(no longer active)]

Comment on attachment 8868467 [details]
Bug 1333933 - Part 2: Add a test case to test whether prefs can be modified and restored correctly when flipping 'privacy.resistFingerprinting'.

https://reviewboard.mozilla.org/r/140072/#review144724

Comment 20

[(no longer active)]

Arthur, do you mind confirming my understanding of the use case in comment 0 please?

Comment 21

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #17)
> Reading comment 0, it seems like the use case here is for the Tor Browser to
> use different values for a number of our prefs and prevent the user from
> changing the values of those prefs at runtime.  Do I understand that use
> case correctly?

Yes and No. I don't have the only opinion on this, but I've got one opinion. The PrefService approach was chosen not to help Tor Browser set and lock preferences. Tor Browser can as easily set 100 prefs individually as it can set 1, and it doesn't prevent the user from changing any of them if they go into about:config.

The goal is having N prefs controlled by 1 pref is to tie the Firefox codebase together under a single logical preference - while still providing flexibility for hotfixes/customization - and make Bug 1308340 possible.

Comment 22

[Arthur Edelstein [:arthur]]

(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #20)
> Arthur, do you mind confirming my understanding of the use case in comment 0
> please?

Hi Ehsan -- I think the main idea of this ticket, as Tom says, is to introduce a single pref ("privacy.resistFingerprinting") that turns on all anti-fingerprinting defenses. As I see it, having a single pref has multiple benefits:

 1. It clearly defines in the code base what features are considered "fingerprinting defenses."
 2. It makes it simple for users to know whether they have fingerprinting defenses activated.
 3. It does the right thing by activating all fingerprinting defenses at once (fingerprinting defenses used individually aren't very effective).

My hope is this will benefit both Firefox and Tor Browser. It gives Firefox users (and users of downstream browsers) a fingerprinting resistance option. And Mozilla's uplift efforts are extremely helpful to Tor by reducing our maintenance burden and by improving our patch quality. (Much appreciated, btw!)

I think your pref locking suggestion is very interesting and is something we might want to adopt. I discussed with Tim how we might ensure "privacy.resistFingerprinting" remains a dynamic pref. One approach we suggested is for each affected pref, we could cache the nonresistant default value, set a new resistant default value, and then lock each pref to ensure the resistant default value is active. Does this idea make sense to you?

But apart from that, I think it would be ideal if Firefox eventually introduces fingerprinting resistance into Private Browsing Mode by default. So it's worth considering if whatever approach used here can work with PBM in the future. One approach would be simply to patch each affected feature directly in the codebase, rather than setting numerous prefs as we do in Tim's patch. If we stick with the prefs approach, on the other hand, then in the future maybe it would be possible to introduce a mechanism that allows pref settings in the PBM child process different from pref settings in the parent process.

Comment 23

[Tim Huang[:timhuang]]

(In reply to Arthur Edelstein [:arthuredelstein] from comment #22)
> (In reply to :Ehsan Akhgari (super long backlog, slow to respond) from
> comment #20)
> I think your pref locking suggestion is very interesting and is something we
> might want to adopt. I discussed with Tim how we might ensure
> "privacy.resistFingerprinting" remains a dynamic pref. One approach we
> suggested is for each affected pref, we could cache the nonresistant default
> value, set a new resistant default value, and then lock each pref to ensure
> the resistant default value is active. Does this idea make sense to you?
> 

This can work on the prefs that have default values. However, it won't work with prefs that have no default values, such as 'general.buildId.override'. The problem comes when turning off the 'privacy.resistFingerprinting' that there is no way to clear the PREF_FLAG_HAS_DEFAULT flag to make these prefs non-default again. So, when we unlock them, they will still report the value that we set during turning on 'privacy.resistFingerprinting'.

That's is to say, we have to make some modifications in the pref API. Either adding a function to clear this flag or adding a lockToGivenValue() function and use this to lock these prefs into resistant default values.


Froydnj, could you provide some insight about this?

Comment 24

[Nathan Froyd [:froydnj]]

(In reply to Tim Huang[:timhuang] from comment #23)
> This can work on the prefs that have default values. However, it won't work
> with prefs that have no default values, such as 'general.buildId.override'.
> The problem comes when turning off the 'privacy.resistFingerprinting' that
> there is no way to clear the PREF_FLAG_HAS_DEFAULT flag to make these prefs
> non-default again. So, when we unlock them, they will still report the value
> that we set during turning on 'privacy.resistFingerprinting'.
> 
> That's is to say, we have to make some modifications in the pref API. Either
> adding a function to clear this flag or adding a lockToGivenValue() function
> and use this to lock these prefs into resistant default values.

I am unclear on how lockToGivenValue() would address the problem with clearing PREF_FLAG_HAS_DEFAULT.  And why would setting these prefs that don't have default values to new values via setting privacy.resistfingerprinting to true also set PREF_FLAG_HAS_DEFAULT?

Stepping back, let me make sure I understand the desired situation here:

* We want a single pref, privacy.resistfingerprinting;
* That pref, when set, should activate a bunch of other prefs;
* That pref, when unset, should set all the other prefs back to whatever values they had previously, default or otherwise?

Where are we going to store the previous state of the other prefs?

Surely this can't be the first time that we've had one pref that really controls multiple other prefs, can it?  What have people done before for this sort of thing?

This usage of the prefs system feels like a bit of an edge case; I'm not keen on adding code to the prefs service in support of it, but it is also entirely possible that I'm misunderstanding the situation.  Please help me understand!

Comment 25

[Tim Huang[:timhuang]]

(In reply to Nathan Froyd [:froydnj] from comment #24)
> I am unclear on how lockToGivenValue() would address the problem with
> clearing PREF_FLAG_HAS_DEFAULT.

Actually, they are two different approaches. Sorry about confusing you.

The problem here is that we cannot clear PREF_FLAG_HAS_DEFAULT since the API itself doesn't allow us to do it. When we turn on 'privacy.resistFingerprinting', it will set a default value to other prefs, and lock them to make them reporting default values, the value for anti-fingerprinting. And then, we turn off 'privacy.resistFingerprinting' and it will unlock those prefs and restore their default back to the original state. However, it is not possible to restore the state of a pref back to *a pref without a default value*. For example, the pref 'general.useragent.override'.

The lockToGivenValue() is another approach that instead of locking one pref to the default value, maybe we could lock it into a given value. By doing so, we don't have to touch its default value.


> And why would setting these prefs that
> don't have default values to new values via setting
> privacy.resistfingerprinting to true also set PREF_FLAG_HAS_DEFAULT?
> 

Because 'privacy.resistfingerprinting' will set default values, so those prefs will report values what we want after locking them. We apply this to those prefs that have no default values as well. 

> Stepping back, let me make sure I understand the desired situation here:
> 
> * We want a single pref, privacy.resistfingerprinting;
  Yes, we want it to be a meta pref that control a bunch of other prefs.

> * That pref, when set, should activate a bunch of other prefs;
  We want those prefs to return a specific value for anti-fingerprinting.

> * That pref, when unset, should set all the other prefs back to whatever
> values they had previously, default or otherwise?
> 
  We like it to be restored back to what it was before 'privacy.resistFingerprinting' was set. So, if it had a user value at before, then we restore it back to that, and the same for prefs had default values.

> Where are we going to store the previous state of the other prefs?
> 

The nsRPFService will do this job for caching the previous state. The previous state would be the previous default value if we use prefLock to implement this.

> Surely this can't be the first time that we've had one pref that really
> controls multiple other prefs, can it?  What have people done before for
> this sort of thing?
> 

I believe SaveBrowsing has done something similar before. Francois should know it better. 

Francois, could you answer this for me?

> This usage of the prefs system feels like a bit of an edge case; I'm not
> keen on adding code to the prefs service in support of it, but it is also
> entirely possible that I'm misunderstanding the situation.  Please help me
> understand!

Comment 26

[Thorin [:thorin]]

(In reply to Tim Huang[:timhuang] from comment #25)
> > Where are we going to store the previous state of the other prefs?
> 
> The nsRPFService will do this job for caching the previous state. The
> previous state would be the previous default value if we use prefLock to
> implement this.

To consider, what if the default/previous state is changed by an application update, such as when a default pref value is flipped, or indeed the build.id on each build

eg. 'pref.example' in FF55 is default true. User turns on privacy.resistFingerprinting which stores the previous value as true, and then flips it to false in order to strengthen anti-fingerprinting. User upgrades to FF56. IN FF56 the default value was changed to false. User disables privacy.resistFingerprinting and the value is "unlocked" and set back to the "stored value" of true, which is no longer the default value, it should now be false.

I think you would need to store two values. A boolean of whether the value matches the current default or not, and the actual value. Then a roll-back of the stored value can check the boolean first and if default was used before, reset to default now, else restore the stored value. This still doesn't cover prefs with no default value.

Comment 27

[Nathan Froyd [:froydnj]]

(In reply to Tim Huang[:timhuang] from comment #25)
> (In reply to Nathan Froyd [:froydnj] from comment #24)
>   We like it to be restored back to what it was before
> 'privacy.resistFingerprinting' was set. So, if it had a user value at
> before, then we restore it back to that, and the same for prefs had default
> values.
> 
> > Where are we going to store the previous state of the other prefs?
> 
> The nsRPFService will do this job for caching the previous state. The
> previous state would be the previous default value if we use prefLock to
> implement this.

I don't see any code that would handle this across browser restarts in nsRPFService.  Maybe prefs would handle this automatically with default values, but I'm not 100% clear on that; Simon's concerns in comment 26 seems relevant, for instance.

Comment 28

[François Marier [:francois]]

(In reply to Tim Huang[:timhuang] from comment #25)
> > Surely this can't be the first time that we've had one pref that really
> > controls multiple other prefs, can it?  What have people done before for
> > this sort of thing?
> > 
> 
> I believe SaveBrowsing has done something similar before. Francois should
> know it better. 

In Safe Browsing, we do this in the UI. We have a couple of UI checkboxes that control multiple about:config prefs at once. Because the UI element is the "meta pref", we don't have to deal with locking prefs or restoring their original values.

Comment 29

[Tim Huang[:timhuang]]

I think what Francois said in comment 28 is also a possible way to do this. 

We could use a UI checkbox to flip prefs, I think we can handle this in Bug 1308340.

For Tor browser, it can still use its default profile, 000-tor-browser.js, to spoof/disable certain functions by default. And if people want to disable anti-fingerprinting, which is really unlikely for tor's user, the UI can flip them as well.

For firefox, we still use our default values and not treat 'privacy.resistFingerprinting' as a meta pref, and this UI checkbox plays a virtual meta pref here. However, we may not expose this UI checkbox by default, but hide this by an another pref.

Arthur, what do you think about this?

Comment 30

[Arthur Edelstein [:arthur]]

(In reply to Tim Huang[:timhuang] from comment #29)
> I think what Francois said in comment 28 is also a possible way to do this. 
> [...]
> Arthur, what do you think about this?

Hi Tim -- sorry for the delay. I am not sure using a UI gives you a cleaner solution than the meta-pref. The fundamental problem seems to be that by modifying secondary prefs, we are introducing a complex behavior that juggles various values as the user flips prefs.

My inclination at this point is that patching the fingerprintable features directly is preferable to using a meta-pref. That means that "privacy.resistFingerprinting" checks will need to be introduced in various places in the codebase. I think this has two advantages:

1. When "privacy.resistFingerprinting" is set to true, then fingerprinting resistance is enforced regardless of other pref values. The behavior is much simpler for users and developers to understand.
2. In the future, it will much easier to migrate to turning fingerprinting resistance on by default in private browsing mode.

Comment 31

[Tim Huang[:timhuang]]

I agree with that we should patch the whole codebase for fingerprintable features instead of building this on top of the pref system. However, I think we should open a series of bugs for each feature and use Bug 1329996 to track them. I will do this, and following is the list of features that we are going to touch:

* GeoIP Search
* WebGL (Bug 1217290)
* Navigator Object (Bug 1333651)
  - GeoLocation API
  - Network Information API
  - User Agent, Build ID, etc.
  - Media devices
* Performance API
  - Performance Timing API
  - Resource Timing
  - User Timing API
* Site Specific Zooming
* GamePad API
* WebRTC
* Language Setting (Bug 1039069)
* Media Stats
* Uptime leaks problem
* Reader View
* Font-Face fallback download
* Restrict Popup windows 
* Use English locale in Javascript
* Device Sensors
* System color (Bug 1330876)
* Suppress modifier key event (Bug 1222285)

Above items are created based on prefs that was listed in comment 0.

Arthur, do you have anything to add here?

Comment 32

[Tim Huang[:timhuang]]

Move this bug into M3 since we are not going to rely on the pref system to spoof/disable features.

Comment 33

[Arthur Edelstein [:arthur]]

(In reply to Tim Huang[:timhuang] from comment #31)

> Arthur, do you have anything to add here?

Hi Tim -- here are some things missing from the list in comment 31:
pref("media.webspeech.synth.enabled", false); // Bug 10283: Disable SpeechSynthesis API
pref("dom.webaudio.enabled", false); // Bug 13017: Disable Web Audio API
pref("dom.w3c_touch_events.enabled", 0); // Bug 10286: Always disable Touch API

Comment 34

[Arthur Edelstein [:arthur]]

Oh, one other thing we disabled in Tor Browser via prefs is the social API:

+// Disable Social API and related stuff (Bug #13612)
+pref("social.directories", "");
+pref("social.remote-install.enabled", false);
+pref("social.share.activationPanelEnabled", false);
+pref("social.shareDirectory", "");
+pref("social.toast-notifications.enabled", false);
+pref("social.whitelist", "");

Comment 35

[Thorin [:thorin]]

^^ +pref("social.enabled", false); // https://dxr.mozilla.org/mozilla-central/search?q=social.enabled&redirect=false

Comment 36

[Thorin [:thorin]]

(In reply to Arthur Edelstein [:arthuredelstein] from comment #33)
> (In reply to Tim Huang[:timhuang] from comment #31)
> 
> > Arthur, do you have anything to add here?
> 
> Hi Tim -- here are some things missing from the list in comment 31:
> pref("media.webspeech.synth.enabled", false); // Bug 10283: Disable
> SpeechSynthesis API
> pref("dom.webaudio.enabled", false); // Bug 13017: Disable Web Audio API
> pref("dom.w3c_touch_events.enabled", 0); // Bug 10286: Always disable Touch
> API

media.webspeech.recognition.enable

Comment 37

[Thorin [:thorin]]

(As per comment #2)

reworded:
> a built-in whitelist should be considered, eg mozilla AMO. i.e user enables privacy.resistFingerprinting and then suddenly wonders why he can't install certain extensions

Bug 1333651 introduced spoofing UA & navigator objects, but now causes issues with AMO. I have not tested (I do not have a 56/57 to test with) but here is a link: https://github.com/pyllyukko/user.js/issues/333

Would it also be prudent to double-check that nothing else used by Mozilla is affected, eg Telemetry?

The whitelist IMO should be hard coded and not stored as a pref. Should I (or someone else) open a new ticket? I only posted in here because I sometimes have trouble getting triage to get Tor Uplift's attention

Comment 38

[Ethan Tseng [:ethan]]

The initial design is no longer valid (see comment 31).
We don't need this bug for the MVP of fingerprinting resistance.
However, there is a bunch of useful information in this bug, leave it open in the backlog.

Comment 39

[Mark]

I recently upgraded from Firefox 54 to Firefox 56 (as per default in Fedora 26).

Unfortunately, Firefox 56 broke site-specific zoom, it no longer works. Is zoom per site disabled because of changes to privacy.resistFingerprinting in Firefox 56? If yes, how can I get back the old behaviour?

Thank you.

Comment 40

[Thorin [:thorin]]

(In reply to Mark from comment #39)
> IS zoom per site disabled because of changes to privacy.resistFingerprinting in
> Firefox 56? If yes, how can I get back the old behaviour?

See Bug 1369357 . In order to get back zoom settings per site, you will have to use an extension. If you don't use privacy.resistFingerprinting then you lose all the other dozens of benefits (and more to come).

Maybe something like https://addons.mozilla.org/en-US/firefox/addon/custom-page-zoom/

Comment 41

[Mark]

Unfortunately, I tried a few extensions but they all depend on browser.zoom.siteSpecific, which is disabled when privacy.resistFingerprinting is enabled, thus site specific zoom isn't possible even with an extension.

Here is one example that doesn't work:
https://addons.mozilla.org/en-US/firefox/addon/zoom-page/

About the suggested custom-page-zoom, it is a horrible extension because it does not resize the site when the browser window is resized, which means I need to re-zoom all websites all over again after a browser window resize, which is of course not realistic.

Would it be possible to use site specific zoom like before, but actually report a fake zoom level, thus solving the problem of fingerprinting and usability?

Thank you.

Comment 42

[Ethan Tseng [:ethan]]

(In reply to Mark from comment #41)
> Would it be possible to use site specific zoom like before, but actually
> report a fake zoom level, thus solving the problem of fingerprinting and
> usability?

This is complicated and I am not positive this approach is feasible.

Tim and Arthur,
Could you provide some feedback to Mark's concern and advice here?

Comment 43

[Tim Huang[:timhuang]]

AFAICT, We have prevented the content to get the real zoom level, i.e. window.devicePixelRatio, when anti-fingerprinting is enabled. However, there are some other ways to know the zoom level. For example, the document will reflow itself when the zoom level is changing, the document elements will be layout differently according to your new zoom level. So, The content can detect the zoom level by using this.

  Right now, we don't have an effective way to prevent this and there could be more ways to figure out the zoom level. Unfortunately, we still have to stick with the current approach unless we can tackle all possibilities of knowing the zoom level.

Comment 44

[Nayeli Jaskolski]

I wonder if features causing breakages should be included in privacy.resistFingerprinting at all until safe solution is found. Zoom and useragent (https://bugzilla.mozilla.org/show_bug.cgi?id=1394448) are good examples.

I'm privacy advocate and was tweaking  various privacy features myself for years but after last changes I had to disable privacy.resistFingerprinting as it was unbearable for me. It's easier to tweak individual options than dealing with one doing multiple things at once with no granularity and without chance for override.

For example you can easily change useragent using one of dozens available addons which won't work on AMO thanks to webextension design. privacy.resistFingerprinting is actually step backward in that case.

I propose to drop such features from privacy.resistFingerprinting for now. Otherwise users won't use it or will be constantly complaining.

Comment 45

[Arthur Edelstein [:arthur]]

(In reply to Tim Huang[:timhuang] from comment #43)
> AFAICT, We have prevented the content to get the real zoom level, i.e.
> window.devicePixelRatio, when anti-fingerprinting is enabled. However, there
> are some other ways to know the zoom level. For example, the document will
> reflow itself when the zoom level is changing, the document elements will be
> layout differently according to your new zoom level. So, The content can
> detect the zoom level by using this.
> 
>   Right now, we don't have an effective way to prevent this and there could
> be more ways to figure out the zoom level. Unfortunately, we still have to
> stick with the current approach unless we can tackle all possibilities of
> knowing the zoom level.

I agree with Tim that there isn't a simple way to hide the true zoom because of reflow of content.

I think there is a complex solution that involves dynamically rounding the dimensions of windows. I wrote a prototype in https://trac.torproject.org/14429 but it would need a re-write in C++ with a number of things different. I opened bug 1407366 to consider this further.

Comment 46

[Arthur Edelstein [:arthur]]

(In reply to Nayeli Jaskolski from comment #44)
> I wonder if features causing breakages should be included in
> privacy.resistFingerprinting at all until safe solution is found. Zoom and
> useragent (https://bugzilla.mozilla.org/show_bug.cgi?id=1394448) are good
> examples.

Hi Nayeli,

I don't think we can easily disable some anti-fingerprinting features without losing the benefits of fingerprinting resistance. Fingerprinting protection will only work when most or all leaks of distinctive information are blocked.

But I do think your concerns about usability are very important. One proposal that might help is bug 1404017, providing an option to enable privacy.resistFingerprinting in Private Browsing windows specifically. In that case, users will perhaps be more understanding of breakage. Also, addons should be disabled when private.resistFingerprinting is being used, because addons frequently expose leak identifying information to content. Disabling addons in Private Browsing windows seems like a reasonable compromise to me.

Comment 47

[Mark]

If you disable my uBlock Origin addon, I'm moving to another browser this millisecond :)

I now understand the technical issues and to be honest I didn't expect a simple thing as zoom-per-site would be such a problem. Maybe off-topic but I think this issue brings something else into mind, that when developers add new "features", they should probably take a moment to think about the privacy implications before implementing them, because it seems like the developers keep adding XYZ feature and then someone else has to clean up all their privacy mess :(  Food for thought...

Thank you all for taking the time to explain the technical issues, I appreciate it.

Comment 48

[Nayeli Jaskolski]

(In reply to Arthur Edelstein (Tor Browser dev) [:arthuredelstein] from comment #46)
> I don't think we can easily disable some anti-fingerprinting features
> without losing the benefits of fingerprinting resistance. Fingerprinting
> protection will only work when most or all leaks of distinctive information
> are blocked.

I'm not proposing to disable them permanently but only to put them on hold until they're ready, i.e. AMO site will be updated to handle useragent issue or correct zooming workaround will be figured out. Those things are very new and I don't think many users depend on them especially with above issues. It's good move but not ready yet in my opinion. 

> But I do think your concerns about usability are very important. One
> proposal that might help is bug 1404017, providing an option to enable
> privacy.resistFingerprinting in Private Browsing windows specifically. In
> that case, users will perhaps be more understanding of breakage. Also,
> addons should be disabled when private.resistFingerprinting is being used,
> because addons frequently expose leak identifying information to content.
> Disabling addons in Private Browsing windows seems like a reasonable
> compromise to me.

Well, until recently addons were thing which prevented those leaks rather than the other way. Now mozilla tries to re-implement some of their functionality in browser itself which is nice but not finished yet. I'm not a fan of Private Browsing mode and would prefer privacy.resistFingerprinting to be usable as default in everyday usage.

Comment 49

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

(In reply to Nayeli Jaskolski from comment #48)
> I'm not
> a fan of Private Browsing mode and would prefer privacy.resistFingerprinting
> to be usable as default in everyday usage.

I, and several others would prefer it be usable in everyday browsing also. We provide it as a pref (and even for Web Extensions) so we can test it and collect feedback on how we may want to expose it to end users. We're extremely grateful for the feedback we get about how we people want this to behave and be exposed. 

Right now we're focused on getting it performing all the technical mitigations we want (tracking at https://wiki.mozilla.org/Security/Fingerprinting target is 58; hard target is 59). After that we'll start exploring how we can tweak it so we can promote it as truly user facing. That may include things like per-origin opt-out (may be useful for AMO), providing additional prefs for individual items that have high breakage, or only enabling it in certain modes or containers.

I just want to set expectations correctly that for the next few months at least, we don't (currently) plan to back out changes relating to this pref, especially since it is a non-default config. But as I said, the more feedback we can get about what sites break and what features are annoying, the better we'll be able to make this in the future and the more likely we'll be able to promote it and make it a first-class citizen.

Comment 50

[Nayeli Jaskolski]

I understand, thank you. Good work!

Comment 51

[Thorin [:thorin]]

@Tom - https://wiki.mozilla.org/Security/Fingerprinting -> the date for 57 is out by a year

MVP for shipping to ESR59 .. Bug 1330890 needs revisiting. As per comments in that ticket, the UTC spoof is not covering Date().toLocaleString() and Intl.DateTimeFormat on Windows. Additionally date/time formatting is not standard, and neither is locale (eg revealing language).
- Reopen Bug 1330890 to address UTC spoof breakage
- New ticket for standardizing the format for various date/time (preferably to ISO 8601)
- New ticket for standardizing the locale? Or is there an existing ticket to do with language settings
Can we get a little action going on this least we forget :)

Comment 52

[Georg Koppen]

(In reply to Simon Mainey from comment #51)
> @Tom - https://wiki.mozilla.org/Security/Fingerprinting -> the date for 57
> is out by a year
> 
> MVP for shipping to ESR59 .. Bug 1330890 needs revisiting. As per comments
> in that ticket, the UTC spoof is not covering Date().toLocaleString() and
> Intl.DateTimeFormat on Windows. Additionally date/time formatting is not

The Intl.DateTimeFormat one seems to be https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.4.0esr-7.5-1&id=9973f6ce594863aad8bec9efec44947a0a5db548 which could get upstreamed.

Comment 53

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

(In reply to Simon Mainey from comment #51)
> MVP for shipping to ESR59 .. Bug 1330890 needs revisiting. As per comments
> in that ticket, the UTC spoof is not covering Date().toLocaleString() and
> Intl.DateTimeFormat on Windows. Additionally date/time formatting is not
> standard, and neither is locale (eg revealing language).
> - Reopen Bug 1330890 to address UTC spoof breakage
> - New ticket for standardizing the format for various date/time (preferably
> to ISO 8601)
> - New ticket for standardizing the locale? Or is there an existing ticket to
> do with language settings
> Can we get a little action going on this least we forget :)

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1409973 to encompass these, thanks! Let me know if I missed any vectors.

Comment 54

[©TriMoon™ Away from Bugmail unless has need to visit]

This snippet in our appcfg on Linux says enough i think...
> // We DONT want to use this because it modifies UserAgent tobe a Windows OS...
> lockPref('privacy.resistFingerprinting',			false)

Comment 55

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

(In reply to ©TriMoon™ from comment #54)
> This snippet in our appcfg on Linux says enough i think...
> > // We DONT want to use this because it modifies UserAgent tobe a Windows OS...
> > lockPref('privacy.resistFingerprinting',			false)

Bug 1404608 fixed this.

Comment 56

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

Arthur's going to go through this and create any new bugs we need to do.

Comment 57

[Thorin [:thorin]]

^^ Arthur: please add a ticket for "when RFP=true, block Etag response headers"

Comment 58

[Arthur Edelstein [:arthur]]

(In reply to Tom Ritter [:tjr] from comment #56)
> Arthur's going to go through this and create any new bugs we need to do.

I went through all the relevant prefs mentioned in this ticket and found or created tickets to address each one, except "browser.startup.homepage_override.buildID", which I'm not sure how to address.

  bug 1441295 pref("geo.enabled", false); [and bug 1372069]
  bug 1369299 pref("browser.search.countryCode", "US"); // The next three prefs disable GeoIP search lookups (#16254)
  bug 1369299 pref("browser.search.region", "US");
  bug 1369299 pref("browser.search.geoip.url", "");
  bug 1369299 pref("browser.search.geoSpecificDefaults", false);
  bug 1217290 pref("webgl.min_capability_mode", true);
  bug 1485249 pref("webgl.disable-extensions", true);
  bug 1485249 pref("webgl.disable-fail-if-major-performance-caveat", true);
  bug 1313580 pref("dom.battery.enabled", false); // fingerprinting due to differing OS implementations
  bug 1372072 pref("dom.network.enabled",false); [Should now be dom.netinfo.enabled]
     obsolete pref("gfx.downloadable_fonts.fallback_delay", -1); (obsolete; see https://trac.torproject.org/27258)
  bug 1333651 pref("general.appname.override", "Netscape");
  bug 1333651 pref("general.appversion.override", "5.0 (Windows)");
  bug 1333651 pref("general.oscpu.override", "Windows NT 6.1");
  bug 1333651 pref("general.platform.override", "Win32");
  bug 1333651 pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0");
  bug 1333651 pref("general.productSub.override", "20100101");
  bug 1333651 pref("general.buildID.override", "20100101");
      ??????? pref("browser.startup.homepage_override.buildID", "20100101");
  bug 1333651 pref("general.useragent.vendor", "");
  bug 1333651 pref("general.useragent.vendorSub", "");
  bug 1369303 pref("dom.enable_performance", false);
     obsolete pref("plugin.expose_full_path", false); [Removed in bug 883671]
  bug 1369357 pref("browser.zoom.siteSpecific", false);
  bug 1485258 pref("intl.charset.default", "windows-1252"); (pref no longer exists, but problem remains)
  bug 1407366 pref("browser.link.open_newwindow.restriction", 0); // https://bugs.torproject.org/9881
  bug 1337161 pref("dom.gamepad.enabled", false); // bugs.torproject.org/13023
  bug 867501  pref("javascript.use_us_english_locale", true);
  bug 1039069 pref("intl.accept_languages", "en-us, en"); // Set by Torbutton
  bug 1485258 pref("intl.accept_charsets", "iso-8859-1,*,utf-8"); // Set by Torbutton
  bug 1485258 pref("intl.charsetmenu.browser.cache", "UTF-8"); // Set by Torbutton
  bug 1369309 pref("media.video_stats.enabled", false);
  bug 1369319 pref("device.sensors.enabled", false);
  bug 1369303 pref("dom.enable_resource_timing", false); // https://bugs.torproject.org/13024
  bug 1369303 pref("dom.enable_user_timing", false); // https://bugs.torproject.org/16336
  bug 1485264 pref("dom.event.highrestimestamp.enabled", true); // https://bugs.torproject.org/17046: "Highres"
  bug 1222285 pref("privacy.suppressModifierKeyEvents", true); // https://bugs.torproject.org/17009: Suppress ALT, SHIFT"
  bug 1485266 pref("ui.use_standins_for_native_colors", true); // https://bugzilla.mozilla.org/232227
     obsolete pref("browser.reader.detectedFirstArticle", true);
  bug 1485268 pref("reader.parse-on-load.enabled", false);
  bug 1330890 pref("privacy.use_utc_timezone", true);
  bug 1372073 `media.navigator.enabled` ==> false // disable media device enumeration
  bug 1372073 `media.ondevicechange.enabled` => false // disable MediaDevices change detection
  needs audit `network.http.spdy.enabled.deps` [https://trac.torproject.org/projects/tor/ticket/27260]
  bug 1233846 pref("media.webspeech.synth.enabled", false); // Bug 10283: Disable SpeechSynthesis API
  bug 1358149 pref("dom.webaudio.enabled", false); // Bug 13017: Disable Web Audio API
  bug 1382499 pref("dom.w3c_touch_events.enabled", 0); // Bug 10286: Always disable Touch API
     obsolete "social.*"
  bug 1485280 pref("media.webspeech.recognition.enable", false)

Comment 59

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

Whoo!