Comment by teravor
4 hours ago
giving the option to completely block attestation and DRM API would be a good start.
> hardware attestation, which is not fingerprinting
this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.
the DRM situation is even worse as ANY app can fingerprint your device serial and I don't mean just the DRM ID. anyone who has a license server certificate can fingerprint the DRM key in-silicon.
if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos. how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?
The amount of work that goes into tracking you is insane
It's not accurate, see https://news.ycombinator.com/item?id=48767176.
Thank you for everything you all do. I recently installed graphene for the first time two weeks ago. :)
> giving the option to completely block attestation and DRM API would be a good start.
Blocking access to attestation or DRM will prevent using the functionality of the app depending on it or the whole app unless it's implemented incorrectly.
GrapheneOS does provide a toggle to block apps using the Play Integrity API because we found a small subset of apps using it are not yet enforcing providing a result due to being in the process of phasing it in. This doesn't apply to DRM or direct use of hardware attestation. We have a planned feature for blocking access to DRM as an attack surface reduction feature since it can eliminate a little bit of OS attack surface and a significant part of the TrustZone attack surface. Hardware key attestation has almost no attack surface and doesn't provide any info not available other ways.
> this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.
That's not how the hardware key attestation system works. Only key provisioning uses their service and if you don't trust their separation of the provisioning with the frontend, that's fine since we run it through our own frontend by default so they can't connect an IP with the provisioned key which would be the only real privacy issue. That's why they made a point of how they separated the systems for it, but you don't have to trust that on GrapheneOS. If you use a VPN it's irrelevant.
> the DRM situation is even worse as ANY app can fingerprint your device serial and I don't mean just the DRM ID. anyone who has a license server certificate can fingerprint the DRM key in-silicon.
That's not an accurate description. It's also implemented via our server by default too. If you use a VPN that's not relevant.
The MediaDRM ID is also widely misunderstood since it is scoped per-app rather than being global. The best way to address it is our planned DRM toggle.
> if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos
We disabled DRM provisioning and usage by default in Vanadium years ago and have a publicly visible feature planned for providing a toggle for native apps being able to use it. We don't have unlimited resources to get everything we want quickly implemented.
> how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?
You're making attestation and DRM key provisioning sound far worse than it is. It's not fingerprinting and it doesn't give them another way to track users in practice. If services want to share data with Google then they don't need any of this to do it and it doesn't inherently result in anything being shared with them that's in any way useful. We have a planned feature for providing a DRM toggle but it's nearly entirely wanted for security, not privacy, and there are bigger security features to implement. There are many planned privacy features which would make a major impact rather than near zero as this would.
Preventing fingerprinting by websites is a very hard problem especially considering things like using timing and performance measurements for it. That's going to be a priority for us. Doing it for native apps would require a massive amount of changes to get anywhere close to websites. We could add 100 features reducing fingerprinting for native apps without accomplishing anything significant. We're focused on privacy features with a larger impact.
which is what the user would want or be fine with in this case... present the option.
you appear to not know how it works, which doesn't inspire confidence.
both remote attestation packets and DRM license request responses contain a unique hardware identifier that can be extracted with knowledge of the right secret information.
in the case of attestation, privacy CA and the verifier must collude to do this (technically, you need the ephemeral key provisioning packet + attestation packet + secrets). blind signatures were proposed to make this impossible and REJECTED. using a proxy/VPN does not prevent having your unique hardware identifier be attributed to the attestation in this scenario. also note how when you attest to google both the CA and verifier are one and the same...
with DRM I'm not even aware of any effort to not directly expose the KeyBox public key to a license server, and ANY app can make use of DRM API. you do need the license server's private key to extract the identifier however.