- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 31 Aug 2011 00:50:53 -0700
- To: Daniel Veditz <dveditz@mozilla.com>
- Cc: "sird@rckc.at" <sird@rckc.at>, "Hill, Brad" <bhill@paypal-inc.com>, "public-web-security@w3.org" <public-web-security@w3.org>
On Wed, Aug 31, 2011 at 12:04 AM, Daniel Veditz <dveditz@mozilla.com> wrote: > On 8/30/11 10:33 PM, Adam Barth wrote: >> It seems like we could let folks specify paths in addition to schemes, >> hosts, and ports. >> >> script-src http://example.com/js > > We've talked about exactly that in the past. I'm fine with it, iirc > we dropped it because people were already complaining about > "complexity". Yeah, I agree that the main cost is complexity. The main question is whether this problem is actually "deadly" or whether lcamtuf is being hyperbolic. Adam >> CSP is still behind vendor prefixes in the two >> implementations I'm aware of, so making non-forwards compatible >> changes is probably still fine. > > If we cared enough we could make it forwards compatible by creating > "script-src2" which old implementations would ignore, and make new > implementations honor script-src if script-src2 is not present. But > then sites that want to be compatible with both old and new (and > take advantage of the path feature) have to enumerate their script > sources twice. > > I'm not seriously suggesting we do that. > > If we support path prefixing for script-src I'd want all the > content-load directives to support it for consistency. I also would > really like to avoid introducing regexp and instead limit this to > simple string prefix matching. I'd be fine allowing full-path match > down to the filename; someone requested that at one point. I think > in practice it would make policies too large (and again complex), > but if we're halfway there no harm in going the rest of the way. > > -Dan Veditz >
Received on Wednesday, 31 August 2011 07:51:53 UTC