- From: Mike West <mkwst@google.com>
- Date: Sat, 7 Feb 2015 08:15:36 +0100
- To: Brian Smith <brian@briansmith.org>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>
- Message-ID: <CAKXHy=evRRQuS=y2Qvt0H8879wFRmLqu9ObetNj4WTAvoS7d0w@mail.gmail.com>
On Fri, Feb 6, 2015 at 8:11 PM, Brian Smith <brian@briansmith.org> wrote: > I think it is best to move "referrer" to the referrer-policy document? > IMO, it makes more sense there, and it will be easier to keep it in > sync with major changes to referrer policy, which seem very likely at > this point. Note that the Mixed Content draft already defines a CSP > directive outside of the CSP spec, so there's now precedent for that. > Otherwise, I don't see how CSP2 can advance to CR until > referrer-policy advances to CR. > Sounds reasonable. I've moved the directive to the Referrer Policy spec, and out of the CSP3 and CSP2 drafts: https://github.com/w3c/webappsec/commit/d8fee06f18d96ccd7cb6e8cbdf144878560459d5 > As for reflected-xss, I agree with deferring it to CSP3. Even if the > working group ultimately decides that CSP shouldn't be a purely > restrictive mechanism, there are several issues with how reflected-xss > is specified (and underspecified) in the CSP2 draft. (I think I have a > rough list of issues with reflected-xss that need to be addressed, if > somebody wants them. But, I don't have time to write it up in the same > level of detail I usually provide.) > A rough list would be great. I really appreciate the time you've spent on detailed feedback, but I don't want to ask you to dive into every detail on this as well. It's marked as "at risk", which gives us freedom to modify/remove during CR. Given that Firefox won't implement anyway (as there's no xss auditor to turn on), it's more or less up to Apple and Microsoft to determine whether they'd like to implement this directive. 1. The semantics of CSP nonce. It is clear what Mike thinks, and I > hope it is clear what I think, but it is not clear whether others' > silence is agreement with what the spec currently says, apathy, or an > indication that the issue hasn't been sufficiently considered. I think > it is better for the spec to be made more secure by making the changes > I suggested in the "Clarifications on nonces" thread, but if there's a > consensus in the working group that it is important for the nonce to > be able to be passed around like a bearer token, I won't argue > further. My concern is that it hasn't been adequately considered. > Ok. I'm not sure how to measure consensus here. :) You (and Dev?) aren't fond of nonces' current behavior. I am. Hopefully other folks will weigh in. > 2. As I mentioned previously, I think it is really unfortunate that > CSP2 isn't properly Unicode-enabled. I know that nobody is > intentionally trying to discriminate against any group of people, but > IMO this incidental discrimination shouldn't be accepted either. I > think this issue deserves the same level of consideration as > accessibility for people with visual impairments. (Note I'm not trying > to diminish the importance of accessibility work.) > To be sure I understand what needs to be done here, you'd like us to: * Remove the recommendation to use punycode (what should we do with punycode? should it match its unicode equiv?) * Allow unicode characters as part of the grammar * Recommend that folks %-encode unicode characters when delivered as an HTTP header Is that accurate? -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Saturday, 7 February 2015 07:16:24 UTC