RE: broadening default-src semantics

Sounds like a good idea.  For example, the proposed frame-options directive uses an origin list, but it is not fetch-oriented and should not have default-src apply to it.

> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Saturday, June 01, 2013 1:27 AM
> To: Devdatta Akhawe
> Cc: Daniel Veditz; Yehuda Katz; public-webappsec@w3.org
> Subject: Re: broadening default-src semantics
> 
> On Fri, May 31, 2013 at 7:45 PM, Devdatta Akhawe
> <dev.akhawe@gmail.com> wrote:
> >>> It would be better if it was spec'ed as covering all network
> >>> requests, period.
> >
> > What does "all network requests" or the broader "all resource loads"
> > cover? links ? window.open? refresh via the meta header? csp reports?
> >
> > Or do you mean "secondary resource loads"?
> >
> > FWIW, I wouldn't mind if it covers everything above, but I am not sure
> > browsers are willing to consider such a design.
> 
> I imagine we'd spec this in terms of the "fetch" algorithm, which will give
> precise answers to all these questions.
> 
> Yehuda and I also talked about reversing the table of which directives
> default-src affects so that other specs can add directives that plug into
> default-src instead of having to rev CSP every time someone wants to do
> that.
> 
> Adam

Received on Sunday, 2 June 2013 20:24:40 UTC