Skip to content
This repository has been archived by the owner on Jul 21, 2021. It is now read-only.

Ability to​ modify HTTP_ACCEPT headers ​ #55

Closed
gorhill opened this issue Nov 11, 2014 · 5 comments
Closed

Ability to​ modify HTTP_ACCEPT headers ​ #55

gorhill opened this issue Nov 11, 2014 · 5 comments
Labels

Comments

@gorhill
Copy link
Owner

gorhill commented Nov 11, 2014

Through email:

For further anonymization, and because User agents are, for most people (not me since I am always on the latest version of Chromium x64​, very identifiable​), obsolete​ (unless they use a nightly or obscure browser)​, it​ is​ important to​ have the ability to​ modify HTTP_ACCEPT headers​ (especially for people who live in smaller countries), assuming this is possible​. Though having the option of cycling it from a list every n minutes would be great as well.

​I would recommend the following to be the default, to more effectively crack down on the usage of fingerprinting tools:
"accept_encoding":"gzip,deflate,sdch",
"accept_default":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8",
"accept_lang":"en-US,en;q=0.8",

Will have to think carefully about this. Just a single whitespace, missing or not, is enough to make one browser stand out among others. I don't have access to any stats regarding strings in widespread use, so it is a bit difficult here to work in blind mode.

My earlier thoughts on this is that the HTTP_ACCEPT header should be tightly coupled with the UA string, and to support the ability to add a suffix string to the candidate UA strings, which suffix, if present, would be used for the HTTP_ACCEPT header.

@ghost
Copy link

ghost commented Nov 11, 2014

There is an extension on GitHub called Chameleon, that besides some
tracker stuff that doesn't actually work, it masks your browser to
match Tor Browser (because everyone using that has the same stuff).

Currently I use a UA changing extension instead of uMatrix, and I can
set that very same User-Agent (the most common one for Tor is simply
Firefox 24 on Windows 7 x86).

But my HTTP_ACCEPT is different and that pre-alpha buggy extension is
able to change it to the Tor Browser equivalent.

On 11/11/14, Raymond Hill notifications@github.com wrote:

Through email:

For further anonymization, and because User agents are, for most people
(not me since I am always on the latest version of Chromium x64​, very
identifiable​), obsolete​ (unless they use a nightly or obscure browser)​,
it​ is​ important to​ have the ability to​ modify HTTP_ACCEPT headers​
(especially for people who live in smaller countries), assuming this is
possible​. Though having the option of cycling it from a list every n
minutes would be great as well.

​I would recommend the following to be the default, to more effectively
crack down on the usage of fingerprinting tools:
"accept_encoding":"gzip,deflate,sdch",
"accept_default":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8",
"accept_lang":"en-US,en;q=0.8",

Will have to think carefully about this. Just a single whitespace, missing
or not, is enough to make one browser stand out among others. I don't have
access to any stats regarding strings in widespread use, so it is a bit
difficult here to work in blind mode.

My earlier thoughts on this is that the HTTP_ACCEPT header should be tightly
coupled with the UA string, and to support the ability to add a suffix
string to the candidate UA strings, which suffix, if present, would be used
for the HTTP_ACCEPT header.


Reply to this email directly or view it on GitHub:
#55

@ghostwords
Copy link

Hey guys, Chameleon's author here. Regarding blending in to match Tor: There is only so much you can do to make Chrome look like Firefox. There might be more merit in (subtle/believable) randomization. Plain old blocking is best, when you know what to block. Please see ghostwords/chameleon#1 for the Chameleon discussion.

@0xBRM
Copy link

0xBRM commented Dec 4, 2014

Sender of the email here.
Can confirm Ghostwords' extension works, in that it modifies the HTTP_ACCEPT headers, as they were previously conveying 18.37 bits of identifying information.
Using Tor's UA is not the way to go though, If we consider the most used browsers are Chrome 38 and Firefox 33, respectively (since both browsers auto-update by default, it's safe to assume the latest version is the most used one).

On µMatrix's compatibility with Chameleon: they work well together and I don't think they overlap in terms of functionality (once you disable UA spoofing on µMatrix for all scopes), according to the documentation I've read thus far. However, it's not super lightweight, using as much memory as µBlock itself.

image

(Using µMatrix to block everything but CSS and images from being requested, the number went down to 1 in ~1700)

HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 gzip, deflate en-us,en;q=0.5

@jankkm
Copy link

jankkm commented Dec 21, 2014

I think it doesn't make sense to pretend using firefox in chrome because the order of the request header is different in both browsers. So if a website can tell you are a chromium user who changed his user agent etc. you are very much identifiable. Am I wrong?
I found out about this on ip-check.info

@0xBRM
Copy link

0xBRM commented Jan 2, 2015

@jankkm Whilst I can't confirm the veracity of your initial statement (though it does seem suspicious), HTTP_REQUEST headers are not browser dependant and constitute an enormous privacy risk for tech literate people from smaller countries.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants