5 ms·

>> * also, some of the changes that Firefox needed to remain competitive with Chrome were going to break most add-ons immediately, possibly all add-ons in the l

by jolmg 6y ago

>> * also, some of the changes that Firefox needed to remain competitive with Chrome were going to break most add-ons immediately, possibly all add-ons in the longer term; This is probably the most important point. The other points apply to almost any software that supports addons, including emacs, vim, zsh, etc. and they're not really an issue. >> * very quickly, add-on developers realized that anything they did could break anything else in the system, including other add-ons and Firefox itself, and they often had no way to prevent this; So they're careful. Any add-on that breaks other stuff doesn't really get adopted. Emacs shares the same namespace for everything. Addon developers just namespace their stuff by putting a prefix on their identifiers. It's not really an issue even for them. >> * similarly, anything Firefox developers did could break add-ons, and they often had no way to prevent this; So don't change Firefox so drastically. Well, I'd say it's nice for software to be stable, but web browsers are a good exception to that. If Firefox didn't try to keep up with Chrome, Chrome would probably have greater dominance. But yeah, other software would just be more stable. When a change needs to be made, the benefit is weighed against the potential of breaking addons, but I imagine that's probably OK with addon developers as long as the change was reasonable. >> * oh, and by the way, since add-ons could do everything, they could very easily do anything to the operating system, from stealing passwords to pretending to be your bank. Most times, addons are almost like any other program, and should be judged accordingly before installing. I imagine even after the restrictions were placed on addons, they're probably still capable of quite a bit of malice.

gibolt 6y ago
Codebases and products aren't that simple. Changes and maintenance cost money and time. In this case, they deemed it to not be worth the expense to resolve the potential security issues (which can never be truly resolved).
marcinzm 6y ago
>Any add-on that breaks other stuff doesn't really get adopted. Yes it does, Firefox is a mainstream browser not a niche product used by experts. Most people couldn't even figure out which of their fifty extensions was causing issues. So they just used Chrome.
- Polylactic_acid 6y ago
  This is exactly it. Normal users don't think "Huh firefox is crashing, I'm going to disable addons one by one to work out if one of them is the cause" They just think "Wow, firefox is super buggy, I'm using chrome now" And then every time they see firefox mentioned online they leave their comment about how its super buggy and crashes all the time.
  - GoblinSlayer 6y ago
    I just had an idea: to install an extension require authentication by a one time random password, show the password in a modal window without ability to copy, the user will have to remember the password and type it into a field. The password length is equal to the number of installed extensions, so to install 50th extension, you need to type 50 character password.
duskwuff 6y ago
> So they're careful. Any add-on that breaks other stuff doesn't really get adopted. This wasn't true at all. A lot of popular addons interacted with the browser XUL in incredibly intrusive ways. In particular, addons which altered the browser's tabbed browsing interface and/or behavior (like the various Tab Mix extensions, as well as Tree Style Tabs) tended to do so by making radical modifications to XUL, which would often break other extensions which interacted with tabs. > Addon developers just namespace their stuff by putting a prefix on their identifiers. That was not standard practice, unfortunately. Conflicts between extensions were commonplace; it was a rule of thumb to avoid installing multiple extensions which interacted with the same browser feature. > So don't change Firefox so drastically. This would have meant effectively freezing most UI development, to say nothing of more ambitious projects like e10s (multiprocess browsing). It would have led to the inevitable death of the project by stagnation. > Most times, addons are almost like any other program, and should be judged accordingly before installing. You heavily overestimate the degree of scrutiny that users applied to extensions. The fact that they could be installed from a web interface made users treat them very casually. > I imagine even after the restrictions were placed on addons, they're probably still capable of quite a bit of malice. XUL-era extensions had vastly more power than WebExtensions. They were equivalent in power to native executables -- they could run native code, read/write any file on the system, and communicate with any host, all without confirmation -- and there wasn't even any framework to allow developers to voluntarily restrict their power, because they ran in the same context as the rest of the browser chrome.
- Reelin 6y ago
  > You heavily overestimate the degree of scrutiny that users applied to extensions. I apply scrutiny in the form of very carefully vetting the author's identity and reputation. At the end of the day that seems to be a fairly common and reasonably effective approach. > XUL-era extensions had vastly more power than WebExtensions. They were equivalent in power to native executables That was an important feature, not a bug (IMO). Sure WebExtensions are nicely sandboxed away from the OS, but the threat posed by a malicious version of uMatrix or Dark Reader is nonetheless difficult to understate. Certainly many users made poor decisions. Certainly there were valid technical issues at play. But let's not pretend that all users are irresponsible or that there weren't serious drawbacks to what was done in terms of lost functionality. Some of the modifications I made use of still haven't been replicated in WebExtensions due to lack of ability (AFAIK). The only solution I'm aware of would be to patch the browser myself and recompile it, which is an _incredibly_ high barrier to entry (and that's before the ongoing maintenance burden).
