Firefox, Chrome and the Future of Trustworthy Extensions

Browser extensions are wonderful. Nearly every day I come across a new Firefox extension that customizes my browser in some creative way I’d never even considered. Some provide amusement for a short time, while others have become indispensable to my work and life. Extensions are a real-world manifestation of one of Mozilla’s core principles — that individuals must have the ability to shape the internet and their experiences on it.

Another of Mozilla’s core principles is that an individual’s security and privacy on the internet are fundamental and must not be treated as optional. We’ve made the decision to support extensions, but it is definitely a balancing act. Our users’ freedom to customize their browser – their “user agent” – and to personalize their experience on the web can also be exploited by malicious actors to compromise users’ security and privacy.

At Mozilla, we continually strive to honor both principles. It’s why Firefox extensions written to the WebExtensions API are limited in their abilities and have good oversight, including automatic and manual review. It’s also why we make sure users can understand exactly what permissions they’ve granted to those extensions and what parts of their browser they can access.

In short, Mozilla makes every effort to ensure that the extensions we offer are trustworthy.

So it was with great interest that I read Google’s recent Chromium Blog blog post entitled “Trustworthy Chrome Extensions, by default.” It outlines upcoming changes to Chrome’s extension architecture designed to make “extensions trustworthy by default.” I thought it would be interesting to explore each of the announced changes and compare them to what Mozilla has built into Firefox.

User Controls for Host Permissions

“Beginning in Chrome 70, users will have the choice to restrict extension host access to a custom list of sites, or to configure extensions to require a click to gain access to the current page.”

Being able to review and modify the sites that an extension has access to, especially those extensions that ask to “access your data for all websites,” is a worthy goal. Mozilla has discussed similar ideas, but the problem always comes down presenting this in a clear, uncomplicated way to a majority of users.

Having played a bit with this feature in Chrome, the implementation definitely seems targeted at power users. Extensions that request access to all websites still get installed with that access, so the default behavior has not changed.

The click-to-script option is intriguing, although the UX is a bit awkward. It’s workable if you have a single extension, but becomes unwieldy to click and reload every site visited for every installed extension.

Admittedly, getting this interface right in an intuitive and easy-to-use manner is not straightforward and I applaud Google for taking a shot at it. Meanwhile Mozilla will continue to look for ways Firefox can provide more permission control to a majority of extension users.

Extension Review Process

“Going forward, extensions that request powerful permissions will be subject to additional compliance review.”

The post is vague about exactly what this means, but it likely means these extensions will be flagged for manual review. This brings Chrome up to the standard that Firefox set last year, which is great news for the web. More manual review means fewer malicious extensions.

“We’re also looking very closely at extensions that use remotely hosted code, with ongoing monitoring.”

Firefox expressly forbids remotely hosted code. Our feeling is that no amount of review can eliminate the risks introduced when developers can easily and undetectably change what code is loaded by extensions. Mozilla’s policy ensures that no unreviewed code is ever loaded into the browser, and enforced signatures prevents reviewed code from being altered after release.

Code Readability Requirements

“Starting today, Chrome Web Store will no longer allow extensions with obfuscated code…minification will still be allowed.”

In reality, minified and obfuscated code are not very useful in extensions. In both Chrome and Firefox, extensions load locally (not over the network) so there is almost no performance advantage to minification, and obfuscation can be overcome by a dedicated person with readily available tools and sufficient effort.

Nevertheless, Mozilla permits both obfuscated and minified extensions in our store. Critically, though, Mozilla requires all developers to submit original, non-obfuscated, non-minified code for review, along with instructions on how to reproduce (including any obfuscation or minification) the store version. This ensures that reviewers are able to review and understand every extension, and that the store version is unaltered from the reviewed version.

As you might expect, this takes a significant investment of time and energy for both Mozilla and developers. We believe it is worth it, though, to allow developers to secure their code, if desired, while simultaneously providing thoroughly reviewed extensions that maintain user security and privacy.

Required 2-Step Verification

