zlacker

So the attacker in this scenario is producing my hardware? That sounds ridiculous, if that were the case they could do anything they want anyways, I see no way in which the scenario you've discussed is materially different from "attacker can literally do anything anyway, they own the hardware".

And this "attacker" gets... what? Nothing. Because this isn't an attacker... it's a device manufacturer. You've described how attestation works except you've described the TPM as an attacker, which is silly.

>>insani+(OP)
That's the point of this framing - it's pitching the device manufacturer as an attacker and Secure Enclave as their sinister fortress inside your device. This is an age-old argument against these systems, but to your point the conspiracy theory crumbles at the edges once you start trying to turn it into a threat model.

>>bri3d+s3
Yeah, I get the point, it's just a terrible framing because, as you said, this threat model is nonsensical.

It's just that this description is describing an "attack" that is just how attestation works. If you have a problem with attestation, talk about that problem, calling it "an attack" does nothing.

I'm actually against the proposal, too - although I see the merits. The ability to have servers authenticate clients based on the context of that client is amazing - it would seriously improve security if done right. But I personally believe that this should be done through the Device Policy extension exclusively, as it is already done there today, and that the extension should be opened and standardized.

In fact, I believe Google should be forced to do so.

>>insani+(OP)
it is becoming impossible to own your hardware. go cloud!

>>BSEdlM+0f
> it is becoming impossible to own your hardware

It sure is not. But I do believe we should have a legal right to own our own hardware, in every sense.

>>insani+rm
I live in a place where legal rights are very different from legal realities, so pardon my snark

>>insani+(OP)
They get a lot more than nothing.

They sell the attack to business partners like Netflix and Spotify.

Effectively, they are selling the end users' liberty (ability to run arbitrary software, including for example, a cracked ad-free version of the Spotify app) to those business partners.

In sales-speak, this is framed as "effective Digital Rights Management", with "Rights" meaning "copyright enforcement". Critically, DRM is not a viable methodology until you provide it this attack surface.

It's also worth noting that YouTube is one of those business partners, and both Android and YouTube are owned by the same corporation: Alphabet.

>>thomas+uU1
> They get a lot more than nothing.

Relative to their current position of already owning the hardware?

> They sell the attack to business partners like Netflix and Spotify.

I don't see how they're "selling" anything. Web Integrity requires no money to change hands. If implemented, Netflix + Spotify would owe Google nothing.

>>insani+eY1
> I don't see how they're "selling" anything. Web Integrity requires no money to change hands.

DRM is the tool that guarantees money will change hands. Without it, there is nothing but a social (legal) threat to prevent people copying and distributing copyrighted content for free.

Forcing users to run the DRM-infected version of an app creates an incentive for Netflix and Spotify to participate on the Android platform; which in turn strengthens Android's position, and the Google Play Store as a market.

This incentive goes both ways for YouTube, because it is owned by Alphabet.

> If implemented, Netflix + Spotify would owe Google nothing.

Yes, but that's not the point. Google wants Netflix and Spotify to have Android apps. Netflix and Spotify want DRM infecting their apps. Without this system in place, users can disinfect the Spotify app, and listen to music without paying Spotify money (or watching ads to pay them indirectly).

Without providing the environment for functional DRM, Netflix and Spotify can simply refuse to make Android apps. That would be a pretty weak threat, except that YouTube wants the same thing; and that incentivizes Android to play ball.

>>thomas+HL4
> Google wants Netflix and Spotify to have Android apps.

Those apps already exist. Don't you think that kind of undermines your entire point?

>>insani+gT4
No, they can still threaten to remove them, which I'm sure they have already.