Also wanted to add that it still doesn't work with 58.0.3029.81

chrome.reg file now included.

Deleted: chrome.reg 36.7 KB

chrome.reg 36.7 KB Download

The issue also persists with Chrome 58.0.3029.81

Assigned to Julian for triage.

Chrome will only read the registry on an AD joined machine. On non-ad joined machine it will only respect policies coming from GPO (set locally). This has been the case for many releases. We were discussing relaxing this requirement but there is no decision on that front until the security implications of this change have been all understood.

+blumberg, georgesak for discussion of whether we want to allow reg only policies on non-AD machines again.

Ok. All I know is that sometimes it would work and sometimes it wouldn't depending on the version

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0acd1627a3481649ceb76eaebbf82a410419b02c

commit 0acd1627a3481649ceb76eaebbf82a410419b02c
Author: Julian Pastarmov <pastarmovj@chromium.org>
Date: Wed Nov 08 11:06:15 2017

Revert to reading the registry in all cases.

This change removes the logic to read GPO files instead of registry keys
on non-domain-joined machines. It was supposed to increase the security
of policy operations but in effect only made the logic harder to follow.

Still some policies will only be respected if the computer is joined to an
AD domain but the contents of the policies will only be read from the registry
in all cases.

BUG= 710641 
TEST=existing unit tests.
TBR=garykac@chromium.org

Change-Id: Ic02d955de7f331370e92ce5a837d4e3b671eddc2
Reviewed-on: https://chromium-review.googlesource.com/756707
Commit-Queue: Julian Pastarmov <pastarmovj@chromium.org>
Reviewed-by: Lutz Justen <ljusten@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514796}
[delete] https://crrev.com/7b5439b5a01b843398dfc0f84945af0abb9f7f79/chrome/test/data/policy/gpo/bad/Registry.pol/.keep
[delete] https://crrev.com/7b5439b5a01b843398dfc0f84945af0abb9f7f79/chrome/test/data/policy/gpo/empty/Registry.pol
[delete] https://crrev.com/7b5439b5a01b843398dfc0f84945af0abb9f7f79/chrome/test/data/policy/gpo/extension_alternative_spelling/Registry.pol
[delete] https://crrev.com/7b5439b5a01b843398dfc0f84945af0abb9f7f79/chrome/test/data/policy/gpo/test1/Registry.pol
[delete] https://crrev.com/7b5439b5a01b843398dfc0f84945af0abb9f7f79/chrome/test/data/policy/gpo/test2/Registry.pol
[modify] https://crrev.com/0acd1627a3481649ceb76eaebbf82a410419b02c/components/policy/core/common/policy_loader_win.cc
[modify] https://crrev.com/0acd1627a3481649ceb76eaebbf82a410419b02c/components/policy/core/common/policy_loader_win.h
[modify] https://crrev.com/0acd1627a3481649ceb76eaebbf82a410419b02c/components/policy/core/common/policy_loader_win_unittest.cc
[modify] https://crrev.com/0acd1627a3481649ceb76eaebbf82a410419b02c/remoting/host/policy_watcher.cc

FYI: the UMA Sampling Profiler detected that the change in comment 7 has resulted in a 41ms average improvement in pre-message loop start time on 64 bit Windows. (Congrats!)

Execution profile flame graph diff between 64.0.3262.0 and 64.0.3263.0: https://uma.googleplex.com/p/chrome/callstacks?sid=603544892a95d183e601014bf6a9a864

We now will always read from the registry instead of the mix of registry and POL file reading it used to do until now. 

This change will appear in Chrome 64 on the stable track.

would it be better if the AD requirement completely?

Re c#10: Not sure what you mean?

If you are asking why some policies are still only respected in AD setups. It is because those are often abused by malware to lock users in settings they did not opt in for and/or can not get easily out of.

Ok.