Re: CSP: connect-src

On Tue, Jun 25, 2013 at 5:41 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Sun, Jun 23, 2013 at 1:54 PM, Adam Barth <w3c@adambarth.com> wrote:
>> Yeah, I'm happy to re-write that section once the fetch spec provides
>> the proper hooks.
>
> So it seems for fetching you need to know which Document is in scope
> and what the API is (e.g. image-src). However, if we want fetching to
> happen of-the-main-thread we don't want a hard dependency on the
> Document object so you need to abstract out. We could either do this
> by passing the CSP policy on a per-fetch basis or have something like
> a "fetch group" through which individual fetches are queued. I believe
> the latter is closer to what implementations have today.

I'm not sure I understand.  Why can't off-the-main-thread fetching
refer to the Document?  Is the issue that the CSP policy is mutable
and there would be an ambiguity as to which version of the policy
would apply?  Can you give a specific example of where we run into
trouble?

> That would also make it easier to standardize the policy for image
> loading consistently across HTML, CSS, and SVG (that using the same
> URL avoids another HTTP request and goes straight to the cache).

I think I'm not understanding the issue.  What does caching have to do
with CSP?  The restrictions in a CSP policy apply regardless of
whether the fetch was serviced from a cache or from the network.

> Not entirely clear to me what the best forum to discuss these issues
> is, but for now I suppose this will do.

The way I imagined this working is that a spec that invokes the fetch
spec would do so both by referring to a browsing context, a Document,
a WorkerContext, or some other similar concept and with a "type"
(e.g., "image", "script").  We'd then write in CSP that whenever a
user agent initiates a fetch of a script on behalf of a Document, ...
check the allowed script sources ... if the URL isn't allowed, abort
the fetch and do X.

Alternatively, CSP can program into the user agent the set of allowed
"X" sources, where "X" is a type of fetch, like "image" or "script"
and the fetch spec can then see if it's been programmed with
restrictions for loads of the specified type and contain the text
saying to check the set of allowed things and what to do if the fetch
isn't allowed.

If you're worried about threading, then the second approach (the
programming approach) might be better.  To program the information
into the fetch engine on the non-main thread, we could queue a task on
its event loop to program the information into its fetch engine.  Then
the new policy would come into effect whenever that thread processed
that event.

Adam

Received on Wednesday, 26 June 2013 04:35:05 UTC