6 ms·

All of this complexity that's being added to lock a system down, purportedly in the name of "security" is actually being done for control by the vendor, at the

by ohazi 5y ago

All of this complexity that's being added to lock a system down, purportedly in the name of "security" is actually being done for control by the vendor, at the expense of control by the user. Microsoft wants an enforceable walled garden just like Apple's. The increased attack surface that all this brings, implemented in a way that's opaque and non-removable, makes me incredibly nervous. You think cars and IoT devices are insecure? We're going to end up with that level of danger baked into every PC on the planet.

Animats 5y ago
You think cars and IoT devices are insecure? We're going to end up with that level of danger baked into every PC on the planet. Tolerance for that among business customers may have just decreased substantially due to the current war.
- hulitu 5y ago
  I would not bet on this. Purchases are made by department leaders based on beautiful Excel spreadsheets which have little to no relation to reality.
slaymaker1907 5y ago
I thought this was initially FUD, but this in particular sounds bad. TPMs really do enhance security since it massively increases the security for even weak passwords (which 90-95% of them are). However, any security feature should be zero cost such that if you don't use it/want it, it doesn't restrict what you can do. Secure Boot at least can be disabled most of the time and that is one of the most locked down features. Random tangent: I really wish we had a better way to customize code signing and verification. For very sensitive environments, you should be able to only trust certain certs/roots for particular binaries. I'd like to enforce that for some particular python script, it has been signed by one of *my* CI servers. Obviously this is possible, but I think you would need to roll your own code.
- salawat 5y ago
  Secure boot can only be disabled on x86/_64 systems. It is decreed that ARM systems not be user deactivatable.
  - oneplane 5y ago
    Let's make that a bit more specific: Microsoft wants OEMs that manufacture Windows on ARM devices to not allow a user to disable secure boot and not allow a user to add CAs or trust individual certificates. In essence, they want secure boot to not be subvertible. This is both good and bad: for the generic end-user, not being able to 'accidentally' disable root-of-trust via secure boot and not being able to have 'tech savvy nephews' try to 'help' them (and not overseeing the long term consequences) is a net win. It's going to be pretty hard to rootkit a system that has a secured root-of-trust. On the other hand, the device is now worthless the second the OEM, ODM or Microsoft decides they don't want to support it. They also completely control all features, so even if it would be hardware-capable of doing something you simply aren't going to be able to do it. There is a third aspect and that is that it is very hard to inspect the device as a researcher. Knowing that closed chassis debugging is a point of vulnerability, it would be great if it was still possible to boot a research OS and check the device. At this point, you can only do that with reverse-engineered drivers and a shim loader and hoping the CA in the firmware is up-to-date enough to contain a trust relation for the intermediate CA used to sign the shim certificate...
    - R0b0t1 5y ago
      > On the other hand, the device is now worthless the second the OEM, ODM or Microsoft decides they don't want to support it. Heh, no, it's useless from the factory assuming you don't want to run windows.
  - my123 5y ago
    This only applies to the (dead) Windows RT and Windows Phone/10 Mobile platforms. Windows on Arm64 devices are regular Windows desktop devices, just running on a different CPU architecture. As such, they share the same security policies. You can disable UEFI Secure Boot just fine on a Surface Pro X, and use custom keys there too. This also applies for devices from other OEMs.
littlecranky67 5y ago
Please refer only to iOS as a walled garden. I can easily install Windows and Linux (natively) on my Macbooks, and this is not more cumbersome as on a regular PC (disabling Secure Boot). With the Apple Silicon its not that easy, but mostly because there are just not mature-enough drivers (Linux) or no interest by the manufacturer (Windows). macOS is also not very locked-down - yes you might need to disable some security feature and reboot to install certain kernel modules, but this is nothing out of the ordinary. I can still run kernel-level code without jailbreaking/rooting the hardware on Macintoshs.
- kavalg 5y ago
  True, but you can't deny that Microsoft has moved a lot into the direction of walled garden / cloud based recently. I don't have the feeling that I own my PC as much as I did in the past (e.g. Windows 7).
- comex 5y ago
  > I can still run kernel-level code without jailbreaking/rooting the hardware on Macintoshs. Only if you’re willing to accept the loss of Apple Pay via Touch ID as well as the entire iOS-apps-on-Mac feature. It’s been years since Apple allowed you to run kernel-level code without losing features.
  - littlecranky67 5y ago
    > iOS-apps-on-Mac feature Can you elaborate what you mean here? Maybe I missed something, but Apple does not provide any iOS-apps-on-Mac feature? Except of course for/through their development tools, but no Appstore thingy or alike.
    - amake 5y ago
      Yes, you missed something. https://machow2.com/run-ios-apps-mac/ https://machow2.com/run-ios-apps-mac/ Edit: In case you prefer a first-party source: https://developer.apple.com/documentation/apple-silicon/running-your-ios-apps-on-macos https://developer.apple.com/documentation/apple-silicon/runn...

