There are two types of wipe/recovery:

1) Powerwash (implemented in the OS).  Sure, go ahead and lock that down if you want.

2) Manual recovery mode (Power+Refresh+Esc, implemented in the read-only firmware).  This is the ONLY way to recover a Chromebook with a corrupted/non-bootable OS or firmware.

We cannot disable manual recovery mode.  It is intentionally implemented in read-only firmware and does not trust any rewritable storage, so there's no place to put a disable flag.  Even if we did decide to implement a recovery-disable flag, that's basically a if-the-machine-doesn't-boot-it's-a-brick flag.  Imagine if we push a bad update to customers and all of a sudden they have thousands of devices that cannot be recovered, even by RMA...

From the manual recovery screen, you can toggle the dev switch on.  This is necessary to boot the RMA/recovery shim, since that image is intentionally not bootable as a normal recovery image.  Toggling the dev switch wipes the TPM as a security measure.  This may be the wipe you're talking about.  If an enterprise has disabled dev mode, you won't be able to *boot* in developer mode, but the wipe has already taken place.  

The TPM wipe must be performed by the read-only firmware.  We can't defer it until even rewritable firmware, because by then the TPM has been locked down enough that the wipe command won't work.  I don't see a way to limit that wipe to keep students from doing it intentionally, yet still make it secure enough to protect the normal-mode TPM data from a subsequent developer mode boot.

Potential workarounds would do something like try to decide if the RW firmware or recovery image that's about to be booted represents a possible threat.  If not, skip the wipe, and somehow communicate to the RW firmware that a wipe hasn't taken place.  

Then the RW firmware would check the FWMP to see if dev mode is disabled.  If so, don't allow the wipe, just go to the TONORM screen.

Only if the RW firmware decides if dev mode is enabled would it set a pretty-please-wipe flag and reboot back to RO, which would actually do the wipe.

This process seems somewhat fragile.

There are also workflows (in enterprise, too) which *rely* on the TPM wipe as a way of forcing re-enrollment.  If we lock it down, we also break those flows.

Thanks Randall. Resolving as Won't Fix.

Thanks Randall. Resolving as Won't Fix.

Reopening this, as I'd like to understand if we can at least close down the dev mode powerwash step (if you transition to dev mode, you'll get a powerwash even if dev mode blocking is active - I'd like to change that, so we can only get a powerwash if you go through a real recovery flow).

We are looking for a way to block developer mode in order to avoid students wiping 
devices and IT having to reconfigure them since they can't re join the wifi.
We would like to block the ability of the user to wipe the device.

Could a password screen come up when a system wipe (Esc+refresh+power) is attempted? This way only administrators can wipe a device when putting in the Google admin password. We have around 20 Chromebooks a day that students are wiping. 

Is there any possible way that anything can be done. Having students constantly reset the Chromebooks a day ( around 20 ) is getting out of control. There must be something like a possible password screen that makes it so you have to put in a password right after Esc+refresh+power is hit so they cant actually wipe the Chromebook. 

Could there be a way to set a password to initiate a powerwash that only admin staff had a not students.  We have them doing this to 20-30 devices a day and it takes a lot of resources to rejoin to the domain, etc.  Any option to lock this down is needed.

This is a serious topic of interest for our school with over 2,300+ Chromebooks. So much so that we are considering switching to laptops instead. If we had a way to set a admin password to wipe the device would be ideal. Please give this ticket a high priority because I know it is a widespread issues all schools face.

We need a way to prevent students from power washing their devices.

Yes, a admin password to confirm powerwash would be ideal. Thanks for the consideration.

Students being able to powerwash is not a joke, Jim! Millions of families suffer every year!

I would like to request the features listed in open ticket # 778342.
As a public school technology director the would help me maintain our chromebooks.

An admin panel configurable password that would be required before a powerwash could occur would be ideal.  You could then set a password per OU (campus, grade, etc. depending on OU structure) and that password could then be carefully distributed to those that need to powerwash (not students).  Of course those that do not wish to require a password should also retain that option by either not setting a password in device management policies or otherwise disabling the requirement.  I think it should be an opt-in setting.

We have just added our latest batch and now have over 450 Chromebooks in use.  It wasn't until this last batch that we started seeing the units be reset.  There definitely needs to be some way to prevent unauthorized users on managed devices from performing the reset.  A password of some type (like a bios password option on a PC) would be a great idea.

Adding the ability to have an admin password when ESC+Refresh+Power is pressed would be great. 

Chromebooks have been great for my environment until recently students discovered how to place the Chromebooks into recovery mode. With over 600 Chromebooks, I would hate to see them all in recovery mode. I'm a bit disappointed that Google does not have a means of preventing this. Please Google, an admin password to initialize recovery mode is needed.   

Count me in as someone who would like to see something done about this. We are a two man shop and have about 1,000 Chromebooks to manage (on top all of our other responsibilities). I like the idea of password protecting recovery mode. Not sure if it could be something that could be set within Google Admin but, at this point, setting the password per machine would be better than having to re-enroll every time a student wipes a device.

This issue is coming up repeatedly. Can you provide a rough estimation regarding the effort of the proposed fix in #2 / #3?

Re#23: I'd even written a design doc for how to fix this.  See go/vboot-clear-tpm-owner.

It's not horribly complex, so probably about a month to implement counting tests.  Unfortunately, it requires RO firmware changes so it would only affect new devices.

+Joel, who is doing more actual vboot implementation than I am these days.