What passkeys can’t overcome is people dismissing the popups asking if they want to switch to passkeys or create them.

I think it’d actually be pretty easy. Just ask:

Trust this device, with biometrics?

Most people will say yes on their Apple/Samsung/Google devices.

It’s been like 25 years since the security world basically moved on from assuming that users could be trusted to act securely. We gotta design processes and protocols that keep things secure even with people who have bad habits.

I can secure my email, but every email I send or receive touches at least one other mailbox I don’t control, of some other user. Same with text messages, social media posts, etc. The digital world we use has a billion overlapping people, some with escalated privileges as employees or admins or mods or whatever. We can’t make them perfect, so we should design systems that work well even with imperfect people.

I think you’re mixing up compromise of an account with compromise of the data associated with that account.

If a particular piece of data is accessible to people of a dozen accounts, compromise of any of those accounts potentially compromises the data. That’s a legitimate concern for people who want certain data secured, whether other accounts with access are also secure. In some cases, it may be best to have an authentication policy that provides a baseline level of protection even for the most clueless users, rather than a system where you’re able to secure your own account.

They don’t need to. It just works to log them in when they’re using one of their own trusted devices. Being able to unlock their phone gives them full access to the services (apps, websites) that are authenticated to that device.

TOTP tokens are often distributed as QR codes, where you can store in more than one place, store/copy/transfer in plaintext between people or places. Compromise of that token gives permanent access to all TOTP codes generated.

I’m not a fan of how most TOTP apps and implementations actually work right now.

I have a secure password manager, offline, nowhere shared, even the passwords are encrypted.

How can the service provider tell, though?

The point of passkeys is to create an authentication flow that is easier for users to keep secure. The question, then, becomes whether a service provider should make user authentication decisions based on the worst case scenario, best case scenario, or average case scenario. Passkeys are a reasonable way to make sure almost all of your users have secure login credentials, even if the best of the best users would have just as secure login credentials with traditional passphrases.

In 2011, Motorola split into two companies, each with rights to the Motorola name and logo.

Motorola Mobility took the business lines related to cell phones. It got bought by Google, and then Lenovo.

Motorola Solutions took the business lines related to everything else, including (and especially) radios for law enforcement, fire departments, militaries, and surveillance video tech.

Yup. My main living data is on a NAS, my on-site backup is an external USB enclosure with a SATA hard drive hooked up to a Mac Mini, all so that I can leverage a Backblaze account to back up the external hard drive with unlimited data.

Yeah if I were starting now I’d be looking at jellyfin. But I paid the lifetime plex pass, and inertia/laziness what it is, so I haven’t found a reason to actually switch yet.

And the other way, too. The whole reason why Android chose Java was because it was, at the time, one of the better languages and runtimes for creating hardware-agnostic software. Now that a software ecosystem is in place, why should Google be able to control what hardware the already-written software runs on?

Ah yeah. Plus apparently Android’s default SELinux configuration blocks this separately, as well.

Android doesn’t have su, which this proof of concept exploit requires. Although rooted Android does, so in theory malware written for rooted Android could escalate to root privileges.

Also, the underlying vulnerabilities might be exploitable without su but I don’t fully understand the AF_ALG and authencesn bug limits things, or what other executables can escalate privileges.

Honestly, this is an easy way to share files with non-technical people in the outside world, too. Just open up a port for that very specific purpose, send the link to your friend, watch the one file get downloaded, and then close the port and turn off the http server.

It’s technically not very secure, so it’s a bad idea to leave that unattended, but you can always encrypt a zip file to send it and let that file level encryption kinda make up for lack of network level encryption. And as a one-off thing, you should close up your firewall/port forwarding when you’re done.

Yeah, if OP has command line access through rsync then the server is already configured to allow remote access over NFS or SMB or SSH or FTP or whatever. Setting up a mounted folder through whatever file browser (including the default Windows Explorer in Windows or Finder in MacOS) over the same protocol should be trivial, and not require any additional server side configuration.

Yeah, I mean I do still use rsync for the stuff that would take a long time, but for one-off file movement I just use a mounted network drive in the normal file browser, including on Windows and MacOS machines.

(the preview fetch is not e2ee afaik)

Technically, it is, but end to end encryption only covers the data between the ends, and not what one of the ends chooses to do with it. If one end of the conversation chooses to log the conversation in an insecure way, the conversation itself might technically be encrypted, but the contents of the conversation can be learned by another. Or if one end simply chooses to forward a message to a new party not part of the original conversation.

The link previews are happening outside of the conversation, and that action can be seen by people like the owner of the website, your ISP, and maybe WhatsApp itself (if configured in that way, not sure if it does).

So end to end isn’t a panacea. You have to understand how it fits into the broader context of security and threat models.

Good writeup.

The use of ephemeral third party accounts to “vouch” for the maintainer seems like one of those things that isn’t easy to catch in the moment (when an account is new, it’s hard to distinguish between a new account that will be used going forward versus an alt account created for just one purpose), but leaves a paper trail for an audit at any given time.

I would think that Western state sponsored hackers would be a little more careful about leaving that trail of crumbs that becomes obvious in an after-the-fact investigation. So that would seem to weigh against Western governments being behind this.

Also, the last bit about all three names seeming like three different systems of Romanization of three different dialects of Chinese is curious. If it is a mistake (and I don’t know enough about Chinese to know whether having three different dialects in the same name is completely implausible), that would seem to suggest that the sponsors behind the attack aren’t that familiar with Chinese names (which weighs against the Chinese government being behind it).

Interesting stuff, lots of unanswered questions still.