The Doctor

Gee. What a shock.

What else is new.

Let’s see here…

Potato Chat - This is the first I’ve heard of it so I can’t speak to it one way or another. A cursory glance suggests that it’s had no security reviews.

Enigma - Same. The privacy policy talks about cloud storage, so there’s that. The following is also in their privacy policy:

A super group can hold up to 100,000 people, and it is not technically suitable for end-to-end encryption. You will get this prompt when you set up a group chat. Our global communication with the server is based on TLS encryption, which prevents your chat data from being eavesdropped or tampered with by others… The server will index the chat data of the super large group so that you can use the complete message search function when the local message is incomplete, and it is only valid for chat participants… we will record the ID, mobile phone number, IP location information, login time and other information of the users we have processed.

So, plaintext abounds. Definite OPSEC problem.

nandbox - No idea, but the service offers a webapp client as a first class citizen to users. This makes me wonder about their security profile.

Telegram - Lol. And I really wish they hadn’t mentioned that hidden API…

Tor - No reason to re-litigate this argument that happens once a year, every year ever since the very beginning. Suffice it to say that it has a threat model that defines what it can and cannot defend against, and attacks that deanonymize users are well known, documented, and uses by law enforcement.

mega.nz - I don’t use it, I haven’t looked into it, so I’m not going to run my mouth (fingers? keyboard?) about it.

Web-based generative AI tools/chatbots - Depending on which ones, there might be checks and traps for stuff like this that could have twigged him.

This bit is doing a lot of heavy lifting in the article: “…created his own public Telegram group to store his CSAM.”

Stop and think about that for a second.

LEOs using what amount to phishing attacks to grab folks looking for CSAM has a long and storied history behind it.

There isn’t a whole lot of grass around here, it’s pretty built up. And they fly over the parts of California that do have grass in private jets.

I’ll just leave this here: https://www.techradar.com/computing/cyber-security/nordvpn-confirms-its-no-logs-claims-for-the-fourth-time-with-security-audit

I use it when I’m on travel. It’s pretty decent, and it wasn’t hard to import the Wireguard configs into Network Mangler.

They remember what happened when they migrated Hotmail to Microsoft Exchange.

That’s pretty well answered here: http://vger.kernel.org/lkml/#s15-3

Maybe that’s why they’re getting so popular.

They’ve been doing this for years.

Seagull consulting has come to marketing, I see.

Ew.

Sometimes the Invisible Hand flips you the Invisible Bird.

for compliance we’d have to get everything re-vetted yearly

Huge pain in the ass to set up, but from the user’s end of things it was pretty easy to do.

Some years ago, I had a client with a really fucked up set of requirements:

• Must run Gentoo Linux. (No, I don’t know why. But it was written into the project specs and everybody who had to sign off did.)
• Must use LUKS for FDE.
• Login (loosely interpreted as “booting up”) must have MFA.

This was during the days when booting into a LUKS encrypted Gentoo install involved copy-and-pasting a shell script out of the Gentoo wiki and adding it to the initrd. I want to say late 2006 or early 2007.

I remember creating a /boot partition, a tiny little LUKS partition (512 megs, at most) after it, and the rest of the drive was the LUKS encrypted root partition. The encrypted root partition had a randomly generated keyfile as its unlocker; it was symmetrically encrypted using gnupg and a passphrase before being stored in the tiny partition. The tiny partition had a passphrase to unlock it. gnupg was in the initrd. I think the workflow went something like this:

• System boots up.
• Script in the initrd prompted the user for the passphrase for the tiny LUKS partition. (first authentication step)
• User entered passphrase.
• Script in the initrd unlocked the tiny partition and prompted the user for the passphrase to decrypt the root partition’s keyfile stored therein.
• User entered the symmetric passphrase for keyfile. (second authentication step_
• Script used the passphrase to decrypt the keyfile to stdout, piped into an evocation of cryptsetup to unlock the root partition.
• /dev/mapper/root mounted, /boot mounted, boot process continued.
• User logged into the box.

I don’t miss those days.

Just like archeologists having to call dildos they find “religious objects,” it all depends on how much you want to risk your reputation and research funding.

Syncthing could do it.

So, it’ll cost them an hour’s worth of revenue in fines.