> 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.
> 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.
> 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).
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.