Journal tepples's Journal: Chromebook Developer Mode Warning 11
It's possible to install a GNU/Linux environment on a Chromebook using Crouton. The first step is to put the Chromebook into developer mode, as described in the article "How to Enable Developer Mode on Your Chromebook" by Chris Hoffman. But every time you turn on a Chromebook in developer mode, the Chromebook firmware begs the user to wipe it. Here's the exact wording that the firmware displays:
The first screen (screenshot):
OS verification is OFF
Press SPACE to re-enable.
The second screen (screenshot):
OS verification is OFF
Press ENTER to confirm you wish to turn OS verification on.
Your system will reboot and local data will be cleared.To go back, press ESC.
(The screenshots are from How-To Geek. Please ignore its pop-ups requesting that you add yourself to the site's mailing list.)
The primary user of a Chromebook in developer mode can press Ctrl+D to skip this prompt each time it appears. But someone else who turns on the device is unlikely to know Ctrl+D. Instead, she is likely to follow the prompts ("Press SPACE" then "Press ENTER") without fully understanding the hardship that following them could cause for the device's owner.
This means the device's owner will not be able to trust the device's internal storage for anything. He will have to operate the device with a USB flash drive sticking out of its USB port, so that all user data gets written to external storage, which is less vulnerable to this sort of data loss. He will also need to carry a second USB flash drive containing reinstallation media for Crouton so that he reinstall Crouton should someone wipe it.
How practical is it to ensure the data on your Chromebook doesn't get wiped without losing eligibility for fixes to, say, the screen hinge and power jack?
Chromebooks are cheap (Score:1)
Don't stuff beans up your nose (Score:2)
They're cheap, so just don't let anyone else use yours.
Good luck with that if you don't live alone. Are you recommending keeping a Chromebook under physical lock and key to prevent accidental wiping by SOs and children who don't know better?
Or, put a sticker on it that says "DO NOT PRESS SPACE/ENTER - YOU WILL WIPE MY DATA!!"
That's not effective for the same reason that "Don't stuff beans up your nose" is not effective [wikipedia.org].
That's fine if you're a dev and know what you're doing, but do you really want non-devs to innocently use your insecure machine?
No, I want non-devs to turn it off and contact the owner (me) through the phone number displayed next to my username and picture on the login screen.
Re: (Score:2)
It's a feature. It ensures that someone who doesn't know to press Ctl-D will never access your data. And there's no reason you can't put it under lock and key. There are laptop bags for that if you really need to. Or you can modify ones that lack a lock so they can be locked. And why would you give anyone physical access to your development machine anyway?
If you do you kind of deserve what happens.
Re: (Score:2)
It's a feature. It ensures that someone who doesn't know to press Ctl-D will never access your data.
But it also ensures that I will never access my data either despite that I do know about Ctrl+D.
And there's no reason you can't put it under lock and key. There are laptop bags for that if you really need to. Or you can modify ones that lack a lock so they can be locked.
I was under the impression that a laptop in an obvious laptop bag would be more valuable to thieves than a laptop in a nondescript bag. That's why I carry a subnotebook in the first place: it fits in a bag that's a less obvious thief magnet. Or am I already suffering from cognitive dissonance that I haven't detected yet?
And why would you give anyone physical access to your development machine anyway?
The way I would phrase this answer to be most readily understood depends on the life circumsta
Planning for frequent surprise factory resets (Score:2)
I would have a backup plan in place to ensure the integrity of work that's older than 3 days. Data loss is a situation that can be planned for an mitigated.
A surprise factory reset causes not only 1. the loss of all work since yesterday's push but also 2. the lost working time between the factory reset and when you return home to your reinstallation media and 3. the lost time to reinstall from said reinstallation media. So can the delay and labor associated with data restoration also be "be planned for an mitigated"? Carrying reinstallation media wherever you carry your Chromebook in developer mode may mitigate 2 but not 3.
I would be sure to push my work into version control
For public free software projects, I
CloudReady's lack of powerwash as a benefit. (Score:2)
I never did reply to your good point pointing this problem out [slashdot.org]...
This isn't a solution, but I've mostly played with Chrome OS on non-Chromebook hardware with CloudReady [neverware.com]. It doesn't support powerwash... which means it doesn't show this wiping stuff. Not a solution on real Chromebook hardware though, but my 13" Retina MacBook Pro is nicer than any Chromebook anyway!
Re: (Score:2)
Re: (Score:2)
I thought messing with the BIOS voided the warranty. Can an alternative BIOS be installed "without losing eligibility for fixes to, say, the screen hinge and power jack?"
Re: (Score:2)
Re: (Score:2)
If the screen or power jack is the broken part, good luck restoring the BIOS in the first place.