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

[Patrick McManus <[e-mail]>]

my gut reaction: why would an expect-ct report be more subject to cors than
something like OCSP? (assuming it wasn't driven directly from content)


On Tue, Jun 6, 2017 at 6:45 PM, Emily Stark <[e-mail]> wrote:

> I'm looking for some feedback on https://github.com/httpwg/h
> ttp-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
>