W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: Scope and complexity (was Re: More on XSS mitigation)

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 25 Jan 2011 13:45:50 -0800
Message-ID: <AANLkTim3EDp=6H+Gbe12BtN+in2aZ2KqLi5QJ5yen6Sn@mail.gmail.com>
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

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

Received on Tuesday, 25 January 2011 21:46:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:25 UTC