danShumway 6y ago
> Emacs shares the same namespace for everything. Addon developers just namespace their stuff by putting a prefix on their identifiers. It's not really an issue even for them. I use and love Emacs (Spacemacs), and I am probably never going to move to another editor. BUT as someone who maintains a Spacemacs config, no, Emacs addons break each other all the time. It's not just a namespacing problem, it's which events you're hooking around or interrupting, it's which system features you're changing that other addons rely on. This kind of organized chaos works out OK in Emacs because I can read the source code of the offending Spacemacs layer or script and wrap around it to get it playing nicely with the rest of my setup. Emacs has very good debugging tools built into it, and you can hack on the editor in the editor. It also has a fairly decent community of people online who will help you debug configs as long as you're not being too annoying about it. This all ends up being pretty important, because you are going to need to debug configs. Emacs expects you to be a power user that knows how to program, and if you are a power user that knows how to program, there are advantages to that. But even with those advantages, the sheer amount of time I've wasted getting EXWM to play nicely with other workspace addons... I just think there's benefits and tradeoffs to both approaches, and I wouldn't be so quick to dismiss the engineers who decided that their users shouldn't need to learn how to program to keep a functioning set of addons running in their web browser.
- Reelin 6y ago
  My question is then: where's the hackabale power user browser implemented in something like Common Lisp with a REPL, hot swap debugging, and built in disassembly tools?
  - ChrisSD 6y ago
    To be honest I'm surprised Emacs isn't a browser yet. It does everything else.
    - danShumway 6y ago
      There are efforts, and there are things you can run, but I wouldn't personally recommend doing so. I am very paranoid about browser security, and I (frankly) don't trust smaller browser projects that aren't highly vetted by lots of people. That's an entirely separate conversation. My opinion is that it ends up being simpler and safer at the end of the day to just wrap the entire Firefox application in an Emacs buffer and then intercept keypresses to that buffer. But you do lose out on a lot of stuff by doing that; I'd love to have tighter integration.
Yoric 6y ago
> But yeah, other software would just be more stable. When a change needs to be made, the benefit is weighed against the potential of breaking addons, but I imagine that's probably OK with addon developers as long as the change was reasonable. We thought that too, for a time, but eventually, we had to realize that we were burning out our add-on developers. (updated the article to clarify this)

by jolmg 6y ago

gibolt 6y ago

Codebases and products aren't that simple. Changes and maintenance cost money and time. In this case, they deemed it to not be worth the expense to resolve the potential security issues (which can never be truly resolved).

marcinzm 6y ago

>Any add-on that breaks other stuff doesn't really get adopted. Yes it does, Firefox is a mainstream browser not a niche product used by experts. Most people couldn't even figure out which of their fifty extensions was causing issues. So they just used Chrome.

Polylactic_acid 6y ago
This is exactly it. Normal users don't think "Huh firefox is crashing, I'm going to disable addons one by one to work out if one of them is the cause" They just think "Wow, firefox is super buggy, I'm using chrome now" And then every time they see firefox mentioned online they leave their comment about how its super buggy and crashes all the time.
- GoblinSlayer 6y ago
  I just had an idea: to install an extension require authentication by a one time random password, show the password in a modal window without ability to copy, the user will have to remember the password and type it into a field. The password length is equal to the number of installed extensions, so to install 50th extension, you need to type 50 character password.

duskwuff 6y ago

