sticky: Prefs vs Recommended Extensions: Co-Existance+Enhancement | Conflicts

[Thorin-Oakenpants]

A list of stuff - thanks @smithfred for the ideas

Extensions can often work better than a global pref because of their flexibility (but may still have downsides or issues), or they can enhance/compliment them, or they can clash. Either way, there is always more than one way to skin a cat ^{no cats were harmed in the making of this issue}.

Here are some solutions that may fit your needs. If you have any other suggestions to this list-in-progress, please let us know :)

---

🔶 Mixed Passive Content

• pref: security.mixed_content.block_display_content=true (1241)
• alternative:
  • set the pref to false
  • add https-strict: * true to uMatrix
  • allow exceptions on a site by site basis

---

🔶 Web Workers

• pref(s): dom.workers.enabled=false (2301) and/or dom.serviceworkers.enabled=false (2302)
  • Note: dom.workers.enabled was removed in FF60
• alternative:
  • set the pref(s) to true
  • add no-workers: * true to uMatrix
  • allow on a site by site basis
• note:
  • FYI: uMatrix (and FF) can't use workers if cookies are set to "Keep until I close firefox" 1429714
  • if FF prefs allow web workers, but uMatrix blocks them, there may be instances where the web site detects workers are available but can't actually use them, leading to breakage, rather than falling back to the non-web-worker version [read this somewhere on uM repo but can't find it now]

---

🔶 Cookies [1]

• pref: network.cookie.cookieBehavior=2 (block all) (2701)
  • use FF site exceptions (allow eg for logins, allow for session eg for sites that require them to work)
• alternative:
  • set pref to allow cookies (recommended value of 1 for same host only)
  • add * * cookie block to uMatrix
  • allow on a granular level
• notes: uMatrix wiki on cookies
  • "Blacklisted cookies are not prevented by uMatrix from entering your browser. However they are prevented from leaving your browser"
  • This is about standard HTTP Cookie header. Cookies can still be read, and sent to remote servers by javascript in other data structures (POST request for example)
• issues:
  • cookies control other persistent storage (local storage, IndexedDB), both when allowing creation and for FF and extensions when cleaning. While uMatrix has a setting to automatically delete blocked cookies, currently FF/Extensions have issues/limitations with sanitizing/FPI. Just removing a cookie can leave behind orphaned persistent data ^{99% sure AFAIK}

---

🔶 Cookies [2]

• pref: network.cookie.cookieBehavior=2 (block all) (2701)
  • use FF site exceptions (allow eg for logins, allow for session eg for sites that require them to work)
• alternatives
  • set pref to allow cookies (recommended value of 1 for same host only)
    • I think Cookie Autodelete requires cookies to be enabled or it won't work
  • cookie extensions
• notes
  • these block/allow cookies coming in. They allow lots of flexibility (white-black-greylists, auto-clearing on tab close etc), and will one day be able to properly handle related persistence storage and FPI (see issues for Cookies [1])

---

🔶 Canvas

• pref(s): privacy.resistFingerprinting=true (4501) (RFP)
  • so much is bundled under this pref that it is not feasible to set it to false
  • for the gazillion things RFP does see meta: tor uplift: privacy.resistFingerprinting #7
• alternatives:
  • CanvasBlocker (or similar)
• notes:
  • RFP canvas protection currently prompts for every site (but can remember site permissions). In FF59+ canvas has been added to the PageInfo>Permissions panel. RFPCanvas might have a pref for its default permission (but looks unlikely). Hopefully it will also be added to the options Site Preferences section for site management. Update: preferred fix is to restrict/lower the prompts
• strategy:
  • set CanvasBlocker to fake. Do NOT set to block as this will disable the API and you will not get the same result as RFP.
  • block sites when prompted: RFP takes over and CB is never used
  • allow sites IF you must: RFP allows CB to take over which will fake
  • use a CB whitelist for sites that MUST have the real thing

---

🔶 Referers

