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 <[email protected]> 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
[email protected]
https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
