tomrittervg

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

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.

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 =)

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.