- From: Hill, Brad <bhill@paypal-inc.com>
- Date: Mon, 11 Feb 2013 19:49:59 +0000
- To: Mike West <mkwst@google.com>, Neil Matatall <neilm@twitter.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E27915478@DEN-EXDDA-S12.corp.ebay.com>
Perhaps "if the URL does not contain an authority component" is the correct language, from http://tools.ietf.org/html/rfc3986#section-3.1 ? (really, REALLY not trying to start a WHATWG vs. IETF URL flamewar here...) From: Mike West [mailto:mkwst@google.com] Sent: Monday, February 11, 2013 6:17 AM To: Neil Matatall Cc: public-webappsec@w3.org Subject: Re: Blank blocked-uris I took a stab at speccing this in https://dvcs.w3.org/hg/content-security-policy/rev/001dc8e8bcc3. I'm not entirely sure that I'm correctly referring to the class of schemes we care about... I stole "URL scheme with a server-based naming authority" from the HTML5 spec, which sounded reasonable, but feedback would be appreciated. -mike -- Mike West <mkwst@google.com<mailto:mkwst@google.com>>, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 On Tue, Feb 5, 2013 at 5:02 PM, Mike West <mkwst@google.com<mailto:mkwst@google.com>> wrote: This makes sense to me. I'd suggest doing the same for filesystem: and blob: URLs. If there are no objections, I'll add something to the spec. -mike -- Mike West <mkwst@google.com<mailto:mkwst@google.com>>, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91<tel:%2B49%20162%2010%20255%2091> On Tue, Feb 5, 2013 at 4:40 PM, Neil Matatall <neilm@twitter.com<mailto:neilm@twitter.com>> wrote: Hello all, I was taking a look at our reports and noticed a significant number of reports without a blocked-uri value. We tracked it down to two (possibly more) culprits: data: uris in images javascript: uris in hrefs I think the protocol would be enough information in this case.
Received on Monday, 11 February 2013 19:50:28 UTC