Re: CSP, Fetch, and frame-ancestors

Well, there's already a lot of magic hidden away in
http://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch. All of
the TLS-handshake, for instance. I don't know what level you'd like Fetch
to dive down to.

Frame ancestors seems like something we could reasonably include in Fetch
(perhaps by pointing to a new hook in CSP, and passing in the request and
response). I'm not really sure where to stop, however. At some point we
reach the transport layer, which doesn't seem like what Fetch should be
concerned with. I guess there's a stopping point somewhere between those
two.

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Wed, Jun 4, 2014 at 9:33 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Jun 4, 2014 at 9:18 AM, Mike West <mkwst@google.com> wrote:
> > We should be able to determine whether or not to load the resource once
> we
> > process the HTTP response headers, we don't have to wait until the whole
> > resource is loaded. Whether or not we should do that in Fetch is a
> somewhat
> > open question, as it would happen somewhere in the middle of step 6.
> >
> > I suppose we could add a new step 7 which checks the ancestor policy
> > (delivered via CSP or via X-Frame-Options) against the ancestor browsing
> > contexts associated with the request. I'm not sure how much of that we
> want
> > to bring into Fetch, though. Seems like a layering problem.
>
> If it's not Fetch it seems like this should be coordinated with HTML
> at all the places where this would be applicable. Otherwise we lose
> track of ordering.
>
>
> --
> http://annevankesteren.nl/
>

Received on Wednesday, 4 June 2014 07:43:28 UTC