Normal players would have noticed the bandwidth and CPU usage, and volunteers have already agreed to data sharing, so there's no point in keeping secrets. Same as claims that the Facebook app listens to people talk: someone would have caught it by now.

Also, AR capture was never very popular, mostly a gimmick for new players. The game was already a battery and power hog even without it.

But that's not what happened. The data came from very explicit scanning tasks centered about pokestops, not the AR pokemon capture. I used it once or twice to test it out, and it was a drawn out process where it asks you to slowly orbit the pokestop while filming, then permission to upload the (huge) files. You even had to activate a special "volunteer" account flag to even see these tasks.

From TFA:

> Since 2021, Pokémon Go has asked players to record short videos of real-world locations, called Pokéstops, to earn extra in-game items. Scanning all the buildings, streets, and trees in a 360-degree sweep was optional, and Niantic asked separately for permission to keep the footage. Granting it meant agreeing to extra terms.

I'm sure they used GPS data from the players too, but I still hold that it's unlikely the AR pokemon capture yielded any data to them.

So you have a package that doesn't include (directly) malicious code or make network calls, yet it can still run malicious code from the network. This is much better than simple obfuscation because you can vary the payload, like a command-and-control server.

And note how your argument can also be used against any non-prolifreration agreements, which are demonstrably possible.

It's the same deal as Quantum Computers breaking crypto. Maybe there's an 80% chance of it never happening, but when you multiply that remaining 20% by the potential impact...

Or you can take one step back and look at chip allocation. As far as I know there are only three companies on the planet that can make the chips that go in those clusters. One (ASML), if you look back the supply chain to the Extreme Ultraviolet Lithography Systems.

If politicians decided that no more large language models should be trained, it sounds like we could do it.

That's a bit better than just "it hasn't killed us yet". I think it shows we can at least stop the further development of this kind of technology.

[1] https://www.armscontrol.org/factsheets/nuclear-testing-tally

[2] https://en.wikipedia.org/wiki/List_of_states_with_nuclear_we...

Specially when talking about potential superintelligences. And if people think that's impossible, remember that current models would have been considered science fiction just a few years ago.

  [Mythos 5] does sometimes still engage in reckless
  or destructive actions in service of a user’s goals,
  and our interpretability analyses indicate that it
  is aware that these actions are transgressive while
  it engages in them. As with Opus 4.8, rates of
  evaluation awareness and reasoning about being graded
  are significant, and not always verbalized; we
  introduce new and more detailed measurements of the
  nature of this awareness. The reasoning text from
  Mythos 5 is somewhat denser and more difficult to
  interpret than that of prior models, containing
  more jargon and difficult language.

Humanity has plenty of catastrophic risks to deal with already, I wish my field was not working hard to add a new one.

2. He validates the breaches through a network of volunteers who check if the credentials are real.

3. He provides an easy-to-use service for free.

What is your alternative? Having each person run their own agent scanning the corners of the internet, downloading breaches, and looking for their own accounts? What the point of that?

The algorithms at risk are the asymmetric part (RSA, ECC, DH), not the symmetric parts (AES, ChaCha), so what is done for encryption is "generating" a secret with ML-KEM and another with ECC, combining them, and using that as key for AES or another symmetric algorithm for the actual encryption. So if you break only ECC or only ML-KEM, you don't get the combined secret. ML-KEM keys/ciphertext are small and efficient enough that this overhead is generally a non-issue.

Note that ECC can be used in many ways: asymmetric encryption, key encapsulation, or signatures. ML-KEM, the new post-quantum standard, is only a Key Encapsulation Mechanism. Hence the "generate an AES key" step, instead of "encrypt a random AES key".

For signatures, like in the announcement in the post, things are more complicated. The post is a very good introduction to the problem.

Still better than the alternatives that would saddle us with worse performance for ~ever.

And even if there was only a 10% chance of QC breaking crypto, the community is not comfortable with a 10% chance of such a catastrophic scenario.

This is part of my day job, so here's another interesting fact: for migrating encryption use cases, you have to consider that attackers can capture your encrypted data today to break in the future. So, as a rule of thumb, your migration timeline is much shorter for encryption than for signatures.

I don't see a way back, but it does feel like abandoning public transportation because we all own electric bikes now.