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.
Dual booting would be much further from passing attestation checks and would be incompatible with a bunch of the hardware-based security features. The boot slots are needed for A/B updates and include the firmware partitions. They're not useful for this and don't provide useful functionality for it. It would be entirely possible to build a bootloader for loading multiple different operating systems but it would be a hacked together mess without proper firmware updates or security. It would require heavily modifying both GrapheneOS and the stock OS to fit them into it. It would require losing a lot of the hardware-based security integration. What would be the point? The end result would be much further from passing attestation checks than GrapheneOS. GrapheneOS has near perfect app compatibility with the exception of the Play Integrity API. Other anti-tampering checks are largely compatible with GrapheneOS with the exception of tripping from certain hardening features which is increasingly being resolved with workarounds and there are toggles to avoid it already.
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 seems to run counter to the preferences of the hn userbase, it is a legitimate desire from an application developer.
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. In theory it should be possible for other parties to provide similar attestation, but that party needs to be deeply involved in the OS and boot chain. Apple is obviously capable and is equally trusted. Graphene probably provides the necessary properties but lacks a good way to attest due to the reliance on Google specific attestation APIs. That could be remedied. Otherwise Graphene would need to create their own APIs and applications would need to use them, which would be a harder sell. In both cases the party asking for the attestation needs to decide to trust Graphene, which is still a barrier, but that's an easier way forward. Alternatively, Google could trust Graphene and everyone who already trusts Google would inherit such trust.
> it is a legitimate desire from an application developer
I want a pony! A legitimate desire. So it's okay if I rifle through your underwear drawer in case there are any ponies I could take?
Requiring there be a physical phone is a speedbump at best ( https://i.dailymail.co.uk/i/pix/2017/05/12/13/403C0D44000005... ) and so de-anonymizing every person using the internet by attaching them to a device and allowing google to track them is not sufficient, nor is the privacy loss necessary for the kind of improvement they could realistically hope to achieve.
But most over even if the panopticon were highly effective and even if were the only option to achieve that end we should still reject it because it's wrong.
> 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).
"AI safeguards" are not working I guess.. or maybe they're only working against those who'd like to secure their software.. good job Anthropic + OpenAI!
The AI safeguards are indeed a joke, you can get around their classifier by simply masking out all the unsafe words and it will happily work on your rootkit.
I don't see a problem with supporting their legitimate hardware or cloud business models. But of course I see a problem supporting their illegitimate adware and spyware business models.
We all agree. But what's the solution? We know 99% of the users don't care. So, the only pressure point is phone manufacturers. I don't have any power to influence anybody significant in this space. I feel helpless.
For me, it's litigation, because the nature of GMS and Play Integrity is highly anticompetitive and these shouldn't even be legal (and most likely already aren't)..
See, mobile phone vendors have their hands tied - they can offer bootloader unlocking, but they can't touch Google spyware, otherwise they won't be "certified", won't be able to use Google Play or even the name Android.. That's of course not enough for Google, they also want to go after users which of such systems / modified systems (with unlocked bootloader) - that's what "Play Integrity" is about, they work hard to make sure the phone gets as useless as possible.. Together those two basically prevent vendors from making the mobile privacy landscape any better.
In the EU, we should outlaw Play Integrity first, by mandating that security level attestation might only be done in a way there's an independent auditing body that might certify alternative operating systems (these could use standard Android attestation) based on objective security criteria, not the Google spyware criteria. I heard about the "UnifiedAttestation" initiative but I'm not sure what's the progress on that.. not that I'm a fan of attestation at all, but you need to understand that it's a different thing when you attest the security model of the system, and a different thing where a system being "secure" actually implies Google spyware must be installed. For banking apps, I'd just want a secure OS, like GrapheneOS - without GMS.
Howver, the main antitrust investigation should happen in the US, only US courts can bring relevant Google executives to justice.
I don't think it's going to be a savior... the same things that make Android hard to modify can happen just as easily when GNU/Linux phones become popular.
Well one way would be just like how Android phone manufacturers are doing it now... with locked bootloaders and binary blobs. Even current GNU/Linux phones still largely need blobs to work properly.
This is misleading. The blobs are only in the firmware, not in the OS, not in the bootloader, not running on the CPU.
Having a technical possibility to lock down GNU/Linux phones in principle in undefined future by undefined entity that doesn't even produce them yet is a FUD argument.
Oh wait they released "Liberty Phone" - still low end(!), this time with absurdly high price.. You can get true linux phone 10x cheaper by buying something that supports PostmarketOS
Your post sounds like you're trying to spread FUD.
Librem says the Liberty phone is the same, it just costs more because it is assembled in the U.S. for people, companies, or governments that don't want it intercepted and modified by a bad actor.
I don't know which activity you're referring to, but why are you trying to discriminate between humans and bots? Because bots don't pay? So demand payment.. Demand like payment per account creation, then set appropriate rate limits per account.
reply