> So they're careful. Any add-on that breaks other stuff doesn't really get adopted. This wasn't true at all. A lot of popular addons interacted with the browser XUL in incredibly intrusive ways. In particular, addons which altered the browser's tabbed browsing interface and/or behavior (like the various Tab Mix extensions, as well as Tree Style Tabs) tended to do so by making radical modifications to XUL, which would often break other extensions which interacted with tabs. > Addon developers just namespace their stuff by putting a prefix on their identifiers. That was not standard practice, unfortunately. Conflicts between extensions were commonplace; it was a rule of thumb to avoid installing multiple extensions which interacted with the same browser feature. > So don't change Firefox so drastically. This would have meant effectively freezing most UI development, to say nothing of more ambitious projects like e10s (multiprocess browsing). It would have led to the inevitable death of the project by stagnation. > Most times, addons are almost like any other program, and should be judged accordingly before installing. You heavily overestimate the degree of scrutiny that users applied to extensions. The fact that they could be installed from a web interface made users treat them very casually. > I imagine even after the restrictions were placed on addons, they're probably still capable of quite a bit of malice. XUL-era extensions had vastly more power than WebExtensions. They were equivalent in power to native executables -- they could run native code, read/write any file on the system, and communicate with any host, all without confirmation -- and there wasn't even any framework to allow developers to voluntarily restrict their power, because they ran in the same context as the rest of the browser chrome.

Reelin 6y ago
> You heavily overestimate the degree of scrutiny that users applied to extensions. I apply scrutiny in the form of very carefully vetting the author's identity and reputation. At the end of the day that seems to be a fairly common and reasonably effective approach. > XUL-era extensions had vastly more power than WebExtensions. They were equivalent in power to native executables That was an important feature, not a bug (IMO). Sure WebExtensions are nicely sandboxed away from the OS, but the threat posed by a malicious version of uMatrix or Dark Reader is nonetheless difficult to understate. Certainly many users made poor decisions. Certainly there were valid technical issues at play. But let's not pretend that all users are irresponsible or that there weren't serious drawbacks to what was done in terms of lost functionality. Some of the modifications I made use of still haven't been replicated in WebExtensions due to lack of ability (AFAIK). The only solution I'm aware of would be to patch the browser myself and recompile it, which is an _incredibly_ high barrier to entry (and that's before the ongoing maintenance burden).

danShumway 6y ago

> Emacs shares the same namespace for everything. Addon developers just namespace their stuff by putting a prefix on their identifiers. It's not really an issue even for them. I use and love Emacs (Spacemacs), and I am probably never going to move to another editor. BUT as someone who maintains a Spacemacs config, no, Emacs addons break each other all the time. It's not just a namespacing problem, it's which events you're hooking around or interrupting, it's which system features you're changing that other addons rely on. This kind of organized chaos works out OK in Emacs because I can read the source code of the offending Spacemacs layer or script and wrap around it to get it playing nicely with the rest of my setup. Emacs has very good debugging tools built into it, and you can hack on the editor in the editor. It also has a fairly decent community of people online who will help you debug configs as long as you're not being too annoying about it. This all ends up being pretty important, because you are going to need to debug configs. Emacs expects you to be a power user that knows how to program, and if you are a power user that knows how to program, there are advantages to that. But even with those advantages, the sheer amount of time I've wasted getting EXWM to play nicely with other workspace addons... I just think there's benefits and tradeoffs to both approaches, and I wouldn't be so quick to dismiss the engineers who decided that their users shouldn't need to learn how to program to keep a functioning set of addons running in their web browser.

Reelin 6y ago
My question is then: where's the hackabale power user browser implemented in something like Common Lisp with a REPL, hot swap debugging, and built in disassembly tools?
- ChrisSD 6y ago
  To be honest I'm surprised Emacs isn't a browser yet. It does everything else.
  - danShumway 6y ago
    There are efforts, and there are things you can run, but I wouldn't personally recommend doing so. I am very paranoid about browser security, and I (frankly) don't trust smaller browser projects that aren't highly vetted by lots of people. That's an entirely separate conversation. My opinion is that it ends up being simpler and safer at the end of the day to just wrap the entire Firefox application in an Emacs buffer and then intercept keypresses to that buffer. But you do lose out on a lot of stuff by doing that; I'd love to have tighter integration.

Yoric 6y ago

> But yeah, other software would just be more stable. When a change needs to be made, the benefit is weighed against the potential of breaking addons, but I imagine that's probably OK with addon developers as long as the change was reasonable. We thought that too, for a time, but eventually, we had to realize that we were burning out our add-on developers. (updated the article to clarify this)