search

arkenfox / user.js

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

Questions regarding compartmentalization, extensions and uniqueness #1018

Closed smokemyshoes closed 3 years ago

smokemyshoes commented 4 years ago

Hey pants

First of all thanks for your great effort with the user.js. I’ve read a good deal of the conversions here on arkenfox’s site and there is really slot of gold here – also a good deal that is too technical for me...

Edit: I've tried to educate myself on the topic of browser fingerprinting and read what seems as credible sources, aka not including reddit. I've even read half-a-dozen of scientific papers on the topic. However I still find it hard correlate the theory to real-world scenarios and advises due to the natural closedness on this topic, therefore...

I would really appreciate your thoughts on the points below.

Regarding FF extensions like uBo, uM, LocalCDN, Skip Redirect, POOP, Site Bleacher, etc., they all enhance privacy, each in their own, but I’m worried about the duel-edged-sword-effect (in lack of a better term) of how (I assume) they also increase uniqueness within the FF-user pool.

Regarding compartmentalization, you’ve mentioned that you compartmentalize among 20+ different browsers but do you compartmentalize based on topic e.g. shopping, news, banking, etc., or is it just random? Also, I think you’ve mentioned that you even use a vanilla FF. What (as in, for which kind of browsing) would you use that for?

Also, regarding compartmentalization, do you believe it would be sufficient to compartmentalize within FF and just have X amount of profiles with different combination of settings and extensions or do I need do use different browsers?

I know it’s a lot in one topic, but I would really appreciate if you could share a bit of light.

By the way, my thread model is nothing out of the ordinary. Just trying to evade / reduce the ever-increasing amount of monetization the “great” companies do from my personal data.

Thanks in advance...

atomGit commented 4 years ago

if Pants doesn't mind, i'll jump in here and hopefully take some of the load off him...

Site Bleacher - i'd suggest replacing that with Cookie AutoDelete since it now supports auto-cleaning indexedDB storage, workers, etc., on a per-host basis and domain-leave - Forget Me Not will surely be doing the same in the near future - Site Bleacher was always a temp solution

re: compartmentalization

it sounds like you're talking about containers - personally i do not like them because making them transparent (as to not interrupt work flow) requires 1 or 2 additional add-ons and a bunch of fiddling - what i do, and this achieves a very similar result, is to make sure first party isolation is enabled (it is in the arkenfox config)

... vanilla FF. What ... would you use that for?

testing

smokemyshoes commented 4 years ago

Thanks for your reply @atomGit

Site Bleacher - i'd suggest replacing that with Cookie AutoDelete since it now supports auto-cleaning indexedDB storage, workers, etc., on a per-host basis and domain-leave - Forget Me Not will surely be doing the same in the near future - Site Bleacher was always a temp solution

My question was not related to any specific extension but the general trade-off (and paradox) of becoming more unique when installing extensions to enhance privacy.

re: compartmentalization

it sounds like you're talking about containers - personally i do not like them because making them transparent (as to not interrupt work flow) requires 1 or 2 additional add-ons and a bunch of fiddling - what i do, and this achieves a very similar result, is to make sure first party isolation is enabled (it is in the arkenfox config)

I was not referring to containers. My intention was to ask if one can accomplish satisfying levels of compartmentalization by using X number of FF profiles, all configured differently, rather than having to install different browsers like Tor Browser, Brave, you name it.

atomGit commented 4 years ago

My question was not related to any specific extension

right, but i just wanted to point out the thing with Site Bleacher

...if one can accomplish satisfying levels of compartmentalization by using X FF profiles configured differently ...

given your stated threat model, yes is my answer - i use Linux but i assume Windows is similar in that your entire profile (all settings... well, most settings, bookmarks, extensions, etc., etc.) is stored in the profile folder, so switching profiles is essentially like removing and re-installing FF

this leaves cache which is NOT stored in the profile folder (at least on Linux), however this is generally stored in memory with the arkenfox config, plus you can dump all storage on browser close, plus there's FPI and all the rest of it

so the only things i'm aware of that would be shared between Firefox instances are the default installation files (binaries, system add-ons, "features", vendor prefs etc.)

i do not know for sure how object cache is handled, but i'd be very surprised if one profile shared it with another

Thorin-Oakenpants commented 4 years ago

I'll answer some more tomorrow ... but while I have a few minutes

you’ve mentioned that you compartmentalize among 20+ different browsers

🔻 not quite: click me for details if you're bored

