2 ms·

Indeed, it's difficult to achieve a perfect balance here. That's one of the reasons the WebExtensions team has been very actively discussing with add-on develop

by Yoric 10y ago

Indeed, it's difficult to achieve a perfect balance here. That's one of the reasons the WebExtensions team has been very actively discussing with add-on developers to try and prioritize which APIs should be created/ported to WebExtensions. I don't remember specific numbers, but I seem to remember that pretty much all the extension points that had been requested by add-on developers were at least somewhere on the TODO list of WebExtensions. I hope that by the end of 2017, they will all be available, with a much cleaner API than their XUL/XPCOM counterpart, better tests and much better survival chances. Of course, some of the changes will require pretty drastic reimplementations by the developers. For instance, going from js-ctypes to the native bridge will require full reimplementation in a different programming language. On the upside, js-ctypes was really painful to use and the native bridge will let you use a much better language for the task. Say Rust :)

the8472 10y ago
The native messaging API is not useful for addon developers. They only cater to application developers that ship a companion addon to their application. js-ctypes allowed an addon to access already-present native libs on the the host machine or bundled with the addon itself. Messaging only works if you can get users to install some external application in addition to your addon, which is a too-tall hurdle for small extensions. From my perspective those barely comparable. > That's one of the reasons the WebExtensions team has been very actively discussing with add-on developers to try and prioritize which APIs should be created/ported to WebExtensions. You are taking requests to keep existing uses supported, mostly for big, already established addons. My concern extends beyond that. Simply by having access to internals anyone can currently develop novel uses, even if they initially do not have a userbase. Those can only be prototyped by access to internals. Someone might not even have an idea if they don't know an API exists that could be leveraged to do it. In other words, "I can't let you do that, Dave" API design can stifle creativity. And it also introduces a bias in favor of already entrenched extensions, which is less open than the current approach.
- Yoric 10y ago
  > js-ctypes allowed an addon to access already-present native libs on the the host machine or bundled with the addon itself. Messaging only works if you can get users to install some external application in addition to your addon, which is a too-tall hurdle for small extensions. > > From my perspective those barely comparable. I haven't checked, but I seem to remember that you can provide a platform-specific binary as part of an add-on, spawn it from WebExtensions and then communicate with it through the native bridge. Building/shipping one binary per platform is annoying, but the rest is infinitely better than using js-ctypes. I should know, I've been one of the first users of js-ctypes and I still shudder at the thought :) > In other words, "I can't let you do that, Dave" API design can stifle creativity. True. On the other hand, this is the kind of paradigm shift that was implemented by operating systems ~20 years ago (more in the case of Unix) and so far, improving the safety and security of operating systems has generally played in favor of users and creativity, not against them. This doesn't mean that there is no space for lower level, MS-DOS/Apple II-style hacking – I'm doing exactly that these days. But still, separating both sounds like a good idea to me. YMMV. > And it also introduces a bias in favor of already entrenched extensions, which is less open than the current approach. Good point. I seem to remember discussions about how to have an "unsafe" extension mechanism that would make it easier to experiment with non-standard APIs. I haven't checked myself, but I believe that this mechanism has been published, as an extension called "the WebExtension Extension" or something like that.
  - marcosdumay 10y ago
    > On the other hand, this is the kind of paradigm shift that was implemented by operating systems ~20 years ago What? No. Every OS out there allows the loading of user (administrator) supplied code to increase it's functionality. In other words, every OS out there allows extensions that touch their internal APIs (or a very permissive subset of them in the case of Windows, that is known by how restrictive this is).
  - the8472 10y ago
    > On the other hand, this is the kind of paradigm shift that was implemented by operating systems ~20 years ago No. Kernel modules can be installed at runtime. The user just has to grant the application the necessary privileges. This means OS developers do not try to attempt to "strike a balance" between power and safety. They allow both, the unsafe stuff merely requires a fairly simple opt-in. This is the whole crux of the issue. I do not mind security measures, as long as there is a bypass. Mozilla has taken the - in my opinion extremist - position that even bypasses cannot be allowed because they know what's best for users. > I haven't checked, but I seem to remember that you can provide a platform-specific binary as part of an add-on, spawn it from WebExtensions and then communicate with it through the native bridge. I am not aware of any such feature. This used to be true for bootstrapped extensions, but not for webextensions. > I haven't checked myself, but I believe that this mechanism has been published, as an extension called "the WebExtension Extension" or something like that. yes, only works on dev edition though.

