Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hardware Attestation as Monopoly Enabler

grapheneos.social

Post reply on HN
Print view View original

321–330 of 799 posts

Re: Hardware Attestation as Monopoly Enabler

#321

Post by altairprime »

danaw wrote: post #319
nickburns wrote: post #314

Earlier quoted context omitted.

Friendly advice: please don't capitalize random common nouns like the president does. It's a marker of one's affinity toward precision (among other things).

you're being this pedantic about someone capitalizing "President"?

It’s not a proper noun, and this is HN: pedantry is par. “The president of Xyz” capitalizes the X in Xyz(pn) but not the P in president(n). However, the P in President(pn) is capitalized when it’s a Title suffixed to a Name - but that varies per country by what they title their president-equivalent locally and isn’t always translated, while the concept-slash-role label of ‘president’ in English generally does not (and is often used interchangeably, albeit somewhat wrongly, for ‘monarch’ and other such single-person executive-leader roles). (That we use the same spelling for both title and concept is annoying, as usual :)

Re: Hardware Attestation as Monopoly Enabler

#322

Post by zb3 »

surajrmal wrote: post #143
zb3 wrote: post #24

Earlier quoted context omitted.

It's a different thing if banking/government apps require a device certified for security, and a different thing if this certification certifies that the user's device has Google spyware preinstalled with elevated privileges.. Google doesn't certify devices basing on security, so that kind of attestation should have no place in banking/government apps, otherwise it just enforces the duopoly

It's hard to listen to arguments when everything is so hyperbolic. The stated rationale for attestation for captcha is to ensure there is a human on the other end and not a bot. This requires a system which is not capable of automated input. The other use case is for ensuring that an application is running on a system which protects the app from being tampered with (by the user, malware, or otherwise). While that see…

> It's hard to listen to arguments when everything is so hyperbolic.

The frog is slowly being boiled so that people start to accept things which would be unthinkable in the past. Whoever refuses to bend nowadays sounds hyperbolic or insane, but I'm just using the "absolute temperature" here, you know...

> Neither of these situations are related to any so-called spyware. The fact that Google is involved here had to do with the fact that they are a trusted party for folks to rely on to ensure the desired properties are being met, nothing more.

They're NOT fullfilling that purpose here - read the post, insecure devices with Google Mobile Spyware pass that, while GrapheneOS doesn't. Yes, Google is trusted to ensure these security/ratelimiting properties are met, but instead uses/abuses that trust to ensure their anticompetitive business goals are met. Google is not an independent attestation authority and should not be treated as such, what Google is doing here should be (and most likely already is) illegal.

> Alternatively, Google could trust Graphene and everyone who already trusts Google would inherit such trust.

While far from perfect, that would be better, since we'll then only rely on having their hardware (legitimate business) and not their adware/spyware preinstalled with elevated privileges (illegitimate business, illegal monopoly).

Re: Hardware Attestation as Monopoly Enabler

#323

Post by AnthonyMouse »

danielmarkbruce wrote: post #299
AnthonyMouse wrote: post #269

Earlier quoted context omitted.

> Anything involving trust cements the incumbents or at least creates a force to an outcome of few players. I don't think that's even true, unless you're using "trust" as a synonym for centralization. Suppose you had actual competing app stores. Google doesn't control which ones you use; you can use Google Play or F-Droid or Amazon or all three at once and anyone can make a new one. You could get Android apps through…

You have given a situation where there are a 3 players - a very concentrated market. Give an example with 30 players and think through all the implications for all the actors. You'll quickly realize it's a total disaster. Building broad trust requires scale on some dimension.

How is it in any way a disaster?

Consider how Linux distributions work. Every distribution is distributing variants on the same kernel and utilities, but there are hundreds of distributions and dozens of popular ones each with their own repositories. You can choose whichever you like, and make a different choice than someone else.

Coming in at #31 on DistroWatch is a lightweight distribution called Alpine Linux. It's popular on things like firewalls and VoIP servers but is rarely recommended to ordinary users because that isn't its niche. It doesn't matter that most people haven't heard of it because the people relevant to it have. It's fine for things to have a niche, and the people in that niche are the only ones who need to be familiar with it.

Meanwhile around half of Linux users use Debian derivatives. Debian and Ubuntu are very similar, but their repositories are maintained by different organizations, so even when choosing between two things that are nearly the same, you have different options.

And the distribution is not the only place to get software. Maybe you like a stable distribution in general but you want the bleeding edge drivers for your GPU. You can add the repository for the hardware vendor and still get everything else from the distribution. The vendor doesn't even need to maintain their own full distribution to have enough of a reputation for people to make an informed choice about where they want to get their drivers.

> Building broad trust requires scale on some dimension.

The flaw is in assuming that broad trust is a requirement. Narrow trust is good.

Re: Hardware Attestation as Monopoly Enabler

#324

Post by zb3 »

revolvingthrow wrote: post #83

Is it possible to dual-boot on android? It sounds defeatist but I no longer believe it’s possible to change course - the increasingly authoritarian governments, google and most moneyed interests are all on the same side, so it’s just a matter of when. Being on the palantir-approved google ranch for the few Apps You Need + graphene (or some other alt OS) for everything else would be quite inconvenient, but still bette…

GrapheneOS said that's not possible, but I'd actually want to see some expanded explanation.

TEE attests that the OS is booted with a given AVB key, OS version and the bootloader unlock state..

But I know that vbmeta is per-slot, so I guess the whole chain is.. I also read that if you flash "custom_avb_key", the original AVB key is also permitted..

Could this mean we could theoretically dual-boot while being able to flash the OS manually using fastbootd?

Credential Encrypted userdata would be unaccessible though, I'm not sure if the second OS could mount that partition at all.

