Note: Chrome should be restarted for this policy to take effect - atleast that is the case for the chrome flag #enable-quic

Looks like issues were observed after system reboot.

Note to self: The QuicAllowed policy was originally introduced in  bug 461739 .

The problem here is the order in which things happen at startup.

The original  bug 461739  implemented the QuicAllowed policy with Windows Registry-based policy in mind. This (and the .json config dir policy on chromeos) is loaded on the first access to BrowserProcessImpl::policy_service():
- BrowserProcessImpl::policy_service() constructs the ChromeBrowserPolicyConnector (subclass)
- ChromeBrowserPolicyConnector ctor calls ChromeBrowserPolicyConnector::CreatePlatformProvider
- which in turn creates a AsyncPolicyProvider with a backing PolicyLoaderWin (for windows registry) or ConfigDirPolicyLoader (for .json)
- AsyncPolicyProvider ctor actually performs a synchronous policy load

This all happens before IOThread is constructed (last action in BrowserProcessImpl::PreCreateThreads), which is where the QuicAllowed policy value is evaluated.

Any cloud-based policies are only fetched afterwards.

Possible solutions:
- If possible, try to disable quic after startup on incoming policy change of QuicAllowed to false ( changing QuicAllowed to true would probably require a restart to take effect)
- don't declare QuicAllowed as user policy
- some special solution (like restart & caching) for QuicAllowed

+bnc

Looping back here - we should allow disabling quic post-profile initialization per our offline discussion.

As far as I remember, disabling QUIC by policy after profile initialization has never been implemented.  It can be done using a NetPrefObserver, a class that used to exists for SPDY/3.1 policy until SPDY/3.1 was removed entirely.  For reference, there are the CLs that ripped out NetPrefObserver:
https://crrev.com/2140733002
https://crrev.com/2172543003

In the net stack QUIC can then be controlled by a static boolean member of some high-level class like HttpStreamFactory, where the SPDY/3.1 policy flag used to live, or maybe there is a more tasteful, I'm not sure.

Thanks a lot for the hint, Bence!

I think a static member in HttpStreamFactory would work but it feels "hacky".

As a HttpStreamFactoryImpl refers to a HttpNetworkSession, a more "natural" solution might be to try to update existing HttpNetworkSessions. The challenge with that approach is that there will be many HttpNetworkSessions instantiated in various places which seem to be unrelated after construction (where params tend to be copied & altered). Updating them afterwards would require introducing a "registry of HttpNetworkSessions" or some kind of hierarchy between them, which sounds like overkill for this usecase.

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

commit 6ab8be2474cd5017e22a4027019546a145474207
Author: pmarko <pmarko@chromium.org>
Date: Wed Jan 11 11:02:55 2017

Respect QuicAllowed policy for new streams

Introduce a mechanism for an incoming QuicAllowed cloud policy
to control QUIC protocol usage for new streams even after
IOThread initialization.
NetPrefObserver has been re-introduced to observe the change
(after it was removed in crrev.com/2140733002 and
crrev.com/2172543003).

BUG= 658454 
TEST=browser_tests --gtest_filter=*QuicAllowed*
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2546533003
Cr-Commit-Position: refs/heads/master@{#442866}

[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/BUILD.gn
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/io_thread.cc
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/io_thread.h
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/policy/configuration_policy_handler_list_factory.cc
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/policy/policy_network_browsertest.cc
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/prefs/browser_prefs.cc
[add] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/profiles/net_http_session_params_observer.cc
[add] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/profiles/net_http_session_params_observer.h
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/profiles/profile_io_data.cc
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/profiles/profile_io_data.h
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/safe_browsing/safe_browsing_service.cc
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/browser/safe_browsing/safe_browsing_service.h
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/common/pref_names.cc
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/chrome/common/pref_names.h
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/google_apis/gcm/engine/connection_factory_impl.cc
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/google_apis/gcm/engine/connection_factory_impl.h
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/net/http/http_network_session.cc
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/net/http/http_network_session.h
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/net/http/http_stream_factory_impl_job.cc
[modify] https://crrev.com/6ab8be2474cd5017e22a4027019546a145474207/net/http/http_stream_factory_impl_job_controller.cc

Verified that when QuicAllowed policy is set to False via YAPS (and double checked in chrome://net-internals), the QUIC active session is no longer visible when visiting YouTube. Verified working in 57.0.2978.0:9176.0.0 dev lulu.

Note: If this is going to be merged somewhere, we should also merge
https://codereview.chromium.org/2639403004
which adds a forgotten command line flag to the browser tests which were newly introduced in this CL.

QUIC failed to honor the policy consistently, as tested in M57.2987.30:9202.17.0 dev daisy and M57.2987.35:9202.21.0 beta daisy.

Steps:

1. Disabled QUIC on YAPS.
2. On a newly imaged and enrolled device, logon device as user, verified policies showed QuicAllowed=false and net-internals showed "QUIC enabled": false.

3. Enabled QUIC on YAPS.
4. policies showed QuicAllowed=true, net-internal showed "Quick enabled": false.  This is ok.
5. Rebooted device.
6. policies showed QuicAllowed=true, net-internal showed "Quick enabled": true. 

7. Disabled QUIC on YAPS.
8. policies showed QuicAllowed=false, net-internal showed "Quick enabled": true. This is ok.
9. Rebooted device.
10. policies showed QuicAllowed=false, net-internal showed "Quick enabled": true. This is bad.

11. Rebooted device.
12. policies showed QuicAllowed=false, net-internal showed "Quick enabled": false. This is good.

13. Rebooted device.
14. policies showed QuicAllowed=false, net-internal showed "Quick enabled": true. This is bad.

15. From here onward, after rebooting the device countless times, QUIC remained enable in net-internals despite the policy said false.

Deleted: log-020917-180508.tar.gz 559 KB

log-020917-180508.tar.gz 559 KB Download

Thank you for reporting the problems you were observing.

I was trying to reproduce this today but had no luck so far.
Could you please help me out with the following few questions:

(1) Are you sure that chrome://policies showed QuicAllowed=false? Did it say Level=MANDATORY and Source=Cloud?
I'm asking to rule out that the policy fetch failed (I see a few lines saying 'DMServer sent an error response: 400' in the logs).

(2) How did you configure YAPS on the device? By adding the URL into /etc/chrome_dev.conf ?

(3) Did you test with one profile or multiple profiles?

(4) How did you go on during the reboots?
(4a) Turn off the device from the UI / using the physical button / typing reboot into the console?
(4b) Did you just re-enter the user's password on the new boot? Or use Guest mode / Or add anothe ruser?
(4c) Did you wait for the network to be connected before logging in?

Thank you!

Also, what other policies were set in YAPS (were any auto-logon device policies set?)

I'm terribly sorry I had not configured YAPS correctly; I had the QuicAllowed policy mode set as RECOMMENDED instead of MANDATORY.

Once I had that option set as MANDATORY, I no longer experienced the issues I reported earlier as tested with public and user sessions.

Tested no issue as verified in M57.0.2987.50:9202.26.0 beta peppy.

No worries, I'm glad that it works!

I'm writing up a document describing the QuicAllowed policy behavior (because its dynamic-disabling but reboot enabling is a bit weird), so I'll include a warning about MANDATORY being needed there.

Thanks!