Issue #356: Form-encode Expect-CT report bodies?

[Emily Stark <[e-mail]>]

I'm looking for some feedback on https://github.com/httpwg/
http-extensions/issues/356.

Expect-CT violation reports are currently specified as POST requests with
JSON bodies. When implemented in a web browser, such reports should
arguably send CORS preflights, because the content type is not
CORS-safelisted (https://www.w3.org/TR/cors/#simple-header).

But sending CORS preflights for these requests doesn't really make sense
from a web browser architecture perspective: CT compliance is checked as
part of certificate verification and connection setup, divorced from the
context one needs to send a CORS preflight (such as an Origin header). This
is not just a theoretical layering issue; implementing preflights for
Expect-CT reports in Chrome would be pretty challenging.

I only see two options to resolve this, both of which seem bad to me:

a) Leave the reporting part of the spec as it currently is, and leave it up
to the UA to decide whether further operations such as CORS preflights are
needed for sending reports. This would basically leave it to us in Chrome
to decide either that Expect-CT reports should not be subject to CORS
restrictions, or that we should not ship reporting. (I'm uncomfortable with
this option because it somewhat jeopardizes the only active implementation
effort that I know of.)

b) The disgusting option: disguise Expect-CT reports as form submissions,
which are not subject to CORS preflighting. This would mean the report body
is sent as hostname=blah&port=443&... or we could even just send
expect-ct-report=<stringified JSON blob>.

Thanks,
Emily