But I'd like someone more competent to address all this.

Re: Hardware Attestation as Monopoly Enabler

#325

Post by altairprime »

xinayder wrote: post #160
coppsilgold wrote: post #98

Requiring authorized silicon (and software) isn't even the biggest problem here. They do not use zero knowledge proof systems or blind signatures. So every time you use your device to attest you leave behind something (the attestation packet) that can be used to link the action to your device. They put on a show about how much they care about your privacy by introducing indirection into the process (static device 'ID…

Can we stop normalizing being surveilled online and on our devices? Saying something like "the problem is not hardware attestation, but that they don't use ZKP". You are normalizing the new behavior. You shouldn't. It doesn't matter if they use ZKP or the latest, secure technology for hardware attestation. The issue is hardware attestation. It's the same with age ID. The issue is not that Age ID is prone to data leak…

How should a government act to prohibit misrepresentation of one’s characteristics online, from accessing services for which that government has formally defined regulations based on characteristic into law?

If your answer is “they shouldn’t ever do that”, then you’re promoting an uncompromising position that governments are disinclined to adopt, being the primary user of identity issuance and verification on behalf of their citizens.

If your answer is “they should do that differently”, then you have a discussion about (for example) ZKP or biosigs or etc., such as the thread you’re replying to.

Which of these two paths are you here to discuss? I want to be sure I’ve correctly understood you to be arguing for the former in a thread about the latter.

Re: Hardware Attestation as Monopoly Enabler

#326

Post by Georgelemental »

gyush wrote: post #304

It seems to me that comments here are reading this as saying attestation is bad, when the real argument is that attestation should explicitly provide a path of inclusion for non-Apple and Google providers. The headline seems to make the statement that Apple and Google are evil and doing this for monopoly lock-in, and GrapheneOS, a competitor, will stand for the people against that. But given their final counterpoint…

That is not what GrapheneOS is saying. They mention their exclusion as proof that attestation has nefarious motives, not because they would be OK with it otherwise

Re: Hardware Attestation as Monopoly Enabler

#327

Post by xphos »

lxgr wrote: post #192
xinayder wrote: post #160

Earlier quoted context omitted.

Can we stop normalizing being surveilled online and on our devices? Saying something like "the problem is not hardware attestation, but that they don't use ZKP". You are normalizing the new behavior. You shouldn't. It doesn't matter if they use ZKP or the latest, secure technology for hardware attestation. The issue is hardware attestation. It's the same with age ID. The issue is not that Age ID is prone to data leak…

You're not necessarily being surveiled just because you're forced to authenticate yourself. It often is the case practically, but it's not inherent, and mixing the two up makes the discussion too imprecise in a technical forum. Hardware attestation often also has problems of centralization, but that's something else as well. By just labeling it as an abstract bad thing without seeing nuance, I'm afraid you won't be c…

I think labeling this an abstract problem because all the existing implementations as having concrete but different problems is a little bit of a Motte and Bailey fallacy.

The surveillance of the future will be powered by the things we produce today. If the accepted algorithms leave cookies those cookies will be used tracked and monitized. The bad argument is the forced verification to do things on the internet. Making that start at the hardware is a lock in thats not okay. Business will always own the services and making standards that trade our practical liberty for the sake of security is a very compromised position in my opinion.

And it does start with the age verification, followed by id checks, etc. Its compromising precisely because no lines are drawn and no rights to privacy are codified in law. Without guiderails the worse path will likely be taken for maximum profit

Re: Hardware Attestation as Monopoly Enabler

#328

Post by rahkiin »

acgourley wrote: post #97
kcb wrote: post #69

Earlier quoted context omitted.

Any system mandated by the government will have a backdoor to deanonymize users. Nothing would convince me otherwise.

Let me try anyway (maybe I'm a masochist) First I'll say the government already has an ID system with a backdoor they mandate you use (your federal social security ID and state ID). The backdoor isn't very interesting because anyone with your ID in hand also has it. So how about this: 1. State assigns citizens an ID at birth 2. State allows citizens to submit a public key along with their ID at any time 3. Citizens c…

Whatever clever crypto system you think of: if it needs to work for the general population, it needs to go hand-in-hand with UX.

Say your example: a user generates a pub/priv keypair locally and shares the public one with the government. How does the government know you’re rightfully sending the ID? How does the user know what they are sending? Can the app/website/tool/person at post office they are using to generate+store+send the public key be trusted by the user? How can the government give trust to the user that this tool/person can be trusted?

And there we have attestation again. Or walled app stores, or certification as we have for physical services.

Re: Hardware Attestation as Monopoly Enabler

#329

Post by ethagnawl »

Seems to me like Microsoft might be opposed to this duopoly and have pockets deep enough to fight it, right? For one, this would make their possible re-entry into the mobile space harder and more costly but I guess it'll inevitably become a standard that other providers could fulfill.

Re: Hardware Attestation as Monopoly Enabler

#330

Post by rahkiin »

josephcsible wrote: post #298
dathinab wrote: post #218

Earlier quoted context omitted.

> Why was this decision ever made? because it wasn't made the decision which was made was having a digital ID wallet, that this needs hardware attestation (or something comparable) is somewhat of a direct consequence of existing laws/regulations regarding making IDs forgery safe it also is a phone only application the huge huge majority of phones runs Googled Android/iOS, so you support them if there where a relevant…

> having a digital ID wallet, that this needs hardware attestation (or something comparable) is somewhat of a direct consequence of existing laws/regulations regarding making IDs forgery safe How do you figure? Isn't just having the digital ID be signed by a key belonging to the issuer good enough for that?

I think they are saying the signed ID can be copied to another device. Unless such ID needs to have acces to some TPM that can be trusted, which likely requires then specific trusted hardware and software
Post reply on HN