5 ms·

This is what is going to happen to most extensions. Mozilla is bonkers, doing this. They're going to regret it.

29052017 9y ago
Bhag bhosdike
mixedCase 9y ago
Are they? The old system is holding improvements back. If they move to a superset of Chrome's they can still get Chrome add-ons and then some. If people value the old extension system that much, then it will live on in one of the FF forks. Regardless Firefox will finally get faster, more responsive, more secure, AND still have a better extension API than Blink/WebKit.
- sweep3r 9y ago
  >If people value the old extension system that much, then it will live on in one of the FF forks. Using a fork is also bonkers. I don't trust the security of my web browsing on a fork. Most people won't, either. So Firefox will just get this nice metric saying "most people have not moved to a fork" and will be able to pat themselves in the back. But it's bogus.
  - walterbell 9y ago
    Forks (or old versions of Firefox + extensions) can be run in isolated VMs on platforms like Qubes.
    - 4c2383f5c88e911 9y ago
      That's kind of a moot point when your browser handles most of your online interactions (and therefore a good chunk of your online identity, which is quite valuable to most people). Even if you isolate it as much as you can, which is a good thing to do in any case, it can still do a lot of damage without escaping the sandbox.
      - walterbell 9y ago
        Yes, usage of isolated browser instances should be restricted to information within a single context or risk profile. E.g. a stateless, frequently rebooted VM for occasional use of a particular extension. Or a Bromium micro-VM for each tab, redirect, etc.
        testestx 9y ago
        This is totally impractical, or people would be already doing this when using other browsers as a defense in depth thing.
        walterbell 9y ago
        Bromium claims to be seamless to end-users, but it's not available to consumers, except on some HP devices, https://www.theregister.co.uk/2017/02/13/hp_bromium_virtualization/ https://www.theregister.co.uk/2017/02/13/hp_bromium_virtuali... As for practicality, if your daily workflow involves a browser extension that has no replacement, the options are: - stop doing the task - all browsing with insecure browser, no isolation - single task with insecure browser, no isolation - single task with insecure browser, some isolation Most people will do #2 or #3. Those who care about security will do #4, with quality of isolation dependent on their threat model.
- Grue3 9y ago
  The only reason to use Firefox is because many of its extensions are not possible in any other browser. Watch the market share drop after the extensions are dumbed down to Chrome level.
  - sethhochberg 9y ago
    I dunno - I'm a very technical user and I use a pretty vanilla Firefox mostly just because I like/trust Mozilla and don't want to support the web becoming a Webkit / Chrome monoculture. The only addon I use is LastPass. They support the new extension format just fine. I'm looking forward to the architectural changes coming in Servo, etc, which WebExtensions help make possible. I can't be the only user like me.
    - nindalf 9y ago
      Ditto here. I use Firefox exclusively and all of my extensions are supported - OneTab, ublock origin, Lastpass. I fail to understand the narrative of "the only thing keeping FF alive is the handful of extensions that can't be ported to Chrome". I don't think the extension API is where this battle will be fought anyway. Performance and reliability are what users care about - is the browser fast to open, are pages fast to load, is it making other apps slow (memory and CPU consumption), how many tabs can I keep open, does it hang, does it crash, does any website fail to load/misbehave? I'm confident Firefox will outstrip Chrome in these areas in the next year or so. But if it doesn't... it will die a slow death and the people on HN will assure us it was because NoScript didn't work anymore.
      - seba_dos1 9y ago
        Thankfully, NoScript will still work just fine - it's already a WebExtension/XUL hybrid and Firefox 57 will bring last changes needed to make it fully WebExtensionified :)
  - ohthehugemanate 9y ago
    Only reason? I use Firefox because it's way faster, more stable, and from an organization that I trust. I run Nightly, which means that I made the shift to Webextensions last week. My only extension that didn't have a WE version or alternative was LastPass. No surprise, since they seem to take such poor care of their extensions anyway. That's a Deal Breaker for me, so I switched to pass.