• pref(s): section 1600
  • these are global settings, and at defaults and in our user.js, they only limit some data in some cases (otherwise way too much of the internet breaks)
  • if you want ANY real control over referers, you NEED an extension
• terms:
  • source: the site you loaded, 1st party
  • destination: a site linked to, or the site being requested for 3rd party content
  • example:
    • load SiteA (SOURCE, 1st party)
    • SiteA requests content from 3rd party SiteB, SiteC, SiteD (B,C,D are DESTINATION)
    • SiteA might include a referer (basically saying "Hi I'm requesting this for SiteA") to any or all of those destination sites
• EXTRA Solution 1: uMatrix
  • spoof by default: referrer-spoof: * true
    • Dashboard>Settings>Privacy>"Spoof HTTP referrer string of third-party requests"
    • uMatrix spoofs any referers as the destination (see this uMatrix wiki entry)
  • allow exceptions on a per scope basis (this is under the three vertical dots dropdown in your uMatrix panel)
  • uMatrix can only control the SOURCE, not per DESTINATION (so in the example above, Sites B C + D would all get referers)
• EXTRA Solution 2: Smart Referer (instead of uMatrix's setting)
  • whitelist, blacklist, built-in whitelist to reduce breakage, etc
  • allows source-destination control: so in the example above, you could allow SiteB but still block Sites C + D
  • allows blocking, spoofing as destination, faking, allowing, etc
  • the ultimate referer tool

[earthlng]

https://bugzilla.mozilla.org/show_bug.cgi?id=1429714 is about service workers.
Since there are problems with the way extensions use Content-Security-Policies to block these things, I wouldn't rely on uMatrix too much. The prefs are the most reliable way to block stuff.

uMatrix allows cookies IN but blocks them from going OUT

that's how it's supposed to work but extensions don't see the changes made to headers by other extensions and therefore it's possible that the cookie(s) will still be sent.

[theWalkingDuck]

uMatrix allows cookies IN but blocks them from going OUT

that's how it's supposed to work but extensions don't see the changes made to headers by other extensions and therefore it's possible that the cookie(s) will still be sent.

Either you're using extensions which are adding there own cookies to the request header (after uMatrix striped it) or you're using malicious extensions which are sending a hidden/background request.

The question is: Why on earth are you using such extensions ?

[earthlng]

after uMatrix striped it

that's not how it works. All extensions receive the headers in parallel and unmodified. It doesn't matter if uMatrix striped it because the next extension still sees the original cookie header.

The question is: Why on earth are you using such extensions ?

I don't but there are apparently people who have like 70+ addons or whatnot, and I'm just saying that it can happen. Here are just 2 examples of legitimate extensions that do or could modify the cookie header in certain situations:

https://github.com/snyderp/web-api-manager/blob/master/add-on/background_scripts/background.js#L58
https://github.com/scakemyer/cloudhole/blob/master/background.js#L216

[kkapsner]

The strategy looks good.

If you block the canvas via FF the canvas is completely handled by it and CB never kicks in.
When you allow via FF the canvas is handled by CB which will do what ever you specified it to do.

EDIT: when I messed around with this feature I think I also found a way to ignore the resistFingerprint setting (or answer). Not sure if this is useful or not...

[kkapsner]

Block does block the API and therefore generates errors in most pages that just assume that the API is accessible. If you want the same behaviour than in RFP=block you have to use the "white" random number generator.

The detection test is using canvas but only a minor subset of the API. The block mode may block before the RFP kicks in.

[smithfred]

Can't find where I mentioned the idea of general API blocking, but hey look:

[dead link]

[Atavic]

3P Request Blocker by Sw prevents your browser from connecting to 3rd party resource without user consent. Only 61.0 KiB

[Atavic]

Re: pyllyukko/user.js#348

[verlain3]

Correct if i'm wrong but shouldn't Cookie AutoDelete work with FPI already in Firefox 59?

[verlain3]

Is there an easy way to find if it's working as intended, i mean, if it's deleting localStorage, etc with CA-D and FPI turned on? Sorry if i'm being a bit off-topic.

[verlain3]

Thanks so much @Thorin-Oakenpants

[crssi]

Sweet ❤️

[vertigo220]

if FF prefs allow web workers, but uMatrix blocks them, there may be instances where the web site detects workers are available but can't actually use them, leading to breakage, rather than falling back to the non-web-worker version [read this somewhere on uM repo but can't find it now]

