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.

How are these people not in prison?

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!

My own NES emulator is on Codeberg, but there are well over a dozen emulators on GitHub. Start here:

- LIJI32/SameBoy (Game Boy)
- TASEmulators/fceux (NES)
- mgba-emu/mgba (Game Boy, Game Boy Advance)
- nesdev-org/MesenCE (NES, Super NES, Game Boy, Game Boy Advance, PC Engine, Master System/Game Gear, WonderSwan)
- jsgroth/jgenesis (Mega Drive/Mega CD, Super NES, Master System/Game Gear)
- dolphin-emu/dolphin (GameCube, Wii)
- stenzek/duckstation (PlayStation)
- ares-emulator/ares (numerous)
- Dwedit/PocketNES (PocketNES on Game Boy Advance)
- FluBBaOfWard/NitroSwan (WonderSwan on Nintendo DS)
- FluBBaOfWard/NGPDS (Neo Geo Pocket on Nintendo DS)
- FluBBaOfWard/NitroGrafx (PC Engine on Nintendo DS)

Which emulator of a 20+-year-old console did you see deleted from GitHub, unless it included ROMs or system software copied without permission?

The problem is that a lot of home ISPs don't let their customers port forward because there just aren't enough IPv4 addresses to go around, and I'd bet a lot of your audience are behind ISPs that don't provide IPv6 (such as Frontier fiber). When an ISP is using carrier-grade network address translation (CGNAT) to put an entire neighborhood behind a single IPv4 address, how would the ISP's router know to which customer to direct a TCP SYN packet received at that address? I guess each Forgejo instance operator could pay per month for some sort of proxy service using a reverse SSH tunnel.

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 :)

If you're using your Google Account to sync your TOTP keys across devices using Google's Authenticator app, you need some way to sign in to Google for that.

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.

If you want "as dumb as possible", the search keyword for that is "static site generator". Then you can redirect /wp-admin/ to Automattic's front page.

People still develop new games for the Master System (which uses a Z80), the Genesis (which uses a Z80 as a sound coprocessor), and especially the Game Boy (whose Sharp SM83 CPU isn't exactly a Z80 but is similar). And they're selling these games both as ROM filess on itch.io and as cartridges.