3 ms·

>We get it. Google's (and Apple's, Intel's, etc) contemporary security model is to work to retain control over the device for themselves This is exactly what y

>We get it. Google's (and Apple's, Intel's, etc) contemporary security model is to work to retain control over the device for themselves This is exactly what you and likely the author of the post don't get. Google's security model is vastly different from Apple's or Intel's or anyone else's. In particular, the google security model is the only one of these which still ensures the ability for a user to take full control of the device (to the extent possible in current times). And they have gone through a lot of effort to do so. The easy way out is to do what every other manufacturer on the planet does.

mindslight 8y ago
Their security model is the exact same one - trust us and we'll maintain your security. The difference is better described as Google deliberately adding an opt-out to the devices. That's definitely appreciated and is nicer than not doing so. But it isn't a real model of hardware protections that would serve a Free device, nor does it allow for agility or nuance around that trust relationship with Google. Which is why the experience of taking ownership of your device turns into a violent one - because you basically have to repudiate the OEM's built-in system in favor of a completely different Free road. Which is why it's much easier to do with a fresh device, rather than after you've grown accustomed to it.
- bubblethink 8y ago
  >But it isn't a real model of hardware protections that would serve a Free device What is your proposed mechanism to ensure a verified chain of boot that the vendor intends for the majority of its customers while simultaneously allowing a user to do whatever they please ? The current solution is about the only one you can do at a technical level. Note that the convenience (or lack thereof) is a separate minor thing that is not so relevant. You really need to understand the verified boot design in chromebooks to appreciate the nuance, as you put it. >you basically have to repudiate the OEM's built-in system in favor of a completely different Free road You are not repudiating anything. You are using a feature that the OEM explicitly added at significant cost to please someone like you. Buy any other machine, and tell me how much freedom you get.
  - mindslight 8y ago
    Even though a TPM has be tamper proof hardware, it does not have to be beholden to the single party of the manufacturer. I'd start by removing any burned in (loaded-once) asymmetric keys from the trust root. I'd pop an explicit serial header on the motherboard to communicate with the TPM in a user-friendly manner. Any signing key could then be loaded into the TPM by holding the machine in a specific wiping mode for say a few days, essentially making the ultimate trust root "long term possession of the machine". The actual signing key that is loaded needs to be percolated up through the UI so the user can verify whom they're actually trusting. But this doesn't actually need to be done every single boot, but really only when the machine is setup for a new user. The banal criticism is that doing so would be work that doesn't directly benefit Google. Well you asked, and that's inherent in any constructive solution. > You are using a feature that the OEM explicitly added at significant cost to please someone like you. Buy any other machine, and tell me how much freedom you get. Erm okay you're taking this back to a hostile direction. Take any pre-DRM PC from 1985-2010, where the CPU simply trusts its memory. That's the longstanding basic model that Google simply added an escape hatch to revert to. I've said that it is appreciated, but don't act like it was somehow onerous.
    - sangnoir 8y ago
      > making the ultimate trust root "long term possession of the machine You probably don't want someone who steals your laptop to get access to your secrets after a few days. Also, how would you know your "brand new" laptop wasn't interdicted by a hostile party while it was "having problems clearing at customs"? It is clear to me that your threat-model and Google's (they dogfood ChromeOS hardware extensively) are divergent. Chromebooks are not for everyone, and that's OK.
      - mindslight 8y ago
        > You probably don't want someone who steals your laptop to get access to your secrets after a few days Obviously. I was describing the signature chain management. The encryption key management would be as it is. > how would you know your "brand new" laptop wasn't interdicted by a hostile party while it was "having problems clearing at customs"? >> The actual signing key that is loaded needs to be percolated up through the UI so the user can verify whom they're actually trusting > It is clear to me that your threat-model and Google's (they dogfood ChromeOS hardware extensively) are divergent. Chromebooks are not for everyone, and that's OK. Here we go again with the condescending simplistic conclusions...

mindslight 8y ago

Their security model is the exact same one - trust us and we'll maintain your security. The difference is better described as Google deliberately adding an opt-out to the devices. That's definitely appreciated and is nicer than not doing so. But it isn't a real model of hardware protections that would serve a Free device, nor does it allow for agility or nuance around that trust relationship with Google. Which is why the experience of taking ownership of your device turns into a violent one - because you basically have to repudiate the OEM's built-in system in favor of a completely different Free road. Which is why it's much easier to do with a fresh device, rather than after you've grown accustomed to it.

bubblethink 8y ago
>But it isn't a real model of hardware protections that would serve a Free device What is your proposed mechanism to ensure a verified chain of boot that the vendor intends for the majority of its customers while simultaneously allowing a user to do whatever they please ? The current solution is about the only one you can do at a technical level. Note that the convenience (or lack thereof) is a separate minor thing that is not so relevant. You really need to understand the verified boot design in chromebooks to appreciate the nuance, as you put it. >you basically have to repudiate the OEM's built-in system in favor of a completely different Free road You are not repudiating anything. You are using a feature that the OEM explicitly added at significant cost to please someone like you. Buy any other machine, and tell me how much freedom you get.
- mindslight 8y ago
  Even though a TPM has be tamper proof hardware, it does not have to be beholden to the single party of the manufacturer. I'd start by removing any burned in (loaded-once) asymmetric keys from the trust root. I'd pop an explicit serial header on the motherboard to communicate with the TPM in a user-friendly manner. Any signing key could then be loaded into the TPM by holding the machine in a specific wiping mode for say a few days, essentially making the ultimate trust root "long term possession of the machine". The actual signing key that is loaded needs to be percolated up through the UI so the user can verify whom they're actually trusting. But this doesn't actually need to be done every single boot, but really only when the machine is setup for a new user. The banal criticism is that doing so would be work that doesn't directly benefit Google. Well you asked, and that's inherent in any constructive solution. > You are using a feature that the OEM explicitly added at significant cost to please someone like you. Buy any other machine, and tell me how much freedom you get. Erm okay you're taking this back to a hostile direction. Take any pre-DRM PC from 1985-2010, where the CPU simply trusts its memory. That's the longstanding basic model that Google simply added an escape hatch to revert to. I've said that it is appreciated, but don't act like it was somehow onerous.
  - sangnoir 8y ago
    > making the ultimate trust root "long term possession of the machine You probably don't want someone who steals your laptop to get access to your secrets after a few days. Also, how would you know your "brand new" laptop wasn't interdicted by a hostile party while it was "having problems clearing at customs"? It is clear to me that your threat-model and Google's (they dogfood ChromeOS hardware extensively) are divergent. Chromebooks are not for everyone, and that's OK.
    - mindslight 8y ago
      > You probably don't want someone who steals your laptop to get access to your secrets after a few days Obviously. I was describing the signature chain management. The encryption key management would be as it is. > how would you know your "brand new" laptop wasn't interdicted by a hostile party while it was "having problems clearing at customs"? >> The actual signing key that is loaded needs to be percolated up through the UI so the user can verify whom they're actually trusting > It is clear to me that your threat-model and Google's (they dogfood ChromeOS hardware extensively) are divergent. Chromebooks are not for everyone, and that's OK. Here we go again with the condescending simplistic conclusions...