https://www.reddit.com/r/uMatrix/comments/7p7adg/web_workers/

[vertigo220]

As for privacy.resistFingerprinting, I had to disable it due to two reasons:

• it breaks the AMO site, since it thinks you're using a different browser version than you actually are, so extension compatibility is inaccurate, and
• it changes your time zone, which then makes time/date features, like in forums, inaccurate.

There may have been other issues as well, but I didn't get far enough in using it to find out. Are there solutions to these problems? I would really like to use this feature.

[vertigo220]

I'm not saying I plan to disable it permanently because of it, but I've had it disabled the past couple weeks while testing stuff, installing and trying out addons, and a feature like this should work for non-advanced users, who aren't going to know why the AMO site isn't working properly and know how to fix it. Not to mention you'd think Mozilla would make their feature not interfere with their own website. Just seems like a pretty significant oversight. Anyways, I was hoping someone knew of a pref or addon that would disable it on certain sites and/or AMO or that could override it so the user agent could be forced on those sites. Also, this should be mentioned in the OP, so people aren't caught off guard when they enable this pref then find AMO doesn't work right.

And I realize the time zone change is a feature, not a bug; I wasn't saying otherwise. I'm just saying that I would like the ability to have the benefits of resistFingerprinting without the subsequent issues caused by that. Ideally, it should provide a way to tell it to leave that alone. Since that's clearly not the case, again I was wondering if anyone knew of a way to override it.

[vertigo220]

Either you buy into the full RFP package, and everyone spoofs the same timezone, or its pointless

I understand how fingerprinting and uniqueness works, and that I would be setting myself apart by changing my time zone, but I suspect I would still be much less unique than if not using the pref at all, and therefore that it would by no means be pointless.

[vertigo220]

Well, that's why it's not been exposed to the public yet

I get that. All I was looking for was a workaround that hopefully somebody had found to fix this issue, to prevent having to change the setting every time the user wants to look at or install addons.

I don't follow. What does RFP have to do with this issue? Unless you meant that I provide some alternative for RFP

I was saying that in your canvas section, where you mention to use the pref, a simple caution that it will cause AMO to not work properly could be added so anybody that reads it will know about the breakage, so then when they go to AMO they'll be aware of it, vs just enabling it and then going there and not knowing why it's not working. I'm not saying they should be told to use it with caution, just that they should be cautioned (or perhaps a better word would be informed) about the issue. That's all.

[crssi]

CanvasBlocker 0.4.6-Alpha1 does now also Audio... see here; kkapsner/CanvasBlocker#71 (comment)

I am sure that @kkapsner would appreciate some testing from you guys too.

Cheers

[ntninja]

@Thorin-Oakenpants: I see you already updated the code URL. Now that @meh has given me full access rights on AMO, I've also create the privacy policy you requested a year ago: https://addons.mozilla.org/de/firefox/addon/smart-referer/privacy/
Sorry for the long delay, but I simply wasn't able to do this before today. 🙂

Edit: Thorin: done. And thanks. PS: I stripped out the /de part

[atomGit]

browser.display.use_document_fonts

value can be toggled with Toggle Fonts add-on (AMO)

note that Toggle Fonts does not alter gfx.downloadable_fonts.enabled

[Thorin-Oakenpants]

You don't seem to understand fingerprinting very well. RFP & canvas currently lowers the entropy in that metric, in fact, it eliminates it by making everyone the same. As soon as you diverge from other RFP users, you stand out. Obviously it depends on the script, but I'm talking theoretically - which is how you need to approach it. Any hole is a hole that can be exploited.

