Content-Encoding and MITM devices

[Patrick Meenan <[e-mail]>]

As part of Chrome's origin trial for compression dictionaries (which is
enabled over secure-contexts only), we are seeing elevated connection
issues on HTTP/1.1 and HTTP/2 but not HTTP/3.

It's visible from both Chrome and from some of the origin trial
participants, seeing elevated failures. From Chrome's side, it looks to be
limited to cases where the connection certificate is not anchored to a
well-known trust root (i.e. likely a MITM proxy using a local trust root).

This seems to match what Edge was seeing with the zsdch deployment:
https://techcommunity.microsoft.com/t5/discussions/edge-and-bing-search-zsdch-encoding-why-is-it-being-used/m-p/3881170/thread-id/60032

We were hopeful that the work to launch brotli had cleaned up a bunch of
the MITM issues but it looks like they are an ongoing problem for
content-encoding.

For any launch with Chrome, we will figure out how to do it as cleanly as
possible (enterprise policy, tie the feature to a version release, etc) but
if you know of anyone responsible for a MITM proxy/firewall that might be
affected, it would be worthwhile to give them a heads-up that it is coming.

Longer-term it would be nice if we can find a way to keep the situation
from getting worse (I don't want to end up in a place where we can only
launch features and protocol changes to HTTP/3 connections to well-known
trust roots).

Some thoughts:

- Should we start greasing existing HTTP header fields (or at least the
content-encoding)?
- Should information about the trust root used for a connection be
web-exposed, server-exposed or user-exposed?