5 ms·

The difference is that currently you can lie. You can identify the fingerprinting techniques being used, and work around them. yt-dlp already does something lik

by wzdd 3y ago

The difference is that currently you can lie. You can identify the fingerprinting techniques being used, and work around them. yt-dlp already does something like this, for example. In Android, there was a lot of support for making your rooted / custom ROM system look like stock Android so you could still do banking. Now, depending on the level of Safetynet the app is using, you literally can't. I'm not arguing in favour of fingerprinting, just pointing out that prior to TPM-backed attestation you had control over your own device. With Android Safetynet attestation, you can't work around the problem because the attestation is backed by a root of trust which your custom ROM can't provide. Being able to supply your own thing doesn't matter, because everyone will just support the one that Google supplies. LineageOS is a good example of this; they have their own Safetynet implementation which has very little buy-in. WEI is effectively an extension of Safetynet to the Web. In summary, this is fundamentally different because it takes away your control of your own device.

metalcrow 3y ago
I mean, you can still lie, it's just made more difficult. Unless i'm missing something, running your OS under a hypervisor with a virtual TPM (or a forked browser with TPM access stubs and custom kernel drivers) still allows you to do whatever you want. It's certainly more difficult, and unreasonably so, but it's still quite possible. While i'm not familiar with Safteynet, i'm sure it's also possible to bypass it that way. The issue with this seems to be a sort of a restricting freedom for the greater good idea. If you restrict the ability of web developers to check security values and stuff, then they can't do some good things like improve security, but they also can't do any really bad things like block ad-blockers. But if you allow this access then you get the opposite.
- wzdd 3y ago
  My understanding is that the vendor installs keys in the TPM which can't be retrieved. So no, a virtual TPM wouldn't work, because you don't have the vendor's keys. Or rather, you would be in the same situation as before, because you can install your own keys and then have the challenge of getting third parties to trust you.
  - metalcrow 3y ago
    They'd have to install them before you even get the parts then, right? Otherwise they'll just install them on your virtual tpm. I know apple does that because they own their own chip fabs and have limited (relatively) production runs, but i don't think google is going to manually etch a unique (and it has to be unique otherwise it'll leak) private key into the silicon of every single tpm for mobile and desktop ever. Or are they planning to only allow you to access websites on Google made hardware, and cut out 90% of the world's population?
    - wzdd 3y ago
      Correct, this is what they do. Google requires hardware manufacturers who want to use Play etc to get their stuff signed with their root certificate, which the TPM then verifies. See https://developer.android.com/training/articles/security-key-attestation https://developer.android.com/training/articles/security-key... In particular: """ If the root certificate doesn't contain the public key on this page, there are two likely reasons: [It is from an old version of Android, or] The other likely reason is that the device isn't a Google Play device. In that case, the device maker is free to create their own root and to make whatever claims they like about what the attestation means. Refer to the device maker's documentation. Note that as of this writing Google isn't aware of any device makers who have done this. """ In other words, to get into the Google attestation party you have to get your device Google Play certified. Obviously device manufacturers are strongly incentivised to do this. Edit: If this were to be applied to desktops as well, the obvious approach would be to partner with Microsoft and make use of their trust root, because Microsoft's keys are installed in ~every TPM.
      - metalcrow 3y ago
        Ahhh, ok that makes sense, they're in effect replicating Apple's method then. That does mean this can't really work on desktops atm, due to the low amount of pre-signed TPMs there, so this API is only actually unbreakable for Google and Apple hardware owned mobile devices. Which is already pretty bad, and allows them to boil the frog on desktops! Thank you for the explanation! Edit: I wasn't aware Microsoft was already pre-signing basically all desktop TPMs, that's crazy. Makes sense thinking about it now, especially with Windows 11 requiring it.
charcircuit 3y ago
>In summary, this is fundamentally different because it takes away your control of your own device. No, it allows a business to deny to you if you can't attest to the security of your device. You are still free to do whatever you want on your own device. If a business had an office that required you to unlock a door, but it also had a pickable lock that wouldn't be great security. It allows people to lie about having a badge by letting them pick the lock to get in. If a business increased security by making the lock no longer printable that seems like a good thing to me. >LineageOS is a good example of this; they have their own Safetynet implementation which has very little buy-in. Have they actually approached apps and offered compensation for them to implemented it? Or are they hoping apps just randomly decide to adopt it?
- wzdd 3y ago
  I'm sorry, but the idea that it's about allowing me to attest to the security of my device is not correct. I can make all the attestations I like about the security of my device, but if they're not backed by a confirmation from Google then it's quite likely that nobody will care. The issue is that making modifications to anything in the chain of trust requires approval from a trusted third party.
  - charcircuit 3y ago
    >the idea that it's about allowing me to attest to the security of my device is not correct I was oversimplifying. A service doesn't have to trust every attestation and a service does not need to do anything with the attestation if it doesn't want to. >The issue is that making modifications to anything in the chain of trust requires approval from a trusted third party. That is by design because it means untrusted people can't make changes while remaining trusted.
    - wzdd 3y ago
      Yes, you are correct that preventing users from making modifications to anything in the chain of trust without being approved by an already-trusted third party, likely the company who certified the device, is by design.

