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

[Martin Thomson <[e-mail]>]

Can we go to first principles?

The URL is controlled by a site.  Though it doesn't include ambient
authority (I hope), it can still be used to poke at things on the same
side of the firewall as a client.  That would seem to qualify it for
CORS.

On 7 June 2017 at 12:23, Patrick McManus <[e-mail]> wrote:
> 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/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
>
>