search

arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
10.04k stars 514 forks source link

discussion: make a bunch of items inactive etc #692

Closed Thorin-Oakenpants closed 5 years ago

Thorin-Oakenpants commented 5 years ago

from #605 (and from comments I have read elsewhere, which has made me step back a little, although to be honest I was always aware of this - it's just more of a kick in the pants to get something done about it, and to move the relaxed sticky on)

Here's the thing. We don't need to go all out super hard (and we don't: a lot of items we could but don't). The threat model just isn't there for most of us, if not all of us. And the prefs would still be there for those who want them. I just think we could come up with a better default

Here's a pic - as you can see, since I made that list back in Dec last year, we've already relaxed a number of items "naturally" (i.e not because of this list) update

You can read this comment if you want and the one above it, but essentially some of these are the threat model, and some are a law of diminishing returns (if that's the right law - I am not a lawyer!!), and some are just extra hoops that make no sense AFAICT

For example: since we've already relaxed most of the shoulder surfing stuff, why should be still block disabling saving to desktop. Why should we stop users "opening with" - it's not a risk as it requires the user to make a choice, etc (AFAIK), i.e exe's won't execute on their own, and if they want to open file types with their own program, FFS, let them do it. This sort of hardening is just going a tad too far IMO.

I know the Big E will scream, but hear me out. ASMJS and WASM: sure, one is new'ish, and both can be security issues - but in all seriousness, the chances of getting hit by anything from these are practically zero. The risk is so low it's ridiculous. It might be years before an exploit is found and even then, not in the wild. It's not like we're not careful internet users, but even a non savvy user would struggle to ever to get bitten. That's my take on it. If it's good enough for major browsers to enable, it's good enough for the DEFAULT template.

GMP + openh264: do we really need to block these. Aren't they just extra things to add to overrides in order to get OTHER things working: i.e in and of themselves, they are not a threat?

Cache: the chances that sites use cache to track are probably extremely slim. I'm talking about embedding UUIDs in the cached item or something. Timing attacks I'm not sure about. I think the threat model here doesn't exist for us. ETAGs are not the issue: you have to disable memory cache as well, and we don't do that.

Same goes for HTTP2/AltSvc: I just don't think the threat is there for us. Although these two I don;t really care that much about (and we've talked to death about them) since they don't break anything at all.

:star:

So all in all, this is me throwing an idea at you all, and I want you to all HAVE AT IT - speak your mind, let it all out. Tell us what you really think, and always be aware that the user.js is a template, and we can easily add [harden tags or something for anything special

Thorin-Oakenpants commented 5 years ago

Just to be clear: this is about making prefs inactive: existing users would still need to reset them in about:config, so this would not affect anyone when they update their user.js - just hope they pay attention to out changelogs ;)

crssi commented 5 years ago

Not a request, but just a loud thinking.

Blue section I don't see any reason to change 702 + 703 (http2/altsvc), 1001 + 1002 (cache) differently that we already have now. As for rest I also do not see any reason not to make them inactive.

Cheers

Thorin-Oakenpants commented 5 years ago

well, cache is cleared on close, so it's not really a security or privacy issue (it's not persistent) if what we're doing is relaxing shoulder/surfer & temp disk type stuff. It's not like we're giving up the entire forensics angle / TB's disk avoidance. If someone's threat model is that bad, they should be using tails and encrypted drives etc, and TB

Thorin-Oakenpants commented 5 years ago

Oh, everybody, if you want to voice an opinion that's cool. Totally respect that. We all have different needs and ways we see things. But if you want to make an argument for something being kept active or made inactive, then you should give some reasoning for it. Pros and cons are needed to make an informed decision on each one. SO the more info, the better.

Thanks crssi for your thoughts :beer:

crssi commented 5 years ago

Everything written by me in this post has no scientific background, but mostly how I feel about 702 - I don't trust HTTP2 - if disabled nothing breaks 703 - I don't trust AltSvc - if disabled nothing breaks 1001, 1002 - I don't see any benefit enabling disk cache,, fast test (not trough) one with memory enabled and disk disabled, and the second one with both enabled, doesn't show any memory consumption difference here... be careful with this sentence, as I said the tests were not trough. 1241 - I don't see any serious problem if inactive and left as default other than getting rid of breakages 1820, 1840 - making inactive removes some breakages, but I don't know about security implications

302b - voting for inactive 860 - leave as is, active and set to false, @earthlng showed us PoC

bitpixl commented 5 years ago

702 - never had any issues set to "false" 703 - never had any issues set to "false" 1001, 1002 - I personally did some tests with disk cache enabled and disabled and never noticed any real world / usage difference. I never use alot of open tabs anyways. 1241 - I personally have this set to "false" because I just find that this breaks too many sites (sadly). If there are any reasons to block images again, I'd love to read about it. 1820 (widevine stuff) - I also enabled this as it breaks sites. Once again would love to read about any real threads)

the only streaming related prefs I enabled are: / 1820 / user_pref("media.gmp-manager.updateEnabled", true); // gecko media plugins - enable local fallback (hidden pref) / 1825 / user_pref("media.gmp-widevinecdm.visible", true); // gecko media plugins - widevine CDM (Content Decryption Module) / 1825 / user_pref("media.gmp-widevinecdm.enabled", true); // gecko media plugins - widevine CDM (Content Decryption Module) / 1825 / user_pref("media.gmp-widevinecdm.autoupdate", true); // gecko media plugins - widevine CDM (Content Decryption Module) / 1830 / user_pref("media.eme.enabled", true); // [SETTING] General>DRM Content>Play DRM-controlled content

302 - already set to manual update. 860 - @earthlng , nuff said ;)

Thorin-Oakenpants commented 5 years ago

cache is interesting: the list is a bit dodgy, in that numbers were lumped together - 1002 (https cache) used to have significance back when banks and ecommerce sites were about the only ones encrypted - but that line is gone, so I would definitely bundle what we do with these as the same

My question is, and I'm just playing devil's advocate, is what exactly does disabling disk cache do for privacy / security / anti-tracking / anti-FP'ing. Forget eTAGs (you also need to disable memory cache)

Speed is not a factor in our considerations, and usability is a distant fifth. That said (usability), if there's one thing we can drop to make things more user friendly, it's the shoulder surfer / chrome annoyances / temp-or-in_session_only things that pose the least risk

section 1000 header

     ETAG [1] and other [2][3] cache tracking/fingerprinting techniques can be averted by
     disabling *BOTH* disk (1001) and memory (1003) cache. ETAGs can also be neutralized
     by modifying response headers [4]. Another solution is to use a hardened configuration
     with Temporary Containers [5]. Alternatively, you can *LIMIT* exposure by clearing
     cache on close (2803). or on a regular basis manually or with an extension.

Still not seeing how disabling disk cache on it's own benefits our goals

Thorin-Oakenpants commented 5 years ago

1241 - I personally have this set to "false" because I just find that this breaks too many sites (sadly). If there are any reasons to block images again, I'd love to read about it.

1240 (active content eg js) we match firefox's default 1241 (passive content eg images) firefox is still false because clearly it breaks visuals on the internet because the internet is slow to change, being the behemoth it is. Most top sites are probably good, but google and mozilla's thresholds are pretty low: I think it might even be as low as 0.3%, and we're years away from that.

So yeah, the question is, what threat does allowing insecure passive images etc on a secure site?

Not sure what else, except the breakage (which is a symptom, not a fix) reduces third party calls

1820 (widevine stuff)

widevine is 1825s. 1820 is GMP, and the question is "in and of itself" what threat does this pose (along with the gmp openh264 plugin in 1840)

widevine's threat I think is it's DRM'ed. I'm not a codec expert, hence this thread. 100% sure this video stuff needs to go in a relaxed list - I mean I'm OK with basically zero video in my setup, but all the lol-cat viewers, youtubers, twitchers, FB junkies and so on, won't be. Not saying we enable them, but reduce the barriers to getting it to work for them.

crssi commented 5 years ago

If there are no differences in enabled/disabled disk cache, then I really do not see any reason not to disable disk cache. I do not need all sort of shit cached on disk.

I have 1820 override to value of true due to some breakages... I don't touch 1825, 1830 and 1840 and have as it is from your user.js and have none breakages with that.

