Eyes Above The Waves

"That's not true if the Web Extension API != Chrome Extension API." That's not a useful comparison, the thing is: It is true for Chrome Extension API ⊂Web Extension API Which is what the goal is, to have the Chrome Extension API as a miinimum baseline and then extend upon it.

The post doesn't make clear that the Web Extension API is supposed to be a superset and the post is specifically talking about making an extension work in both browsers which would require that the same APIs are present. My point is that the add-ons blog post caused confusion and negative press because it's inaccurate.

Jetpack doesn't sandbox addons, does not ensure they work well in a multiprocess browser, and instead of being a stable API implemented in the browser, it was designed to be a library that ships with addons, which means you have to have repacks.

I'm not sure what you mean by "designed" but JPM-packaged add-ons no long have any libraries in them - there is pretty much nothing but the add-on code there. So as of Firefox 38 Jetpack is an API implemented in the browser (which has its downsides, like a SeaMonkey-related bug which went unnoticed for a while and cannot be fixed for already released SeaMonkey versions). Also, the browser decides what the add-ons have access to - tomorrow the access to require("chrome") and low-level modules could be removed, and then the add-ons won't have a way of breaking out of the sandbox (or messing up multiprocess support).

If we made those changes to Jetpack (and other necessary changes like removing XUL access), it wouldn't really be Jetpack anymore. Most Jetpack addons would be broken and need significant modifications. WebExtensions requires big changes too, but at least it gives us the extra value of making it easy to have extensions work in multiple browsers.

I have to disagree. Jetpack implemented significant changes before, quite successfully. What we have now already isn't Jetpack as it was introduced a few years ago. Lots of APIs have been replaced by better designs and new APIs have been created. Mozilla finally committed significant resources towards developing well-designed add-on APIs, if these were added to Jetpack there would be far less incentive to break out of the sandbox - most add-ons could gradually migrate away from low-level APIs. But not all of them, because you simply cannot have an API for everything. That's why WebExtensions will have native.js which is the moral equivalent of require("chrome") - sometimes the only way is breaking out of the sandbox, even if there is a risk that some future browser version will break your extension (well, either that or losing many innovative extensions which is where Chrome is right now). I also don't buy the "value of making it easy to have extensions work in multiple browsers" talk. This kind of thing doesn't come for free, it forces you into bug-for-bug compatibility with a competitor and limits your innovation. Many Chrome's APIs have non-obvious bugs and limitations or are simply badly designed. Will Mozilla fix them even though that would mean losing compatibility with existing Chrome extensions?

Compatibility isn't all-or-nothing. There is some value in making it easy to port an extension between browsers, with some testing and tweaks, without going all the way to full drop-in compatibility.

I was parroting what I thought I heard at BlinkOn. I removed "intentionally" from the post.

