Hacker News new | past | comments | ask | show | jobs | submit login

Telecom operators have admitted to being able to identify people through CGNAT since at least 2015 https://torrentfreak.com/pirates-can-be-identified-despite-s...

You just have to have the source port as well as IP instead of just the IP (which the MPAA et al surely gather). CGNAT is basically just port-based DHCP; it still has to keep an inventory of what ports are available, practically requiring the ability to tell who was using what port at what time.

Even from a first principle's perspective, if they can't identify subscribers for relatively benign things like piracy, they also can't do it for something like CP. Those logs 100% exist, if only so the telecom has something to turn over when the FBI comes looking for pedophiles.

> One of the tools Wikipedia gives admins to protect pages from vandalism/abuse is ip address blocks and not browser fingerprints: https://en.wikipedia.org/wiki/Wikipedia:Blocking_IP_addresse...

And yet that very tooling will detect if a hard-blocked user tries to log in from a new IP address and block that new IP address. It's almost like IP address blocking doesn't work very well...

You're of course free to do what you want, but it seems naive to me to assume that anyone operating even a moderately popular site isn't browser fingerprinting. Even if the site isn't, CloudFlare will if they use CloudFlare (and I wouldn't be surprised if other CDNs).




Yes, CGNAT can't give you any protection against state actors.

But if you are NOT under criminal investigation, having an IPv6 lets every single server on earth know who you are so they can correlate and profile you. That's happening with or without IPv6 of course, but is much less reliable through CGNAT - and essentially useless through a CGNAT if you have proper fingerprinting/cookie/js/3rd party protection. But if you HAVE IPv6, there is nothing you can do to remain anonymous except e.g. Tor.


My symmetric NAT seemingly assigns a random port for every UDP packet. At least that's what I see from STUN servers.


I got kind of curious how UDP works with CGNAT, and in my travels I found this on the Wikipedia page [1]:

> STUN does not work with symmetric NAT (also known as bi-directional NAT) which is often found in the networks of large companies. Since the IP address of the STUN server is different from that of the endpoint, in the symmetric NAT case, the NAT mapping will be different for the STUN server than for an endpoint. TURN offers better results with symmetric NAT.

Not sure if that's related or if you're even having issues, but figured I'd drop it since I found it.

As for the privacy aspect, are you CGNAT'ed? My understanding is that bidirectional UDP streams generally don't work with CGNAT unless your ISP adds a proxying service that can construct "sessions" out of those packets. E.g. for DNS, you can proxy it across the CGNAT by having the DNS proxy record the transaction ID and the internal IP/port that requested it, and then looking for that txid in UDP packets coming to the DNS relay to forward it.

The solution I usually see for getting UDP across CGNAT is TURN, but then you're making a TCP connection which can be tracked by port easily.

I just can't see any way for an ISP to proxy UDP packets without knowing which subscriber they're going to. It seems like trying to make a router route without any routing tables; I just don't see how your ISP can forward that packet to you without knowing it's going to you.

[1]: https://en.wikipedia.org/wiki/STUN




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: