strips x-client-data headers from outgoing requests #2549
Conversation
There was a problem hiding this comment.
I think there are two more places where we might want to remove the header: first-party requests when Badger is enabled, and third-party requests that are not yet cookieblocked. So ... we always want to remove x-client-data, unless Privacy Badger is disabled.
ablanathtanalba
force-pushed
the
remove-x-client-data-header
branch
5 times, most recently
from
90f2fda
to
0365ff7
Compare
ablanathtanalba
changed the title
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ablanathtanalba
force-pushed
the
remove-x-client-data-header
branch
from
0365ff7
to
67570bd
Compare
This comment has been minimized.
This comment has been minimized.
ablanathtanalba
force-pushed
the
remove-x-client-data-header
branch
from
41f30b0
to
a3ae9f8
Compare
|
Refreshed and rebased this branch, including adding a setting in the options page for user's to toggle this on/off. I'm not sure yet what kind of supplementary information that toggle setting might need to let the user know what's going on (a helper tooltip? a link outwards to some credible article that lays out why |
src/_locales/en_US/messages.json
Outdated
| @@ -129,6 +129,10 @@ | |||
| "message": "Prevent WebRTC from leaking local IP address", | |||
| "description": "Checkbox label on the general settings page" | |||
| }, | |||
| "options_x_client_data_setting": { | |||
| "message": "Remove \"x-client-data\" header from outgoing requests", | |||
There was a problem hiding this comment.
We should phrase this in a way that's intelligible to non-technical people. Take a look at our existing privacy overrides. Something like Disable sending [NON TECHNICAL DESCRIPTION OF VARIATIONS HEADER DATA] to Google ("X-Client-Data header").
And, yes, exactly, we should also have a "learn more" icon that links to somewhere helpful.
| @@ -168,6 +168,22 @@ function loadOptions() { | |||
| }); | |||
| } | |||
|
|
|||
| // only show the x-client-data header setting if in Chrome & Chromium browsers | |||
| // TODO: more accurate way to determine this is a Chrome or Chromium browser | |||
There was a problem hiding this comment.
X-Client-Data is not in Chromium, only Chrome, I think.
We could try doing feature detection (always better than guessing based on UA). Something like, on Privacy Badger startup, make a dummy request to a Google domain. This request should get cancelled, but before it does, we'll see the headers and set our internal xClientDataHeaderDetected flag.
Evidence shows that the
x-client-dataheader in GET requests that Chrome sends could be used for tracking.This change strips all
x-client-dataheaders from outgoing requests when Privacy Badger is enabled, the user is on Chrome or some Chromium browser, and the option is toggled on.