X-IMHO-Hat: On Purely regarding opt-in vs opt-out:
One significant advantage of the opt-out (of protections) approach rather than the opt-in approach is that it generally maps well to common web developer workflows.
The opt-out model generally requires web developers to model their expected application behavior (which API's they use, that external advertisers they import, which image servers they use, plugins they allow, etc.) This only requires knowledge of their expected site behavior, but little security knowledge. It also has advantages in testing insofar that the developer only needs to add directives until their website works properly, which is the type of positive testing web developers are generally quite good at.
One weakness with opt-in is that it requires the developer to understand what threats they want to mitigate and implement those restrictions correctly. This is much harder for web developers to do from my experience, as it requires significant security knowledge; the complexity of the policy will always have to be somewhat proportional to the complexity of the site so I don't think we can design this problem away. Now I completely agree that given a flexible enough model (opt-in or opt-out) what you would see develop is common policies being developed into patterns, so the developer could hopefully find the right set of patterns to help them implement their policies, given the right resources and some basic security knowledge. However, the issue is that the developer still can't determine if those policies are the strongest policies from a security standpoint, since its a negative testing problem. So the model I would recommend for web developers that want optimal security would be to enable all of the protections, then loosen them individually until the site works properly. Which is really no different from the opt- out model. This is a general best practice for securing any environment (ask anyone in IT).
So it seems regardless of opt-in vs opt-out, the optimal approach for web developers is to model what their expected environment is and enable only that functionality. Both models suffer from the same flaw of course: the developer could enable things that allow their site to operate properly but also leave them wide open to attack.
I have to say as an aside, there has been a lot of argument about which model is more extensible or less complex. Frankly that all seems rather subjective to me and not super productive, so I'd probably be more effective if nobody assumed their model is inherently more or less complex as we are not getting any closer to consensus there. If there are specific areas where we can actually compare complexity, then please lets just focus on those. So far I haven't seen a single concrete example. From https://wiki.mozilla.org/Security/CSP/Strawman (thank you for posting that, btw), they seem largely equivalent in terms of nature and number of directives. Thanks,
Lucas. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