by wzdd 3y ago

metalcrow 3y ago

I mean, you can still lie, it's just made more difficult. Unless i'm missing something, running your OS under a hypervisor with a virtual TPM (or a forked browser with TPM access stubs and custom kernel drivers) still allows you to do whatever you want. It's certainly more difficult, and unreasonably so, but it's still quite possible. While i'm not familiar with Safteynet, i'm sure it's also possible to bypass it that way. The issue with this seems to be a sort of a restricting freedom for the greater good idea. If you restrict the ability of web developers to check security values and stuff, then they can't do some good things like improve security, but they also can't do any really bad things like block ad-blockers. But if you allow this access then you get the opposite.

wzdd 3y ago
My understanding is that the vendor installs keys in the TPM which can't be retrieved. So no, a virtual TPM wouldn't work, because you don't have the vendor's keys. Or rather, you would be in the same situation as before, because you can install your own keys and then have the challenge of getting third parties to trust you.
- metalcrow 3y ago
  They'd have to install them before you even get the parts then, right? Otherwise they'll just install them on your virtual tpm. I know apple does that because they own their own chip fabs and have limited (relatively) production runs, but i don't think google is going to manually etch a unique (and it has to be unique otherwise it'll leak) private key into the silicon of every single tpm for mobile and desktop ever. Or are they planning to only allow you to access websites on Google made hardware, and cut out 90% of the world's population?
  - wzdd 3y ago
    Correct, this is what they do. Google requires hardware manufacturers who want to use Play etc to get their stuff signed with their root certificate, which the TPM then verifies. See https://developer.android.com/training/articles/security-key-attestation https://developer.android.com/training/articles/security-key... In particular: """ If the root certificate doesn't contain the public key on this page, there are two likely reasons: [It is from an old version of Android, or] The other likely reason is that the device isn't a Google Play device. In that case, the device maker is free to create their own root and to make whatever claims they like about what the attestation means. Refer to the device maker's documentation. Note that as of this writing Google isn't aware of any device makers who have done this. """ In other words, to get into the Google attestation party you have to get your device Google Play certified. Obviously device manufacturers are strongly incentivised to do this. Edit: If this were to be applied to desktops as well, the obvious approach would be to partner with Microsoft and make use of their trust root, because Microsoft's keys are installed in ~every TPM.
    - metalcrow 3y ago
      Ahhh, ok that makes sense, they're in effect replicating Apple's method then. That does mean this can't really work on desktops atm, due to the low amount of pre-signed TPMs there, so this API is only actually unbreakable for Google and Apple hardware owned mobile devices. Which is already pretty bad, and allows them to boil the frog on desktops! Thank you for the explanation! Edit: I wasn't aware Microsoft was already pre-signing basically all desktop TPMs, that's crazy. Makes sense thinking about it now, especially with Windows 11 requiring it.

charcircuit 3y ago

>In summary, this is fundamentally different because it takes away your control of your own device. No, it allows a business to deny to you if you can't attest to the security of your device. You are still free to do whatever you want on your own device. If a business had an office that required you to unlock a door, but it also had a pickable lock that wouldn't be great security. It allows people to lie about having a badge by letting them pick the lock to get in. If a business increased security by making the lock no longer printable that seems like a good thing to me. >LineageOS is a good example of this; they have their own Safetynet implementation which has very little buy-in. Have they actually approached apps and offered compensation for them to implemented it? Or are they hoping apps just randomly decide to adopt it?

wzdd 3y ago
I'm sorry, but the idea that it's about allowing me to attest to the security of my device is not correct. I can make all the attestations I like about the security of my device, but if they're not backed by a confirmation from Google then it's quite likely that nobody will care. The issue is that making modifications to anything in the chain of trust requires approval from a trusted third party.
- charcircuit 3y ago
  >the idea that it's about allowing me to attest to the security of my device is not correct I was oversimplifying. A service doesn't have to trust every attestation and a service does not need to do anything with the attestation if it doesn't want to. >The issue is that making modifications to anything in the chain of trust requires approval from a trusted third party. That is by design because it means untrusted people can't make changes while remaining trusted.
  - wzdd 3y ago
    Yes, you are correct that preventing users from making modifications to anything in the chain of trust without being approved by an already-trusted third party, likely the company who certified the device, is by design.