Stop syncing privacy.resistFingerprinting by default
Categories
(Firefox :: Sync, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox102 | --- | fixed |
People
(Reporter: gregp, Assigned: markh)
References
Details
Attachments
(1 file)
Steps to reproduce:
I was helping someone that had a problem with websites not working in Firefox. We tried removing all add-ons, reinstalling the browser, making a new profile, etc. Eventually we narrowed it down to him signing into Firefox Sync. At some point he toggled privacy.resistFingerprinting, forgot about it, then signed into Firefox on a new computer. This preference synced, and trouble ensued.
Actual results:
privacy.resistFingerprinting Synced
Expected results:
privacy.resistFingerprinting should not sync.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Sync' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
| Assignee | ||
Comment 2•3 years ago
|
||
I don't see why this implies the preference should not sync - doesn't the same argument apply to all preferences, such as ones relating to 3rd-party cookies, or https-only etc?
| Reporter | ||
Comment 3•3 years ago
|
||
(In reply to Mark Hammond [:markh] [:mhammond] from comment #2)
I don't see why this implies the preference should not sync - doesn't the same argument apply to all preferences, such as ones relating to 3rd-party cookies, or https-only etc?
privacy.resistFingerprinting is not exposed in any UI and is expressly not intended for end users, it exists to make the maintenance of Tor Browser easier, if I remember correctly. I do not believe the same argument applies for ones relating to 3rd-party cookies, or https-only because those are intended for end users.
| Assignee | ||
Comment 4•3 years ago
|
||
A subset of the prefs synced by default is at https://searchfox.org/mozilla-central/search?q=services.sync.prefs.sync.&case=true&path=firefox.js, and many many of them do not have any UI. Maybe that should be our policy? But I'm not sure that "user was surprised when they forgot they set a pref" is the correct benchmark. Bug 1414153 is where this was added and has a compelling use-case - so I'm not sure there is one correct answer, but I do slightly lean towards assuming people flipping this pref know what they are doing and ones who did not explicitly ignored the warning about:config shows.
| Reporter | ||
Comment 5•3 years ago
|
||
I do slightly lean towards assuming people flipping this pref know what they are doing and ones who did not explicitly ignored the warning about:config shows.
I would agree with you, but I have seen many cases of folks flipping it, forgetting about it, then having big problems. The fact that RFP syncs feels like a bit of a footgun.
I'm not sure that "user was surprised when they forgot they set a pref" is the correct benchmark.
It isn't the best benchmark, but I think it applies in this case. When a site malfunctions because of privacy.resistFingerprinting, the cause is not obvious and may lead the user down a rabbithole of messing with unrelated settings, ultimately getting nowhere. Troubleshooting mode does not disable privacy.resistFingerprinting, which makes this even worse. so I think a pref of this magnitude should not sync by default, given its low discoverability, high risk for site breakage, and low troubleshootability (I hope this is a word).
| Assignee | ||
Comment 6•3 years ago
•
|
||
Everyone I've spoken to here is torn about this - on one hand, it's clear this is a footgun and many people follow random instructions on reddit etc and shoot themselves in the foot in a way that's difficult to diagnose. On the other hand, not syncing this could reasonably be considered a regression for privacy conscious users who explicitly set this, as witnessed in bug 1414153. I think we are leaning towards not syncing it though, so thanks! It is clear to everyone that troubleshooting mode should disable this, but a quick look didn't show me how to arrange for that to happen. So we'll discuss this some more.
Comment 7•3 years ago
|
||
FWIW In Bug 1693861 we added telemetry for RFP and determined the percentage of users who have enabled it were fewer than we thought based on bug reports. The results of that analysis were not documented well though, so re-running it isn't a bad idea.
I tend to think that it reasonable to have people who want to use an undocumented, not-recommended preference to need to enable it explicitly and not sync it.
| Assignee | ||
Comment 8•3 years ago
|
||
Updated•3 years ago
|
Comment 10•3 years ago
|
||
| bugherder | ||
Description
•