Wandering Thoughts archives


Firefox 57 and the state of old pre-WebExtensions addons

Back in June I wrote an entry about the current state of pre-WebExtensions addons and what I thought was the likely future of them. Based on Mozilla's wiki page on this, which said that legacy extensions could still be loaded on Nightly builds with a preference, I said I expected that they would keep working well into the future. As far as I can currently tell, I was wrong about that and my optimistic belief was completely off.

As of right now given the ongoing state of Firefox Nightly, it appears that Mozilla has abandoned practical compatibility with many old addons. With the preference set, Mozilla may allow Nightly to load them, but Mozilla won't necessarily keep them working; in fact, available evidence suggests that Mozilla has been cheerfully breaking old extension APIs left and right. The only old APIs that we can probably count on continuing to work are the APIs that Mozilla needs for their own use (the 'signed by Mozilla internally' status of legacy extensions in the wiki page), and it's clear that these APIs are not sufficient for many addons.

In particular, all of my addons remain in various states between broken and completely non-functional on Nightly. This situation has not been improving since the preference change landed; if anything they've been getting worse in more recent Nightly versions. Since this has persisted for weeks and weeks, I have to assume that Mozilla no longer cares about general legacy extensions on Nightly and they're either landing code improvements that have no support for them or are actively removing the code that supports legacy extension APIs. Or both. I can't blame Mozilla for this, since they've been saying for years now that they wanted to get rid of the old APIs and the old APIs were holding back Firefox development.

One implication of this is that Mozilla is now fairly strongly committed to their Firefox 57 extension plans, come what may. With legacy extensions broken in practice, Mozilla cannot simply re-flip the preference the other way to back out of the transition and return legacy extensions to operation. Nor do I think they have time to fix the code should they decide they want to. If I'm reading the Firefox release calendar correctly, we're about one or two weeks from Firefox Nightly transmuting into the Firefox 57 beta version, and then six weeks more until Firefox 57 is actually released.

The personal implication for me is that I've now reached the last Nightly version I can use, although it happened perhaps a month later than I thought it would way back when. Now that I look at the dates of things, I think my current Firefox 'Nightly' versions are actually before Firefox 56 branched off, so I should probably switch over to Firefox 56 and freeze on it. That way I'll at least get security fixes until November or so.

Firefox57OldAddonsState written at 01:54:58; Add Comment


My view of the problem with Extended Validation TLS certificates

In a conversation on Twitter, I said:

EV isn't exactly a scam, but it is trying to (profitably) solve a problem that we don't actually know how to solve (and have failed at).

The main problem that plain old TLS certificates solve is making sure that you're talking to the real facebook.com instead of an imposter or a man in the middle. This is why they've been rebranded as 'Domain Validation (DV)' certificates; they validate the domain. DV certificates do this fairly well and fairly successfully; while there are ways to attack them, it's increasingly expensive and risky, and for various reasons the number of people hitting warnings and overriding them is probably going down.

The problem that Extended Validation TLS certificates are attempting to solve is that domain validation is not really sufficient by itself. You usually don't really care that you're talking to google.ca or amazon.com, you care that you're talking to Google or Amazon. In general people care about who (or what) they're connecting to, not what domain name it uses today for some reason.

(Mere domain validation also has issues like IDN homographs and domains called yourfacebooklogin.com.)

Unfortunately for EV certificates, this is a hard problem with multiple issues and we don't know how to solve it. In fact our entire history of trying to inform or teach people about web site security has been an abject failure. To the extent that we've had any meaningful success at all, it's primarily come about not through presenting information to people but by having the browser take away foot-guns and be more militant about not letting you do things.

There is no evidence that EV certificates as currently implemented in browsers do anything effective to solve this problem, and as Troy Hunt has written up there's significant anecdotal evidence that they do nothing at all. Nor are there any good ideas or proposals on the horizon to improve the situation so that EV certificates even come close to tackling the problem in the context where it matters.

Right now and for the foreseeable future what EVs deliver is math, not security. As math they provide you with what they claim to provide you, which makes them not exactly a scam but also not exactly useful. I'm sure the CAs would like for EV certificates to solve the problem they're nominally aimed at, but in the mean time the CAs are happy to take your money in exchange for some hand-curated bits.

Sidebar: Some general issues with what EV certificates are trying to do

First, as far as we know people don't think of who they're talking to in any conveniently legible form, like corporate ownership. We know what we mean by 'Facebook', 'Google', 'Amazon', and so on, but it can be very hard to map this to specific concrete things in the world. See Troy Hunt's saga for one example of translating a theoretically simple 'who this is' concept into something that was more or less legible to a certificate authority and came out more or less right and more or less understandable.

Second, we don't know how to present our theoretical 'who this site is' information to people in a way that they will actually notice, understand, and be able to use. Previous and current attempts to present this information in the browser in a form that people even notice, much less understand, have been abject failures.

Finally, we especially don't even know how to get people to even consider this issue. You see, I cheated in my description of the problem, because in reality people don't even think about who they're connecting most of the time. If it looks like Facebook and your browser isn't complaining, well, it probably is and you'll proceed. This is how people enter their Facebook credentials into 'yourfacebooklogin.com' (and we can't blame them for doing so, for any number of reasons).

(The final issue is a variant of the fundamental email phish problem.)

EVCertificateProblem written at 02:49:38; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.