how to disable the flags/#enable-brotli  flag for our college

as when people load youtube in chrome it comes up with funny characters 

if I disable this flag and relaunch chrome for the user and relaunch chrome it will work again

Adding respective feature owners.

I guess this is due to a buggy proxy.  :(

[+eustas]:  Is there a group policy to disable Brotli?

@jgmaddox7: Can you say something about what proxy configuration you are using?  

Brotli should only be enabled if the connection to the endpoint is over HTTPS, which should prevent proxies from interfering with it.  So in order for this to happen the proxy would both have to be doing HTTPS MITMing and would have to be dropping or interfering with new Content-Encoding fields.  If that's what's happening I'd like to understand the configuration better to judge whether or not we're likely to run into this in other contexts. 

Not sure.
If base::feature could be controlled by policy, then yes:(https://cs.chromium.org/chromium/src/content/public/common/content_features.h?rcl=d10c3182e3802a0140769643c559acd926ff8cdb&l=24).
There is nothing else I am aware of.

rdsmith:  Note that this is an edu user, so an MITM cert seems likely.
eustas:  To the extent of my knowledge, you have to explicitly add a group policy entry if you want to let enterprises opt-out via policy.

Yes we are a education college, we have  A MITM cert and a watchguard firewall, I`m on 2nd line support so I am not aware of the details, is there anything to look out for or anything I could pass on to our 3rd line network team that may be able to resolve this.. 

The key question is how the firewall handles "Content-Encoding: br".  My guess is that it's not recognizing the content encoding, and hence stripping it, which will result in chrome being unable to decode the random bytes because it won't know it's a Brotli encoding.  If that guess is right, not stripping the header should fix the problem.  That would interfere with the firewall's monitoring (because it won't be able to see the actual content bytes); what you do about that is up to you, but the possibilities that come to my mind are:

* Accept that you can't monitor material encoding with brotli.  I don't think this will seriously limit your web monitoring, since it's not widely used yet and I don't think (?) most Google properties will serve things you want to be blocking.  Also note that you're not currently blocking brotli encoded content, just leaving it encoded, which I wouldn't think is ideal for your purposes. 

* Strip the "br" from Accept-Encoding on the way out. 

* Incorporate Brotli decoding in the firewall.

If you want to attach a net-export log, I could confirm that the client advertises "br" and the server doesn't show "Content-Encoding: br".  See http://dev.chromium.org/for-testers/providing-network-details.  But this does not sound like a bug in Chrome, so that would be just to confirm my guess as to the problem with the firewall.

Eustas: Worthwhile reaching out to WatchGuard about this?

I think it is worth trying. About a year ago we've reached Kaspersky, to resolve the same problem; though it took some time - now there are no more complaints from users who are hit by this problem...

Reasonable to assume you're in charge of that?

Yup.
One question: do we also need add a group policy to help people dealing with this problem in a more "enterprise" way?

We've had a number of reports of another Watchguard issue with Chrome 60 and the TLS 1.3 rollout (See  issue 733223 ), but this is the first report I've seen of running into issues with Watchguard + Brotli, and I see this is Chrome 59, so seems a bit strange this is the first we've heard of this issue.

I believe davidben may have a Watchguard contact, due to the aforementioned SSL issue (Though not sure how much success he's had contacting them).

What version of Watchguard is this?  We should probably know that before reaching out to them.

Hi, we are running WatchGuard Fireware XTM v11.10.5.B492938 on a XTM850

Hi everyone.

(I'm JGMad / Wil's boss and the network engineer for the affected site.

I'm confident it's nothing to do with the WatchGuard as that was never doing any significant MITM processing.  

Sic ne march, when this problem manifested we have been using iBoss webfilters inline on our firewall uplink - so I'm going escalate this problem on their support to see what comes back.  The filters are based on Squid/Snort/other open products so should hopefully be reconfigurable at some level.

Adding a Group policy to switch off brotli would be amazing as a fallback too.

 Issue 752147  has been merged into this issue.