tomrittervg

Yes, it is a bug, in fact it's this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1863193#c9 which is of course getting some more attention now =)

WebAudio fingerprinting is largely mitigated (in Firefox, potentially other browsers) - I wrote a quick overview that talks about the current distribution of values as well as our more recent efforts. https://ritter.vg/blog-webaudio_alibaba.html

For a time RFP - by itself - could be enabled by web extensions. (It might still be possible, I don't recall if we removed it.) But it's a footgun because it became even easier for people to enable it by accident.

I can point you at a few things you could do if you wanted to pursue this:

1) We have a dev extension https://github.com/mozilla-extensions/fingerprinting-protect... that lets you enable/disable individual fingerprinting protections. We use to debug why something is broken.

2) granularOverrides allows you to enable/disable individual protections for a given website.

If you wanted this, you could go read https://docs.google.com/document/d/1FywogzvkWupoUoz4PcCp9nNd... ; then made an extension that made it easy to edit granular overrides (you couldn't directly set the preference, but you could produce the json you could copy/paste into the pref). You could do stuff with lists if you want. (Somewhere there was a FF fork that had a pretty impressive granularoverride list itself...) You'll be in this awkward spot where you don't have all the permissions to do what you want to do directly, but you can get yourself about.... 40 - 60% of the way there?

I would like to find a way to support power users while not making the problem worse (In https://ritter.vg/blog-telemetry.html I describe that the 'confused users think FF is broken' problem got so bad management wanted to just disable RFP entirely, but I was able to show that these users are a very vocal minority and the problem is not as bad as it seems) while also not giving myself a maintenance burden but... maybe there a path forward where this dev extension - that can do things normal extensions can't - could potentially get more functionality...?

And to the point about Mozilla's protections lacking, I've corrected the record: https://ritter.vg/blog-webgl_renderer.html

The Bugzilla bug is at https://bugzilla.mozilla.org/show_bug.cgi?id=2036440

The breadth of responses here about people who can't reproduce this (or can) is one of the most frustrating things about working on fingerprinting protection. I also cannot reproduce this behavior, and have to assume that there is some complicated, behind-the-scenes risk assessment that is being done and some people trigger it and some don't. If any Cloudflare devs want to chat, I would love to. While not a normal way to contact us (support requests will be ignored), I can be reached at security@mozilla.com

> Also by default addons.mozilla.org is a privileged site so of course they include google tracking in it and they get the proper fingerprint no matter what you have configured

AMOs privileges are limited to (A) installing extensions with only one prompt (instead of two) (b) launching some sort of "UI Tour" feature that highlights some features of the UI and (c) extensions cannot, by default, operate on the site. That last one is an unfortunate trade-off we've made because of the massive waves of malicious extensions. You can re-enable extensions access to AMO on a case by case basis: https://support.mozilla.org/en-US/kb/quarantined-domains but I recognize this is an opt-in, non-default configuration.

I am saddened to hear we use Google Analytics on the site, but I can tell you with certainty that it is not bypassing any of Firefox's built-in fingerprinting protections or getting any privileged access that way.

(n.b. I own these features in Firefox)

There are three levels of protection:

- ETP Standard (see [0] for the latest improvements we rolled out)

- ETP Strict (we're working on things in Bugs 2036879 specifically this issue, 2037260, and more generally 2036786)

- Resist Fingerprinting (RFP)

These levels are something akin to "Wash your hands after using the subway", "Wear a mask on the subway", and "Wear a level B hazmat suit on the subway".

"people already expect sites to break, so why holding back?" - because the breakage is so severe, and people _don't_ associate that breakage with the setting they made. There are bug reports all over the internet proving it, here are some examples [01-4]. The protections we deploy in ETP Standard and Strict are calibrated to provide as much protections as possible while keeping the internet usable, and we're working fulltime on improving them.

[0] https://www.firefox.com/en-US/firefox/151.0/releasenotes/#no... [1] https://old.reddit.com/r/firefox/comments/fy6l1z/youtube_bor... [2] https://necromuralist.github.io/posts/mozilla-madness-resist... [3] https://support.mozilla.org/en-US/questions/1212634 [4] https://support.mozilla.org/en-US/questions/1322787

Mozilla is working on it. (I know you said 'Academic', but we publish papers sometimes too.)

> Ultimately most fingerprinting technologies use features that are intended behavior

Strong disagree.

> IP address/cookies/useragent obviously are useful

Cookies are an intended tracking behavior. IP Address, as a routing address, is debatable.

> Canvas/font rendering is useful for some web features

These two are actually wonderful examples of taking web features and using them as a _side channel_ in an unintended way to derive information that can be used to track people. A better argument would be things like Language and Timezone which you could argue "The browser clearly makes these available and intends to provide this information without restriction." Using side channels to determine what fonts a user has installed... well there's an API for doing just that[0] and we (Firefox) haven't implemented it for a reason.

n.b. I am Firefox's tech lead on anti-fingerprinting so I'm kind of biased =)

[0] https://developer.mozilla.org/en-US/docs/Web/API/Local_Font_...

In this context "a unique fingerprint" means that your fingerprint does not match any other user's. When you visit Site A and B you give a fingerprint X that is the same on A and B but no one else on the internet has ever sent.

In contrast a randomized fingerprint mean when you visit A you have a fingerprint X' and on B you have a fingerprint Y' and no one else on the internet has X' or Y' but A and B can't correlate you.

The protections we've put in place first try to do API normalization to make it so more people have a fingerprint X, and it isn't unique. And then they do API randomization so you use X' and Y'.

If a fingerprint goes to extra effort of detecting a randomized fingerprint, and ignore (or remove) the randomization, they will get the X fingerprint which - hopefully - matches many more users.

It's 'Suspected Fingerprinters' that controls the Fingerpritning Protection feature described in the blog post. But yes, naming and descriptions is hard and never seems to work.

But to disable it on a per-site basis, I would just disable ETP for the entire site. If it's a service or site you use frequently you probably trust them or otherwise have a login to them that makes trying to avoid fingerprinting illogical.

This is true, but adding a sandboxing to browsers has been a huge part in driving up the difficulty/cost of browser exploits, and driving down the frequency of their use.

And also we'll pay for a bypass of the wasm sandbox. (Actually, looking at our table, I'm going to try and get the bountyamount upped...)

