5 ms·

> Chrome OS is far from perfection In fact, I would say for some users, Chrome OS is near perfection. Take my uncle for instance, who for years was getting him

by slacka 11y ago

> Chrome OS is far from perfection In fact, I would say for some users, Chrome OS is near perfection. Take my uncle for instance, who for years was getting himself infected with malware requiring regular visits from me or geek squad to wipe his system. When he was ready for his most recent upgrade, I tried him on Mint, but he didn't like the interface. Then I suggested a Chromebook. He LOVES IT. He says it's the best machine he's ever owned. One year later, and not a single issue with malware. I don't worry about him getting infected. If instead of a Chromebook, he had gotten some Android tablet with an OS stuck at 4.x, he's likely be infected by now. Android and Chrome OS serve different use cases. Even if Android manages to fix their upgrade issue, I doubt it will ever be as secure as Chrome OS. From the blog, "guaranteed auto-updates for five years", sounds like a few people at Google get this. Fingers crossed.

rdl 11y ago
The "perfection" I want is "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps". I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state. These probably don't matter much for individuals but do matter for enterprise. If this existed, even if it were just keys to approve/sign updates and still required google services for a lot of the functionality, would be awesome.
- magicalist 11y ago
  > I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state. Isn't the verified boot portion of the firmware not reflashable without hardware modifications[1]? Even if the dev switch has been flipped before, a verified boot is a verified boot and the machine should be in a good state. I haven't looked at that since the early ChromeOS machines, so has something changed about that? [1] https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot https://www.chromium.org/chromium-os/chromiumos-design-docs/...
  - rdl 11y ago
    Yeah -- it's supposed to be physically Read Only. There are some corner cases requiring physical access (you could physically replace the RO firmware, or fake the switch). I don't think it does full remote attestation validation of the local OS before talking to cloud services, although it does some other stuff. I should look into that more. But really, what I want is the ability to put my own enterprise key in there, in a write-once area, and do exactly what Google does now.
- bobajeff 11y ago
  > "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps" That's a good idea I wish they'd implement. Basically allow you to choose your own sync/updates server instead of having it hardcoded to Google's. I imagine I could then basically make any modifications to my own personal Chrome OS fork and have them stick.
  - groby_b 11y ago
    You're seeing the contradiction between having a verifiably "good" device and the ability to change the update/sync server at will, right?
    - rdl 11y ago
      Write-once of an enterprise key. If you buy 10k units, you should be able to put your own key in there. Or, have some kind of "we just check keys and add a layer of indirection as a service" for boot and boot signing keys. A batch of devices (identified by range of manufacture-time keys) is registered to a specific enterprise, and then that enterprise's keys are allowed to boot. That involves some kind of network service at boot time, or some kind of signed second-stage loader delivered to the devices telling them they're authorized to boot only from third-stage signed by that registered key.
    - bobajeff 11y ago
      I don't quite understand the need for that level of security. Surely the cases where being able to elaborately go into the BIOS and change such settings will lead to infections is miniscule. It's certainly worth the tradeoff of not relying on an external entity for verification of what's "good".
      - rdl 11y ago
        It's a big deal if you have fleets of machines which travel outside your control. It lets you treat them as identical (modulo hardware damage). It's also a big deal because on a conventional machine, malware remotely can download, root, reflash, and persistently doom you, no physical access needed.
ocean3 11y ago
he's likely be infected by now - What kind of infections would these be viruses/malware? Other day there was security expert who mentioned how Android security was bad, but did not mention any specific cases. My dad uses a 4.x device. Many other as well( India where low end has 4.x devices). But i don't see these user complaining about viruses or malware. Considering that they would usually complain about virus affecting their windows os. Is there anyway to know if the devices are infected?
- m45t3r 11y ago
  Even Android have a much better security model than your traditional desktop OS. Except if the malware includes a root exploit (in this case, all bets are off), the traditional "malware" in Android is limited to basically what the user allows it. However malware including root exploits should be rare, at least if the user only install applications using Google Play. Using applications from other sources, specially to get "free versions" of paid applications can be really bad. Unless the user are a completely moron, without enabling access for Accessibility, a malicious app can't, for example, read everything on the user screen, or capture the information the user types (the user would need to explicit allow it by turning on keyboard servicesin this case). This means that a malware can't sniff login information, or read the user e-mail. However they can still get valuable information (if the user did not read the permissions that Android asks before performing installation), like user contacts.

