chrome://restart wiping out all pushed settings when 'erase all local user data' is selected
Reported by
amandawu...@gmail.com,
Jan 23 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. under device mgmt, select 'erase all local user data' 2. push some user level settings 3. login as user and enter chrome://restart 4. test previously set user level settings, they can now be bypassed What is the expected behavior? in school environments, we need a way to block students from being able to temporarily do whatever they want What went wrong? When going to chrome://restart with 'erase all local user data' enabled - all pushed settings are wiped out. We have an extension whitelist, for example, but when students do this, they can download whatever extension they want. We use 'erase all local user data' because Chromebooks are in carts and labs and shared among dozens of students in order to not fill up the local hard drives. Could there be a policy setting to block chrome://restart or chrome:restart or any other shortcuts that would allow students to bypass all of our security? Did this work before? N/A Chrome version: 55.0.2883.87 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 24.0 r0
,
Jan 23 2017
,
Jan 23 2017
if this is a duplicate, is there anyway for users to follow progress of that bug? The links given (668204), I can't access.
,
Jan 23 2017
This is really bad news. Using a lockdown browser, and following this method puts the user outside of the lockdown browser.
,
Jan 23 2017
@patt Support said this is fixed in v56 due out soon. Can test in the beta channel
,
Jan 24 2017
,
Jan 24 2017
Looks like a duplicate of crbug.com/672779 . That bug is resolved and will be rolled out in version 56, which should hit stable in the next week or two. Thank you for reporting this!
,
Jan 24 2017
,
Jan 24 2017
,
Jan 24 2017
@khar - i think that's what the fix is. pushed settings are retained/repushed. who cares if students can do chrome://restart as long as they aren't bypassing settings. let me know if i'm misunderstanding.
,
Jan 24 2017
@aman I apologize and I deleted my previous comment due to typos. We are even having this issue when we place both a user account and device in an OU that is set to Do Not Erase Local User Data, not just Erase Local User Data. I can go to a website that is blocked by GoGuardian (we block buzzfeed) and it will show up as blocked. If I type chrome://restart and go to buzzfeed again, this time it will load. I am not seeing this behavior on 56 beta, and was just wondering if anyone else was experiencing this as well. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 Deleted