canmove, Confirmed users
1,537
edits
(added concerns from reading the spec.) |
(structured the discussion a bit and added some replies) |
||
| Line 5: | Line 5: | ||
squarely in the realm of the Accept header? | 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 | "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. -[[User:SidStamm|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 | 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. -[[User:SidStamm|SidStamm]] | |||
== 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 | 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 | ||
== 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 | 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. -[[User:SidStamm|SidStamm]] | |||
== 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 | What MIME-type is used when sending the Report XML? -EricLaw | ||
| Line 21: | Line 39: | ||
Should there be a "font-src" restriction? -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). -[[User:SidStamm|SidStamm]] | |||