- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Tue, 01 Oct 2013 14:51:59 -0700
- To: Glenn Adams <glenn@skynav.com>
- CC: Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <524B43FF.2020104@mozilla.com>
On 10/1/2013 1:46 PM, Glenn Adams wrote: > "Privilege escalation vulnerabilities are common in Firefox, and > comprise roughly a third of the critical vulnerability advisories. [...]" > > I can't comment on the age of this report or whether the same concerns > remain active, but it is sufficient to cause me to be concerned about > this as an attack vector. That seems to be a concern about Firefox, not add-ons. > In my commenting here, I am representing Cox, who, as a commercial video > service provider, is required to meet regulatory requirements about > presenting Emergency Alert Messages to end users while they are actively > using this service. Failure to do everything reasonably possible to > present an Emergency Alert could have liability consequences. The internet in general and the World Wide Web in particular are not a video service. How does this requirement apply in any way? > It seems reasonable on our reading of CSP that it do a better job of > reducing exposure to attacks from compromised add-on script injection, I'd worry far more about malicious addons than compromised ones. The former is a reality, but CSP isn't going to help that problem. > Again, I'm attempting to find a better balance than that suggested by > current CSP specification text, which states "a CSP policy /should > not/ interfere with the operation of user-supplied scripts such as > third-party user-agent add-ons". I believe this is too open-ended and > that reasonable technical options exist to better protect both end user > and content author. My eventual plan for Firefox is to let an add-on specify a CSP whitelist. This lets the add-ons do what the user presumably want them to do but by default means add-ons will respect CSP. The explicit steps to override CSP can then be reviewed and won't accidentally introduce issues. Although perhaps not as wide open as the spec implies I think that fits with the spirit of the spec ("should not", not "must not"). -Dan Veditz
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 1 October 2013 21:52:33 UTC