-
Notifications
You must be signed in to change notification settings - Fork 469
Ability to modify HTTP_ACCEPT headers #55
Comments
There is an extension on GitHub called Chameleon, that besides some Currently I use a UA changing extension instead of uMatrix, and I can But my HTTP_ACCEPT is different and that pre-alpha buggy extension is On 11/11/14, Raymond Hill notifications@github.com wrote:
|
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. |
Sender of the email here. 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. (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 |
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? |
@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. |
Through email:
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.
The text was updated successfully, but these errors were encountered: