What this country needs is a good two-dollar red-team AI, that will try to create an exploit based on a submitted bug report and use the exploit to compromise a Mac in the QA lab. If it succeeds, the bug report is definitely genuine and should be prioritized.

I agree that has historically been the case, but OTOH Trump is deteriorating so rapidly (both psychologically and in terms of his level of popular support) that after November's bloodbath (and whatever Trump's unhinged response to that will be), the remaining Republicans may well decide it's in their own interest to get him out of office sooner rather than later.

We've reached the "Pope is selling indulgences" phase of the American government's decent into blatant corruption.

I suppose they could do that, but I don't know what it would accomplish. Telegram is already written and functional; murdering Durov wouldn't uninstall it anywhere. I suppose it might intimidate the next guy who is considering writing a secure messaging app, but I don't think Russia is playing that kind of decades-long game anymore. Their main goal now is short-term: figure out how survive the Ukraine debacle without getting strung up by their own citizenry.

This could have been avoided; instead of erasing the drive, the duress password could have been set to load a "clean" partition with nothing on it that the defendant didn't want the US government to see.

... but Dear Leader will keep us safe from the dangerous and corrupt outside world. Juche!

Just wait until you try to download the bootleg video and end up with a copy of Musk's AI-generated "historically accurate" version instead. D'oh! :)

The key point here is that data's security isn't enforced by the OS, but rather by the encryption algorithm itself. A non-OS forensics terminal would see the raw contents of the hard drive, which is to say, blocks of random-looking bytes that might be encrypted data or might just be truly random; without the corresponding password, there is no way to to tell.

Without any password (and assuming a robust encryption implementation), that's as far as they'd get. With a password, they'd be able to decrypt the blocks associated with that password and view the files for that account, but not any of the other blocks/accounts.

At that point, the FBI's nerds might well suspect that there are other accounts on the phone that they don't know about, but short of coercing the phone's owner into providing additional passwords, that's as far as they could get.

The goal would be to have a device OS with no concept of "correct blocks", i.e. there are only a bunch of blocks, all equally correct, and the OS uses some subset of them based on the password that was entered. Ideally the OS wouldn't even have the ability to tell anyone how many viable subsets there are.

Of course, "more cost-effective than SLS" is a pretty low bar. The actual goal would be "more cost effective than Falcon 9".

To me, it sounds like "well, we thought we had it isolated..."

There's nothing like saying "it can't be done" to make a nerd's imagination fire...

I'd start with a filesystem that stores all data encrypted, so that without the proper decryption key, there's no way to tell whether a given block of storage contains encrypted data or random noise. We'd overwrite the entire drive with random noise on install, of course.

Then on top of that, add a layer that determines which subset of the physical blocks to use based on a hash of the decryption key; so if you log in with password A you get a particular filesystem, but with password B you get a completely different/unrelated filesystem, and so on. Repeat as necessary for as many accounts as you like; all accounts which are equally real/valid; the only downside is additional drive space required.

The tricky bit would be coming up with an algorithm that tells each account which storage-blocks it is allowed to overwrite, but doesn't simultaneously provide a hint to the police that those other not-to-be-written-to blocks might actually contain hidden data rather than just noise. Well, that and the fact that just having this software installed would look suspicious, if they were able to recognize that it was present :)

LLMs have two effects here:

1. They help the white hats find and fix bugs
2. They help the black hats find and exploit bugs

These two effects cancel each other out to some extent (depending on which "team" is more proactive in its bug-discovery and consequent activities).

Eventually all of the low-hanging-fruit will be picked, and the current deluge of AI-induced CVEs will be reduced to only those bugs that were subtle enough not to be noticeable by anyone except the latest-and-greatest AI models.

Here's some example code of a "wrong" program that is 100% valid:

// well-formed code; no compiler will flag an error
int sum_two_numbers(int a, int b)
{
        return a-b;
}