It's not hard to detect RFP: you can just check timing rounding (which could be changed by a pref value - it sucks though because the check takes time: you could probably get away with 30ms). And there are other cumulative checks that could give it away (but not totally infallible). But since FF78 there's an even quicker method (less than 1ms, 100% correct, all the time).

And RFP does allow a site exception for canvas: it's not like you don't have some control.

Of the at least 8 methods to confound FPing, one is to lower entropy, one is to raise. Both have pros and cons. AFAIK, RFP canvas is going to become randomized - but until it does, don't undermine it - that's just stupid

---

Also: just so people are aware - don't use Waterfox: there is nothing it does that Firefox can't (there might be the one odd thing here or there: I'm not wasting my time checking). This does not include legacy extension support: which I consider the lack of in Firefox as a good thing, and the inclusion of in Waterfox as a security hole.

• HTTP UserAgent cleaner (extension, XUL/XPCOM) #517 (comment)

I feel many many more users would switch to Waterfox, especially this user.js crowd

Not if I can help it. There is no reason to use a fork.

[Thorin-Oakenpants]

OK, you really don't understanding FPing

I blend in MORE using a faked fingerprint canvas hash than using the one generated by RFP according to panopticlick.

And that there is the first flaw in your argument: panopticlick is not real world and the data is tainted (not the actual FPing, just the entropy). And that's not the site's fault, it's the nature of the beast and those who (repeated) visit, and who constantly tweak their metrics: thus artificially screwing the results.

since the standard now is to lie to the webserver

What does that even mean? In reality, the standard is not lying (most users don't install extensions, at least not canvas ones, and at least not in Firefox).

For those who do lie: they can be lowering or raising entropy. So if you mean randomizing is more prevalent, then I would say based on some numbers, that you're wrong. In Firefox (and it's trivial to detect that you are on Firefox), I don't know the number of RFP, but all the TB users (which uses Firefox) are lowering canvas. There's some 2 million TB users at any given time [1]. Overall, there would be more.

That figure there far outweighs the total (i.e not always online at the same time) FF users with canvas randomizing - CB has 50k installs, Canvas Defender 15K and so on.

But that doesn't even fucking matter: if the subset of users you are in lowers, then you do the same. You sure don't get it.

[1] https://metrics.torproject.org/userstats-relay-country.html

Also: just so people are aware ... [followed by a bunch of batshit crazyshake statements]

Clearly you need help.

[B00ze64]

Just visited uMatrix repos, @gorhill has Archived it all, says he won't spend any more time on uMatrix. uBO is nice and all for cosmetic filtering but it does not come anywhere close to the control you have in uMatrix. Disappointing - no discussion, no warning, just a guy opening an issue and getting told "forget it I'm done" and poof, everything archived :-(

[atomGit]

not surprising at all given the number of commits on uBO vs. uM

i'm very disappointed by this - there's lots i could say about this but i'll refrain, suffice to say that i think some of his decisions are idiotic, starting with splitting uBO off from uM

[Kraxys]

Either you buy into the full RFP package, and everyone spoofs the same timezone, or its pointless

I understand how fingerprinting and uniqueness works, and that I would be setting myself apart by changing my time zone, but I suspect I would still be much less unique than if not using the pref at all, and therefore that it would by no means be pointless.

With Chameleon, your timezone can be automatically adapted to your IP. Ant in that precise case, it supersedes the RFP's GMT+0 timezone

[rusty-snake]

I guess you refer to https://addons.mozilla.org/de/firefox/addon/chameleon-ext/.

No, you shouldn't use such extensions.

Useragents

• Randomly select from a list of browser profiles
• Choose between different platforms or device types
• Change user agent at specified interval

No further questions, Your Honor.

[Xenoslyce]

What should be done to make uBlock Origin handle trackers instead of the browser? I use AdNausuem so it'd be nice to be able to send a message