The vulnerability did require JavaScript to trigger.

I think it would be a labor of love and craftsmanship to exploit a content process today without using JavaScript.

This is precisely how I feel about Binary Transparency

Ah okay, I understand better.

The (second) pseudocode you have is right (the second two 'hash()' should be 'hkdf()', and the first should be 'pbkdf()'.)

The first is an alternate way to do it. But for cryptographic reasons that tend to be buried in formal proofs; you generally don't want to derive twice the keylength you need and then split for two keys. (Besides the necessity for formal proofs (as I understand it) - it's just easier to make an indexing mistake and reuse key material. One also becomes more vulnerable to a collision attack, although that might not make sense in this context it related to the formal proofs.) I will note that sometimes - especially in embedded spaces - you'll see people taking this shortcut in the name of speed or codesize.

Instead you want to fully derive two keys using separate HKDF calls with separate 'labels'. This provides strong domain separation for the keys.

But I'm mostly trying to provide with a pointer to what to read about to convince yourself. I'd start at https://crypto.stackexchange.com/search?q=domain+separation

If you find out we're doing something that still seems weird though, please send me an email!

There are more details above but the short version is that it is possible to build extensions for other browsers that work with Firefox Sync. But the only one linked seemed to be for Gnome's browser, so no one may have actually done it.

From the RFC: "Its goal is to take some source of initial keying material and derive from it one or more cryptographically strong secret keys."

In our case, the initial keying material is the output of PBKDF; and the two outputs we use are used as an encryption key and a bearer token (essentially a password but I call it an authentication token to avoid confusion with your actual password). There are less complicated ways to do this; but this one is cryptographically conservative.

"essentially requires the server to be able to reverse HMAC-Hash to find the encryption key from the the authentication token" - the server can't do that; which is why the server can't figure out your encryption key from your authentication token. (The best the server could do would be to try a password guessing attack.)

