- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 25 Jan 2011 13:45:50 -0800
- To: Brandon Sterne <bsterne@mozilla.com>
- Cc: Gervase Markham <gerv@mozilla.org>, Lucas Adamski <lucas@mozilla.com>, public-web-security@w3.org
On Tue, Jan 25, 2011 at 12:31 PM, Brandon Sterne <bsterne@mozilla.com> wrote: > On 01/25/2011 10:42 AM, Adam Barth wrote: >> IMHO, in the first iteration we should nail XSS and set up a >> extensible policy framework that we can extend to address other >> threats in the future. > > It doesn't make sense to me to pass over features that have value to > potential implementors for the sake of getting something out there > quickly. Future extensions to the model, while expected, will come with > costs, so we should do our best to reduce the number of iterations. > > Let's deliver something quickly, but let's include as much as we think > is useful, with justifiable levels of complexity, in the first iteration. On Tue, Jan 25, 2011 at 12:13 PM, Lucas Adamski <lucas@mozilla.com> wrote: > Yes, but you are proposing to remove significant amounts of security > protections that others clearly desire and have practical uses for. That > would seem to call for specific compelling arguments that current proposal > is substantially worse than your alternative proposal, and that those > deficiencies outweigh the additional benefits. I guess I wish we had an extensibility model more like HTML where we could grow the security protections over time. For example, we can probably agree that both <canvas> and <video> are great additions to HTML that might not have made sense when folks were designing HTML 1.0. As long as you're not relying on the security policy as a first line of defense, the extensibility story for security policies is even better than it is with HTML tags. With an HTML tag, you need a fall-back for browsers that don't support the tag, whereas with a security policy, you'll always have your first line of defense. Ideally, we could come up with a policy mechanism that let us nail XSS today and that fostered innovation in security for years to come. In the short term, you could view the existing CSP features (e.g., clickjacking protection) as the first wave of innovation. If those pieces are popular, then it should be easy for other folks to adopt them. Adam
Received on Tuesday, 25 January 2011 21:46:49 UTC