search

sereneblue / chameleon

WebExtension port of Random Agent Spoofer
https://sereneblue.github.io/chameleon
GNU General Public License v3.0
502 stars 53 forks source link

FYI: timezone spoofing #126

Closed Thorin-Oakenpants closed 5 years ago

Thorin-Oakenpants commented 5 years ago

Prerequisites

:exclamation: dude, would you like a link - gimme an email and I'll let you have at it

Relevant settings

Context (Environment)

note

I am not testing if you leak languages here (that's what a lot of the long versions are for - just simple formats of the returned strings so users can see the names of days, months, literals, etc), but I did download and set up a German FF, and all the tests pass (whatever your language is, then that is what is used, AFAIK, regardless of the API (window.date, Intl.* , formatToParts, etc). There's a little more to it: javascript.use_us_english_locale=true, RFP=true, and intl.accept_languages=en-US, en for spoofing are required to enforce english, etc in testing: but that's for RFP/Tor testing. All the tests made so far don't seem to leak if the language/locale is different (even literals and hour cycles are correct!).

Anyway, enough of languages - onto time zone spoofing: what the heck, I live in [edited] .. now everyone knows. I was going to censor all that out, but then you wouldn't see the difference - so WTF ... I'm in [edited] guys and girls .. come get me!! It's [edited] in the morning .. and I'm [edited hrs [edited] of GMT - so for easy reference in this test

this is just for your info

here is a pretty pic of your spoof getting unmasked [edit pic removed - go test it for yourself, peoples!!]

some observations

First of all, apologies for probably confusing order and the nature of the naming conventions. It gets confusing. And there's a lot of cross over & usage with each other e.g. between resolvedOptions, formatToParts, numerous windows.date, and various Intl APIs. It makes my head spin. I think I might buy some beer and get drunk tonight :beer:

This is a WIP, I have more things to add, including one that leaks regardless of RFP. Might have a check in my German FF for you.

Do you have a language spoof - I know there's a setting for the http header. But is there one that is meant to apply here?

sereneblue commented 5 years ago

I don't try to match everything, that's mostly up to to the user. Profile spoofing is browser and browser version spoofing. Timezone and language are separate, would be a pain to try to match them!

I'm using the data from https://momentjs.com/timezone/ to get the timezone information. I may need to work on this to get it to output things a little differently.

I don't think I've covered everything, so I'll go over the methods you've listed above when I have a bit more time to focus on resolving this issue. Language is spoofed (at least some of the navigator properties)

I recently spent a lot of time looking into timezone spoofing, and it's generally not a good idea to mess around with the Date object. It breaks a lot of widgets/libs. The current version of Chameleon only spoofs Date objects created without a parameter (to break less sites). If there's a solution that won't break many sites, I'll definitely work on adding it to Chameleon.

I've invited you to a private repo (nice timing Github!). You can post the link in an issue. I'd give you my email but I don't want to post it in public. Thanks! :)

sereneblue commented 5 years ago

Haha, yes, RFP is a solution for timezone spoofing. However, I meant something with a little more flexibility so the user could change the timezone. Spoofing whitelisted domains is an interesting idea, but I don't think it'd be too helpful (which sites would you spoof and why) Then again, if you're using NoScript/uMatrix leaking the timezone is probably not much of a concern (from the client).

The invite was for a temporary repository so you could post the link in an issue but it's a public link. :) Great work with the site, it's a bit of an eye opener.

Thorin-Oakenpants commented 5 years ago

Ahh OK. I wasn't trying to hide it - anyone looking under the ghacksuserjs repo can plainly see it. I just didn't want to make it public until I done a lot more work on it.

Then again, if you're using NoScript/uMatrix

It's always about worse case scenarios, and looking at each vector in isolation - e.g look at FP'ing and persistent local data is a different issue. Absolutely lock down 3rd parties, 1st party JS, inline scripts .. but eventually you need some of those to make shit work. The problem is that even if all FP'ing scripts became 1st party (such as reddit, who also serve a nasty tracking pixel image), there's nothing to stop the behind scenes data brokers who buy and sell all this data. At the moment, most of those major data brokers are the third parties - driving data collection to 1st party would just change their business model, but they would still do it.

Kraxys commented 5 years ago

There is a solution for timezone spoofing... it's called privacy.resistFingerprinting - doesn't break anything

The problem with RFP is that (for what I know) the faked time zone it produces is always UTC+0. Good with Tor, because in using it Tor users become less identifiable. But if (without using Tor) I'm using a proxy in Hong Kong, il will almost surely be the sole people browsing the web at this moment from a HK proxy and displaying an UTC+0 time zone in the same time. . When, in order to fake his location, a user uses a vpn/proxy located in X, he may prefer to display a time zone compatible with this location.

Thorin-Oakenpants commented 5 years ago

Don't confuse tracking (which can use IP, cookies, etc) with FP'ing (browser characteristics). FP'ing is a subset of tracking. Switch IPs (VPN location) and resume browsing and the tracking is broken (for IP). Tracking is essentially linking activity.

FF is not the Tor Browser. RFP's aim is to lower entropy in FP'ing (browser characteristics) and cannot do anything with masking your IP. The only thing that can be done is to increase the set of RFP users enough to make it unfeasible to use TZ as a metric this way.

will almost surely be the sole people browsing the web at this moment from a HK proxy and displaying an UTC+0 time zone in the same time.

As long as only HTTPS is enforced, as long as you block/sanitize other tracking measures (such as cookies and persistent local data), and as long as you don't give yourself away (e.g logging into an account - doesn't have to give away your real ID, it's enough to link previous activity, e.g gmail), then you should be fine.

There are many parts to being private, anonymous, and secure on the internet. Tracking does not necessarily break any of those - there will always be metadata. OpSec is what you need.

Kraxys commented 5 years ago

Don't confuse tracking (which can use IP, cookies, etc) with FP'ing (browser characteristics). FP'ing is a subset of tracking. Switch IPs (VPN location) and resume browsing and the tracking is broken (for IP).

Yes but if eg Iclose my browser, clear residual browsing traces, switch my IP for an other HK IP and restart my browser, I remain being (almost?) the sole people having a HK IP and displaying a GMT+0 TimeZone, and this contributes to link my previous browsing session to the the new one. In displaying an HK TimeZone each time, it's more difficult to link the two browsing sessions (at least the session are no more linkable by the sole characteristics of having an HK IP and a GMT TimeZone). This may lead to my identification: If session A and B are linked through some element c, session B and C linked through an element d etc etc (whatever these elements are) and if in session Y I end up in connecting to a personal account (linked to me), session A becomes linked to me, too, which may be unpleasant.

An other way to consider these things: In displaying a TZ compatible with my IP location, I smooth my browsing profile, and, many people having an HK IP and a HK TZ at the same time, I melt better in the crowd.

FF is not the Tor Browser. RFP's aim is to lower entropy in FP'ing

In my opinion it "lowers entropy" for Tor users, because it's relatively common (when browsing through a Tor exit IP), to display a GMT TZ. And it will lower entropy in the future for casual FF users when (and only when) a significant portion on FF users will have adopted RFP. But for the moment, if I browse the web through a non Tor US/Canadian/Russian/Chinese IP, having GMT TZ I think increases my "entropy".

At this point I would like to precise why I have been using quotes when talking about "entropy": In Physics/Thermodynamics, the higher the entropy, the less information you have about the system and its components/particles. For example, you have a box full of gaz. In configuration (a), all the gaz is in the left half of the box. In configuration (b), the gaz is uniformly distributed in the box. Entropy tends to increase, and (a) naturally tends to evolve to (b). So the entropy in (b) is higher than the entropy in (a). On the other hand, in (a) you have some information about every gaz particle (you know that a given particle is necessary in the left half of the box, which is exactly 1 bit of information). And in (b) you have lost this sole bit of information. So the higher the entropy of something, the less you hold information on this something.

So, in that sense, when some mechanism renders me less identifiable, less unique, it should be said that this mechanism increases entropy, and then, increasing entropy would be seen desirable. You (and panopticlick) consider that being less unique is something desirable too, but you name that "decreasing entropy" (and "increasing entropy" if I become more identifiable, more unique). It seems that the notion of entropy you (and panopticlick) use is just the opposite of the physical/thermodynamical notion of entropy (it should be named "negentropy" I think).

This last part od my post was maybe a little off topic. But sometimes people get puzzled by this two opposite meanings of the word "entropy", and I think this point should be emphasized.

then you'll find you'll be sending and receiving messages from the past and future and things get out of whack.

This may be really precious: Alice, to Bob 3h PM: "You have not yet replied to the email I sent to you 4 hours ago!" Alice to Bob 3h30: "Ah, Ok I just received it... I see you have sent it to me at 11h10 AM, so there was surely a problem with the email server, it's not your fault".

sereneblue commented 5 years ago

I've fixed some issues with the timezone. I won't touch Intl.DateTimeFormat because things will get complicated fairly quickly.

I've realized that spoofing the timezone is even more complicated than I initially thought. Some locales have different output formats, so Chameleon's spoofing only works if you have an English locale. I'll update the wiki with these limitations.