What I have is FF60 thru to current stable, along with ESR60-68-78 (updated or at end of life), all portable versions with practically vanilla profiles - just a few tweaks such as disabling auto-updating, removing distractions (snippets, animations, etc, disabling passwords, and sanitizing everything on close), dark theme, saved test bookmarks on the bookmark toolbar etc. I also have a FF59 (so I can check feature detection changes in 60), and ESR60+68+78 32bit versions (for testing architecture shit). As each new release comes out, I update the ESR if applicable, and add the new release as well. So in a few days I will add a new portable FF81 and copy my FF80 profile into it (saves me time). Then I have TB esr60 (end-of-life 64 and 32bit builds), TB esr68 (end-of-life 64 and 32bit builds) and TB alpha (currently 78esr, also in 64 and 32 builds). Oh, and 34 other TB alphas (in each language to test app language PoCs). All of those are my testing, I don't browse in them: but I tend to only update the non_en-US builds about once every 6 months: depends if I need to test something But wait .. there's more I also have a Beta (installed) and a Dev (portable) and a Nightly (installed) - I update these as required (so nightly twice a day etc..). I even flip on prefs sometimes in Nightly for dogfooding (like warp) and I send telemetry on Nightly And then I have my actual FF that I use for almost everything. So, if you're keeping track, that's approx 28 stable releases, 3 beta/dev/nightly .. 6 en-US TB's, 34 non en-US TB's and my actual FF .. (and I actually have an archive of lots of TB alphas back to 8.5a1, and releases back to 8.0.0 - accumulated over time troubleshooting TB bugs, so add another 38 TBs) ... **we'll let atomGit add everything up** What I like about this, is that while I could let **all** those test FFs run concurrently, I don't need to, because it's enough that Beta, Nightly and Release already do that between themselves (as well as TB ignoring open FFs) I also have an Opera portable and a chrome portable: also only for testing

... which means I have approximately two browsers: Nightly and my main FF (release channel). Everything else is purely testing.

As already mentioned, all test browsers are set to sanitize on close. And I only open them to test things in. That said, if something doesn't work nicely in my main FF (due to how I have locked it down), then I can just flick open Nightly (if it's not already open) and paste the url. In nightly I have a ton of bookmarks (in folders on the toolbar) on some things to follow up on, extra tests, ideas etc for fingerprinting - it's kinda of my ToDo workspace for TZP, so it's often open. So it's basically my second browser for the very occasional page - I wouldn't call my browsing habits "normal" - almost nothing breaks for me that I care about - I just don't do video, tweets, social media, snapchat, instagram, zoom, etc. Sometimes something in a CNN article for example might break, and instead of fiddling for a one off in uMatrix, it;s easier to just view in nightly. PS, nightly has uBlock in default mode - fuck adverts

So, I don't really compartmentalize browsers : but because I basically always have two FFes open, it's easy for me to unbreak something in my uber-super-duper-very-bigly-whopper-dopper-hardened FF by viewing in it my Nightly, but it's rare, because, I'm my browsing habits are narrow and I've already unbroken most things (within reason: I won't compromise much)

I'll talk about the other shit tomorrow

Thorin-Oakenpants commented 4 years ago

@atomGit ^^ have you added those up yet?

atomGit commented 4 years ago

added wut up?

smokemyshoes commented 4 years ago

@Thorin-Oakenpants thnks for clarifying, I clearly misunderstood you from the other post I read awhile back. However I do believe you wrote something along the lines of "...many people greatly underestimate the value of compartmentalization..." Which I completely agrees to. I shamefully also have to admit that I compartmentalize less than I should/would like to.

I do have a few different FF profiles all configured slightly differently but I wonder if that is enough from a entropy poinf of view . See I run linux and I use FF so already there I'm part of a relatively small (<1% ??) part of the browser population. Add to that the 10 or so privacy-related extensions i have installed and my arkenfox hardening, I imagine that I'm pretty unique. And I'm very much in doubt how much difference it makes that I have a few profiles where Ithe extensions and setting vary slightly?

On the other hand I find TOR too inconvenient and I would never touch chrome...

Thorin-Oakenpants commented 4 years ago

I haven't forgotten this, and I will get to it. The first thing is to understand how they track you or linkify your traffic. Once you know that, then you can model your response

I see three basic ways (web sites) use to track you

We'll assume that IP addresses are covered: that is, at worst, the entropy is "hey, this person is using X company's VPN" (or on Tor Browser: hey it's a known exit node - these are public anyway). And an IP !== a person - but that doesn't stop sites from using it.

b + c to follow tomorrow

smokemyshoes commented 3 years ago

@Thorin-Oakenpants, not to punk you but I would still very much appreciate your thoughts on b and c...

Many thanks in advance.

Thorin-Oakenpants commented 3 years ago

OK, this is not going to be easy, because it's a very big topic. I'm just replying off the top of my head: so It might get a little long and seemingly disjointed - it's hard not to branch off in a dozen directions to reach important points. So I don't miss something important, I tend to type it out, and afterwards maybe cut/paste things into some sort of order, before posting. I might also post my answer in several posts.

I'm not going to provide sources (or look up exact info), so any figures are from memory. And I'll be talking in generalizations, and I'll assume some basic knowledge already (but ask if anything isn't clear).

b + c are two completely different things. One is stateless, the other is not. One is controlled by the provider, the other is not. One is extremely well-developed, well-oiled, time-proven and widespread setup and the other is (quite frankly) in it's infancy (and it's a bit of a gimmick IMO: more on that later). I think you can tell which is which. The threat model of each is very different.

So what drives all of this is corporate surveillance in order to drive targeted advertising. The biggest problem is the data aggregators, some of which cover large swathes of the internet (top sites) - that's all it takes: one or two big bastards that have their hooks into everything and wham, there's a (shadow) profile. And all it takes to tie shadow profiles to a real id is one link.

So the easiest way to stop that, is to kill the mechanisms that allow it to happen. .. more to follow

Thorin-Oakenpants commented 3 years ago

state tracking

the whole of point of the tracking is to linkify your traffic. Persistent web storage (which requires a state) does that by assigning (and re-spawning if possible) unique identifiers - that's it's mechanism. Kill that and you're golden. If you isolate by first party, then each and every site cannot associate itself with any other unique identifier

This is what Tor Browser does: they don't even bother with blocking third parties or trackers, because denying cross-origin "chatter" is enough to break the linkifying.

Caveat: that's sessioned (assuming you sanitize on close). If you want every repeat visit to a site within a session to be isolated, you can use Temporary Containers. If you don't sanitize on close (sanitizing is clearing persistent web data), then any unique identifiers would still persist (per site)

Another option is to deny sites the ability to store any data, period. That's default deny, and then whitelist: this is what I do. I allow four sites a cookie permission: this permission controls all the rest (localStorage, sessionStorage, IDB, service workers cache). Another four or five sites, I allow for session otherwise they won't work well enough to use. This is my mileage - everyone will be different. I sanitize everything on close except cookies (so I can auto login to my four sites). Those four sites I login into, I am already GIVING them a unique identifier by logging in - I am not losing anything here.

So that's it. Kill the "state" (persistent storage) and you kill the ability to persist an id and to linkfy. Using cookie cleaners IMO are a waste of time and vastly inferior to FPI or TC. If you're not isolating then the chance exists for cross-origin chatter (while you have multiple tabs open, in the period of time before your extension cleans things, etc)

note: assumption that I am not talking about logging into a service (real id or not) - that's giving them an id: that's in your control still though, not theirs

now you know my setup in my main FF to stop "state" tracking .. and perhaps that helps explain why I really don't need to use profiles. In case anyone asks, I don't even use TC since there's nothing persistent that matters

PS: Also: using uBO (or adblockers etc) is inferior in this regard - as it's a game of whack-a-mole. But it does hurt corporate surveillance: hence you see adblocker blockers, cname workarounds, and so on. I read a article about ad revenue in Germany (I think), it was a short time after Firefox enabled it's tracing protection by default - and the ad industry was totes upset (FF usage in Germany is a lot higher than the average). The numbers of trackers blocked is staggering to the lay person - they had some cool graphs on twitter as they hit milestones, or stats per day per person, etc.

However, even Mozilla realize this is not enough, which is why they have built dFPI (dynamic FPI), and this will become the default at some stage. Just to make that clear: if you're not isolating by first party, you're playing a mugs game.

more to follow

Thorin-Oakenpants commented 3 years ago

stateless tracking

Fingerprinting is stateless. It's not stored on your device, it simply keeps giving away the data by default or when asked. There are two types: active and passive. Passive comprises things like headers, cipher suites, tls handshake info, tcp/ip stack characteristics, etc - things which the browser/network sends out automatically and the server can collect. Active is when the browser is asked (namely by using JS) and coughs up the information (because it's standards compliant).

