Talk:Security/CSP/Spec

Is there an appropriate forum to discuss this? If so, please post a link. If not, is more misuse of the user-agent header the best way to go, or does handling a certain file type, a policy file, fall squarely in the realm of the Accept header?

Script Languages

"No inline JavaScript will execute" should probably be generalized to "No inline script will execute" as there are a number of different script-protocol handlers in different browsers, and most browsers have the ability to host script other than JavaScript. -EricLaw

Good idea, updated accordingly. -Sidstamm

X-Content-Security-Policy HTTP header

Allowing the X-Content-Security-Policy header "anywhere" in the response clearly isn't correct-- it must be somewhere in the response *headers*. More importantly, it might be worth explicitly specifying that the header should/must appear in the initial headers and specifically not in TRAILER headers, because otherwise the entire page must be buffered to ensure that the policy is retrieved before the user interacts with the page. -EricLaw

Good idea, updated accordingly. We should probably remove the X- from the header name too, eventually. -Sid

Sid: that would require us to write and get published an RFC. :-) - Gerv

Gerv: One can dream. :) X-Content-Security-Policy it will remain for now. -Sid

javascript: URIs

Currently "JavaScript Uris" are restricted by both the "inline" and "eval" rules. This makes it unclear as to which I must allow to permit JavaScript URIs. -EricLaw

This is an unfortunate artifact of the late addition of the two opt-back-in keywords. It seems to me that javascript: URIs are probably "inline" code, but it's not completely clear. They could be considered "eval" code too (since it's code from string). I think maybe we should take the javascript: URIs out of the eval section. Thoughts? -Sid

origin/host/source terminology

Rather than using the term "host" and "source" would it be more accurate to replace all instances with "HTML5 Origin"? This term has a defined meaning and would remove ambiguity in cases (like report-uri) which are currently defined as both "same host" and "same source". -EricLaw

self: "self" is defined as the scheme/host/port (origin) in the prose, but the flowchart defines it as document.domain. Which is it? -EricLaw

"self" is scheme/host/port (origin). The flow chart is wrong and will be repaired. -Sid

syntax

The Host Expression List should describe exactly what types of wildcarding are permitted. For instance, can a * represent more than one DNS label? Can * appear in the middle or end of a string? -EricLaw

implementation details

What MIME-type is used when sending the Report XML? -EricLaw

Should the HTTP header syntax allow a "Final" directive to force ignoring META tag declarations? -EricLaw

Shouldn't "object-src" allow restrictions on what TYPES of objects are allowed, rather than just which hosts are allowed? -EricLaw

Should there be a "font-src" restriction? -EricLaw

Good question. Right now fonts are subject to the "allow" catch-all directive, and loading third-party fonts requires loosening that restriction. Perhaps we should discuss adding such a directive as well as an xhr-source directive (for when cross-site xhr explodes). -Sid