I've been a firm believer that CSP will evolve over time but that's an
argument for versioning though, not modularity. We are as likely to
have to modify existing behaviors as introduce whole new sets. It's
also not a reason to split the existing functionality into modules.
Lucas
On Oct 20, 2009, at 14:53, Collin Jackson <mozi...@collinjackson.com>
wrote:
It seems to me that thinking ahead would tend to favor the modular
approach, since we're unlikely to guess the most compelling use cases
on the first try, and modules will provide a backwards-compatible
means of evolving the spec to what web authors actually need.
On Tue, Oct 20, 2009 at 2:49 PM, Lucas Adamski <lu...@mozilla.com>
wrote:
We should think ahead, not just a year or two but to the point that
all
current browsers will be EOL and (just like every other feature
that is
currently in HTML5) this will be widely adopted and reliable.
Lucas.
On Oct 20, 2009, at 2:30 PM, Collin Jackson wrote:
Why do web developers need to keep track of which user agents
support
CSP? I thought CSP was a defense in depth. I really hope people
don't
use this as their only XSS defense. :)
On Tue, Oct 20, 2009 at 2:25 PM, Lucas Adamski <lu...@mozilla.com>
wrote:
I'm not sure that providing a modular approach for vendors to
implemented
pieces of CSP is really valuable to our intended audience (web
developers).
It will be hard enough for developers to keep track of which
user agents
support CSP, without requiring a matrix to understand which
particular
versions of which agents support the mix of CSP features they
want to
use,
and what it means if a given browser only supports 2 of the 3
modules
they
want to use. If this means some more up-front pain for vendors in
implementation costs vs. pushing more complexity to web
developers, the
former approach seems to be a lot less expensive in the net.
Lucas.
On Oct 20, 2009, at 1:42 PM, Collin Jackson wrote:
On Tue, Oct 20, 2009 at 1:20 PM, Sid Stamm <s...@mozilla.com>
wrote:
While I agree with your points enumerated above, we should be
really
careful about scope creep and stuffing new goals into an old
idea. The
original point of CSP was not to provide a global security
infrastructure for web sites, but to provide content
restrictions and
help stop XSS (mostly content restrictions). Rolling all sorts
of
extra
threats like history sniffing into CSP will make it huge and
complex,
and for not what was initially desired. (A complex CSP isn't
so bad if
it were modular, but I don't think 'wide-reaching' was the
original aim
for CSP).
I think we're completely in agreement, except that I don't think
making CSP modular is particularly hard. In fact, I think it
makes the
proposal much more approachable because vendors can implement just
BaseModule (the CSP header syntax) and other modules they like
such as
XSSModule without feeling like they have to implement the ones
they
think aren't interesting. And they can experiment with their own
modules without feeling like they're breaking the spec.
One idea that might make a module CSP more approachable for
vendors is
to have a status page that shows the various modules, like this:
https://wiki.mozilla.org/Security/CSP/Modules
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
