- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 7 Jun 2017 15:39:46 +0200
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: Emily Stark <estark@google.com>, httpbis <ietf-http-wg@w3.org>
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 <mcmanus@ducksong.com> 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 <estark@google.com> 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 > >
Received on Wednesday, 7 June 2017 13:40:21 UTC