Comment on Google updates Chrome's Incognito Mode disclaimer to admit it is tracking users
heyoni@lemm.ee 10 months ago
I don’t use chrome but this is a whole lot of nothing. It’s basically saying if you save a file or an article to your reading list it’ll still be there…and that remote websites will still stuff your face with cookies and try to track you…but it’s not like they’re giving you a special chrome cookie to link your private and non private browsing. Server side tracking never goes away, not even with Firefox.
Anyways, who cares. Delete chrome and start using Firefox. But again, make sure you delete the files you download in incognito or they’ll still be there. And your ISP can still see which domains you’re going to if you use them as your DNS.
cttttt@lemmy.world 10 months ago
Just so you know, because TLS SNI is not encrypted and not yet universally obfuscated (adoption of this is pretty slow and one of the largest CDN providers had to pause their rollout last I checked), not-even-deep packet inspection can be used to track the sites you visit regardless of your DNS provider or wherever resolution is encrypted.
Also, if a website isn’t fronted by one of the most popular CDN providers in existence, it can be possible to infer the sites you’re visiting based on their server IP addresses.
Although this just shifts where tracking can occur, a VPN is the only reliable way to maybe prevent your ISP from tracking the sites you visit, if this is your desire.
heyoni@lemm.ee 10 months ago
Yep, I’m aware. It’s how that one guy hacked his airplanes wireless, by setting up a certificate with his domain and the airlines and then using that domain + port 443 as an ssh or vpn tunnel.
So TLS rollout is slow because the websites can still be seen with packet inspection? We’re talking about TLS 1.4 right?
cttttt@lemmy.world 10 months ago
I’m not sure if it’s part of a TLS standard yet but I was talking about encrypted SNI (ECH, formerly called ESNI).
Today, early on in a TLS connection, the client actually tells the server, in plain text, the domain name it’s intending to communicate with. The server then presents a response that only the owner of that domain can produce, then keys are exchanged and the connection progresses, encrypted. This was required to allow a single server to serve traffic on multiple domains. Before this, a server on an IP:Port combo could only serve traffic on a single domain.
But because of this, a man in the middle can just read the ClientHello and learn the domain you’re intending to connect to. They can’t intercept any encapsulated data (e.g. at the HTTP level, in the case of web traffic) but they can learn the domains you’re accessing.
ECH promises to make the real ClientHello encrypted by proceeding it with a fake ClientHello. The response will contain enough information to fetch a key that can be used to encrypt the real ClientHello. Only the server will be able to decrypt this.