How to liberate a Chromebook
ar.al
ar.al
"You'll have to locate the Write Protect jumper and enable it."
But it gives you absolutely no clue where the write-protect jumper is, or how to find it. For this critical step, you are on your own.
It's pretty clear that Google really doesn't want people doing this. (Not that I blame them. But still, the OP page does add quite a bit of value IMHO.)
The adjective I'd use to describe OP's writing is "resolute". And in these days when surveillance and other corporate monsters continually bathe us in soft nudging to acquiesce to their agendas, it is a stance that's quite necessary.
If you don't like them, fine, but this just comes off as nerd rage in an attempt at saying "I am very smart."
The Chromebook's model is obviously consistent with Google's fleshed out security model. But this model is at odds with Free users, and there isn't one straightforward way to reconcile the two, but rather various ones that will each attract their own criticism.
Individuals don't have the luxury of massaging their opinions with a PR department, and conflict (with the corporate narrative) draws attention to rough points. People aren't going to express things perfectly - one can either work to be tolerant of varying personalities and colorful overstating, or retreat to the safe space of sanitized corporate press releases.
Ask yourself what is your motivation to shit on him with classical bullying ("nerd rage"). Some casual ranting about security models while tediously reflashing a BIOS is not an attempt to say "I am very smart".
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, taking end users under their wing to provide them security. For a non-technical person with no technical family, obtaining a device with this security model from Best Buy is likely the pinnacle of what can be done.
But this is not the only device security model. And the idea of a manufacturer working against the owner of a device is abhorrent to the perspective of Freedom. Weighing Google's specific design decisions within their model is not terribly important if one is repudiating the entire model. I personally think a better synthesis could be found between the two models, but that was obviously not the point of the original post!
I'm not personally a huge fan of blog posts / youtube / etc that just reiterate and editorialize information that is easily found elsewhere. But I do recognize that this is how many people learn - both the viewers and the authors. By picking on this post for not having the details fleshed out and stated in an impartial manner, all you're really doing is putting a veil of faux impartiality over shouting down the culture of Freeing computing devices.
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.
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.
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.
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.
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.
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...
Your "common knowledge" notwithstanding, I can tell you with 100% certainty that the os protection features in chromeos devices are about security. More specifically, it's about creating a device that Google can use themselves for extremely high-security use cases.
You can trust it, or not, doesn't matter. But for Google, the modern Chromebook is the only desktop environment where they can be absolute sure that all the software and all the hardware are clean. Turns out that other companies like this capability as well, so it's a general product feature.
But if all you want is some cheap hardware where you can flash the bios and run Windows Vista, then you just go ahead and be you. That's fine.
It seems to me that there's a bit of a blind spot here on ycombinator, specifically for tech companies and developers that is, in assuming they are working in good faith.
I guess it's that most people here work in tech or with said folks so I get why; it's just the way ycombinator swings.
>I guess it's that most people here work in tech or with said folks so I get why; it's just the way ycombinator swings.
There is HN bias, but in this case it's the reverse bias, specifically because most folks DO NOT work in this sort of tech.
I personally appreciated "A Chromebook is an inexpensive data milking device and you are the cow". Rather than throwing everything at the wall and hoping something would stick, OP would have certainly benefited from some editing. But the bulk still shouldn't have been hard to read past.
There is editorializing in every communique. IMHO the protests here say more about being acclimated to a culture of milquetoast-positivity corporatespeak than anything else.
That would require effort on the author's part. This is the equivalent of that guy who goes "gNu pLus LiNuX ;D" whenever someone simply says/mentions Linux as part of a larger conversation topic because they have nothing to contribute.
> But the bulk still shouldn't have been hard to read past.
It is difficult because the author has two simultaneous discussions going on: their actual work with the Chromebook and their banal google privacy comments which are intertwined with the actual interesting content.
> IMHO the protests here say more about being acclimated to a culture of milquetoast-positivity corporatespeak than anything else.
I clicked the link to read an article on getting ChromeOS off of a Chromebook. I didn't click the link to have to scrape aside the same wannabe revolutionary feel-good drivel that's been propagated on every common and tech-focused news site just to get at the content. If anything, the author writing the equivalent of "ha ha doodoo head google sheeple FITE DA POWA" and the volume of people defending it speaks volumes about what constitutes privacy advocacy in HackerNews comments.
> Glad I won't have to give my Chromebook a screwdriver enema again!
If you’re willing to do that, you can disable this key sequence.
Edit: let me elaborate on what I think is the reason. They are selling the hardware at a loss or close to it. When you put Linux on there you eat their revenue. Instead of being honest about this, they dress it up in a bunch of phony security talk. They don't want people reselling them as useful Linux workstations.
The point of the Chromebook’s security approach (with the developer mode beep + notification, etc.) is to have a “Trusted Computing Base”, in the original, non-dystopian meaning of the phrase: you’re supposed to be able to tell, as a regular user, just by looking at/booting up a Chromebook, that it’s running Google-signed firmware/software.
A Trusted Computing Base is precisely for the case where you do trust some particular third-party to be your IT admin (because, for example, they’re your school or employer, or—more likely—a subcontractor of one of those that MDM is being delegated to.) In such cases, you want to know that your device is in exactly the state that that party wants it to be in, and that no other party has been able to modify it.
Google aren’t trying to make it impossible for you to use your Chromebook for whatever you want; that’s just a side-effect. Their goal is to make it impossible for someone who intercepts your Chromebook in shipment to install a rootkit on it, in a way where the device still appears to be (and act like) a Chromebook, with no sign that there’s anything wrong.
Yes, Google is the IT admin of the device. Someone’s gotta be; in a Trusted Computing Base scenario, you remove the possibility of handing the thing off to a repair shop (because what is a repair shop—from the TCB perspective—but another attacker?)
Essentially, a Chromebook has the same goal as a high-security lock: nobody should be able to pick it. Not even a locksmith. Not even the locksmith you hired because you lost your keys to the lock you own. Just like with encryption, you can’t leave a backdoor that only works for people with good intentions. You have to leave no backdoor at all—only a “front door.” In the case of a high-security lock, the “front door” is ordering new keys from the manufacturer, supplying your proof of purchase of the lock. In the case of a Chromebook, the “front door” is the signed update system, which allows one party (in this case the manufacturer, but in TCB Windows/macOS PCs this is your enterprise MDM admin) to manage everything. And also spy, if they want. But the two things are one and the same, really. The manufacturer of your high-security lock could break into your building, too. That’s why you pick a lock manufacturer you trust.
Sadly, as the author proves, it’s not impossible to install a rootkit (in this case, a Linux distribution, but it could just as well be a keylogger-injected version of ChromeOS) onto a Chromebook, in a way that’d be invisible to the end-user (unless the end-user X-rays their devices upon receipt and uses ML to compare them to a standard blueprint, ala the brouhaha around spy chips surface-mounted onto the bus of Supermicro servers.)
> you’re supposed to be able to tell, as a regular user, just by looking at/booting up a Chromebook, that it’s running Google-signed firmware/software.
Google did do that. But they went a step further - making it extremely easy to accidentally wipe your device and reset it to factory-defaults: https://www.chromium.org/chromium-os/chromiumos-design-docs/...
If you make it easy to persistently use a rooted device, then regular users would use rooted devices for regular tasks. (Because there are advantages of doing so, like side-loading native apps.)
If regular users use rooted devices, some people’s only experience of a device would be of a rooted device.
If some people’s only experience of a device is of a rooted device, then they’ll have no idea what an actually tampered device looks like, because every device they’ve seen is “tampered.”
This is exactly the state of Android, as it happens. Tons of people use Android in its developer mode; and so people don’t take a security mindset toward using a rooted phone.
The solution to this is to use technical mechanisms to achieve social effects (a.k.a. “incentive design” — the type of thing that tax credits are.) By making it irritating and risky to use developer mode in a persistent way, people won’t do it for anything other than tasks that truly require using developer mode for what it’s for (that’s “using the device as a debug build target”, by the way, not “writing code on the device.”)
Thus, nobody uses Chromebooks in developer mode.
Thus, the average person’s experience of seeing a Chromebook in use is, 99.9% of the time, of a non-rooted Chromebook.
Thus, the boot beep is surprising, and will scare the average user off of using the device.
Adding a switch in the OS that disables this, would be akin to having a switch in your OS (on a device MDM-managed by someone else, including the certificate store) that disables web browsers from doing any certificate checking. You could flip it; but so could viruses, and so could the NSA half-way through the laptop’s delivery process. Why would you want that switch to exist?
——
What people with complaints like yours really want, I think, is not to disable the TCB. You want to be able to be in control of the TCB. You want something that’s like a Chromebook, but where the MDM controller is an enterprise (e.g. you individually, if you’re clever enough) rather than Google.
Well, I mean, first: that’s what a regular PC with Secure Boot is.
But if the particulars of Chromebooks appeal to you (and I suppose they could appeal to somebody): the cheap hardware, the keyboard layout, the sandboxing, etc. Then what you might want is a variant Chromebook.
Such a device would have to look different than a regular Chromebook, somehow, to show regular users that it’s not for them. Sort of like how developer units of game console hardware are clearly not the same as production units. But if that were done, I think it’d be okay for those units to have a user-controllable TCB.
This is false. All but the most technically inept user will understand "WARNING! YOUR COMPUTER IS NOT RUNNING GOOGLE CHROME OS/HAS BEEN ALTERED FROM FACTORY DEFAULTS!" shown at boot time. Which is what Chromebooks do. All that's needed to make it into a usable device is to get rid of "Press space to wipe your device."
> Tons of people use Android in its developer mode; and so people don’t take a security mindset toward using a rooted phone.
Android security is catastrophic on factory settings already, so how you managed to blame the tiny proportion of users that root their phones to get rid of vendor bloatware for it is beyond me.
No. Not if half† the Chromebooks people own emit that message.
Users do not read. I know, it's hard to believe, but a large portion of average (not "most technically inept", average) users have never read a warning message on a screen in their lives. They see a warning message—and then they ask an authority figure what it means. They then classify whatever technobabble response they get into two executive-summary categories: either the warning means they should stop and wait for assistance; or the warning means nothing, and they should confirm whatever it's asking them to confirm and go on as per usual. After that, every time they see a prompt that looks like the one they asked about, they'll remember which of the two categories they surmised it to fall into, and that's what they'll do. Even if it's a prompt with different text. It looks the same—it gets the same treatment.
The next time you see a non-IT person using Windows and they get a UAC prompt, observe what they do. Ask them why it came up, and why they reacted the way they did. They won't know. All they'll know is that someone once told them it's fine to ignore those and click Accept.
If the ChromeOS boot screen is as common as Windows UAC, then it fails at its mission. That is why it makes it easy to un-root the device: because, if you have a boot screen that can "trick" average users into un-rooting a Chromebook, then you can't trust the average user around your rooted Chromebook to not accidentally wipe it, so you can't ever give the average user a rooted Chromebook as some kind of cheap kiosk (i.e. exactly what the author of the article was trying to do.)
And so rooted Chromebooks "in the wild" are rare—rare enough that if any user ever sees that boot screen, it'll be a new error that no authority figure ever told them "the trick" to bypassing and getting on with their day. New enough that they'll either "fall for" the prompt and un-root the device; or they'll call someone over to ask what the prompt "means."
----
† Sure, far less than half of Android devices are rooted. But consider the demographic difference. Every human being has a potential reason to own an Android device. Right now, very few average human beings have a reason to own their own Chromebook. (Be assigned a Chromebook by an enterprise MDM system, sure. But own their own? Quite rare.)
Ignoring the enterprise users, and taking the small slice of people who own their own Chromebook as the base population, any random niche use that requires rooting the Chromebook, if it got popular enough, could blow that population out of the water. If rooted Chromebooks turned out to be, say, good for running TAILS, or game emulators, or any other stupid thing you can think of, suddenly half the Chromebooks "in the wild" that a non-enterprise user ever sees would be doing that, and so would be rooted. They'd all beep and show the warning. And, like UAC, it'd be just another one of those things you ignore.
I personally find this useful, I've got two ChromeOS devices running other OSes, and I like the minimalist hardware. Frankly, I also get enjoyment out of using things in ways not totally intended.
The reasons for this design are documented: https://www.chromium.org/chromium-os/chromiumos-design-docs/...
(Of note, the newer Chromebooks no longer require a physical hardware switch or jumper to be toggled. The hardware folks said this was expensive, so newer devices let you enter developer mode by holding the correct keys on boot.)
For now, if you truly want to give a Chromebook running another OS to someone, you have to replace the EEPROM: https://www.chromium.org/chromium-os/chromiumos-design-docs/... https://www.chromium.org/chromium-os/chromiumos-design-docs/...
Yeah, if that is the vulnerability scenario they see necessary to "protect" me against, it's pretty clear I'm not the owner of the machine. I think the anger if warranted.
More broadly, I find the distinction between "normal users" and "developers" in that article pretty telling. I guess the goal isn't anymore to make everyone Computer-Literatur enough to run anything else than Chrome OS.
Good. Even by the standards of comic book villainy, that was an insane idea.
Much more of a problem for me personally is that I've spent several hours trying to follow the guides to recompile the kernel I already have, so I can try to modify it, and it comes out grossly wrong and unbootable. It's doing a very bad job of handling open source.
If you want debug features without opening the case, there is https://www.chromium.org/chromium-os/ccd
Google tells you how to install alternate os' on there. It doesn't have easily upgradable storage in part because that makes them cheaper, but some have had upgradable stoage. My chromeos Asus desktop brick like device has upgraded memory and storage. Look at Mac laptops for serious anti upgrade efforts.
Part if the restrictions are to prevent virii or other rootkit like takeover of the machine.
Now who's exaggerating? I'm largely in the middle of privacy vs convenience but I can get through the information just fine.
Similar to OP (little less emotion maybe), I flashed coreboot[0][1] on it and installed Ubuntu[2] (display brightness, audio doesn’t work so I have usb-c audio adapter) - couldn’t be happier: keyboard is excellent, it’s light, it was relatively inexpensive (for low end i7, 512gb , 16gb ram), it’s silent (no fans), display is 3:2 aspect ratio (I think) and it’s not 4k, hardware feels nice and solid. Other than audio issue, Ubuntu runs solid on it after some tinkering. If you’re willing to tinker with it s bit - Google totally nailed it on this![3]
[0] https://www.coreboot.org [1] https://mrchromebox.tech [2] https://www.reddit.com/r/elementaryos/comments/9vu3hm/juno_o... [3] https://www.google.com/chromebook/device/google-pixelbook/
https://github.com/optio50/ChromeBook-Keyboard-xkb/blob/mast...
> Four of the screws are hidden under the pads for the feet...
I consider it a helpful reminder to count to verify I have gotten them all.
For example, take a look at the ThinkPad Yoga 460 Hardware Maintenance Manual:
https://download.lenovo.com/pccbbs/mobiles_pdf/p40_yoga14_mt...
Go to "1020 Base cover assembly" on page 71 (page number at the bottom of the page, not the PDF page number). Note how it instructs you to remove the three caps (feet) to reveal those screws.
Instead of a screwdriver, which can easily damage the casing, breaking a washing line pin in half gives you a sturdy plastic object of right size for the job that won't scratch stuff.
I appreciate the sentiment behind the author's desire to do this. But I'm wondering:
- Did it void a warranty if it was still valid, and the tampering with the case had damaged some hardware that the end user can't fix on her own?
- Does the user require knowledge of GalliumOS, and understand that updates may need to be pulled manually?
- Can common college programs in her major be run on GalliumOS and on the hardware defined by Chromebooks (low-end)? Can she run SSH to Linux or VNC for Windows w/o difficulty?
I agree having one corporation say to the poor and the young and the otherwise disenfranchised that a corporate, locked-down operating system is good for you is not a great idea. It trades your freedom for convenience, and no matter how appealing that may be for both parties (the end user for cheapness and ease of use, and the corporation for not having to deal with the insanity and unworkablity of some users), it's not a good tradeoff in the long run for anybody, including the corporation that discovers too late that hiring the same sheep it raised is bad.
But I don't think this is the right way to go about it. Shrieking the principles of Stallman from a hill just makes you look like an old crazy person. I personally didn't get to love Linux until I had a MacBook Pro, a UNIX fork that works pretty nicely on a laptop, and moved slowly into Linux until I prefer the CLI over GUIs for many things now. At every stage of my transition, everything worked, and worked best for me, and I understood why I needed to move further. Doing something like this and encountering issues solved by ChromeOS may create a negative impression of Linux in a young mind, which is the exact opposite of what you want to do.
As an alternative way forward, I installed Ubuntu on my parent's laptop after Windows 10 kept freezing up on them. Yes, it has binary blobs and a corporation runs it and whatnot, but it works and it's still Linux.
My dad got a virus from downloading a YouTube video somehow, and I could fix it because I could reinstall chrome using 'apt', and taught him how to use 'youtube-dl' instead (open terminal, paste, enter key). I don't think he cares that it's Linux, but I do think he is happy it works and I can fix it when it goes wrong.
You never want to do the right thing by going against the laws of power, because that's how you end up as cannon fodder and a footnote in an moldy AP compsci textbook somewhere.
The work the Gallium team did was necessary, and its definitely paid off. It's nice to see things open up over the past few months.
https://liliputing.com/2018/07/handheld-pc-face-off-gpd-pock...