| I don't think you did much research on Jetpack for this post. True. I combined what I athought I knew with info from other people I trust. | This is wrong, all jetpack modules are loaded in sandboxes, including the jetpack loader itself. That is not the same thing as being properly sandboxed. Every Jetpack addon that uses "require(chrome)" is not properly sandboxed. Furthermore, a key part of the sandboxing of a WebExtensions addon is an explicit manifest specifying a set of permissions, with the guarantee that whatever the addon's JS does, it can't wield permissions not granted in its manifest. As far as I know Jetpack doesn't have this; correct me if I'm wrong! | This is all wrong, if you watch Aza's videos and read his blog posts from 2009-2010, and look at the Jetpack wiki history, we had been planning to support e10s and servo, and ship the stable apis in the browser from the beginning over 5yrs ago. Yes, I recall that being the plan at some point in the early days, but then we went and took the repacks path for three years (per your chronology), so we went far off the rails. (I'm not blaming you for that, or anything else.) I apologize again for not remembering that we've fixed the repacks problem since. | having the sdk support e10s is less than 2 weeks worth of work for one person by my estimate back in June, it's quite an easy thing to do. OK, but does "sdk support" include fixing all Jetpack API modules to support e10s? Can that even be done in a non-addon-breaking way? If the answers are "yes" and "yes", we should probably still do it! I've been told that's not the case. | What changes are you referring to here? Whatever changes are needed to make all Jetpack addons e10s-friendly, plus requiring Jetpack addons to ship with a permissions manifest which is enforced, plus ensuring that XUL is disabled in any context Jetpack addons can access (unless perhaps it gets its own permission). | if a module needs to be updated to support e10s, servo, or whatever then the module on npm merely needs to be updated then every add-on in the world that uses that module will be updated automatically when the add-on developer uses `npm install`. That only works if the API is e10s-friendly. The question then is how many APIs aren't e10s-friendly (by which I mean both support running the addon in a separate process to the browser chrome, and running the addon in a separate process to the content). I assumed from what I've been told that the answer is "many", but maybe I misunderstood. | This is cute, we should have copied the chrome.* api before it existed? No, we should have assumed a similar set of requirements and designed a similar sort of API and security model and shipped them in the browser from the beginning. | Of course once `require('chrome')` is removed from Jetpack the freedom and innovation parts will no longer be accurate, and that is very bad decision imo. It's tough. I think we should allow some extensions to do absolutely anything, but we need to very carefully separate those extensions from other extensions that are constrained so we can properly sandbox with a sane permissions system. The former extensions need to be carefully reviewed and will need to be regularly updated to account for browser changes. The latter can be supported via stable APIs indefinitely and need less careful review. We need to make sure there's an incentive for developers to create the latter kind of extension if their needs fit into those constraints (or work with us to expand the APIs to their needs do fit). Arguably as long as we support the very-old-fashioned classic addons, that satisfies the needs of the do-anything extensions, and we don't need to also support that class of extensions with Jetpack and WebExtensions. Anyway, sorry where I've got things wrong, and FWIW I haven't been involved in any decision-making on these issues. And thanks for speaking up.

| Furthermore, a key part of the sandboxing of a WebExtensions addon is an explicit manifest specifying a set of permissions, with the guarantee that whatever the addon's JS does, it can't wield permissions not granted in its manifest. Jetpack originally had this as well - only modules explicitly specified in the package manifest could be required. At some point the packaging changed and this restriction was removed. I don't know the reasoning but I guess that Mozilla's priorities shifted from enforcing sandboxing towards more flexibility. Now that the priorities are shifting back adding this functionality back would be pretty trivial. | That only works if the API is e10s-friendly. The question then is how many APIs aren't e10s-friendly (by which I mean both support running the addon in a separate process to the browser chrome, and running the addon in a separate process to the content). I assumed from what I've been told that the answer is "many", but maybe I misunderstood. I think you are. Jetpack APIs have been designed with e10s and out of process execution in mind, hence the extreme reliance on content scripts. That doesn't mean that there are no issues - since they never actually executed out of process before I would expect some issues that the API designers didn't foresee. But the issues definitely aren't massive. | No, we should have assumed a similar set of requirements and designed a similar sort of API and security model and shipped them in the browser from the beginning. IMHO that's exactly what Jetpack did. | The latter can be supported via stable APIs indefinitely and need less careful review. Sadly, that's wishful thinking in my experience. Providing stable APIs has been attempted a number of times before (remember FUEL?). The problem with those: if the platform changes in a radical way as is happening right now then these APIs won't survive either - unless the API designers knew that these changes were coming and prepared in advance. Jetpack and WebExtensions are prepared for e10s and Servo but who knows what will come up after that. Also, less careful reviews are already being performed for Jetpack-based extensions (the system warns if low-level modules are used and these parts can be reviewed more thoroughly then). The problem is, understanding extension logic still isn't optional for those reviews. The biggest problem with extensions isn't the ones that take over your computer but rather the ones that will spy on you - e.g. send your entire browsing history to some third party or even inject a remote script into every web page you are visiting. Most of the time the extension developers aren't actually malicious but simply use third-party services mindlessly (and don't get me started on jQuery-related security issues). I don't think that any kind of privilege system will make these any less problematic than they are right now. Chrome of course chose a different solution: they simply ignore the problem, spying on the user isn't prohibited behavior in Chrome Web Store.