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.
  - 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.
    - sweep3r 9y ago
      Firefox is way faster than what? IE6?
      - jsudhams 9y ago
        I don't use extension any extension but i use Firefox on Desktop and Mobile. From end user wait time etc i dont see any difference between firefox and chrome. For some reason firefox is seem to be faster than chrome on mobile. I use firefox focus mostly on mobile. It would be really sad to see firefox go away as that is only one which is not tied to OS or tied to provider of webmail etc. I see firefox as a product from browser company.
      - sgift 9y ago
        Firefox nightly, which will end up as FF57, uses less memory than Chrome and is faster. (Windows, x64). One of the reasons this was possible was disabling the old extension system. Does it hurt? Sure. Was it needed? Yes.
        quazeekotl 9y ago
        Do you have any evidence this is actually true? XUL is still there, the firefox UI is still written in it and it will be for quite some time to come. I find it hard to beleive disallowing XUL extensions have significantly sped anything up.
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.
- 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.
  - sweep3r 9y ago
    Firefox is way faster than what? IE6?
    - jsudhams 9y ago
      I don't use extension any extension but i use Firefox on Desktop and Mobile. From end user wait time etc i dont see any difference between firefox and chrome. For some reason firefox is seem to be faster than chrome on mobile. I use firefox focus mostly on mobile. It would be really sad to see firefox go away as that is only one which is not tied to OS or tied to provider of webmail etc. I see firefox as a product from browser company.
    - sgift 9y ago
      Firefox nightly, which will end up as FF57, uses less memory than Chrome and is faster. (Windows, x64). One of the reasons this was possible was disabling the old extension system. Does it hurt? Sure. Was it needed? Yes.
      - quazeekotl 9y ago
        Do you have any evidence this is actually true? XUL is still there, the firefox UI is still written in it and it will be for quite some time to come. I find it hard to beleive disallowing XUL extensions have significantly sped anything up.

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.