Students bypassing incognito mode disable policy by inspecting chrome://oobe/lock
Reported by
18bloise...@etudegroup.org,
Nov 10 2017
|
||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 9901.54.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.74 Safari/537.36 Platform: 9901.54.0 (Official Build) stable-channel kip Steps to reproduce the problem: 1. Load chrome://inspect/extensions#other 2. Wait until chrome://oobe/lock shows up on the page, click on inspect 3. Device opens up an incognito inspect tab, they can make a new tab in developer tools based off of that in incognito mode, thus bypassing most blocks (other than policy-based blocks) What is the expected behavior? Clicking "inspect" doesn't do anything. Because both developer tools inspect and incognito are blocked. What went wrong? It is a way to bypass enterprise blocking systems in place like goguardian or similar. If incognito mode is blocked it shouldn't have opened incognito mode, if developer tools/javascript console is blocked it shouldn't have opened it. Did this work before? N/A Chrome version: 62.0.3202.74 Channel: n/a OS Version: 9901.54.0 Flash Version:
,
Nov 13 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by poromov@chromium.org
, Nov 13 2017Status: Available (was: Unconfirmed)