Wow, this is a tough one. I've wanted to write such an extension myself for quite some time. In fact, I probably would write one or more extensions, if Mozilla were to allow this, for a variety of use cases. That said, such extensions are extremely dangerous, and users are just going to accept any warning that might exist about using such an extension. But I don't think designing for the ignorant and clueless is wise. You'll just find better idiots.
I personally find persuasive the argument that an extension already has the ability to do equivalently bad things. The research group I used to work with many years ago did lots of work with application extensions of all kinds, and web extensions in particular were obscenely powerful because of the very rich structure of the Document Object Model. I'm sure (I hope!) things have been tightened up at least a little bit since then, but I think in the presence of a malicious extension, the question of whether it can affect the connection UI is rather moot. Naïve users are going to lose to a malicious extension every time, no matter what, and I seriously doubt that even sophisticated users will have much of a chance in such scenarios, whether the connection UI can be changed by the extension, or not. It's probably useful to discuss this in conjunction with what controls Mozilla has available in its ecosystem to combat malicious extensions in general, as opposed to this particular case, which doesn't seem to be very special. That more general question might lead to good principles that can be applied in this specific situation. Basically, I think it's a question of what the security model/policy for extensions should be, how to balance the risks vs benefits of various pieces of exposed functionality. The tension between powerful, open APIs and limited, but safer APIs has existed forever, and there isn't one point on the spectrum that is optimal. We recently had a case internally where some Office automation was not possible due to some ad hoc restrictions imposed during the ILOVEYOU era. Addressing security risks piecemeal instead of holistically generally results in a random set of arbitrary restrictions instead of a coherent security model. Figure out what the security policy and security model is, and it will tell you whether allowing extensions to modify the connection UI is ok. -Tim > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Tuesday, February 27, 2018 9:21 AM > To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Allowing WebExtensions to Override Certificate Trust Decisions > > I am seeking input on this proposal: > > Work is underway to allow Firefox add-ons to read certificate information via > WebExtensions APIs [1]. It has also been proposed [2] that the WebExtensions > APIs in Firefox be enhanced to allow a 3rd party add-on to change or ignore > the > normal results of certificate validation. > > This capability existed in the legacy Firefox extension system that was > deprecated last year. It was used to implement stricter security mechanisms > (e.g. CertPatrol) and to experiment with new mechanisms such as Certificate > Transparency and DANE. > > When used to override a certificate validation failure, this is a dangerous > capability, and it’s not clear that requiring a user to grant permission to > the > add-on is adequate protection. One solution that has been proposed [4] is to > allow an add-on to affect the connection but not the certificate UI. > In other words, when a validation failure is overridden, the page will load > but > the nav bar will still display it as a failure. > > I would appreciate your constructive feedback on this decision. Should this > capability be added to the Firefox WebExtensions APIs? > > - Wayne > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951 > [3] https://mail.mozilla.org/pipermail/dev-addons/2018- > February/003629.html > [4] https://mail.mozilla.org/pipermail/dev-addons/2018- > February/003641.html > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
