> a) trivial to bypass by adding dither to the test transactions and
I know someone who worked in fraud detection of financial transactions. He told me that indeed lots of filters that are applied mostly test for anomalies. The thing is that most criminals are not insanely smart, and commonly don't have a lot of inside knowledge about accounting, banking, finance system etc., so criminals often have a bad intuition about more subtle things that are looked at for fraud detection.
But if you are a very dedicated criminal with lots of inside knowledge about, say, accounting, banking, finance system, ..., you could likely outsmart these filters. But these people typically have much better career options (even if they want a career as a "big fish criminal": just look at the history of accounting scandals, stock manipulations, Ponzi schemes, ...).
I would say writing it myself is more enjoyable (in some cases). But I quite understand that I am not paid to enjoy myself. I'd say it's quicker getting AI to do it and reviewing. I believe the outcome is no worse on average. So yes, that's my chosen approach.
Similarly, if you are a random person being alive, it likely means that the world population is near its peak and extinction is at hand, or at least the start of a permanent decline.
We have at least global warming and impending WW3, so that line of reasoning seems to work.
No, because I don't keep a list of every article I've read over the past decade or so, but there were multiple busts where a regular law enforcement agency (FBI and their international counterparts) were able to prove the identity of a user simply by timing attacks.
The fact that Tor does not intend to tackle the timing problem is plainly stated on the Tor website.
I was also curious about a source for this but if you just mean the common knowledge that...
> Tor does not intend to tackle the timing problem [as] plainly stated on the Tor website.
then that's not how I read the above claim about Tor "having been deanonymized". Yes, yes, it strictly fits within the meaning of what you wrote, but it's like saying bread has been made free before because someone found a place where they could plant wheat seeds and chop trees to bake it without having to pay for using the ground and wood: there is a roundabout way of getting there but it's not true in the common case (you can't just do this for everyone at will)
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.
reply