I will be (mainly?) talking about active fingerprinting (because that's all that really matters) - I'm not talking about how to defeat FPing (yes, there are some passive elements you can control such as headers) - I'll be talking about the threat level here

Fingerprinting has one function - to try to uniquely id your device/browser. It can be used for good (security: is this the same device that accessed this account last time: if not alert the user), or bad (tracking)

Because it's stateless, it doesn't matter if it's first or third party (there are plenty of examples of first party scripts run on behalf of third parties), and because it is supposed to uniquely identify you - the only way to defeat it, is to make that id useless. I don't know what you know about entropy, or the many general methods (in my model there are seven) to render an id useless - and I don't want to get into a discussion about those methods or how entropy works. Suffice to say that there are many ways to achieve this. ⭐ sidebar: sites which give you entropy scores are FULL OF SHIT - see this

In the science of FPing, if it's exploitable, it's a hole that should be patched (if possible). In reality, generally speaking:

That said, scripts are evolving.

some short (generalized) notes

Scripts are dumb and limited

Scripts are not that widespread, many are already blocked

A lot of so called holes are just equivalency

^^ so, tl;dr: a lot of FPing metrics/tests are a. stupid b, a waste of time c. add nothing

It's enough that you're in a sizeable bucket...

Firefox

In my main FF, I use RFP. If a FP script were to run, I doubt it gets anything unique (limited metrics tested, dumb scripts) - especially now RFP randomizes canvas as a poison pill (it's trivial to detect, but that's not the point: every script uses canvas and the vast bulk are stupid)

If I need to do a one off site in Nightly, who cares if a FPing script FPs me. All it will ever get is a few random sites, sites which statistically won't have FPing scripts (not to mention Tracking Protection and uBO default are on)

So now maybe you can see why I don't really use multiple profiles. Almost everything works to my standard in my main FF, based on what I do. And a few one offs in Nightly is no big deal. Especially since I open/close it dozens of times a day, and I sanitize everything on close, and I never use it to login anywhere, etc.

⭐ As for anyone else: if you're going to compartmentalize - use a different browser. A slightly different tweaked FF profile isn't going to do jack shit regards FPing - and FPing is overrated/overhyped (for now) - and if you're logging in somewhere, you're already giving then an id. And you can already do a one off private window in your main FF for "state" persistence/tracking (among other tools).

Did I answer your question? It depends on your setup and your threat model

Thorin-Oakenpants commented 3 years ago

Did I answer your question?

Oh .. extensions. Tomorrow, maybe if you want more info

basically

That's about it. In the real world, trying to get entropy via extensions are just PoCs (and I'm not talking about "are you using an adblocker?" yes, it adds another point of entropy (true/false), but there's nothing you can do about it and the answer is simple - use an adblocker - the benefits far outweigh any potential theoretical FP

smokemyshoes commented 3 years ago

Wow thanks for taking your time to provide such detailed and thorough answer. I do have a few follow up questions / points for clarification but first I guess it makes sense to explain my setup high-level:

I run MX Linux (Debian based) and FF as my only browser. My main FF profile which I use 95 % of the time is hardened with the Arkenfox user.js in which I have a lot of settings set more privacy-minded than default. I of course use FPI, RFP, I sanitize EVERYTHING on browser closure and I have WebGL completely disabled, etc. Furthermore, I have 10 or so extensions installed including uBo, uM, Cookie Autodelete, ClearURL’s, CSS Exfil Protection, POOP, LocalCDN, Skip redirect, etc.

I don't know what you know about entropy, or the many general methods (in my model there are seven) to render an id useless

I do understand the concept of entropy. I don’t know exactly how it’s calculated from my browser characteristics, but I guess that is not needed for this discussion.

Now with that out of the way lest jump right into it…

And all it takes to tie shadow profiles to a real id is one link.

Does that mean that I should never ever log into any accounts from my main profiles? Does that also cover fake ID logins?

Because it's stateless, it doesn't matter if it's first or third party (there are plenty of examples of first party scripts run on behalf of third parties)

Does that mean that allowing 1st party scripts in uM (scripts are allowed in prefs) can lead to fingerprinting? And should I therefore never allow 1st party scripts in my main profile?

Scripts are dumb and limited

  • generally they all do the same things: user agent, canvas, some fonts, screen + available screen, language, etc.

Does that mean that those fancy WebGL/canvas FP’ing methods (that if I remember correctly, even enabled cross-browser FP’ing) from the PoC study we’ve both read, haven’t made it to the real world yet?

the extension will could leak (either the UUID or a unique extension behavior) - vet your extensions

Please elaborate? Can you prevent extension UUID leakage with some FF prefs or is it solely up to the individual extensions?

That's about it. In the real world, trying to get entropy via extensions are just PoCs (and I'm not talking about "are you using an adblocker?" yes, it adds another point of entropy (true/false), but there's nothing you can do about it and the answer is simple - use an adblocker - the benefits far outweigh any potential theoretical FP

Okay so the square root is that – although not universally true – If the extensions are picked and combined thoughtfully and configured properly, the upsides of the added privacy (at least for now) outweighs the additional entropy?

atomGit commented 3 years ago

Pants - regarding vetting extensions, how do you do this, and is this something that can be done (at least to some extent) by a non-coder? (and is this something that might be worthwhile adding to the wiki?)

i don't do JS, but my very limited coding ability enables me to gain a very limited insight as to an extensions internals - basically though i use Extension source viewer (ESV) to browse some of the core code and search for !http in the files

what else can one do to vet an extension? what else should one look for using ESV?

Thorin-Oakenpants commented 3 years ago

And all it takes to tie shadow profiles to a real id is one link.

Does that mean that I should never ever log into any accounts from my main profiles? Does that also cover fake ID logins?

So I was speaking in general terms about the two types (persistent state and stateless) - if you do nothing, you're fucked. If however, you control the mechanisms that empower them, then you're fine. (note that there are other tracking methods not yet discussed which can be used to linkify traffic)

simplistic persistent storage example:

That's what I mean by it only takes one "link".

sidebar: I'm not an expert on this, but my understanding is that there is a lot of data sharing going on behind the scenes with the data brokers. I'm not too interested in it, because by controlling what I do, I'm not necessarily affected. So you have large players like google, facebook etc who won't "share" that data: that's their goldmine: instead they sell access to targeted groups. But those larger players do buy data, including from non-Internet sources (fuck them) - e.g. Facebook and Mastercard (or it may have been Visa), or alumni selling your data (bastards), or medical records & google (WTF?). Seriously, it's so disgusting.

Now imagine how that tracker functions under various setups

So if you're using FPI, then go ahead and log in - it's not going to be used to track you via "state"

simplistic fingerprinting example

Because it's stateless and (supposed to be) unique and reliable - then you're fucked. There is no need to store a UUID or set one, or try and resurrect it. There's nothing to isolate, nothing to sanitize. It just is, and the browser reports it on demand. It's a completely different kettle of fishies

more to follow

Thorin-Oakenpants commented 3 years ago

it doesn't matter if it's first or third party (there are plenty of examples of first party scripts run on behalf of third parties)

Does that mean that allowing 1st party scripts in uM (scripts are allowed in prefs) can lead to fingerprinting? And should I therefore never allow 1st party scripts in my main profile?

Sorry. I put that under FPing, but it applies to both persistent data and FPing. There is no difference to what damage either can do when 1st party vs 3rd party. You have no control over, or even knowledge of, what the first party does with any data.

sidebar: I'd have to try and find the articles, and I can't be fucked: and it's not my area, so take this as second hand and hazy: because trackers are getting blocked more and more as third party by default, and with the rise of adblockers etc .. the industry is fighting back: see cname cloaking as an example. Now when 3rd parties are doing the tracking, they control the information on ad impressions and clicks etc (and websites can verify AFAIK) = control of the money - and they don't want to cede control of that. If it was all done as first party, and data sent to the third party behind the scenes, how does the third party verify anything. Something like that. But that's exactly what they're starting to do. Like I said, we are not privy to what happens to any data a first party site collects

One other thing - so the thing with state is the first party would need to linkify you for the third party: e.g. your email account for logging in, or talking to the third party behind the scenes to set a UUID to persist - so nothing really changes there.

With FPing, the script (or each part of the script) would need to be universal: that is

That's not going to be very useful to tie traffic together. And it's not going to be any use to on-sell. At the moment FPing scripts are very diverse and basically all unique to each other. It's a dog eat dog world in the ad biz, and they're all out for themselves

click here and search for FingerprintingGeneral .. feel free to unobfuscate and deminify some of them

more to follow

Thorin-Oakenpants commented 3 years ago

generally they all do the same things: user agent, canvas, some fonts, screen + available screen, language, etc.

Does that mean that those fancy WebGL/canvas FP’ing methods (that if I remember correctly, even enabled cross-browser FP’ing) from the PoC study we’ve both read, haven’t made it to the real world yet?

FPing likes high entropy. Canvas is high entropy - yup, every one uses it. WebGL (esp rendering) is high entropy - yup, everyone uses it. Screen and available screen is relatively high (window and inner window aren't considered stable) - yup, everyone uses it. Fonts is pretty high entropy - yup, everyone uses it. Plugins, mimetypes, navigator properties .. it's all the same stuff. There isn't much new ground to cover here. The thing with scripts is they all start from a boilerplate - and 90% of them are all the same shit.

RFP takes care of almost all that. There's nothing new that hasn't been thought of and taken care of: in Tor Browser by default, and in FF with a couple of extra pref changes (such as disabling webGL and webaudio)

That's not to say more advanced scripts don't exist, or new metrics don't appear (web standards and new APIs are being introduced all the time). So it's a never ending game.

Thorin-Oakenpants commented 3 years ago

Please elaborate? Can you prevent extension UUID leakage with some FF prefs or is it solely up to the individual extensions?

So extensions get an internal UUID. In chrome this is consistent across all users: e.g uBO has the same UUID for all users on chrome. This allows extension fingerprinting: e.g. by checking a list of known UUIDs, you can tell which of the list the user has. So Firefox instead assigns a random internal UUID to each extension when it is installed - this means scripts can't use a list of known UUIDs. The downside, is that if the extension leaks the UUID, it is unique to them (entropy = infinity = game over)

see #227 and 1372288

I did some recent scripts that targeted chromium with a known list of extensions that leaked their ID, but in FF that central approach won't work

@atomGit

Pants - regarding vetting extensions, how do you do this

You can check if an extension has web_accessible_resources by checking its manifest.json (which does not necessarily mean it leaks: e.g uBO uses a secret token to protect itself). Outside of that, it's reputation and number of users is important and other indicators - and talking to them: e.g. kkapsner is awesome, gorhill is awesome .. and so on.

Thorin-Oakenpants commented 3 years ago

I run MX Linux (Debian based) and FF as my only browser. My main FF profile which I use 95 % of the time is hardened with the Arkenfox user.js in which I have a lot of settings set more privacy-minded than default. I of course use FPI, RFP, I sanitize EVERYTHING on browser closure and I have WebGL completely disabled, etc. Furthermore, I have 10 or so extensions installed including uBo, uM, Cookie Autodelete, ClearURL’s, CSS Exfil Protection, POOP, LocalCDN, Skip redirect, etc.

Firefox - check FPI - check RFP - check tweaks - webgl off, webaudio off, a handful of others - check

Congrats - you are now 95% of the way to being exacty like Tor Browser (sans Tor). The less extensions the better, IMO (depends what they do)

You're you and everyone's needs/threat model/mileage will differ slightly. Personally I would ditch

As for these

and I think I'm done here .. close if you're happy, or keep asking questions

Thorin-Oakenpants commented 3 years ago

@smokemyshoes

I run MX Linux

Awesome. I haven't had time to set that up as a VM here for testing. Can you do me a favor, please? Go here and click the Firefox button, then click copy to clipboard in the short report and past me the results - TIA

atomGit commented 3 years ago

re: add-ons...

Outside of that, it's reputation and number of users is important and other indicators

i assume you're implying that the better the rating and the more users, the less likelihood of malware (i include tracking, ads, etc. in 'malware') - those are not great indicators IMO

the more users, the higher the likelihood of a developer being targeted by data-slurping morons who want to buy or monetize the extension - Stylish is a great example of that and so is AdBlock - i might include NoScript in there as well and there are many others - all had/have many thousands of users and all had/have very high ratings - Ingo Wennemaring, dev for the once popular and well-liked All-in One-Sidebar, commented about this...

It was always very important for me to be honest and fair to the users. I had very good offers to sell the extension, but I didn't want to see that AiOS turn into adware or spyware.

i'm not suggesting one should ignore ratings (one should always read the negative reviews especially to see if they're legit), but the number of users is meaningless and, actually, is often an indicator of something fishy ... consider the millions of people using the plethora of ultra-sketchy VPN add-ons

LocalCDN - Since you're FPI'd then who cares.

very good point - i never thought of it that way - still, it does speed up loading and, personally, i figure, why give the bastards anything - the down side is that LCDN can break sites on rare occasions and it will fail where same-origin CSP is used

CSS Exfill Protection - the threat doesn't really exist

i kind of got the same impression, but it seems this is a rather nasty exploit - i will add that this add-on can peg the CPU and bring page load to a crawl in rare cases, but there's now a work-a-round in the settings for those sites

atomGit commented 3 years ago

ps: you have me rethinking the necessity of these extensions Pants - CAD, LCDN - with FPI being enabled - i'm gonna add info to my guides based on what you said so thanks for bringing this up - i'm actually a bit embarrassed i didn't give this enough thought prior

Thorin-Oakenpants commented 3 years ago

i assume you're implying that the better the rating

No. Ratings mean jack shit if the vast bulk of those rating aren't technically aware. Number of users though means there are more eyeballs on it, and thus more likely to be someone who finds a flaw. Ratings overall only indicate if the users are happy - obviously a low rating indicates a shit product

the more users, the higher the likelihood of a developer being targeted .. monetized

The more users, the more likely it is that nothing flies under the radar. Also reputation / history of the developer: e.g gorhill is a classic example - he's principled, never wavered from the core purpose, always sound logic, and stated he will never sell out, he doesn't even ask for donations. You can spot people like this - they are passionate: it's not about money or fame or kudos. And likewise you can usually easily spot people who are in it for the money

[exfil] but it seems this is a rather nasty exploit

No it's not. In order to get it, the source has to be compromised - at which point the attacker pissing around with css would a laughing stock. I'd have to re-read up on the exact info, so take what I said as a bit hazy - and yes I get that css can served by CDN

CAD etc

I've never understood why any of you mofos have ever used sanitizing extensions. I've told/shouted it to you guys for years. The wiki has said almost since day one that it's a waste of time. But you all keep making suggestions for bleachers and wipers and scrubbers and mops and toilet brushes and soap. Just wear a fucking condom (FPI/TC)

atomGit commented 3 years ago

I've never understood why any of you mofos ...

so triGGerED i am

i get it, but where you default deny, i default allow and let my toilet brush clean up the shit because i think that's less hassle than prefs -> privacy & security -> manage exceptions -> REtype the address since FF wasn't smart enough to auto-fill in the active tab domain -> allow -> save changes -> close tab ... should be able to do that right from the damn address bar icon thingy ... or am i missing something?

Thorin-Oakenpants commented 3 years ago

i think that's less hassle than prefs -> privacy & security -> manage exceptions

It has nothing to do with cookie preferences. Sites are ISOLATED ... just sanitize on close = persistence per site is session only. If you don't like session only persistence, then use TC

Thorin-Oakenpants commented 3 years ago

i think that's less hassle than prefs -> privacy & security -> manage exceptions

You should always do it from the address bar: this way it gets the correct origin attribute. It's as simple as click padlock, click the right arrow, click more, click permissions. And clicking the padlock also shows you the exceptions for that site (where you can cancel them)

Anyway, if you're allowing all sites by default - why do you need to set exceptions - nothing should break. Unless you meant that's what you would have to do if you default denied like me. Well, honestly - my mileage is that almost nothing breaks - I haven't changed my cookie exceptions for about a year - a whole whopping 8 or 9 exceptions.

atomGit commented 3 years ago

why do you need to set exceptions ... Unless you meant that's what you would have to do if you default denied

bingo

my mileage is that almost nothing breaks

you visit 2 pron sites though, right (i think i recall you mentioning you don't visit many sites at all)?

It's as simple as click padlock, click the right arrow, click more, click permissions.

yeah... i knew that... just wanted to see of i could catch you off guard (now that's TWICE)

ok, i think you convinced me - and i'll be happy to dump another ext., even though CAD is pretty neat

...except...

i'm trying the default-allow thing without CAD, so everything gets dumped at browser close except the storage i want to keep (whitelist) - the problemo here is tabs don't get restored on startup and, please correct me if i'm wrong, but there's NO WAY to do that unless we privacy.clearOnShutdown.history = false right? and obviously that's not an option - not that i was generally using that feature anyway, but i'd like to have the option for followers of my 'dummy' guide

Svallinn commented 3 years ago

Can confirm that is the case with Session Restore and privacy.clearOnShutdown.history, so CAD might be a necessity for users that want their tabs saved (although they could just bookmark things, but don't tell them that, they'll get triggered...)

Edit: Please understand that everything I'm writing after this is based on my own understanding which may be wrong

I just realized this is a faulty premise to begin with. CAD isn't even closely related privacy.clearOnShutdown.history, this shouldn't haven an influence on whether you should have CAD on not. If you are:

or alternatively to these last two

then CAD is a pointless extension to have (due to existing isolation per site), unless for some reason you'll want more fine-grained control over data, e.g only sanitize IDB or only sanitize some cookies. Even if Session Restore is mixed in, (which means privacy.clearOnShutdown.history = false), I don't think there'd be a problem?

And just like Pants said, if you are default denying, you can use exceptions instead.

P.S. I'm a Session Restore user BTW, so I'm literally dissing myself

P.P.S There's so many acronyms on this repo that I have to check frequently (technical and non technical) that I'll actually be able to understand forum-level manbojumbo language in a few weeks...

crssi commented 3 years ago

  • LocalCDN - Since you're FPI'd then who cares. All the CDN know is they're serving content to that page + user UUIID - just like every other visitor to that page - big deal. Maybe it gives you a speed perf?

  • POOP - I don't use it and I'm not knowledgeable about CORS (and I assume a lot has changed since CORS first came out?). IMO if you're 95% or higher like the Tor Browser sans Tor, and you're masking your IP (wear your fucking mask, people) - then if TOr Project don't care, why should we.

I am not hiding IP behind some VPN and do not use FPI due to breakages (using a bit of relaxed TC auto mode instead)... that is one of the powerful reason to use those extensions to avoid leaking browsing details to 3rd party. I think LCDN and POOP does the hell of a job in this case.

crssi commented 3 years ago

ok, i think you convinced me - and i'll be happy to dump another ext., even though CAD is pretty neat

IMHO, CAD can be handy when you do not use FPI or TC auto mode. I do not use it due to TC.

smokemyshoes commented 3 years ago

@Thorin-Oakenpants Thanks alot for your advice and perspective.

Awesome. I haven't had time to set that up as a VM here for testing. Can you do me a favor, please? Go here and click the Firefox button, then click copy to clipboard in the short report and past me the results - TIA

I'll do that when I'm at my PC again and close the issue.

Thorin-Oakenpants commented 3 years ago

network.cookie.lifetimePolicy = 2

This makes all cookies = session cookies. Session cookie permissions break shared and service worker permission

 If you set a site exception for cookies (either "Allow" or "Allow for Session") then they become
accessible to websites except shared/service workers where the cookie setting *must* be "Allow"

So a solution to that (for those who don't clear cookies on close so they can keep some cookies for auto-login), is to change those sites to Allow as exceptions - but that's potentially flawed - because you may need a site to work, but you don't want to keep persistent data

You keep cookies as Allow by default (not lifetime = session) = zero breakage. You sanitize cookies on close (nothing survives: no exceptions, no flaws). You will have to login again to sites (big deal).

Now you can do what you like. IDK if wiping persistent cookies (and related data) you want to keep only affects a login or also a ton of preferences for that site (IMO opinion site preferences should be retained by the server and populated locally on login)

So that's just something to be aware of

atomGit commented 3 years ago

This makes all cookies = session cookies ... Session cookie permissions break shared and service worker permission

either i'm dense (stfu) or something has changed in fox? regex101.com requires workers to work (properly) - i have not set an exception and it works (properly)

So a solution to that (for those who don't clear cookies on close so they can keep some cookies for auto-login), is to change those sites to Allow as exceptions - but that's potentially flawed - because you may need a site to work, but you don't want to keep persistent data

yes, and that's the beauty of CAD - without it you lose the granularity and session restore and with it you lose nothing

Thorin-Oakenpants commented 3 years ago

workers still work .. it's shared and service workers that break

atomGit commented 3 years ago

well shit - i was shooting for 'simple' and it's looking like using CAD might be the easier way (for me)

i deleted my post because if one needs to add exceptions to get service/shared workers to work, then it seems it's just easier to use CAD (plus not break session restore)

smokemyshoes commented 3 years ago

@Thorin-Oakenpants as agreed...

control: Firefox 78 64bit on Windows 64bit
----------------------------------------------------
 hash: e6c7b364678e8ecec909088314318acb8430ee47 [F30]
 func: a50d51b002ce8700024e0b97427ad26b3b2ae2ab
 poly: 0cde3749d8f342c858af1eef6b48f2e2be985440
  cos: 3, 4, 5, 6, 7, 13, 15, 16, 17, 18, 19, 20, 21
  sin: 11, 12, 14
  tan: 1, 10, 15

Windows ???

Thorin-Oakenpants commented 3 years ago

@smokemyshoes thanks. No, it's not saying you're windows - it's comparing your results against a control set generated by windows 64bit FF 64bit, and showing the differences: specific cos, sin and tan functions in the above example. I can use those differences across all FF tests to determine a minimum set of math functions for max entropy

F30 is a short code for your hash - which is Linux (one of several) - namely debian based one (but I need to more tests)

Thorin-Oakenpants commented 3 years ago

PS: you can also just go to about:debugging#/runtime/this-firefox and click on each manifest

atomGit commented 3 years ago

that's something i always do, but how reliable is that? in other words, can an ext. communicate with a server that isn't included in the manifest?

Thorin-Oakenpants commented 3 years ago

web_accessible_resources

An array of strings specifying the paths of packaged resources that are expected to be usable in the context of a web page

 "web_accessible_resources": [
    "images/*.png",
    "style/double-rainbow.css",
    "script/double-rainbow.js",
    "script/main.js",
    "templates/*"
  ],

Check this property is a first step. If it has no web accessible resources, then it wont leak it's internal UUID then at least that avenue of leaking it's internal UUID is covered - see erthling's comment

atomGit commented 3 years ago

very helpful - is there a test site to check for ext. UUID leaking? i'm not seeing anything in the wiki

also it seems this depends on JS, but even with that i'm not clear on how easy it is to exploit

and just a note for others reading this - an ext. having web_accessible_resources apparently doesn't necessarily mean it will leak (i saw where gorhill commented on this)

Thorin-Oakenpants commented 3 years ago

is there a test site to check for ext. UUID leaking? i'm not seeing anything in the wiki

No, because each extension would (probably) require it's own PoC. And correct, the presence of web accessible resources does not mean it actually leaks

earthlng commented 3 years ago

If it has no web accessible resources, then it wont leak it's internal UUID

just FYI, this is unfortunately not true. UUIDs can also leak through certain types of requests

Thorin-Oakenpants commented 3 years ago

here's a nice write up on STATE tracking:

edit: not sure why I posted this in here, it was meant for a different issue

Thorin-Oakenpants commented 3 years ago

quoting myself

No. Ratings mean jack shit if the vast bulk of those rating aren't technically aware

https://xkcd.com/937/ 😀

In future I think I'll just answer questions with xkcd links

edit: might as well throw in https://xkcd.com/1098/