IDK (and I fully trust your decision) about 2026, 2420 and 2660. There are some pages that require 2422 (https://scratch.mit.edu/ for example and some others), but then again, those pages also requires WebGL, so I am not sure if its worth it. My kid is using Opera ATM for those few pages.

I don't have any problem with 1220 to stay as it is now.

Cheers

crssi commented 5 years ago

What about 4503? Is there really problem with it? For sure we have reduced functionality on AMO when 4503 is set to false.

Thorin-Oakenpants commented 5 years ago

I do not need all sort of shit cached on disk.

But it's cleared on Firefox close

If there are no differences in enabled/disabled disk cache, then I really do not see any reason not to disable disk cache.

Nah bro, you can't flip the argument like that. If we change from Firefox's default then we need a reason. Speaking of which, I would think that heavy tab users and people who run Firefox for long periods, would probably benefit from having a disk cache, and maybe it even helps with things like 4K streaming. And those who use session restore (with loads of tabs?) might also benefit. Edit: And it would benefit low bandwidth users somewhat (I think)

On the other hand, cache cannot be cleared by host. This could open you up to cache tracking techniques?

If we disable things, lets at least put some reasons in the user.js

Thorin-Oakenpants commented 5 years ago

AltSvc: https://tools.ietf.org/html/rfc7838

I need to read this again, but I think I can craft something for the user.js that easily tells people why it's disabled

bitpixl commented 5 years ago

isnt ETAG [1] and other [2][3] cache tracking/fingerprinting techniques can be averted by disabling BOTH disk (1001) and memory (1003) cache reason enough to leave these two disabled?

Thorin-Oakenpants commented 5 years ago

^^ we don't disable memory cache (1003)

bodisor commented 5 years ago

about disk cache: Since you say you're not concerned with performance and usability, my post is off topic, but I'll chime in anyway.

Disk cache is a vestige of the dial-up era, useless these days even for those on a very tight metered connection. I stopped using disk cache since I switched from IE to Opera (in its early days), so I don't know if the cache rules have changed. But the cached content you're most likely to reuse are the site's logo, site banner, a navbar's background image, few icons and maybe couple of scripts, totaling half a megabyte. Everything else is dynamic content you're unlikely to reuse (like article images, thumbnails and ads). And even if you revisit a specific page every 30 minutes, its cached content will probably get flushed by other pages navigation due to the cache getting full (web images these days can be very large).

Unless you have strict control over what's cached, it's rather pointless.

Atavic commented 5 years ago

AltSvc appears at the bottom of the http2 issue: https://github.com/ghacksuserjs/ghacks-user.js/issues/107

Thorin-Oakenpants commented 5 years ago

@bodisor Yup. I'm not an expert on caching, but it wouldn't hurt but could help. Personally, since I've using portable FF for about eight years, cache has been off (it comes pre-configured like that and I just left it as is), and it's never been a problem for me. Anecdotally, I could probably say that if I flipped a few things, it would seem snappier/faster - but that may be a placebo affect (note that I am blocking all the web's bullshit, so things are quite fast anyway).

There certainly are a lot of parts of a web page that can get re-used, depending on the site - but these would be js, css, nav sections, footers etc (tiny % of the entire content) - larger elements are likely to differ per page (vid previews, news story images). All of this stuff in memory is just fine - I can see a difference when memory cache is also turned off - but we don't do that.

Disabling cache on android might be a perf issue: I know my FF on droid is slow AF: can take 4 or 5 secs to load a page that takes half a sec on my desktop. I do not apply the user.js to my droid FF - as I only use it on there for testing.

I do kinda care about perf/usability - but only to add a setup tag. Otherwise the rule is, we should only change things from default if they increase privacy, security, anti-tracking etc. I think this issue is going to become more about adding clearer info on why things are disabled, than actually making anything inactive (although I do see a couple that probably will)

Thorin-Oakenpants commented 5 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=1532486#c10 and comment9 are relevant. I did mention video earlier. Not entirely sure what is meant by Georg's comment

When quitting private mode, the media cache is cleared in a secure fashion." in comment:4, which is great. However, Tor Browser is never quitting private mode as we are using permanent Private Browsing Mode. I am under the impression that the cache is not deleted in that case which is one of the reasons why we came up with the idea to have a cache in memory.

If that's true, then PB mode never clears cache if you always start in PB mode. That doesn't sound right. It might be an issue for TB with new identities, since that doesn't close TB.

Does the disk cache pref cover all cache (they keep talking about media cache) - it must do, right? I'll have to look at what TB do with their prefs on this.

Thorin-Oakenpants commented 5 years ago

http2 (rethink on http2, so skip that one) altsvc, cache - I will just add them to the wiki, along with why form history is a threat. Already updated it a bit, eg removing old data about cookies, making TP/SB info clearer, updating what we do with auto-updates etc. Trying to weed out the mis-information that gets strew about on various forums

Thorin-Oakenpants commented 5 years ago

https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.3-Implementation

just did about 300 edits (feels like it) .. i prototype this shit and I'm hopeless at writing ... nits and criticisms and flat out laughing at my work on this wiki page is welcomed (in order to make it better)

note that I will add the form data stealing info to the user.js, and I'll maybe add something to AltSvc and cache. At the end of the day, the criticisms of these items was due to ignorance. The fact that out of about 300 altered prefs from default, they can only bitch about 6 or 7 of them in total says a lot.

Thorin-Oakenpants commented 5 years ago

@earthlng et al I've been thinking about this long and hard. Very long, very hard.

First of all, FP'ing is the last thing on my mind: you control 90% that shit by controlling your JS/3rd parties. And most FP'ing is not that sophisticated (e.g recent scraps etc of the top 500K Alexa sites showed less than 1% of sites used canvas, but it was only the landing page tested - earlier tests from others indicated about 1.6%). I can pull up other stats on a couple of other items, but long story short, no-one really does anything more than fingerprintjs2. That's what reddit uses as a 1st party.

And it is my opinion that ID'ing users and tying their web traffic together is done by large networks, and google & fb with their widgets and services etc, and via logins (also think disqus etc), not to mention header referers, cookies, persistent storage, blah blah blah ... the list is endless. No-one in the corporate world is interesting in investing any money in new tracking techniques, when 95% of the population is giving it all away for free.

So a lot of changes probably don't make a difference to FPing in reality (and we can just wait for RFP to cover them in due time) - e.g you could probably fuck around with all media capabilities and no would ever know.

That's part of the risk assessment - which can also be used to say that a bunch of items we change from default have very low risk as well, not in FP'ing necessarily, but in security. As already mentioned: WASM, ASMJS, ORGASM, HTTP2, AltSvc, mathml, SVG and so on. I'll also add ALL the video playing stuff we break - the whole lot. If it's good enough for everyday users, and good enough for Tor Browser (I'll have to double check some of them), then these are good enough for a default. In other words, if you want to harden shit up, then go ahead. It's a template.

If your threat model calls for it, then use TB. I know we can almost make FF as good as, even better in some regards, to TB (sans the Tor protocol), but I don't want that.

If wasm, asmjs, mathml, svg (which i know we don't disable due to breakage) is that bad, then browsers would have fixed it or removed it, and we'd be hearing of thousands of hacks and shit. But we don't. Yes, I know mathml, svg, and a few others cater for most CVEs - but chances of damage are practically nil.

Out defaults should be more along the lines of TB: that is more relaxed by default, but then you can turn the slider up.

So I'm going to think some more on this, but at least 10 to 15 items are on the chopping block (i.e they will made inactive). I will change those required to have a [SETUP-HARDEN] tag. Personally, I am sick of having a slightly broken web. If I need to see a mathml equation, then FFS let me see it. And so on. The risk factor IMO is just not there.

All of this would then do at least two things:

If you think this is the wrong way to go, then speak up. We already relaxed a heap of shoulder surfer stuff, we relaxed blocking all cookies, we don't change TLS settings, we don't change ciphers, we don't change any media playing codecs etc, we don't fuck with prompt permission defaults or turn off geo (which is behind a prompt). I certainly think we can relax some more and find a better middle ground

Last thing: on HTTP2, disabling it two or three years ago is very different to today. Every major browser supports it, so as more websites take it up, you start to become that ONE user that doesn't use HTTP2 on more and more sites. I believe, but would have to check, but the 50% threshold was passed some time ago. On top of that, TB finally enabled it (yes I know it's a different protocol being used). And, it is inevitable - HTTP3 is being drafted. HTTP1.1 will at some stage start to get removed as a fallback. It's like cloudflare - nothing you can do about it. And finally (correct me if I'm wrong), but the http header SERVER_PROTOCOL is always sent, and therefore collected / given away = and I bet you it's used. This would be one of the FP'ing items I'm more than happy to get back to the default..

Edit: also, I am not convinced on the HTTP2 privacy issues, and I doubt anyone uses them. The only study/paper was really quite vague

Class discuss

Thorin-Oakenpants commented 5 years ago

PS: just for kicks, here's detection of your mathml.disabled state. TB on the left, me on the right mathml

Thorin-Oakenpants commented 5 years ago

So here's where I'm at

After that the list of items left for me to work thru is reduced to 34, some can be ignored, some can have a setup tag, and then It's done - create a relaxed sticky, and a maybe a hardened sticky (with extras like site permissions memory only etc).

status

Thorin-Oakenpants commented 5 years ago

I've also added hardware acceleration, and document_fonts to the PR.

There's no benefit with disabling document fonts. Your only real solution for fonts will come from RFP.

And HWA is low risk as well - it's not like we expose webGL. Personally, I've been seeing the faint outlines of "blocks" getting redrawn as I scroll, among other tiny issues, for about 6 months - everything is just a bit too janky - that's ALL gone now and things are buttery smooth. Even TB allows HWA now.

crssi commented 5 years ago

What about 1405?

Cheers

Thorin-Oakenpants commented 5 years ago

IDK. I'm just targeting a select few items that either.

And I will probably (99% sure) move them to a new section (6000) with a one char switch - especially if we can keep the list small (I don't want to start ending up fracturing logically grouped items too much). This would then allow a nice little header paragraph, remove the need for a "hardened" sticky, and probably make it easier for end users who want to use them.

1405 looks like it might fit the bill: I'd have to re-read all about it etc.

Thorin-Oakenpants commented 5 years ago

I also hope @earthlng turns up soon, because I value his input - but at some stage, I won't be able to wait any longer

crssi commented 5 years ago

Also 4503. I do not see a reason to be true and not as default false. When true there is a breakage which is as side effect when disabling FP on AMO site and I really do not believe that Mozilla would do FPing on us.

Cheers

Thorin-Oakenpants commented 5 years ago

I've changed the PR https://github.com/ghacksuserjs/ghacks-user.js/pull/697 to now use a section 6000 for optional hardening (with the one switch char off for now to view it more easily). It's just a draft. Could do with a little better writing .. and E's input. And of course I want to add a couple more items (if they make sense) and maybe remove a couple (but leave them inactive).

There's a few too many parameters floating around here as to how to structure this - e.g do I really want to limit this to contentious items AND use some setup-harden tags, or do I make it a bit broader; do I really want a one-char switch; questions over just removing some items (more of a general get rid of dead wood question), etc.

As I type crssi pipes up with 4503: I need to re-evaluate it. 2662 is inactive. The two together allow extensions to function on these domains. But since we don't have 2662 as active, then what does 4503 achieve on it's own? That's the question. I've got too much going on in here, I'll throw in in another issue.

Thorin-Oakenpants commented 5 years ago

not liking having a section 6000. Anyway, I'm just going to close this, and do whatever the F I think is right and if anyone has objections, then they can open a new issue. My approach is to just leave things in situ, but make some of them inactive and flip the wording e.g setup-perf to warning .. and not all of the items discussed. Some items might get a setup-harden, IDK, I'll just wing it

Thanks to those of you who gave some feedback

Thorin-Oakenpants commented 5 years ago

FYI:

made inactive

I am still going thru the original list of people's overrides. There are also some more items like mathml (minimal risk but breaks things) that I might also make inactive and add a harden tag to: but it needs to be regular breakage. e.g graphite: never seen an issue with it, so wouldn't qualify. WOFF2, maybe. etc.

Not made inactive

That's about it for now. See #605 is you want to follow along, or else I'll open an issue: such as what to do with all the gmp, cdm, eme, openh264 stuff

Atavic commented 5 years ago

I'm still not 100% sure on the http header sent: does that change on an HTTP2 site?

HTTP2 queries add some requests and responses: https://blog.cloudflare.com/using-http-2-server-push-with-php/

More here.

Privacy Considerations: https://http2.github.io/http2-spec/#rfc.section.10.8

Thorin-Oakenpants commented 5 years ago

Still confused. That's server push. I was wondering if the client sends a different header - i.e always recorded in the logs or whatever, so probably used for FP'ing, who knows.

Atavic commented 5 years ago

Yes, http2 has its own specific headers.

claustromaniac commented 5 years ago

are there stats anywhere on how many polar bears died since HTTP/2 prefs were made inactive?

Thorin-Oakenpants commented 5 years ago

Measuring the Impact of HTTP/2 and Server Pushon Web Fingerprinting Weiran Lin, Sanjeev Reddy, and Nikita BorisovUniversity of Illinois at Urbana-Champaign

It's a good read.

claustromaniac commented 5 years ago

I meant that as kind of a joke, but thanks.

Thorin-Oakenpants commented 5 years ago

So was my reply (its not about polar bears), but thanks :)

claustromaniac commented 5 years ago

(its not about polar bears)

Are you sure? There are some well-documented cases of exploiting polar bears for fingerprinting, after all. Ok I'll stop polluting this thread now. Sorry.