I happen to also work on Firefox/Tor Browser's anti-fingerprinting work, so yea - we're trying to make improvements there too =)

Containers is a big Firefox feature (exposed through an Add-On) in this category too.

As far as Web Extension APIs, I don't know much about that, but if you have an API that would enable a use case that Mozilla doesn't have a bug on and haven't considered; you are welcome to file a bug explaining what you would like and what you would use it for, and the Web Extension team will consider it.

I wasn't aware that any distribution (besides Tor Browser) was building Firefox (or anything really) reproducibly.

There's debian's https://reproducible-builds.org/ effort, but I thought that wasn't making much progress lately, nor was it deployed.

Could you provide more info on what distro you're using, or how they're doing this?

It is many folks', and we appreciate the feedback. Hopefully things will get better soon: https://github.com/mozilla/multi-account-containers/issues/3...

There's a few children of this comment, noting this, but to tie things together from someone from Mozilla:

- You can self-host your own sync server. It's not something we spend a lot of time making easy, but it is possible and supported in some capacity: https://mozilla-services.readthedocs.io/en/latest/howtos/run...

- You can definitely build extensions for other browsers (or a standalone app) that implement the Sync protocol.

Thanks! I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1503872

When we have time we'll have to trace through what it's doing and what components of RFP are causing the failure. (If anyone wants to do that and report in the bug, we (Mozilla/Tor) would much appreciate the contributions!)

Safari by default has a stricter storage access policy by default for all third-party domains, which requires you to visit the domain as a first party first. So it's probably that rather than ITP.

Thanks for diagnosing that for me, you're right blocking third party cookies does cause it to fail.

Both tests are equally valid. I just gave one because trying to be exhaustive about testing it would be mind-numbing. The test I provded only does localstorage, but FPI also isolates DNS cache, H2, image cache, favicons, cookies, localstorage, indexdb, etc etc

You can do yours by visiting https://anonymity.is/misc/ff/fpi-iframe.html first; then visit the ritter.vg and rittervg.com links.

I won't copy paste my reply from above, but rather link it: https://news.ycombinator.com/item?id=17949613

Go to https://ritter.vg/misc/ff/fpi.html On first load it should say "There was nothing in local storage."

Now go to https://rittervg.com/misc/ff/fpi.html On first load it should say the same. If it says the same timestamp that was stored on the first page - it's not working.

Source: I'm a Mozilla Developer who is one of the primary devs/supporters of First Party Isolation.

> An option could be to provide a webRTC-based node, but I am not sure how feasible that would be, after reading some comments here.

I'll point you at FlashProxy (https://crypto.stanford.edu/flashproxy/) and Snowflake (https://github.com/keroserene/snowflake) the latter of which is in active development. =)

Tor Browser will exist as long as Tor feels it needs to. If the features or anti-features in FF cause them to believe Firefox does not fit their need, then we're/they're not going to discontinue it.

The Fusion project is done by a subset of that team (+me, I happen to sit with Sandboxing due to other responsibilities).

Hi all. I am a Tor Project Developer and work at Mozilla on this project. We appreciate everyone's enthusiasm and feedback. Our ultimate goal is a long way away because of the amount of work to do and the necessity to match the safety of Tor Browser in Firefox when providing a Tor mode. There's no guarantee this will happen, but I hope it will and we will keep working towards it.

If anyone is interested in assisting development-wise, Firefox bugs tagged 'fingerprinting' in the whiteboard are a good place to start. You can also run Tor relays and help us improve the health of the network by working with Tor's new Relay Advocate (https://blog.torproject.org/get-help-running-your-relay-our-...). More people being involved in spec work (especially at the W3C) and focusing on fingerprinting and privacy concerns is also very useful - it's very hard to keep eyes on all the things happening everywhere.

We also appreciate users of Firefox Beta and Nightly (Nightly especially). The flags Tor features are developed behind (privacy.resistFingerprinting and privacy.firstparty.isolate) are experimental. I appreciate bug reports from users running these flags but you should expect them to break things on the web (resistFingerprinting especially; first party isolate is generally more stable and usually only has breakage on particular login forms).