by slacka 11y ago

rdl 11y ago

The "perfection" I want is "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps". I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state. These probably don't matter much for individuals but do matter for enterprise. If this existed, even if it were just keys to approve/sign updates and still required google services for a lot of the functionality, would be awesome.

magicalist 11y ago
> I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state. Isn't the verified boot portion of the firmware not reflashable without hardware modifications[1]? Even if the dev switch has been flipped before, a verified boot is a verified boot and the machine should be in a good state. I haven't looked at that since the early ChromeOS machines, so has something changed about that? [1] https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot https://www.chromium.org/chromium-os/chromiumos-design-docs/...
- rdl 11y ago
  Yeah -- it's supposed to be physically Read Only. There are some corner cases requiring physical access (you could physically replace the RO firmware, or fake the switch). I don't think it does full remote attestation validation of the local OS before talking to cloud services, although it does some other stuff. I should look into that more. But really, what I want is the ability to put my own enterprise key in there, in a write-once area, and do exactly what Google does now.
bobajeff 11y ago
> "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps" That's a good idea I wish they'd implement. Basically allow you to choose your own sync/updates server instead of having it hardcoded to Google's. I imagine I could then basically make any modifications to my own personal Chrome OS fork and have them stick.
- groby_b 11y ago
  You're seeing the contradiction between having a verifiably "good" device and the ability to change the update/sync server at will, right?
  - rdl 11y ago
    Write-once of an enterprise key. If you buy 10k units, you should be able to put your own key in there. Or, have some kind of "we just check keys and add a layer of indirection as a service" for boot and boot signing keys. A batch of devices (identified by range of manufacture-time keys) is registered to a specific enterprise, and then that enterprise's keys are allowed to boot. That involves some kind of network service at boot time, or some kind of signed second-stage loader delivered to the devices telling them they're authorized to boot only from third-stage signed by that registered key.
  - bobajeff 11y ago
    I don't quite understand the need for that level of security. Surely the cases where being able to elaborately go into the BIOS and change such settings will lead to infections is miniscule. It's certainly worth the tradeoff of not relying on an external entity for verification of what's "good".
    - rdl 11y ago
      It's a big deal if you have fleets of machines which travel outside your control. It lets you treat them as identical (modulo hardware damage). It's also a big deal because on a conventional machine, malware remotely can download, root, reflash, and persistently doom you, no physical access needed.

ocean3 11y ago

he's likely be infected by now - What kind of infections would these be viruses/malware? Other day there was security expert who mentioned how Android security was bad, but did not mention any specific cases. My dad uses a 4.x device. Many other as well( India where low end has 4.x devices). But i don't see these user complaining about viruses or malware. Considering that they would usually complain about virus affecting their windows os. Is there anyway to know if the devices are infected?

m45t3r 11y ago
Even Android have a much better security model than your traditional desktop OS. Except if the malware includes a root exploit (in this case, all bets are off), the traditional "malware" in Android is limited to basically what the user allows it. However malware including root exploits should be rare, at least if the user only install applications using Google Play. Using applications from other sources, specially to get "free versions" of paid applications can be really bad. Unless the user are a completely moron, without enabling access for Accessibility, a malicious app can't, for example, read everything on the user screen, or capture the information the user types (the user would need to explicit allow it by turning on keyboard servicesin this case). This means that a malware can't sniff login information, or read the user e-mail. However they can still get valuable information (if the user did not read the permissions that Android asks before performing installation), like user contacts.