Inspecting chrome://oobe/lock from chrome://inspect/#other and clicking on settings from that incognito window soft-bricks chromebook in an enterprise policy
Reported by
jeremyeb...@gmail.com,
Dec 15 2017
|
||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 10176.13.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.24 Safari/537.36 Platform: 64.0.3282.24 (Official Build) dev (64-bit) Steps to reproduce the problem: 1. Go to chrome://inspect/#other 2. Click inspect 3. Click "Application" 4. Click "read manifesto" 5. In that incognito chrome window, open settings. What is the expected behavior? Open settings. What went wrong? The whole Chromebook soft-bricks because on an enterprise Chromebook with incognito restricted by policy, this incognito window is not supposed to be allowed. Crashed report ID: No How much crashed? Whole browser Is it a problem with a plugin? No Did this work before? N/A Chrome version: 64.0.3282.24 Channel: n/a OS Version: 10176.13.1 Flash Version: 28.0.0.133
,
Feb 5 2018
This has allowed for student uses in EDU domain to bypass Lightspeed filter. Policy is set to no Incognito & dev tools are disallowed. This completely negates what we have in place. I had to manually block Chrome://inspect to prevent. Hopefully this can be addressed.
,
Feb 28 2018
I can no longer reproduce in M65 as lockscreen has been replaced with a new implementation that does not use webview. Please reopen if you can reproduce on M65+.
,
Feb 28 2018
|
||
►
Sign in to add a comment |
||
Comment 1 by afakhry@chromium.org
, Dec 15 2017Status: Untriaged (was: Unconfirmed)