4 ms·

It's remarkable the extent to which people assume the worst every time this topic comes up. The Mozilla stance has always been that the add-on community is a h

by aswan 10y ago

It's remarkable the extent to which people assume the worst every time this topic comes up. The Mozilla stance has always been that the add-on community is a huge asset but that supporting add-ons based on XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. The plan, intended to keep the benefits while addressing the problems, is to migrate to a new set of APIs -- web extensions. This is meant to be a migration, not a narrowing of the capabilities -- building compatibility for existing Chrome extensions is just the first step in this plan, when that foundation is in place the next steps are to extend the webextensions APIs to keep expanding the set of add-ons that can be written as webextensions. A transition like this has two halves: adding the new (performant, maintainable, secure) APIs and deprecating the old ones. Comments like the one above jump to the bizarre conclusion that Mozilla will decide to remove of the old APIs but never add the new ones. The closest thing to an explanation for why this would happen is ... uh, something about pocket and hello?

kuschku 10y ago
Mozilla has publicly said several times that they will NOT provide the same set of APIs. What we want is the ability to modify the whole browser chrome as if it was a website, and the ability to modify every action that happens in the browser. (For example, for tree style tabs, or a tab bar at the bottom, or stuff like redirecting some keypresses to other processes). Vivaldi does provide these things. Vivaldi allows users to literally rewrite 100% of the actual browser with simple JS addons. Mozilla should provide at least what Vivaldi provides.
protomyth 10y ago
> XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. Is there some report on the security implications of supporting XUL?
the8472 10y ago
In my eyes mozilla's stance on security is patronizing towards power-users because it assumes that every addon and every non-root application on the system is potentially hostile. Thus the goal is to prevent free interaction between processes or between addons and native in general (unix philosophy anyone?). Everyone has to suffer just to protect those who click on "yes, install" whenever prompted. The result are less powerful APIs in the name of security. Just look at addon signing. Mozilla refuses to add an off switch to that (and thus user control) because they fear that some other processes already running on the user's computer might inject unsigned addons. In my eyes this is a crazy kind of threat model that basically writes off the user's system security as a lost cause and tries to defend FF against that lost cause. It's elevating mozilla's needs over interoperability between applications. Imagine if awk refused to run unless the parent process is bash, signed by canonical, because they deemed some other shell's argument expansion as potentially confusing to the user or something like that. Crazy, right?

by aswan 10y ago

kuschku 10y ago

Mozilla has publicly said several times that they will NOT provide the same set of APIs. What we want is the ability to modify the whole browser chrome as if it was a website, and the ability to modify every action that happens in the browser. (For example, for tree style tabs, or a tab bar at the bottom, or stuff like redirecting some keypresses to other processes). Vivaldi does provide these things. Vivaldi allows users to literally rewrite 100% of the actual browser with simple JS addons. Mozilla should provide at least what Vivaldi provides.

protomyth 10y ago

> XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. Is there some report on the security implications of supporting XUL?

the8472 10y ago

In my eyes mozilla's stance on security is patronizing towards power-users because it assumes that every addon and every non-root application on the system is potentially hostile. Thus the goal is to prevent free interaction between processes or between addons and native in general (unix philosophy anyone?). Everyone has to suffer just to protect those who click on "yes, install" whenever prompted. The result are less powerful APIs in the name of security. Just look at addon signing. Mozilla refuses to add an off switch to that (and thus user control) because they fear that some other processes already running on the user's computer might inject unsigned addons. In my eyes this is a crazy kind of threat model that basically writes off the user's system security as a lost cause and tries to defend FF against that lost cause. It's elevating mozilla's needs over interoperability between applications. Imagine if awk refused to run unless the parent process is bash, signed by canonical, because they deemed some other shell's argument expansion as potentially confusing to the user or something like that. Crazy, right?