Animats 9y ago
Only about 20% of Firefox add-ons have been converted to WebExtension format. One of the headaches is that access to local storage is asynchronous (in the "promise" sense) in WebExtensions. As a result, if you want something based on stored data such as a stored script or a blocklist to happen early, during page load, you can't get it to run soon enough. This breaks Greasemonkey[1] and NoScript.[2] WebExtensions needs some extensions for them to work. The new features appear to be coming, but represent divergence from cross-platform WebExtensions, and they may not be working in the release version before the XUL death date. Fortunately, my own add-on didn't need anything that isn't working yet, so I had a successful port. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1332273 https://bugzilla.mozilla.org/show_bug.cgi?id=1332273 [2] https://blog.mozilla.org/addons/2017/08/01/noscripts-migration-to-webextensions-apis/ https://blog.mozilla.org/addons/2017/08/01/noscripts-migrati...
- clarry 9y ago
  > if you want something based on stored data such as a stored script or a blocklist to happen early, during page load, you can't get it to run soon enough. This breaks Greasemonkey[1] and NoScript.[2] How does UBO work? Or is it broken too? EDIT: Thanks for the replies. I know there's a webext version of UBO, but that doesn't really explain why the problem I quoted would affect noscript and greasemonkey but not ubo?
  - Animats 9y ago
    There were problems, but they seem to be past them.[1] [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1309926 https://bugzilla.mozilla.org/show_bug.cgi?id=1309926
  - naibafo 9y ago
    UBlock Origin has a working version in the dev channel [1] [1] https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/versions/beta?page=1#version-1.13.9b7 https://addons.mozilla.org/en-US/firefox/addon/ublock-origin...
- naibafo 9y ago
  At least the ones I use are all migrating and the issue at the moment is more, that new versions are pushed to the Mozilla store but waiting for approval - If Mozilla doesn't speed up that process, a lot of extensions will probably be missing for a while. The only really sad thing is that pentadactyl/vimperator won't work at all and require complete rewrites to cover at least part of the old functionality.
pilif 9y ago
the same people who are most vocal about this are the same people that are most vocal about not having multi process support and about having compatibility issues with extensions when the browser updates or when one extension steps onto another extension (all old-style extensions share a single namespace). Web Extensions are designed in such a way that these issues can go away. Apparently Mozilla weighs the complaints with regards to missing multiprocess support and addon security issues higher than they weigh the complaints about the old extensions going away. I wouldn't call this decision "bonkers" either as, clearly, adding security is more important than keeping the platform stuck in the past in order to keep addons used by a minority of users working.
- quazeekotl 9y ago
  >the same people who are most vocal about this are the same people that are most vocal about not having multi process support and about having compatibility issues with extensions when the browser updates or when one extension steps onto another extension (all old-style extensions share a single namespace). These strawpeople exist only in your mind.
toyg 9y ago
> Mozilla is bonkers, doing this. No they are not. Anyone who has done (or tried to do) any cross-browser extension development will attest that working with Chrome-style apis is so much faster than trying to make sense of XUL. Look at how many new extensions start life as Chrome-only these days. Chrome did to Firefox what Firefox did to IE - which had an extension mechanism that required C++ (!). Ease of development always wins, because humans are lazy. Mozilla tried for years (and failed) to match that ease of development, and then decided XUL is not a hill worth dying on - especially considering how it also held back a lot of performance-related improvements. As others have said, it will hurt but it's worth doing if the browser is to survive. It would have probably come sooner had it not been for the FFOS distraction. Once the ecosystem is fully rebased on webextensions, then Mozilla can try an embrace-and-extinguish play if they really want to.

29052017 9y ago

Bhag bhosdike

Are they? The old system is holding improvements back. If they move to a superset of Chrome's they can still get Chrome add-ons and then some. If people value the old extension system that much, then it will live on in one of the FF forks. Regardless Firefox will finally get faster, more responsive, more secure, AND still have a better extension API than Blink/WebKit.

sweep3r 9y ago
>If people value the old extension system that much, then it will live on in one of the FF forks. Using a fork is also bonkers. I don't trust the security of my web browsing on a fork. Most people won't, either. So Firefox will just get this nice metric saying "most people have not moved to a fork" and will be able to pat themselves in the back. But it's bogus.
- walterbell 9y ago
  Forks (or old versions of Firefox + extensions) can be run in isolated VMs on platforms like Qubes.
  - 4c2383f5c88e911 9y ago
    That's kind of a moot point when your browser handles most of your online interactions (and therefore a good chunk of your online identity, which is quite valuable to most people). Even if you isolate it as much as you can, which is a good thing to do in any case, it can still do a lot of damage without escaping the sandbox.
    - walterbell 9y ago
      Yes, usage of isolated browser instances should be restricted to information within a single context or risk profile. E.g. a stateless, frequently rebooted VM for occasional use of a particular extension. Or a Bromium micro-VM for each tab, redirect, etc.
      - testestx 9y ago
        This is totally impractical, or people would be already doing this when using other browsers as a defense in depth thing.
        walterbell 9y ago
        Bromium claims to be seamless to end-users, but it's not available to consumers, except on some HP devices, https://www.theregister.co.uk/2017/02/13/hp_bromium_virtualization/ https://www.theregister.co.uk/2017/02/13/hp_bromium_virtuali... As for practicality, if your daily workflow involves a browser extension that has no replacement, the options are: - stop doing the task - all browsing with insecure browser, no isolation - single task with insecure browser, no isolation - single task with insecure browser, some isolation Most people will do #2 or #3. Those who care about security will do #4, with quality of isolation dependent on their threat model.
Grue3 9y ago
The only reason to use Firefox is because many of its extensions are not possible in any other browser. Watch the market share drop after the extensions are dumbed down to Chrome level.
- sethhochberg 9y ago
  I dunno - I'm a very technical user and I use a pretty vanilla Firefox mostly just because I like/trust Mozilla and don't want to support the web becoming a Webkit / Chrome monoculture. The only addon I use is LastPass. They support the new extension format just fine. I'm looking forward to the architectural changes coming in Servo, etc, which WebExtensions help make possible. I can't be the only user like me.
  - nindalf 9y ago
    Ditto here. I use Firefox exclusively and all of my extensions are supported - OneTab, ublock origin, Lastpass. I fail to understand the narrative of "the only thing keeping FF alive is the handful of extensions that can't be ported to Chrome". I don't think the extension API is where this battle will be fought anyway. Performance and reliability are what users care about - is the browser fast to open, are pages fast to load, is it making other apps slow (memory and CPU consumption), how many tabs can I keep open, does it hang, does it crash, does any website fail to load/misbehave? I'm confident Firefox will outstrip Chrome in these areas in the next year or so. But if it doesn't... it will die a slow death and the people on HN will assure us it was because NoScript didn't work anymore.
    - seba_dos1 9y ago
      Thankfully, NoScript will still work just fine - it's already a WebExtension/XUL hybrid and Firefox 57 will bring last changes needed to make it fully WebExtensionified :)
- ohthehugemanate 9y ago
  Only reason? I use Firefox because it's way faster, more stable, and from an organization that I trust. I run Nightly, which means that I made the shift to Webextensions last week. My only extension that didn't have a WE version or alternative was LastPass. No surprise, since they seem to take such poor care of their extensions anyway. That's a Deal Breaker for me, so I switched to pass.

Animats 9y ago

Only about 20% of Firefox add-ons have been converted to WebExtension format. One of the headaches is that access to local storage is asynchronous (in the "promise" sense) in WebExtensions. As a result, if you want something based on stored data such as a stored script or a blocklist to happen early, during page load, you can't get it to run soon enough. This breaks Greasemonkey[1] and NoScript.[2] WebExtensions needs some extensions for them to work. The new features appear to be coming, but represent divergence from cross-platform WebExtensions, and they may not be working in the release version before the XUL death date. Fortunately, my own add-on didn't need anything that isn't working yet, so I had a successful port. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1332273 https://bugzilla.mozilla.org/show_bug.cgi?id=1332273 [2] https://blog.mozilla.org/addons/2017/08/01/noscripts-migration-to-webextensions-apis/ https://blog.mozilla.org/addons/2017/08/01/noscripts-migrati...

clarry 9y ago
> if you want something based on stored data such as a stored script or a blocklist to happen early, during page load, you can't get it to run soon enough. This breaks Greasemonkey[1] and NoScript.[2] How does UBO work? Or is it broken too? EDIT: Thanks for the replies. I know there's a webext version of UBO, but that doesn't really explain why the problem I quoted would affect noscript and greasemonkey but not ubo?
- Animats 9y ago
  There were problems, but they seem to be past them.[1] [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1309926 https://bugzilla.mozilla.org/show_bug.cgi?id=1309926
- naibafo 9y ago
  UBlock Origin has a working version in the dev channel [1] [1] https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/versions/beta?page=1#version-1.13.9b7 https://addons.mozilla.org/en-US/firefox/addon/ublock-origin...
naibafo 9y ago
At least the ones I use are all migrating and the issue at the moment is more, that new versions are pushed to the Mozilla store but waiting for approval - If Mozilla doesn't speed up that process, a lot of extensions will probably be missing for a while. The only really sad thing is that pentadactyl/vimperator won't work at all and require complete rewrites to cover at least part of the old functionality.

pilif 9y ago

the same people who are most vocal about this are the same people that are most vocal about not having multi process support and about having compatibility issues with extensions when the browser updates or when one extension steps onto another extension (all old-style extensions share a single namespace). Web Extensions are designed in such a way that these issues can go away. Apparently Mozilla weighs the complaints with regards to missing multiprocess support and addon security issues higher than they weigh the complaints about the old extensions going away. I wouldn't call this decision "bonkers" either as, clearly, adding security is more important than keeping the platform stuck in the past in order to keep addons used by a minority of users working.

quazeekotl 9y ago
>the same people who are most vocal about this are the same people that are most vocal about not having multi process support and about having compatibility issues with extensions when the browser updates or when one extension steps onto another extension (all old-style extensions share a single namespace). These strawpeople exist only in your mind.

toyg 9y ago

> Mozilla is bonkers, doing this. No they are not. Anyone who has done (or tried to do) any cross-browser extension development will attest that working with Chrome-style apis is so much faster than trying to make sense of XUL. Look at how many new extensions start life as Chrome-only these days. Chrome did to Firefox what Firefox did to IE - which had an extension mechanism that required C++ (!). Ease of development always wins, because humans are lazy. Mozilla tried for years (and failed) to match that ease of development, and then decided XUL is not a hill worth dying on - especially considering how it also held back a lot of performance-related improvements. As others have said, it will hurt but it's worth doing if the browser is to survive. It would have probably come sooner had it not been for the FFOS distraction. Once the ecosystem is fully rebased on webextensions, then Mozilla can try an embrace-and-extinguish play if they really want to.