On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne <bste...@mozilla.com> wrote: > 1. Splitting the modules based upon different threat models doesn't seem to > be the right approach. There are many areas where the threats we want to > mitigate overlap in terms of browser functionality. A better approach, > IMHO, is to create the modules based upon browser capabilities. With those > capability building blocks, sites can then construct policy sets to address > any given threat model (including ones we haven't thought of yet).
Would that mean that each module would have multiple directives, with a separate threat model for each one? It seems like the directives should be granular to the level of threat models, or else a site will be forced to give up functionality to defend against threats it's not concerned about. > 2. The original goal of CSP was to mitigate XSS attacks. The scope of the > proposal has grown substantially, which is fine, but I'm not at all > comfortable with a product that does not require the XSS protections as the > fundamental core of the model. I think if we go with the module approach, > the XSS protection needs to be required, and any additional modules can be > optionally implemented. I think it makes sense to have modules that are required for browser vendos to implement, but are not required for web authors to enable. Is that what you mean? We could make the XSSModule "required" for browser vendors to implement instead of just "recommended." I don't, however, think that a web author should be required to use the XSSModule in order to benefit from the ClickJackingModule (for example). > I propose that the default behavior for CSP (no > optional modules implemented) is to block all inline scripts (opt-in still > possible) and to use a white list for all sources of external script files. I understand the desire to have "by-default" security, but one problem with opt-out CSP rules is that they're hard to change. You can't add new opt-out rules in the future because it will break web sites that didn't know they were supposed to opt out, so we'd be stuck with an initial set of opt-out rules and any rules added in future versions of the spec would have to be opt-in. Also, it's tricky to change an opt-out rule to be an opt-in rule in the future because web sites may be relying on the opt-out behavior. If there are a set of behaviors that make sense when used together, then maybe providing a concise opt-in directive that enables them all would be easier, e.g. "core-xss". > I'm definitely not opposed to splitting apart the spec into modules, > especially if it helps other browser implementers move forward with CSP. I > REALLY think, though, that the XSS protections need to be part of the base > module. Could you elaborate a little more on why you feel this way? This seems like a major extensibility limitation that would be impossible to change in the future. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