by ohazi 5y ago

Animats 5y ago

You think cars and IoT devices are insecure? We're going to end up with that level of danger baked into every PC on the planet. Tolerance for that among business customers may have just decreased substantially due to the current war.

hulitu 5y ago
I would not bet on this. Purchases are made by department leaders based on beautiful Excel spreadsheets which have little to no relation to reality.

slaymaker1907 5y ago

I thought this was initially FUD, but this in particular sounds bad. TPMs really do enhance security since it massively increases the security for even weak passwords (which 90-95% of them are). However, any security feature should be zero cost such that if you don't use it/want it, it doesn't restrict what you can do. Secure Boot at least can be disabled most of the time and that is one of the most locked down features. Random tangent: I really wish we had a better way to customize code signing and verification. For very sensitive environments, you should be able to only trust certain certs/roots for particular binaries. I'd like to enforce that for some particular python script, it has been signed by one of *my* CI servers. Obviously this is possible, but I think you would need to roll your own code.

salawat 5y ago
Secure boot can only be disabled on x86/_64 systems. It is decreed that ARM systems not be user deactivatable.
- oneplane 5y ago
  Let's make that a bit more specific: Microsoft wants OEMs that manufacture Windows on ARM devices to not allow a user to disable secure boot and not allow a user to add CAs or trust individual certificates. In essence, they want secure boot to not be subvertible. This is both good and bad: for the generic end-user, not being able to 'accidentally' disable root-of-trust via secure boot and not being able to have 'tech savvy nephews' try to 'help' them (and not overseeing the long term consequences) is a net win. It's going to be pretty hard to rootkit a system that has a secured root-of-trust. On the other hand, the device is now worthless the second the OEM, ODM or Microsoft decides they don't want to support it. They also completely control all features, so even if it would be hardware-capable of doing something you simply aren't going to be able to do it. There is a third aspect and that is that it is very hard to inspect the device as a researcher. Knowing that closed chassis debugging is a point of vulnerability, it would be great if it was still possible to boot a research OS and check the device. At this point, you can only do that with reverse-engineered drivers and a shim loader and hoping the CA in the firmware is up-to-date enough to contain a trust relation for the intermediate CA used to sign the shim certificate...
  - R0b0t1 5y ago
    > On the other hand, the device is now worthless the second the OEM, ODM or Microsoft decides they don't want to support it. Heh, no, it's useless from the factory assuming you don't want to run windows.
- my123 5y ago
  This only applies to the (dead) Windows RT and Windows Phone/10 Mobile platforms. Windows on Arm64 devices are regular Windows desktop devices, just running on a different CPU architecture. As such, they share the same security policies. You can disable UEFI Secure Boot just fine on a Surface Pro X, and use custom keys there too. This also applies for devices from other OEMs.

littlecranky67 5y ago

Please refer only to iOS as a walled garden. I can easily install Windows and Linux (natively) on my Macbooks, and this is not more cumbersome as on a regular PC (disabling Secure Boot). With the Apple Silicon its not that easy, but mostly because there are just not mature-enough drivers (Linux) or no interest by the manufacturer (Windows). macOS is also not very locked-down - yes you might need to disable some security feature and reboot to install certain kernel modules, but this is nothing out of the ordinary. I can still run kernel-level code without jailbreaking/rooting the hardware on Macintoshs.

kavalg 5y ago
True, but you can't deny that Microsoft has moved a lot into the direction of walled garden / cloud based recently. I don't have the feeling that I own my PC as much as I did in the past (e.g. Windows 7).
comex 5y ago
> I can still run kernel-level code without jailbreaking/rooting the hardware on Macintoshs. Only if you’re willing to accept the loss of Apple Pay via Touch ID as well as the entire iOS-apps-on-Mac feature. It’s been years since Apple allowed you to run kernel-level code without losing features.
- littlecranky67 5y ago
  > iOS-apps-on-Mac feature Can you elaborate what you mean here? Maybe I missed something, but Apple does not provide any iOS-apps-on-Mac feature? Except of course for/through their development tools, but no Appstore thingy or alike.
  - amake 5y ago
    Yes, you missed something. https://machow2.com/run-ios-apps-mac/ https://machow2.com/run-ios-apps-mac/ Edit: In case you prefer a first-party source: https://developer.apple.com/documentation/apple-silicon/running-your-ios-apps-on-macos https://developer.apple.com/documentation/apple-silicon/runn...