Exactly. Even if you enable "privacy addresses", you'll be disappointed to find that they only rotate every 24 hours by default, so all your incognito tab browsing can be trivially linked back to you, if they're done in the same day as your regular browsing.
>You already said the word "default". One can simply adjust the rotation time to 600 seconds or even shorter.
1. setting it to short intervals eventually causes issues, because it fills up your router's routing tables and eventually causes it to crash.
2. Having a short rotation period doesn't help because people typically don't time their incognito tab usages to when the privacy IP rotates. Moreover if you have any apps/tabs in the background that are logged in (eg. gmail), it can track your new privacy addresses as they're being rotated. The only way to fix this is to somehow integrate privacy addresses into the browser itself (ie. having separate privacy addresses for regular/incognito browsing), but that doesn't seem like it's going to happen any time soon.
>The control is in _your_ hands. Unlike CGNAT, where the NAT owner is the one making decisions.
You're trying to imply this is a bad thing but it's unclear how the CGNAT owner can sabotage anonymity in this case. You're mixing your browsing with tens or hundreds of other customers. That provides strictly better anonymity compared to privacy addresses that rotate but are shared by every app/tab on a given system.
>setting it to short intervals eventually causes issues, because it fills up your router's routing tables and eventually causes it to crash.
I don't buy this argument at all. The router knows about the /64 prefix only, unless are you talking about the ND cache?
Furthermore, let's say you can fill up your route table somehow. What prevents the same thing from happening to the NAT state tracker?
>Moreover if you have any apps/tabs in the background that are logged in (eg. gmail), it can track your new privacy addresses as they're being rotated.
HTTP cookies are enough for that (tracking sessions). No amount of Layer 3 tricks like CGNAT or IPv6 privacy extension will fix it.
>You're trying to imply this is a bad thing but it's unclear how the CGNAT owner can sabotage anonymity in this case.
I assume you understand CGNAT sessions are logged?
>I don't buy this argument at all. The router knows about the /64 prefix only, unless are you talking about the ND cache?
How does your router know which device to route a specific address? It can't possibly be broadcasting any incoming packet to all devices.
>Furthermore, let's say you can fill up your route table somehow. What prevents the same thing from happening to the NAT state tracker?
NAT has specific logic to handle dead connections. UDP connections typically time out if there's no activity within 2 minutes, and TCP within 10-60 minutes. Under typical usage situations you're unlikely to hit those limits, however consumer routers were known to choke on too many connections, eg. from torrenting. There's no similar mechanism for ipv6 privacy addressees. The closest is a dumb expiration timer (ie. temp_valid_lft), but that means it can only drop addresses without regard for whether it's active or not, causing issues for long lived connections (eg. ssh).
None of these are impossible problems to solve. There's clearly enough computing power on routers to track each and every connection, so it should be possible to implement better tracking of privacy addresses, but that doesn't mean it's happening today. The same applies to browsers using a different address for private browsing. However "it can theoretically be fixed" isn't a valid response to the sad state of ipv6 privacy today. It's entirely reasonable for ivp4 holdouts to refuse ivp6 until these issues are fixed.
>HTTP cookies are enough for that (tracking sessions). No amount of Layer 3 tricks like CGNAT or IPv6 privacy extension will fix it.
This is false. Third party cookie tracking doesn't work on Firefox anymore because they enabled first party isolation by default a few years ago. Chrome is planning to do the same, but regardless users can already opt into it.
>I assume you understand CGNAT sessions are logged?
Irrelevant. If ISPs wants to log your CGNAT sessions, they can also log your ipv6 traffic.
To maintain any kind of project, you need a set of inputs that a human can understand and manipulate to produce desired results, and a build chain that reproducibly produces output from the inputs.
The inputs were traditionally source code, but sure, we could in principle use prompts for an LLM as the primary inputs, which then produces source code that gets fed to the rest of the build chain.
But editing the source code produced by the LLM is a non-starter because then you're editing build artifacts.
In fact, a sabotage manual should include the opposite action for each point. These are not the methods of sabotage, they're the methods of shrouding your sabotage in plausibility. It wouldn't provide you plausible deniability if doing the things on the list was never reasonable.
Yeah you're right, the screw-with-them-shell would have to be strictly a honeypot thing, with a custom-compiled ssh and all the usual guard rails around a honeypot. The password tarpit could stay, though script kiddie tools probably scale well enough now that it's not costing them much of anything.
I'll be boycotting IPv6 for as long as it's possible.