zlacker

>>danShu+(OP)
In case it's not obvious, here is how the attack works:

1. The attacker manufactures a device, such as a smartphone, generates a keypair for it, stores it on an HSM on the device (generally called a "trusted enclave"), and signs the public key of the keypair with a master key

2. The device runs the attacker's software and is designed so that whenever non-attacker software is run with elevated privileges, the HSM is informed of that fact in a way that can't be reset without rebooting (and starting again with the attacker's software). For instance, the device might use a verified boot scheme, send the key the OS is signed with to the HSM in a way that is unchangeable until reboot, and it might employ hardening like having the CPU encrypt RAM or apply an HMAC to RAM

3. The HSM produces signatures of messages that contain statements that the device is running the attacker's software, plus whatever the attacker's software wants to communicate and it won't produce them if it's running software of the user's choice as opposed to the attacker's software as established above. It also includes the signature of its public key with the master keypair, allowing accomplices to check that the device is indeed not under the user's control, but rather under the control of someone they trust to effectively limit the user's freedom

4. Optionally, that attestation is passed through the attacker's servers, which check it and return another attestation signed by themselves, allowing to anonymize the device and apply arbitrary other criteria

5. Conniving third parties can thus use this scheme to ensure that they are interacting with a device running the attacker's software, and thus that the device is restricting the user behavior as the attacker specifies. For instance, it can ensure that the device is running the accomplice's code unmodified, preventing the user from being able to run software of their choice, and it can ensure that the user is using device as desired by the attacker and their accomplices.

This attack is already running against Android smartphone users (orchestrated by Google, in the form of SafetyNet and the Play Integrity API) and iOS smartphone users (orchestrated by Apple) and this extends the attack to the web.

>>devit+fD
Actually it would be useful to present the problem using your framing - in the press, blogs, everywhere. The other side is already bending over backwards to stretch the meaning of words (their introduction about DRM being "the backbone of the open Internet" made me me sick).

>>benter+IO
The framing would work just as well if we substituted for Google a certain not-exactly-friendly-with-the-U.S. regime that also happens to produce a shitload of smartphones. Whatever we don't want them to be able to do to our smartphones, we don't want Google to be able to do, either.

>>kijin+j21
Nobody much cares about Tiktok being run by China despite years of fearmongering about it by powerful elites with the entirety of the mass media at their disposal.

Highly abstract risks just dont seem to register for most people. It was hard enough to get the masses to act in self interest over an existential risk to their health (covid).

I reckon the way to avoid maximum damage from this proposal will be some sort of inoculation - e.g. safe, trusted, easy to use tools that help people work around it. The political angle of attack is worth trying but I think it will fail.

I wish Mozilla worked that angle too - e.g. supporting lineage and microg.