We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it.
-
Murena and iodé are extremely hostile towards GrapheneOS. They've spent years misleading people about it with inaccurate claims to promote their insecure products. We'll never work with them. Volla, Murena and iodé should have no say in which OS people can use on their devices.
@GrapheneOS and what exactly is your conflict with volla. I get the iodé and Murena part, but what's wrong with Volla?
-
We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it. Companies selling phones should not be deciding which operating systems people are allowed to use for apps.
@GrapheneOS Yes, we don't need a Play Integrity API under another name.
-
@GrapheneOS and what exactly is your conflict with volla. I get the iodé and Murena part, but what's wrong with Volla?
If I had to guess than locked bootloader or something similar.
-
@GrapheneOS and what exactly is your conflict with volla. I get the iodé and Murena part, but what's wrong with Volla?
@ftm Murena and iodé relentlessly spread false claims about GrapheneOS and our team. That includes personall targeting our team with absolutely vile bullying and harassment.
Here's the founder and CEO of /e/ and Murena linking to content from a neo-nazi conspiracy site targeting our founder with blatant fabrications including links to harassment content from Kiwi Farms users:
https://archive.is/SWXPJ
https://archive.is/n4yTOVolla is fully aware of all this but works closely with these groups.
-
@ftm Murena and iodé relentlessly spread false claims about GrapheneOS and our team. That includes personall targeting our team with absolutely vile bullying and harassment.
Here's the founder and CEO of /e/ and Murena linking to content from a neo-nazi conspiracy site targeting our founder with blatant fabrications including links to harassment content from Kiwi Farms users:
https://archive.is/SWXPJ
https://archive.is/n4yTOVolla is fully aware of all this but works closely with these groups.
@ftm Their Unified Attestation system is a proposal to ban people from using GrapheneOS while permitting using insecure operating systems from the companies working with them. Why wouldn't we have an issue with that? Even if they did give in and permit using GrapheneOS, we don't want these systems to exist. Hardware attestation should be used to protect users rather than determining OS compatibility in a way that has nothing to do with security. Banning using an OS based on this is wrong.
-
We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it. Companies selling phones should not be deciding which operating systems people are allowed to use for apps.
@GrapheneOS Go FULL BLAST with Motorola folks
-
We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it. Companies selling phones should not be deciding which operating systems people are allowed to use for apps.
@GrapheneOS what the fuck. that is absolutely horrifying
remote attestation is a technology that has no good uses. it's just drm
everyone should have the freedom to run whatever they want on their own devices. this freedom should never be taken away and it should be enshrined in law that it can never be taken away
someone else should not be able to decide whether my device is "secure" enough for their purposes. this is reverse security. the os needs to boot securely and the attestation chain should go upwards, with each stage verifying the ones on top of it. not this opposite world bullshit -
@GrapheneOS what the fuck. that is absolutely horrifying
remote attestation is a technology that has no good uses. it's just drm
everyone should have the freedom to run whatever they want on their own devices. this freedom should never be taken away and it should be enshrined in law that it can never be taken away
someone else should not be able to decide whether my device is "secure" enough for their purposes. this is reverse security. the os needs to boot securely and the attestation chain should go upwards, with each stage verifying the ones on top of it. not this opposite world bullshit@GrapheneOS apps should not even have the privilege to check these things. it's a complete violation of a security boundary
-
Play Integrity API should be regulated out of existence rather than making another system where companies permit their own products while disallowing others. It shouldn't be legal when Google does it and it shouldn't be legal when Volla and Murena do it either. This is wrong.
@GrapheneOS people who are buying these phone execute a form of digital self-imprisoning.
Why are these walled gardens so attractive?
-
@GrapheneOS what the fuck. that is absolutely horrifying
remote attestation is a technology that has no good uses. it's just drm
everyone should have the freedom to run whatever they want on their own devices. this freedom should never be taken away and it should be enshrined in law that it can never be taken away
someone else should not be able to decide whether my device is "secure" enough for their purposes. this is reverse security. the os needs to boot securely and the attestation chain should go upwards, with each stage verifying the ones on top of it. not this opposite world bullshit@lumi Android's hardware-based attestation API would not cause these issues if it only had the pinning-based attestation we use as the basis for Auditor and omitted root-based attestation. The issue is having attestation roots which determine which hardware and operating systems are valid. Hardware-based attestation can be provided without any centralized authority determining which hardware and software is valid. It would still provide nearly all of what our Auditor app uses without roots.
-
@lumi Android's hardware-based attestation API would not cause these issues if it only had the pinning-based attestation we use as the basis for Auditor and omitted root-based attestation. The issue is having attestation roots which determine which hardware and operating systems are valid. Hardware-based attestation can be provided without any centralized authority determining which hardware and software is valid. It would still provide nearly all of what our Auditor app uses without roots.
@lumi We support hardware-based attestation based on pinning for protecting users against attacks. Root-based attestation has extremely weak security due to depending on the entire ecosystem of devices not having vulnerabilities enabling leaking keys chaining up to the root. Pinning-based attestation can be used as a very strong security feature. Check out our Auditor app. It does use the root-based attestation for first verification but it would provide most of what it does without it.
-
@GrapheneOS apps should not even have the privilege to check these things. it's a complete violation of a security boundary
@lumi Apps should be able to use pinning-based attestation but root-based attestation as it exists today is inherently anti-competitive and anti-security. It locks people into using less secure hardware and software. The approaches should be differentiated. Any device can provide pinning-based attestation support including software emulation of it if they don't support the security features. Apps can use it with no loss of choice or privacy. Attestation roots are the abusive part.
-
@lumi We support hardware-based attestation based on pinning for protecting users against attacks. Root-based attestation has extremely weak security due to depending on the entire ecosystem of devices not having vulnerabilities enabling leaking keys chaining up to the root. Pinning-based attestation can be used as a very strong security feature. Check out our Auditor app. It does use the root-based attestation for first verification but it would provide most of what it does without it.
@GrapheneOS does this mean, if i build grapheneos myself and flash it on my device, i could still run all these applications?
and i mean without contacting any third party or anything like that
edit: woops. replied to the wrong post. was meaning to reply to the latest one. sorry -
@lumi Apps should be able to use pinning-based attestation but root-based attestation as it exists today is inherently anti-competitive and anti-security. It locks people into using less secure hardware and software. The approaches should be differentiated. Any device can provide pinning-based attestation support including software emulation of it if they don't support the security features. Apps can use it with no loss of choice or privacy. Attestation roots are the abusive part.
@lumi Root-based attestation is can be used to bootstrap pinning-based approach to bootstrap initial trust in a weak way that's vulnerable to leaked keys and trusts a bunch of different parties which is what we do in our Auditor app. The real security model it uses is a Trust On First Use model to provide secure attestation going forward. The problem is Google or this new group declaring themselves as arbiters of what's allowed and using a root CA to allow only business partners.
-
@GrapheneOS does this mean, if i build grapheneos myself and flash it on my device, i could still run all these applications?
and i mean without contacting any third party or anything like that
edit: woops. replied to the wrong post. was meaning to reply to the latest one. sorry@lumi GrapheneOS supports the Android hardware-based attestation API. The API itself is a neutral approach which can support arbitrary roots of trust, non-stock operating systems verified based on verified boot key fingerprint and also has pinning-based attestation based on a proposal we made to Google before they stopped collaborating with us. Pinning-based attestation can be used with or without chaining up to a root for bootstrapping trust. It could exist without root-based attestation.
-
@lumi GrapheneOS supports the Android hardware-based attestation API. The API itself is a neutral approach which can support arbitrary roots of trust, non-stock operating systems verified based on verified boot key fingerprint and also has pinning-based attestation based on a proposal we made to Google before they stopped collaborating with us. Pinning-based attestation can be used with or without chaining up to a root for bootstrapping trust. It could exist without root-based attestation.
@lumi The problem with the Android attestation API is that the documentation and libraries treat Google as the only root of trust and it's also inherently biased towards stock operating systems since it can verify those by simply checking for the green state instead of needing to allowlist keys for the yellow state. Even if apps used hardware-based attestation instead of the Play Integrity API, many wouldn't permit GrapheneOS and they'd still be limiting what people can use if they did allow it.
-
@lumi GrapheneOS supports the Android hardware-based attestation API. The API itself is a neutral approach which can support arbitrary roots of trust, non-stock operating systems verified based on verified boot key fingerprint and also has pinning-based attestation based on a proposal we made to Google before they stopped collaborating with us. Pinning-based attestation can be used with or without chaining up to a root for bootstrapping trust. It could exist without root-based attestation.
@GrapheneOS so, if i built my own aosp rom, or decide to use an emulator run an aosp rom (for compat reasons, not security), could i pin my own certificates, to make (unmodified) apps work on my device without complaining?
-
@GrapheneOS so, if i built my own aosp rom, or decide to use an emulator run an aosp rom (for compat reasons, not security), could i pin my own certificates, to make (unmodified) apps work on my device without complaining?
@lumi Apps don't use the hardware-based attestation API directly in practice by rather using a service like the Play Integrity API choosing what's allowed. Unified Attestation is a group which wants to use hardware-based attestation to choose what's allowed themselves. We don't think hardware-based attestation should be used to choose which operating systems are allowed and also don't agree with this specific group of companies selling insecure products adding vendor lock-in for themselves.
-
@lumi The problem with the Android attestation API is that the documentation and libraries treat Google as the only root of trust and it's also inherently biased towards stock operating systems since it can verify those by simply checking for the green state instead of needing to allowlist keys for the yellow state. Even if apps used hardware-based attestation instead of the Play Integrity API, many wouldn't permit GrapheneOS and they'd still be limiting what people can use if they did allow it.
@GrapheneOS i think it is fundamentally wrong that the app gets to decide what it runs on. it should not have this authority as it is completely backwards
if i wanted to run the most insecure system, i should still be able to run whatever apps i want, as long as all the apis are implemented
of course i don't want to run an insecure system. but it's my device so i should be able to do whatever i want -
@GrapheneOS i think it is fundamentally wrong that the app gets to decide what it runs on. it should not have this authority as it is completely backwards
if i wanted to run the most insecure system, i should still be able to run whatever apps i want, as long as all the apis are implemented
of course i don't want to run an insecure system. but it's my device so i should be able to do whatever i want@lumi Apps wouldn't be able to disallow using operating systems via the hardware attestation API if it only supported pinning-based security and didn't have support for chaining up to a root. It's chaining up to a root which enables trusting only Google's root or specific roots permitted for specific alternate hardware. Similarly, there's the fact that they differentiate green and yellow where green trusts every OS approved by the root CA party vs. yellow requiring allowlisting fingerprints.
