W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2013

RE: broadening default-src semantics

From: Hill, Brad <bhill@paypal-inc.com>
Date: Sun, 2 Jun 2013 20:24:11 +0000
To: Adam Barth <w3c@adambarth.com>, Devdatta Akhawe <dev.akhawe@gmail.com>
CC: Daniel Veditz <dveditz@mozilla.com>, Yehuda Katz <wycats@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E27AE22E2@DEN-EXDDA-S12.corp.ebay.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:02 UTC