The likely end of DownThemAll

>Electrolysis apparently breaks XUL extensions.

This is wrong. It absolutely does not break XUL extensions per-se. Add-ons will require some (moderate for most add-ons) changes when accessing out-of-process web content. A lot of add-ons may not even require changes at all, because they either do not access web content directly in the first place, or the Cross-Process-Wrappers and shims mozilla already implemented will be enough (changes might be still wise to get away from a blocking wrapper-API to the async frame script API, but that matters only for perceived performance of the browser, not for security)

DownThemAll! for example does already support e10s in the Nightly builds since quite some time, NoScript supported e10s in the past, Greasemonkey spend 9 months to add e10s support (Anthony tells in a comment to the original blog post). GM is admittedly an add-on that required a lot of changes to make it work, but it does work now apparently.

https://developer.mozilla.org/en-US/Add-ons/Working_with_mul...

I think it's more that nowadays the browser is the most important, if not the only way users interact with a computer, so any change in look/functionality is going to have an enormous impact on their digital lives.

Due to the ongoing nature of threats and exploits users also cannot opt for not upgrading, like they could for, say, a text editor, a painting program, etc. they are more or less implicitly forced to keep up with the releases, which means they are at the mercy of the browser developer's decisions a lot more than other software users.

It is understandable from a development perspective that there is a tying of functionality and security upgrades, on the other hand it is not the most user friendly paradigm around for those who prefer their customized environments not to have unintended changes.

Off topic. The url reads like down-the-mall in all lower case. s/Can be a pivot if no backoff from Mozilla/s

Something I just thought of... if these changes are presumably meant to keep malware addons out of the browser, then it's necessarily operating in an infected environment.

(I.e. something already had the ability to do things in the context of the user without that user's permission, and we're just preventing it from doing this one thing via restricting what the user can do)

In what way does this meaningfully secure the browser from malware, with that in mind? If I've got code running in the user's account, I don't need to hook into the browser engine to direct the user at popup ads, phishing sites, harvest their keystrokes, or do any number of other evil things. Hooking into the browser is one of the least interesting things that evil me could be doing. I've got access to the browser's memory, the TCP stream, the ability to launch whatever programs the user does, and am probably traveling along with a payload to allow for privilege escalation.

So, WTF?

Don't be so pessimistic. 18 months are a lot of time, Mozilla folks are smart and often listen to their users, there's the browser.html experiment going on, etc.

I have a gut feeling that in a way or another, things will roughly be the same for extensions developers.