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;
}

Is it faster? It sounds really tedious and error-prone to me. If someone were to suggest I quit writing code and instead spend the rest of my career supervising the intern as he writes code for me to review and correct, I'd feel the same way about that.

I love scapegoating individual developers as much as the next guy, but if you take a look at the Win32 API, you'll find loads of fun "features" such as:

- Every single function that takes a string has two implementations: one that ends with the letter A (and takes its strings as ASCII) and one that ends with the letter W (and takes its strings as UCS-16). And then it has a preprocessor-define (with no suffix) that gets expanded to either one implementation or the other, based on your compiler settings.

- windows.h defines preprocessor-tokens for min() and max(), which means any C++ program that ever calls std::min() or std::max() will error out with a very strange compile-time error, if it included windows.h first; the work-around is to define NOMINMAX first to prevent windows.h from polluting the namespace.

- Modern windows is perfectly capable of arbitrary-length file-paths, but ships by default with a 260-character filepath limit anyway, "to preserve backwards compatibility with older software that expects that limitation to be enforced". To get correct behavior you have to hand-modify your registry; otherwise you find out about this limitation when you go to unzip a .zip file and the unzip mysteriously fails even though the .zip file is valid.

These are all defects that other OS's simply don't suffer from, either because the other OS's were designed correctly from the beginning, or because the people in charge of the other OS's long ago took the hit (in short-term breakage) and fixed the problems rather than letting them linger forever to preserve backwards compatibility.

All Windows developers (good and bad) have to deal with these issues, probably forever, and every line of code they add to work around these problems has to be supported and debugged and tested as well, hence the damage compounds.

Before Trump, it was a cultural norm that a President of the United States was expected to follow ethical and moral guidelines as well as laws; not only because anything less would be dishonorable and a disservice to his country, but also because otherwise he would pay a steep political price for his unethical behavior. Trump's most significant political innovation has taken the form of figuring out how to convince a plurality of the American public that the only real standard for Presidential behavior is "whatever you can get away with".

Imagine it's ten years from now, and for $199 anyone can buy an in-home UPS from Home Depot with enough capacity to keep their lights on and their ice cream frozen for 48 hours. Once most houses have one of those, most power outages become more of a minor nuisance than a significant problem.