Update to say this is not a "backdoor" in any event, and custom headers are allowed per
https://tools.ietf.org/html/rfc7231#section-5.
Lots of confusion today about network requests or (in this case) custom but user-id-free headers vs. "tracking". A script load exception list (we will try to get rid of it;
new thinking is defer until user clicks on FBConnect widget) we hardcode should be overridable and really should go away, but we are practical about not defaulting to a browser that doesn't work on too many sites to have adoption. That's on my twitter today.
This post is about custom HTTP headers we send to partners, with fixed header values. We could have just hacked the user-agent: header but chose custom instead. There is no tracking hazard here.
In both cases, third party tracking requires some kind of persistent-in-the-client identifier, or else fingerprinting. We block 3rd party cookies and storage, also 3rd party fingerprinting. We block (dual-key, actually -- same as Safari) HSTS supercookies (HSTS added 1 bit per domain of client-persistent state, so 32 junk domains enables the Criteos of the world to make a per-user 32-bit identifier).
As a user, I find it important to understand the diffs between requests and tracking before choosing a tracking protection solution. At first (in the '90s), I didn't grok the implications of 3rd party cookies, images, and scripts -- neither did pmarca or montulli, lol. Those genies are long out of their bottles.
Also I find it silly to assume we will "heel turn" so obviously and track our users. C'mon! We defined our model so we can't cheat without losing lead users who would see through it. That requires seeing clearly things like the difference between tracking and script blocking or custom header sending, though.
