New issue
Advanced search Search tips

Issue 783911 link

Starred by 4 users

Issue metadata

Status: Duplicate
Owner: ----
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Students bypassing incognito mode disable policy by inspecting chrome://oobe/lock

Reported by 18bloise...@etudegroup.org, Nov 10 2017

Issue description

UserAgent: 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:
 
Screenshot 2017-11-10 at 2.15.32 PM.png
89.4 KB View Download
Cc: poromov@chromium.org atwilson@chromium.org
Status: Available (was: Unconfirmed)
Reproduced on my device.
Mergedinto: 776427
Status: Duplicate (was: Available)

Sign in to add a comment