However, continuous user tracking
via TLS session resumption is only
possible as long as the browser is
not restarted, because this clears
the TLS cache.
I'm under the impression Firefox intends to do DOH with Cloudflare shortly.
Does this allow Cloudflare to tie together user sessions to different HTTPS domains?
If X and Y are Cloudflare fronted domains, can they now pair sessions? I'm guessing a DOH session queries for domain X and immediately an HTTPS connection appears for X, then queries for Y and another appears at Y. Then the whole DOH session becomes identifiable once Cloudflare fronts any service with email sign in.
Unless I'm mistaken at least UDP DNS made the guess work a lot harder because you couldn't pin a session down behind an internet gateway as easily.
Cloudflare is not as bad as it looks. It is much worse :)
As a reverse proxy, it strips SSL, in fact MITMs your traffic. All your data is in plaintext to Cloudflare, which leaks not only history, but also logins/passwords, IPs, credit card numbers, coin wallets, everything.
I don't see obvious solution today for DNS queries be private. Pointing your system to Google or Cloudflare DNS is plainly giving away your browsing history, for free, DOH (dns over https) or not. As of today, all my devices are using always-on VPN, and using my VPN provider's DNS.
>"Eight years later, everyone in the business seems keen to point out that TLS version 1.3 will finally address this issue by encrypting session data, although it isn't obvious if the measures taken by IETF actually work."
Can someone say why it not yet if the measure taken by the IETF in TLS 1.3 work? Is it simply that this part of the spec hasn't been finalized yet? Or does the author mean something else?
So, TLS 1.2 servers offer session identifiers in cleartext and client resumption sends them in cleartext also. Which probably means someone watching lots of traffic to Google can correlate users even as they move across ips.
TLS 1.3 servers send the session identifiers encrypted to the client, and then the client sends it back in cleartext, but each successful handshake will generate a new identifier; a passive observer will not be able to correlate sessions -- except for retries, but the service owner still could. In TLS 1.3, the server can establish a session ticket any time after the handshake is complete, so conceivably, the server could wait until it had some idea of who you are, and establish a token then which contains your userid. (Anyway, it could always associate a random session id with your userid later)
Thanks for the clear explanation. Would it not have been more accurate for the author to have stated then that "the measures taken by the IETF in TLS 1.3 will work, although with some caveats"?
There are a lot of dark patterns Google could use to track you if it wanted to. Does it? Who can say besides those on the inside. If you think they're using this, then there are probably half a dozen other methods you also think they are using, so this shouldn't bother you (at least, not any more than you are already bothered). If you don't think they're using any of those half a dozen other methods, you probably shouldn't worry about this one too much either.
Made me smile. Google needs to track you, its their core business model. Defeat is not an option, all methods should be found and blocked. Thankfully Chrome is not the only usable browser, and network requests are detectable.
Google does not need to track anyone. Google needs to sell ads, and Google needs to be perceived as the best place to spend your advertising budged.
What business case is there for Google to work hard at tracking people, defeating anti-tracking measures? There is a cost to doing that, and I don't see a financial incentive for doing it.
There are certainly business cases for Google to not defeat anti-tracking measures, as collecting that sort of data is a liability. However, per previous lawsuits like the mapping cars sniffing WIFI data, perhaps they are still just trying to collect everything they can without thought to if it is a benefit, waste, or liability.
Keyword is targeted ads, it revolutionised the market and made FB and Google rich.
The only way to sell an ad placement to white males, with >100k income, in this zip code, with specific health problem is to track those people, and Google tracks them all.
FB gets data from your posts and messages, Google gets it from your emails, files, searches, location. Both get data from your browsing history (Like buttons, G-Analytics scripts), as do all the rest of third party trackers (cookies).
Without real numbers, like AdWords vs Profile Ads, one has to rely on common sense, in my sense, profiling is a gold mine. Below is a random quote I Googled up :)
In practice, this means that Google can now, if it wanted to, build up even richer profiles of named individuals’ online activity. It also means that the DoubleClick ads that follow people on the web could be personalized based on the keywords that individuals use in Gmail.
(4) Gmail and Facebook will complain that you're logging in from 'unknown device', meaning not from IP they recorded on you. Set up MFA to get around it, like FreeOTP mobile app to generate codes.
There are a variety of them. Cookies are obvious, but even if you block those, there are a variety of techniques to enable server-side super cookies, where you are taking a fingerprint of the browser and storing the information on the server (e.g. https://amiunique.org/fp). And that's not even counting stuff you can do with no cooperation from the user-agent at all. You can do a lot of deanonymization using IP blocks, time of day, and behavior analysis. I'm not an expert. There's a lot of stuff here that you can read about if you dig in to it.
Personally, I don't believe that Google is doing much if any of this stuff, because I think they rightly believe that if it were discovered that they are, it would go poorly for them in the public sphere.
And this is strange "They found that 80% of websites make a correct use, unsuitable for tracking repeat visitors — just resuming an existing session within the last ten minutes." Just Cloudflare has a 48 hour TTL. (Previously I stated 2 hours)
This is why you block the surveillance shops' IP space. They are professional panty-sniffers, dependent on doing so for their dinner. Like trolls and narcissists, your only value to them is instrumental. Assuming you care about these things, communicating with them in any way is against your interests.
The internet is a much nicer, safer place when you blackhole the commercial-Stasi-wannabes.
Did you turn on that 'Block dangerous and deceptive content' feature in Firefox' security tab? It works by consulting Google each time you visit a new website. You can imagine the rest.
Patently wrong. Here's how the API works:
The Update API lets your client applications download hashed versions of the Safe Browsing lists for storage in a local database. URLs can then be checked locally. Only if a match is found in the local database does the client need to send a request to the Safe Browsing servers to verify whether the URL is included on the Safe Browsing lists.
> So then it semi-randomly sends Google URLs you visit?
No, it computes a 4 byte hash of the URL (domain?) and if this matches a local DB entry then it asks google for all malicious URLs with that hash (explained in the link of parent).
Depending how many entries there are your browser contacts google fairly frequently and then google using techniques mentioned in the article can link your TLS-Cookie to your IP.
A four byte hash is unique to two billion sites. The collision space with non-mainstream sites you might visit is going to be tiny.
It’s as good as sending the actual URL, and possibly even the full path to the document you requested, if the browser has previously asked Google for another site and Google has seen a pattern of browsing from Site A to Site B in browsers not using this “security” feature.
Yes, but that is (by the nature of the paradox) only true for a small subset of sites. It provides a huge amount of information, and for much the same reason, DoB is often used as part of an identifier.
Let’s assume that it is indeed the hash of the URL as they wrote. There are much more than 2B URLs on the net. Assume google flagged 2M as malicious (a 8MB db).
So on average you get a hit for 1 in thousands URLs. For each hit you query google for the malicious sites with the actual hash. It does feel like some information could leak but at the same time there are literally hundreds of possible URLs that map to each hash value. So there is plausible deniability as well.
Again, combined with more information this could be exploited. But probably there are easier attack vectors.
You issue quest on hash A then hash B. Google guesses that because of other activity it has seen today, visits to a site marked by hash A followed by visits to site marked hash B means you are following a link from Alex Jones’ blog to a flat earth holocaust denial web site, and thus prepares to serve your IP address ads for tin foil hats and prepper magazines.
The chances of your traffic pattern of hash A then hash B colliding with, say, my browsing of the MLP fan club and following a link to cosplay photos from Dragon Con are pretty slim, even though the MLP fan club URL hash collided with the Alex Jones blog hash.
Google aren’t just looking at the one thing you viewed, they are following you everywhere.
any evidence that it doesn't match with the top ~1M websites? because that page says "hashed versions" which kind of implies "not inspect-able".
also why does it collect client ID at all and also "should uniquely identify a client implementation, not an individual user" doesn't sound a lot like "can't identify an individual user" ... especially in a home user context.
Given that the system makes a network request when a hashed match is found, anybody could verify this. Surely the evidence would need to go in the other direction, especially since revealing the offending websites would signal to malicious parties exactly what they need to change.
No, there's a substantive difference between "contacts Google to run a check on a specific domain" and "contacts Google to update the local database of bad domains". They're not comparable.
And a browser that doesn't contact third parties isn't much of a browser.
Those session resumption tokens save you redownloading 1- 10kb of certificates every fresh connection and the multiple round trips for the TLS handshake. Its a bandwidth and latency optimization.
The largest company which tracks surfing habits without need for HTTP cookies is Amazon. When you visit every website hosted on AWS, Amazon tracks you, without saving/reading any cookies. The same is for any server hosting provider companies.
Surely, there is a lot of lot of. Mainly your IP addresses and your browser fingerprints. Through the two, a server hosting company can collect your browsing habits when you visit the websites they are hosting, without your awareness. Whether or not they really do this is another thing. I mean they just can.
Amazon stands to lose billions of dollars if what you say is found to be true. They host governments, banks, health care facilities, payment providers and more, all of which would sue the shit out of AWS if they found this out.
So I'm going to go on a limb and say you are probably wrong.
What I mean is "Amazon can track you when you visit a website hosted on AWS", I have not any evidences that they really did it. Just as the OP's title shows, Google can ..., but we have not any evidences that they did it.
When you visit a website hosted on AWS, your IP and browser fingerprint are all sent to AWS's servers, that is why they can track you. Whether or not they really track you is another thing.
64 comments
[ 2.8 ms ] story [ 50.8 ms ] threadDoes this allow Cloudflare to tie together user sessions to different HTTPS domains?
If X and Y are Cloudflare fronted domains, can they now pair sessions? I'm guessing a DOH session queries for domain X and immediately an HTTPS connection appears for X, then queries for Y and another appears at Y. Then the whole DOH session becomes identifiable once Cloudflare fronts any service with email sign in.
Unless I'm mistaken at least UDP DNS made the guess work a lot harder because you couldn't pin a session down behind an internet gateway as easily.
As a reverse proxy, it strips SSL, in fact MITMs your traffic. All your data is in plaintext to Cloudflare, which leaks not only history, but also logins/passwords, IPs, credit card numbers, coin wallets, everything.
I don't see obvious solution today for DNS queries be private. Pointing your system to Google or Cloudflare DNS is plainly giving away your browsing history, for free, DOH (dns over https) or not. As of today, all my devices are using always-on VPN, and using my VPN provider's DNS.
But yes, it is often not a problem at all to block Google Fonts/Analytics - almost everything works as expected.
That was why I originally started using uBlock origin… it had a thing to shim in that, as opposed to uMatrix which didn't.
Just checked my uBlock Origin on smh.com.au: fonts.gstatic.com are loaded ...
>"Eight years later, everyone in the business seems keen to point out that TLS version 1.3 will finally address this issue by encrypting session data, although it isn't obvious if the measures taken by IETF actually work."
Can someone say why it not yet if the measure taken by the IETF in TLS 1.3 work? Is it simply that this part of the spec hasn't been finalized yet? Or does the author mean something else?
TLS 1.3 servers send the session identifiers encrypted to the client, and then the client sends it back in cleartext, but each successful handshake will generate a new identifier; a passive observer will not be able to correlate sessions -- except for retries, but the service owner still could. In TLS 1.3, the server can establish a session ticket any time after the handshake is complete, so conceivably, the server could wait until it had some idea of who you are, and establish a token then which contains your userid. (Anyway, it could always associate a random session id with your userid later)
Made me smile. Google needs to track you, its their core business model. Defeat is not an option, all methods should be found and blocked. Thankfully Chrome is not the only usable browser, and network requests are detectable.
What business case is there for Google to work hard at tracking people, defeating anti-tracking measures? There is a cost to doing that, and I don't see a financial incentive for doing it.
There are certainly business cases for Google to not defeat anti-tracking measures, as collecting that sort of data is a liability. However, per previous lawsuits like the mapping cars sniffing WIFI data, perhaps they are still just trying to collect everything they can without thought to if it is a benefit, waste, or liability.
The only way to sell an ad placement to white males, with >100k income, in this zip code, with specific health problem is to track those people, and Google tracks them all.
FB gets data from your posts and messages, Google gets it from your emails, files, searches, location. Both get data from your browsing history (Like buttons, G-Analytics scripts), as do all the rest of third party trackers (cookies).
People way overestimate the helpfulness of profile targeted advertising vs search term targeted ads.
In practice, this means that Google can now, if it wanted to, build up even richer profiles of named individuals’ online activity. It also means that the DoubleClick ads that follow people on the web could be personalized based on the keywords that individuals use in Gmail.
https://www.theguardian.com/technology/2016/oct/21/how-to-di...
What about Adwords Customer Match, identity-based targeting ? (updated in 2018, by Erin Sagin is the Global SMB Solutions Go To Market Lead at Google) https://www.wordstream.com/blog/ws/2015/11/02/adwords-custom...
1. Switch everything to Apple, hardware company. iPhone, Mac OS
2. Use myname@icloud.com email, create few email aliases. Forward your gmail to it, and finally delete gmail accounts.
3. Don't use any of Googles software, like Chrome. Install adbocker extention/app and use Private Browsing windows by default
4. Buy a VPN subscription and set up your phone and Mac to always use it (on-demand).
Could you elaborate here? I'm primarily only aware of cookies and javascript/pixels, but I'm sure there are much more elaborate ways.
Personally, I don't believe that Google is doing much if any of this stuff, because I think they rightly believe that if it were discovered that they are, it would go poorly for them in the public sphere.
A high TLS resumption lifetime is used to decrease latency and it can have a huge impact. The RFC itself recommends a TTL of 24 hours (RFC4346).
The internet is a much nicer, safer place when you blackhole the commercial-Stasi-wannabes.
Patently wrong. Here's how the API works:
The Update API lets your client applications download hashed versions of the Safe Browsing lists for storage in a local database. URLs can then be checked locally. Only if a match is found in the local database does the client need to send a request to the Safe Browsing servers to verify whether the URL is included on the Safe Browsing lists.
From: https://developers.google.com/safe-browsing/v4/update-api
Source: Safe Browsing engineer on Chrome.
No, it computes a 4 byte hash of the URL (domain?) and if this matches a local DB entry then it asks google for all malicious URLs with that hash (explained in the link of parent).
Depending how many entries there are your browser contacts google fairly frequently and then google using techniques mentioned in the article can link your TLS-Cookie to your IP.
It’s as good as sending the actual URL, and possibly even the full path to the document you requested, if the browser has previously asked Google for another site and Google has seen a pattern of browsing from Site A to Site B in browsers not using this “security” feature.
Due to the birthday paradox collisions happen much earlier.
So on average you get a hit for 1 in thousands URLs. For each hit you query google for the malicious sites with the actual hash. It does feel like some information could leak but at the same time there are literally hundreds of possible URLs that map to each hash value. So there is plausible deniability as well.
Again, combined with more information this could be exploited. But probably there are easier attack vectors.
You issue quest on hash A then hash B. Google guesses that because of other activity it has seen today, visits to a site marked by hash A followed by visits to site marked hash B means you are following a link from Alex Jones’ blog to a flat earth holocaust denial web site, and thus prepares to serve your IP address ads for tin foil hats and prepper magazines.
The chances of your traffic pattern of hash A then hash B colliding with, say, my browsing of the MLP fan club and following a link to cosplay photos from Dragon Con are pretty slim, even though the MLP fan club URL hash collided with the Alex Jones blog hash.
Google aren’t just looking at the one thing you viewed, they are following you everywhere.
Is it? Typically these shady sites would be the ones I'd most like to keep private.
also why does it collect client ID at all and also "should uniquely identify a client implementation, not an individual user" doesn't sound a lot like "can't identify an individual user" ... especially in a home user context.
Ideally Firefox wouldn’t rely on contacting any third parties in their default browser configuration.
And a browser that doesn't contact third parties isn't much of a browser.
https://news.ycombinator.com/item?id=17930752
I am looking for responses.
E.g.: https://github.com/jackspirou/clientjs/blob/master/README.md https://github.com/Valve/fingerprintjs/blob/master/README.md
Is that just an unsubstantial accusation or do you have a source for that?
So I'm going to go on a limb and say you are probably wrong.
When you visit a website hosted on AWS, your IP and browser fingerprint are all sent to AWS's servers, that is why they can track you. Whether or not they really track you is another thing.
Also remember using free Google dns 8.8.8.8 is not that free they track your dns requests.