On Tue, Feb 27, 2018 at 6:15 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> In the bug I referenced as [2], people said that they specifically need to > be able to override "negative" certificate validation decisions, so they > may not see this as a compromise. I think an example would be a site > serving a self-signed certificate for a DANE add-on to validate. > I think some of it may relate to Moz Platform questions, since they go to the heart of extensions' behaviours. For example, can extensions allow mixed content when it's been blocked? Can they disable sandboxing if the user requests? There's a spectrum of decisions that a browser makes as an intrinsic part of guaranteeing the security of its users that it does not allow extensions or the like to override, and may not even allow users themselves to override. The design of the new extension model is to try to explicitly make sure each capability granted to extensions is balanced in its security rationale and functionality, and aligns the collective risks against the individual rewards. There's a full spectrum here, well beyond PKI bits, so that's why I suggest it strikes a bit core. It was one of the big benefits of the process-sandboxing efforts, as extensions no longer had an 'implicit' backdoor into the browser process. Would you consider extensions that enabled SHA-1 automatically or disabled technical enforcement of CAs? Fundamentally, the capability to alter trust either grants that ability or is no-different-to that ability. What about an extension called "HTTPS-made-easy" that just disabled all certificate errors, on the view that the Web should be like it was in the HTTP days, and solving the technical hurdle? What about vendors that force-install extensions to Firefox users so they can use a shared key for all of their installations? All of these things become possible or significantly easier with an extension that can confer positive trust on something that Firefox has deemed negative. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