As a whole, the web is moving in this direction and requiring it for developer accounts is a strong step towards protecting users. Mozilla recently added two-step authentication for Firefox Sync accounts, and two-step authentication for Firefox extension developers is on the roadmap for the fourth quarter of 2018. Like Google, we expect to have this feature enabled by 2019.

Manifest v3

“In 2019 we will introduce the next extensions manifest version…We intend to make the transition to manifest v3 as smooth as possible and we’re thinking carefully about the rollout plan.”

In 2015, Mozilla announced we were deprecating our extremely popular extension system in favor of WebExtensions, an API compatible with Chrome, as well as Edge and Opera. There were several reasons for this, but a large part of the motivation was standards — a fundamental belief that adopting the API of the market leader, in effect creating a de facto standard, was in the best interests of all users.

It was a controversial decision, but it was right for the web and it represents who Mozilla is and our core mission. Three years later, while there still isn’t an official standard for browser extensions, the web is a place where developers can quickly and easily create cross-browser extensions that run nearly unchanged on every major platform.

So I would like to publicly invite Google to collaborate with Mozilla and other browser vendors on manifest v3. It is an incredible opportunity to show that Chrome embodies Google’s philosophy to “focus on the user,” would reaffirm the Chrome team’s commitment to open standards and an interoperable web, and be a powerful statement that working together on the future of browser extensions is in the best interests of a healthy internet.

Conclusion

While all of the changes Google outlined are interesting, some of them could go a step further in protecting users online. Nevertheless, I’d like say — bravo! The motivation behind these changes is definitely in the spirit of Mozilla’s mission and a gain for the open web. With Chrome’s market share, these initiatives will have a positive impact in protecting the security and privacy of millions of users around the world, and the web will be a better place for it.

A lot of work remains, though. Expect Mozilla to keep fighting for users on the web, launching new initiatives, like Firefox Monitor, to keep people safe, and advancing Firefox to be the best user agent you can have in your online journies.

6 responses

Post a comment

  1. Bill Dietrich wrote on :

    I’d like to see some per-add-on permission setup. Such as “this add-on is/isn’t allowed to access microphone, access camera, offer to save files on disk, read files on disk, read disk outside its home directory, read a tab outside the current tab, create a pop-up dialog, create a new tab, change contents of the current tab, talk to a helper app” etc.

    Reply

  2. Andrey Kartashov wrote on :

    Thanks for the update!
    One point is confusing: what stops someone from giving you code for review different from the one they’ve obfuscated? Even if you know the process these tools don’t have to produce identical results even with identical input.

    Surely it’d be easier to just offer developers an option where your publishing tool obfucates the code in a manner you can trust but they submit and you review the original.

    Reply

    1. Jorge Villalobos wrote on :

      Developers are required to submit steps that reproduce the exact package that is being shipped on our site. There aren’t many tools that produce unpredictable results, so it’s not such a common problem.

      We did consider providing our own obfuscation / minification process, but decided against it. Developers tend to be very protective about their workflow, and taking over that step was probably going to cause some conflict and have reduced adoption. Also, dynamically changing the package server-side can lead to add-ons that worked for the dev but are broken once published.

      Reply

  3. Dorothy West wrote on :

    Trying to be able to send emails

    Reply

  4. Nathar Leichoz wrote on :

    Getting the UI right for “user control for host permissions” is not straightforward indeed, but the current Firefox way is downright uninformative. Currently we get prompted by a tiny hanger dialog with permissions listed by tiny bullet-points. This doesn’t convey the seriousness of the user’s actions. Each bullet point should be bigger in red font and the bullet point should be shaped like a shield. That ought to get users to think twice before installing an extension.

    Reply

  5. basil wrote on :

    what’s the point? you already stripped away our choice to give consent to experimental addons about a year ago. There’s a reason I’m still on my esr 52, i need the legacy addons I use, and until firefox “trusts” that i’m an adult and know what i’m doing and downloading, I see no reason to move to a newer version.

    You want to treat us like big kids now with a “auto consent” option for addons? Tough, you should have thought of that over a year ago when everyone was asking for the option.

    Reply

Post Your Comment