2015-07-31
The future problem with Firefox's Electrolysis project
Firefox Electrolysis ('e10s' for short) is a project to push Firefox towards a multiprocess model like Chrome's. This is both a daunting amount of work and a praiseworthy goal with a number of benefits, but there is a problem lurking in the future and that is Firefox addons.
The direct problem is that any number of addons are not Electrolysis compatible for technical reasons. Firefox developers have partly worked around this with shims, but shims are an incomplete solution and can't make all addons work. Checking arewee10syet makes for depressing reading much of the time; a great many popular extensions are not working under Electrolysis (including NoScript, one of my critical extensions). It seems quite likely that a number of reasonably popular extensions will never be updated to be Electrolysis compatible and so people will be faced with a choice between not getting Electrolysis or abandoning them (the likely choice here being 'don't go e10s').
(The popularity of an addon has no relationship with the attention and spare time of its developer(s). There are any number of popular addons that have basically been abandoned by their developers.)
The indirect problem is that at some point Mozilla is going to want to turn Electrolysis on by default in a released Firefox version. In a straightforward version of the switch, some amount of reasonably popular extensions will partially or completely stop working. If people are lucky this will be obvious, so at least you know that you have a different browser now; if people are unlucky, the extension will quietly stop doing whatever it does, which is bad if this is, say, 'protecting me from some sort of bad stuff'. There are various things Firefox could do here to avoid silent breakage, like not enabling Electrolysis unless all your addons are known to be e10s compatible or warning you about some addons perhaps breaking, but none of the options are particularly good ones.
(Well, they're not particularly good ones if Mozilla's goal is widespread Electrolysis adoption. Mozilla could take the safe conservative approach if they wanted to; I just don't think they will, based on past behavior.)
When this future comes to pass, knowledgeable people can go in and turn off Electrolysis in order to get a fully working browser back (at least one hopes). Other people, well, I suspect we're going to see a lot of quietly or loudly upset people and Firefox is going to leak some more browser share as well as seeing some more people turn off Firefox automatic updates (with the resulting damage to security).
Ubuntu once again fails at a good kernel security update announcement
Ubuntu just sent out USN-2700-1, a 14.04 LTS announcement about a kernel update for CVE-2015-3290, CVE-2015-3291, and CVE-2015-5157. People with good memories may at this point remember USN-2688-1, a 14.04 LTS announcement about a kernel update for CVE-2015-3290, CVE-2015-1333, CVE-2015-3291, and CVE-2015-5157. Gosh, that's a familiar list of CVEs, and it sort of looks like the 'repeated CVEs' thing Ubuntu has done before. If you already applied the USN-2688-1 kernel and rebooted everything, it certainly sounds like you can skip USN-2700-1.
That would be a mistake. What Ubuntu is not bothering to mention in USN-2700-1 is that the 64-bit x86 kernels from USN-2688-1 had a bad bug. In that kernel, if a 32-bit program forks and then execs a 64-bit program the 64-bit program segfaults on startup; for example, a 32-bit shell will be unable to run any 64-bit programs (which will be most of them). This bug is the sole reason USN-2700-1 was issued (literally).
The USN-2700-1 text should come with a prominent notification to the effect of 'the previous update introduced a serious bug on 64-bit systems; we are re-issuing corrected kernels without this problem'. Ubuntu has put such notices on updates in the past so the idea is not foreign to them; they just didn't bother doing it this time around. As a result, people who may be affected by this newly introduced kernel bug do not necessarily know that this is their problem and they should update to the USN-2700-1 kernel to fix it.
(At best they may start doing a launchpad bug search and find the bug report. But I don't think it's necessarily all that likely, because the bug's title is not particularly accurate about what it actually is; 'Segfault in ld-2.19.so while starting Steam after upgrade to 3.13.0-59.98' does not point clearly to a 32-bit on 64-bit issue. It doesn't even mention 'on 64-bit platforms' in the description.)
Kernel update notices matter because people use them to decide whether or not to go through the hassle of a system reboot. If a notice is misleading, this goes wrong; people don't update and reboot when they really should. When there are bugs in a kernel update, as there were here, not telling people about them causes them to try to troubleshoot a buggy system without realizing that there is a simple solution.
(Lucky people noticed failures on the USN-2688-1 kernel right away, and so were able to attribute them to the just-done kernel update. But unlucky people will only run into this once in a while, when they run a rare lingering 32-bit program that does this, and so they may not immediately realize that it was due to a kernel update that might now be a week or two in the past.)
(See also a previous Ubuntu kernel update failure, from 2011.)