Re: CSP reports on eval() and inline

Thanks for the field experience, Neil.

In general, I think this is one of the more under-specified parts of the spec, and the variation has real impact on users.  (It also makes writing tests difficult.)

If one implementation is reporting something that users find sane and useful, where other implementations aren't reporting anything, documenting and converging on the existing useful behavior would be my strongest preference.

For the sake of completeness in this area, do javascript: urls get reported as such or just an inline violation? (my tests for that don't have a report-uri and I won't be able to context-switch and fix that for a bit)

-Brad


Also - I'll just throw out my own experience from Test the Web Forward that Safari doesn't send a report at all when blocking eval() at the moment - it seems to have the same bug in that regard that earlier Chrome implementations did.  The interfaces to javascript engines for reporting blocked execution seem to be more troublesome to implement than those with fetch, generally.



On Sep 4, 2014, at 10:02 AM, Neil Matatall <neilm@twitter.com> wrote:

> Firefox's script sample says: "call to eval() or related function
> blocked by CSP" and that's pretty useful.
> 
> Also, if this is plugin noise the line number / column number may be
> skewed if DOM elements are injected.
> 
> On Thu, Sep 4, 2014 at 9:58 AM, Neil Matatall <neilm@twitter.com> wrote:
>> There's already plenty of non-URIs in that value:
>> 
>> null
>> about
>> data:text/javascript;base64,...
>> asset
>> weixin
>> android-webview
>> pixivnanikahelper
>> 
>> Or at least URIs that the standard java URI cannot parse. As a likely
>> unauthenticated endpoint, validation is required either way.

Received on Thursday, 4 September 2014 18:11:54 UTC