Maybe my tinfoil hat is on too tight, but I always thought it was interesting that Graphene OS places so much blind trust in a proprietary black box security chip from Google that they pinky-promised to open source but never did.

▲

TheCraiggers 2 days ago | parent | next [-]

Because they are a software project. When you're only concerning yourself with software, you have to pick some hardware and move on.

Going down the rabbit hole of secure hardware leads you down a slippery slope of eventually needing to create your own chips. And that's basically impossible these days for anybody smaller than Google or Samsung. So you do some research, pick the best you can, and hope for the best.

Perfect is the enemy of good.

▲

JacobThreeThree 2 days ago | parent | prev | next [-]

You're worried about Google hardware but your requirement for a phone is that it must have Google Pay? Bizarre.

▲

transpute 2 days ago | parent | prev | next [-]

OpenTitan has open silicon (RISC-V) and is capable of open firmware (based on Rust TockOS) and is coming to 2025 Chromebooks, https://news.ycombinator.com/item?id=44416304. Hopefully a derivative of OpenTitan will ship in future Pixel devices.

Google Pixel hardware provides nested virtualization, enabling a Debian Arm "Linux Terminal" in pKVM/AVF VM, with use of Debian package repos.

▲

sigmar 2 days ago | parent | prev | next [-]

Are you referring to the titan M2? why do you describe Graphene OS putting "so much blind trust in" it? I don't think they put much trust in it besides using it for storing keys and for their "Auditor" app

	▲	TheCraiggers 2 days ago \| parent \| next [-]
		> I don't think they put much trust in it besides using it for storing keys Ummm. Was this sarcasm that went over my head? Because if not, I have a hard time thinking of anything that requires as much trust as your private key storage.
	▲	2 days ago \| parent \| prev [-]
		[deleted]

▲

bjackman 2 days ago | parent | prev | next [-]

If you think the org that produced the hardware might have backdoored it, architecting your software to avoid the TPM or whatever is dumb. Targeting Google HW at all is an unavoidable act of complete trust so you might as well use the HW properly.

Also, why would Google bother backdooring their special HW when 99.999% of its users are anyway gonna be running a totally Google-controlled proprietary SW stack?

▲

perching_aix 2 days ago | parent [-]

> Targeting Google HW at all is an unavoidable act of complete trust

Doesn't the existence of FHE downgrade that to just "complete practical trust" at least? Not that I know of it being employed, but that it could be, and that it may be worth shouting out exactly cause of how niche and impractical it is.

	▲	bjackman 2 days ago \| parent [-]
		We are talking about hardware here so ultimately you need to trust some manufacturer, software algorithms don't help. With SEV-SNP and Intel TDX I think it's possible to build a hardware platform that doesn't require the user to trust the OEM although they still need to trust at least one large American tech company that controls the root of trust. But I don't think this is ever gonna happen for consumer devices. AFAIK it's only sorta kinda happened for any real-world platforms at all (but maybe someone can correct me). Ultimately if your threat model includes Google as a potential adversary, and you are not in control of nuclear weapons, you are gonna have to make some serious sacrifices to achieve security IMO. Smartphones are out. (Actually, I guess if you trust China you have a way forward).

▲

XMPPwocky 2 days ago | parent | prev | next [-]

How is it a black box? You can get the firmware trivially.

▲

2 days ago | parent | prev [-]

[deleted]