Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

privacy.resistFingerprinting #56

Open
allo- opened this issue Dec 2, 2016 · 8 comments
Open

privacy.resistFingerprinting #56

allo- opened this issue Dec 2, 2016 · 8 comments

Comments

@allo-
Copy link
Owner

@allo- allo- commented Dec 2, 2016

https://bugzilla.mozilla.org/show_bug.cgi?id=1308340

@allo-
Copy link
Owner Author

@allo- allo- commented Oct 1, 2017

I am note sure what this exactly implies before reading this in more details.

I reopen here now. Fo you have concrete suggestions about the setting or is it a bigger deal to use it correctly?

@allo- allo- reopened this Oct 1, 2017
@allo- allo- removed the easy label Oct 1, 2017
@allo-
Copy link
Owner Author

@allo- allo- commented Oct 1, 2017

Just picking some points for the moment:

geo.enabled if false disables the API but the RFP patch instead blocks requests (same as if you clicked deny when a website requests it)
In general I prefer to use defaults for settings, which ask the user for permission anyway. Blocking silently avoid one bit of information if I get it right, but probably the same bit as when the user chooses "always deny" in the firefox UI.
I guess there could be some tracking via "can I ask or is it always denied", but as this would be quite visible I see not important threat here. The setting is more convenience to avoid the dialog.

End users need to make sure relevant prefs are reset in about:config, otherwise their fingerprint is not the same.
So resist + enable = enabled, resist + disabled = disabled and resist + default = resist-fingerprint?
This is quite a problem, as I am not sure if you can override settings with unset when pasting new lines into prefs.js.
In principle I want to generate fresh profiles, which does not have such problems. But actually it is useful to add stuff to existing profiles as well if you know what you're doing.

So for new profiles it would be a tri-state switch (and hard to explain to users), for existing profiles probably manual work needed. And the best fingerprint probably the one of the tor browser (the more settings are included in resistFingerprint, the better).

I would have said maybe it needs an helper extension, but firefox 57+ extensions won't be able to change "about:config" settings.

@allo-
Copy link
Owner Author

@allo- allo- commented Oct 2, 2017

Maybe mozilla can be convinced to a "RFP overrides settings" option? Either another integer value or per pref, like dom.netinfo.enabled.rfp_overrides=true or something like that?

Tor though, only has to worry about a single release - and so do we in a sense - your profile maker has to deal with the entire spectrum

Yes and I think it only scratches on the surface. Still it tries to get some of the main points. When I imagine people browsing with year old cookies, I suddenly realize how much protection a single setting can give you.

@allo-
Copy link
Owner Author

@allo- allo- commented Oct 2, 2017

Most people are FP'able anyway
In the end I see the issue a bit more complicated. Panopticlick tells me always I am unique.
But it tells me always I am unique.

The fingerprinting we need to fear is the stable fingerprint, not the unique one. Install one font and lose your font-fingerprint. Now reduce it to a few bit linux vs. windows fonts, install one font and do not lose it.
That are the important points, what can be used over a longer time will be used, not the most unstable things, just because they convey a few bits more.

I would leave the pref in on its own, and just add a disclaimer that prefs marked with [symbol] in your profilemaker can conflict at worst, or be redundant at best with RFP
Sounds like a good idea. But in the end I do not know for most settings, which firefox versions introduced them, possible for some not even when they are no longer needed. This is hard to keep up with and currently I have a lot less time then I would like to have for it.

From the vast amount of input I think the ghacks things are what I want to process next, because it comes with some more documentation than most. If you're still searching for more unsorted input, look in the wiki of this project, there are quite a few collections linked.

@allo-
Copy link
Owner Author

@allo- allo- commented Oct 2, 2017

They have a point about bits of information, but they present it in the wrong way.
For fonts ... the problem is bigger than disabling websites to choose their fonts, as you may think this setting is 1 bit, but actually it would only be if half the people switch it off. Many other settings have the same problem.
And the seemingly changing properties can be dangerous. You do not need things like big learning, which are already used to optimize err webanalysis, with simple statistics you can significantly reduce the noise. So you may see 100 unique font combinations (to use a simple example again), but with some statistics you see that there are 10 fonts (present or absent), which are your actual fingerprint. With enough log-data you can find these factors and use them. So you either need full random fuzzing or zero information, just "good enough" isn't really.

Resources: been on this train for years mate - we've already mapped the Firefox genome

A lot of work ...

@allo-
Copy link
Owner Author

@allo- allo- commented Dec 11, 2017

For the useragent, RFP overrides general.useragent.override currently using Firefox 50, not the other way round.

This is no good thing, as Firefox 50 now isn't very common anymore. I do not get why they don't set this to the current ESR or the previous ESR if the current one is too recent.

@hoshsadiq
Copy link

@hoshsadiq hoshsadiq commented Aug 2, 2020

It's been a while this issue has progressed, has there been any updates around this? Do we know what I as an end user of profile maker can do to maximise my privacy (whether that's using privacy.resistFingerprinting or not)?

@allo-
Copy link
Owner Author

@allo- allo- commented Aug 2, 2020

This is still a complicated question.

Resist fingerprinting is a powerful tool for having a single switch that increases your privacy without thinking about the details. This comes at the cost of breaking a few features and for example instantly lowering your reCaptcha score. You'll probably get a very bad rating at reCaptcha v3 (what may become a huge problem for any privacy optimized profile when it becomes widely deployed) and get harder image puzzles.

In general the option seems to try to bring tor-browser features into the mainline Firefox, possibly for making it easier to maintain them when Mozilla likes to have them in the main codebase.

It is for a generated profile probably better to configure each feature separately, so you know what you changed and why (on the other hand you need to undo it separately when something is broken), but I don't know if all things from resistFingerprinting are covered by the generator.

My personal pet peeve with the setting is, that it disallows to override the user agent and sets the latest ESR user agent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Firefox Profilemaker
  
In Progress
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants