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
