[Gys]

From the article this is part of any modern Chromebook:

The Cr50 device is a classic “Fritz chip” — i.e. a hardware “policeman”, built into a computing device [...], so as to specifically and deliberately act against the purchaser’s interests, by subverting the Laws of Sane Computing in these three ways:

Prevention of the full control of the machine by its physical owner, typically by inhibiting attempts to install modified firmware. [...]

Enablement of one or more types of “NOBUS” back door (Official NSA terminology! “No One But US“, [...]

Prevention of a clueful hardware owner’s attempts to “jailbreak” — to disable, remove, or circumvent the Fritz chip itself.

[pgeorgi]

> typically by inhibiting attempts to install modified firmware

This also inhibits attempts by malicious third parties to install modified firmware on your machines.

For Chromebooks we traditionally tried to find a middle route: locked down by default, since most people care more about nobody tampering with their device than about the ability to do so themselves. For the others, there's dev mode (easy to get at, but with scary notifications, to make tampering obvious) and the write-protect screw (hard to get at, no tamper notification).

Hooking up cr50 into the write-protect line allows to develop a best-of-all-worlds approach:

* still locked down by default for people who don't want to think about their device's firmware security.

* simple to get at (but complicated enough that drive-by attacks remain infeasible), even with form factors that aren't service friendly (eg. glued chassis - firmware folks have no voice in these decisions).

* the ability to implement tamper evidence checks through remote attestation, even if the scary screens were disabled.

Compared to everything else on the market, I think it's a very user friendly set of trade-offs, both for power users and computers-are-appliances folks.

(disclosure: Chrome OS firmware developer)

[asciilifeform]

Why lie to the public ? Pulling the battery does enable rewrite, by the user, of the AP ROM, but not the Cr50 -- the latter remains Tivoized. And every owner of this machine can verify this with his own hands, it is not even necessary to build the USB debug cable.

The Cr50 accepts firmware updates at all times, but only when signed with Google's RSA key.

[pgeorgi]

> Why lie to the public?

I don't, and TBH I don't find your writing style (of which this is an example) very engaging.

Cr50 is a replacement for the old TPM. It has approximately the same constraints as the Infineon TPM used in the past: firmware updateable, but not for you.

[edit to add: would a mechanism to disable the update mechanisms, at the price of "no warranty" since RMA becomes impossible be acceptable to you? Or would you suspect that there's another update mechanism anyway?]

> Pulling the battery does enable rewrite

Pulling the battery is non-trivial on a device like Pixel C, hence a new mechanism.

[asciilifeform]

My current alternative appears to be to desolder the Cr50 and fabricate harmless replacements (to e.g. init 3.3v rail).

So naturally voids warranties.

> firmware updateable, but not for you

Finally, honesty. It's a Tivo.

[asciilifeform]

The Infineon couldn't force a boot ROM update via USB-C.

[pgeorgi]

> firmware updateable, but not for you

Like the Infineon before it.