by Yoric 10y ago

the8472 10y ago

The native messaging API is not useful for addon developers. They only cater to application developers that ship a companion addon to their application. js-ctypes allowed an addon to access already-present native libs on the the host machine or bundled with the addon itself. Messaging only works if you can get users to install some external application in addition to your addon, which is a too-tall hurdle for small extensions. From my perspective those barely comparable. > That's one of the reasons the WebExtensions team has been very actively discussing with add-on developers to try and prioritize which APIs should be created/ported to WebExtensions. You are taking requests to keep existing uses supported, mostly for big, already established addons. My concern extends beyond that. Simply by having access to internals anyone can currently develop novel uses, even if they initially do not have a userbase. Those can only be prototyped by access to internals. Someone might not even have an idea if they don't know an API exists that could be leveraged to do it. In other words, "I can't let you do that, Dave" API design can stifle creativity. And it also introduces a bias in favor of already entrenched extensions, which is less open than the current approach.

Yoric 10y ago
> js-ctypes allowed an addon to access already-present native libs on the the host machine or bundled with the addon itself. Messaging only works if you can get users to install some external application in addition to your addon, which is a too-tall hurdle for small extensions. > > From my perspective those barely comparable. I haven't checked, but I seem to remember that you can provide a platform-specific binary as part of an add-on, spawn it from WebExtensions and then communicate with it through the native bridge. Building/shipping one binary per platform is annoying, but the rest is infinitely better than using js-ctypes. I should know, I've been one of the first users of js-ctypes and I still shudder at the thought :) > In other words, "I can't let you do that, Dave" API design can stifle creativity. True. On the other hand, this is the kind of paradigm shift that was implemented by operating systems ~20 years ago (more in the case of Unix) and so far, improving the safety and security of operating systems has generally played in favor of users and creativity, not against them. This doesn't mean that there is no space for lower level, MS-DOS/Apple II-style hacking – I'm doing exactly that these days. But still, separating both sounds like a good idea to me. YMMV. > And it also introduces a bias in favor of already entrenched extensions, which is less open than the current approach. Good point. I seem to remember discussions about how to have an "unsafe" extension mechanism that would make it easier to experiment with non-standard APIs. I haven't checked myself, but I believe that this mechanism has been published, as an extension called "the WebExtension Extension" or something like that.
- marcosdumay 10y ago
  > On the other hand, this is the kind of paradigm shift that was implemented by operating systems ~20 years ago What? No. Every OS out there allows the loading of user (administrator) supplied code to increase it's functionality. In other words, every OS out there allows extensions that touch their internal APIs (or a very permissive subset of them in the case of Windows, that is known by how restrictive this is).
- the8472 10y ago
  > On the other hand, this is the kind of paradigm shift that was implemented by operating systems ~20 years ago No. Kernel modules can be installed at runtime. The user just has to grant the application the necessary privileges. This means OS developers do not try to attempt to "strike a balance" between power and safety. They allow both, the unsafe stuff merely requires a fairly simple opt-in. This is the whole crux of the issue. I do not mind security measures, as long as there is a bypass. Mozilla has taken the - in my opinion extremist - position that even bypasses cannot be allowed because they know what's best for users. > I haven't checked, but I seem to remember that you can provide a platform-specific binary as part of an add-on, spawn it from WebExtensions and then communicate with it through the native bridge. I am not aware of any such feature. This used to be true for bootstrapped extensions, but not for webextensions. > I haven't checked myself, but I believe that this mechanism has been published, as an extension called "the WebExtension Extension" or something like that. yes, only works on dev edition though.