Test the new Content Security Policy for Content Scripts

Firefox

As part of our efforts to make add-ons safer for users, and to support evolving manifest v3 features, we are making changes to apply the Content Security Policy (CSP) to content scripts used in extensions. These changes will make it easier to enforce our long-standing policy of disallowing execution of remote code.

When this feature is completed and enabled, remotely hosted code will not run, and attempts to run them will result in a network error. We have taken our time implementing this change to decrease the likelihood of breaking extensions and to maintain compatibility. Programmatically limiting the execution of remotely hosted code is an important aspect of manifest v3, and we feel it is a good time to move forward with these changes now.

We have landed a new content script CSP, the first part of these changes, behind preferences in Firefox 72. We’d love for developers to test it out to see how their extensions will be affected.

Testing instructions

Using a test profile in Firefox Beta or Nightly, please change the following preferences in about:config:

  • Set extensions.content_script_csp.enabled to true
  • Set extensions.content_script_csp.report_only to false to enable policy enforcement

This will apply the default CSP to the content scripts of all installed extensions in the profile.

Then, update your extension’s manifest to change your content_security_policy. With the new content script CSP,  content_scripts works the same as extension_pages. This means that the original CSP value moves under the extension_pages key and the new content_scripts key will control content scripts.

Your CSP will change from something that looks like:

content_security_policy: "script-src 'self'; object-src 'none'"

To something that looks like:

content_security_policy: {
  extension_pages: "script-src 'self'; object-src 'none'",
  content_scripts: "script-src 'self'; object-src 'none'"
}

Next, load your extension in about:debugging. The default CSP now applied to your content scripts will prevent the loading of remote resources, much like what happens when you try to  insert an image into a website over http, possibly causing your extension to fail. Similar to the old content_security_policy (as documented on MDN), you may make changes using the content_scripts key.

Please do not loosen the CSP to allow remote code, as we are working on upcoming changes to disallow remote scripts.

As a note, we don’t currently support any other keys in the content_security_policy object. We plan to be as compatible as possible with Chrome in this area will support the same key name they use for content_scripts in the future.

Please tell us about your testing experience on our community forums. If you think you’ve found a bug, please let us know on Bugzilla.

Implementation timeline

More changes to the CSP for extensions are expected to land behind preferences in the upcoming weeks. We will publish testing instructions once those updates are ready. The full set of changes should be finished and enabled by default in 2020, meaning that you will be able to use the new format without toggling any preferences in Firefox.

Even after the new CSP is turned on by default, extensions using manifest v2 will be able to continue using the string form of the CSP. The object format will only be required for extensions that use manifest v3 (which is not yet supported in Firefox).

There will be a transition period when Firefox supports both manifest v2 and manifest v3 so that developers have time to update their extensions. Stay tuned for updates about timing!

The post Test the new Content Security Policy for Content Scripts appeared first on Mozilla Add-ons Blog.

Mozilla’s Manifest v3 FAQ

Firefox

What is Manifest v3?

Chrome versions the APIs they provide to extensions, and the current format is version 2. The Firefox WebExtensions API is nearly 100% compatible with version 2, allowing extension developers to easily target both browsers.

In November 2018, Google proposed an update to their API, which they called Manifest v3. This update includes a number of changes that are not backwards-compatible and will require extension developers to take action to remain compatible.

A number of extension developers have reached out to ask how Mozilla plans to respond to the changes proposed in v3. Following are answers to some of the frequently asked questions.

Why do these changes negatively affect content blocking extensions?

One of the proposed changes in v3 is to deprecate a very powerful API called blocking webRequest. This API gives extensions the ability to intercept all inbound and outbound traffic from the browser, and then block, redirect or modify that traffic.

In its place, Google has proposed an API called declarativeNetRequest. This API impacts the capabilities of content blocking extensions by limiting the number of rules, as well as available filters and actions. These limitations negatively impact content blockers because modern content blockers are very sophisticated and employ layers of algorithms to not only detect and block ads, but to hide from the ad networks themselves. Extensions would still be able to use webRequest but only to observe requests, not to modify or block them.

As a result, some content blocking extension developers have stated they can no longer maintain their add-on if Google decides to follow through with their plans. Those who do continue development may not be able to provide the same level of capability for their users.

Will Mozilla follow Google with these changes?

In the absence of a true standard for browser extensions, maintaining compatibility with Chrome is important for Firefox developers and users. Firefox is not, however, obligated to implement every part of v3, and our WebExtensions API already departs in several areas under v2 where we think it makes sense.

Content blocking: We have no immediate plans to remove blocking webRequest and are working with add-on developers to gain a better understanding of how they use the APIs in question to help determine how to best support them.

Background service workers: Manifest v3 proposes the implementation of service workers for background processes to improve performance. We are currently investigating the impact of this change, what it would mean for developers, and whether there is a benefit in continuing to maintain background pages.

Runtime host permissions: We are evaluating the proposal in Manifest v3 to give users more granular control over the sites they give permissions to, and investigating ways to do so without too much interruption and confusion.

Cross-origin communication: In Manifest v3, content scripts will have the same permissions as the page they are injected in. We are planning to implement this change.

Remotely hosted code: Firefox already does not allow remote code as a policy. Manifest v3 includes a proposal for additional technical enforcement measures, which we are currently evaluating and intend to also enforce.

Will my extensions continue to work in Manifest v3?

Google’s proposed changes, such as the use of service workers in the background process, are not backwards-compatible. Developers will have to adapt their add-ons to accommodate these changes.

That said, the changes Google has proposed are not yet stabilized. Therefore, it is too early to provide specific guidance on what to change and how to do so. Mozilla is waiting for more clarity and has begun investigating the effort needed to adapt.

We will provide ongoing updates about changes necessary on the add-ons blog.

What is the timeline for these changes?

Given Manifest v3 is still in the draft and design phase, it is too early to provide a specific timeline. We are currently investigating what level of effort is required to make the changes Google is proposing, and identifying where we may depart from their plans.

Later this year we will begin experimenting with the changes we feel have a high chance of being part of the final version of Manifest v3, and that we think make sense for our users. Early adopters will have a chance to test our changes in the Firefox Nightly and Beta channels.

Once Google has finalized their v3 changes and Firefox has implemented the parts that make sense for our developers and users, we will provide ample time and documentation for extension developers to adapt. We do not intend to deprecate the v2 API before we are certain that developers have a viable path forward to migrate to v3.

Keep your eyes on the add-ons blog for updates regarding Manifest v3 and some of the other work our team is up to. We welcome your feedback on our community forum.

 

#s3gt_translate_tooltip_mini { display: none !important; }

The post Mozilla’s Manifest v3 FAQ appeared first on Mozilla Add-ons Blog.

Upcoming deprecations in Firefox 70

Firefox

Several planned code deprecations for Firefox 70, currently available on the Nightly pre-release channel, may impact extension and theme developers. Firefox 70 will be released on October 22, 2019.

Aliased theme properties to be removed

In Firefox 65, we started deprecating the aliased theme properties accentcolor, textcolor, and headerURL. These properties will be removed in Firefox 70.

Themes listed on addons.mozilla.org (AMO) will be automatically updated to use supported properties. Most themes were updated back in April, but new themes have been created using the deprecated properties. If your theme is not listed on AMO, or if you are the developer of a dynamic theme, please update your theme’s manifest.json to use the supported properties.

  • For accentcolor, please use frame
  • For headerURL, please use theme_frame
  • For textcolor, please use tab_background_text

JavaScript deprecations

In Firefox 70, the non-standard, Firefox-specific Array generic methods introduced with JavaScript 1.6 will be considered deprecated and scheduled for removal in the near future. For more information about which generics will be removed and suggested alternatives, please see the Firefox Site Compatibility blog.

The Site Compatibility team also intends to remove the non-standard prototype toSource and uneval by the end of 2019.

The post Upcoming deprecations in Firefox 70 appeared first on Mozilla Add-ons Blog.

Timeline for disabling legacy add-ons on addons.mozilla.org

Firefox

Mozilla will stop supporting Firefox Extended Support Release (ESR) 52, the final release that is compatible with legacy add-ons, on September 5, 2018.

As no supported versions of Firefox will be compatible with legacy add-ons after this date, we will start the process of disabling legacy add-on versions on addons.mozilla.org (AMO) in September. On September 6, 2018, submissions for new legacy add-on versions will be disabled.  All legacy add-on versions will be disabled in early October, 2018. Once this happens, users will no longer be able to find your extension on AMO. For more information about how

After legacy add-ons are disabled, developers will still be able to port their extensions to the WebExtensions APIs. Once a new version is submitted to AMO, users who have installed the legacy version will automatically receive the update and the add-on’s listing will appear in the gallery.

For more information about porting legacy extensions to the WebExtensions API is available on MDN.  We encourage legacy add-on developers to visit our wiki for more information about upcoming development work and ways to get in touch with our team for help.

The post Timeline for disabling legacy add-ons on addons.mozilla.org appeared first on Mozilla Add-ons Blog.

Switching to JSON for update manifests

Firefox

We plan on switching completely to JSON update manifests on Firefox and AMO. If you self-distribute your add-on please read ahead for details.

AMO handles automatic updates for all add-ons listed on the site. For self-hosted add-ons, developers need to set an update URL and manage the update manifest file it returns. Today, AMO returns an RDF file, a common legacy add-on feature. A JSON equivalent of this file is now supported in Firefox. JSON files are smaller and easier to read. This also brings us closer to removing complex RDF parsing from Firefox code.

Firefox 62, set to release September 5, 2018, will stop supporting the RDF variant of the update manifest. Firefox ESR users can continue using RDF manifests until the release of Firefox 68 in 2019. Nevertheless, all developers relying on RDF for their updates should read the documentation and switch soon. Firefox 45 introduced this feature, so all current versions of Firefox support it.

Developers of add-ons hosted on AMO don’t need to take any action. AMO will switch to JSON updates in the coming weeks. You don’t need to make any changes for add-ons hosted on AMO to update normally. Users on versions of Firefox older than 45 will no longer receive automatic updates. However, that should be a very small number of users. It’s also a very small number of active add-ons, since Firefox 45 predates the move to WebExtensions.

If you have any questions about this, please post a comment on the Discourse thread.

The post Switching to JSON for update manifests appeared first on Mozilla Add-ons Blog.

Removing Support for Unpacked Extensions

Firefox

With the release of Firefox 62 (currently scheduled for August 21, 2018) Mozilla will discontinue support for unpacked sideloaded extensions. You will no longer be able to load an extension via the Windows registry by creating an entry with an extension’s directory (i.e. unpacked) after Firefox 61. Starting with Firefox 62, extensions sideloaded via the Windows registry must be complete XPI files (i.e. packed).

 

Removing a Legacy Heritage

Support for unpacked extensions was originally a feature used by legacy extensions. With the release of Firefox Quantum (57) and the transition to the WebExtensions architecture for add-ons, support for unpacked extensions is no longer required. Maintaining support for both unpacked and packed extensions places a significant technical burden on the engineering and testing organizations, and removal of the legacy unpacked extension code helps Mozilla preserve the long-term stability of Firefox.

Convert Unpacked to Packed

If you are the developer of an extension that has been installed via the Windows registry as an unpacked directory, your extension will continue to work through Firefox 61. Starting with Firefox 62, however, your extension will be no longer be loaded by Firefox. To avoid this situation and ensure users do not lose functionality, please pack your extension and update the Windows registry entry to use the packed XPI file (see MDN for detailed instructions).

Development Still Supports Unpacked Extensions

Note: this does not impact the use of unpacked extensions for development. Temporarily loading and debugging an extension either via the about:debugging page or via the web-ext tool will continue to be supported; both methods will still be able to load extensions contained within a filesystem directory. Developers will not be required to sign or pack their extensions into an XPI file for development purposes.

The post Removing Support for Unpacked Extensions appeared first on Mozilla Add-ons Blog.

Q&A with Developer Stefan Van Damme

This is a guest post from Mozilla technical writer Judy DeMocker. She recently chatted with Stefan Van Damme about his extension Turn Off the Lights, and his experience porting it from its original Google Chrome version. Take it away, Judy…

Stefan Van Damme had a small problem—but it happened all the time. He liked to watch videos online, but video players on sites like YouTube don’t eliminate the other content on the screen—and that makes it hard to focus on the show. So Stefan, who lives in Antwerp, Belgium, built his first browser add-on to dim the lights on distracting content. And since so many people love movies, he built it for seven different browsers for users around the world.

Stefan’s extension, Turn Off the Lights, has been downloaded more than 3 million times. With that many users, it’s critical for him to be able to update it quickly and easily, without spending days or weeks on maintenance. So he’s excited about the new WebExtensions API, which makes it easy for him to port his extensions to Google Chrome, Mozilla Firefox, and Microsoft Edge using a universal code base.

Turn Off the Lights in action.

 

Porting to Firefox

What browser did you first create your extension for?
Google Chrome

Why was it important for you to write your extension for Firefox?
It is important to me that everyone can have the Turn Off the Lights experience in their favorite web browser. And Firefox is still one of the most popular web browsers out there today.

Did you migrate your add-on from the legacy Firefox platform, XUL? How difficult was that?
In the first version of Turn Off the Lights, I used the XUL technology. If I had to migrate to the new version, it would be difficult. However, I already had the Chrome extension, so migrating that code to Firefox was very easy. There was only one file I had to change, the manifest file. All the other files, I had to do nothing.

How difficult was it to learn and write to the WebExtensions API? (1 = easiest; 10 = hardest)
Since Firefox now supports the WebExtensions API, it was very easy to take code that runs on Chrome or Edge and put it on Firefox. I can use the same code base and just change the settings to work with each browser. If I continue with Chrome extensions, then it’s just a “1,” very easy.

Did you find all the functionality of your XUL add-on in the WebExtensions API? Or did you have to learn a new way to write the same features?
At the time I wrote the XUL add-on from my Chrome extension code, it was difficult, but I got all the functions inside. Today WebExtensions have more APIs, even those that extend outside the website content. For example, the extension can now dim the toolbar of Firefox thanks to the browser.theme API. And that is very unique and also cool.

What problems, if any, did you experience developing for Firefox?
Mostly I had trouble with the performance of the browser. If I click on my gray lamp button, it goes very slowly to that capacity level. On other browsers, it’s one click and done. I understand Mozilla is working hard to improve this.

What do you think of the new Quantum version of Firefox?
I see some good improvement in the Firefox Quantum web browser. That is what I like, and it can also be good for my users.

Tools & Resources

How has the technology changed since 2009?
At first, I used Notepad ++ on Windows to write my code. Now I use a Mac and Microsoft Visual Studio. Visual Studio is a better experience for both platforms. I can use it on Mac and Windows (using Boot Camp). I can switch to a Windows PC and use the same developer kit to write code and test it also.

How long does it take to publish a Firefox extension?
It’s very quick to publish an update to an add-on. Normally I just zip it and click on “Publish” and it’s done. Yesterday, I updated my Date Today add-on, and it took 10 to 15 minutes.

How is adoption of your new extension?
It’s good. Turn Off the Lights has been downloaded more than 3,000,000 times. I’’ve set up my website to detect a visitor’s browser and send them to the correct hyperlink, so they can download the version that works for them.

How long does it take up update your different extensions?
So in browsers like Chrome, Firefox, and Opera, it takes about two hours to update my add-on. I do one or two major updates for Turn Off the Lights a year, for instance moving from version 3.3 to 3.4. Those take more time. But it’s worth it. I get user feedback from my users that those updates provides better harmony in the current web experience.

What resources helped you learn about the WebExtensions API?
The MDN website was helpful. I was working with the Chrome documentation, but their site only shows information for the Chrome platform. That’s a minus for the Google team. They didn’t have a browser compatibility table that could show me if a feature is available on another web browser.

What help, if any, did you get from Mozilla?
I didn’t talk to anybody at Mozilla. But I do report bugs and performance issues. It’s important to get a great experience on all web browsers.

What advice would you give other developers who are thinking of creating extensions for Firefox?
Just do it. And, listen to your users’ feedback. They are the experts on how you can improve your Firefox extension.

The post Q&A with Developer Stefan Van Damme appeared first on Mozilla Add-ons Blog.

Add-ons Update – 2017/10

Firefox

Here’s your monthly add-ons update.

AMO

We changed the way contributions are handled on AMO. This should be simpler to maintain, and offer more payment options for developers.

The Review Queues

We recently moved to a new review model, where developers don’t have to wait for long before their add-ons are reviewed. Legacy add-ons still go through the old model, but there are only a small number of updates awaiting review now. So I’m discontinuing this section of the monthly update for now.

Compatibility Update

Firefox 57 is now on the Beta channel and will be released on November 14th. It will only accept WebExtensions add-ons by default. In order to ease the transition to 57, here are some changes we’re implementing on AMO.

Recognition

We would like to thank the following people for their recent contributions:

  • ian-henderso
  • Jp-Rivera
  • Apoorva Pandey
  • ilmanzo
  • Trishul Goel
  • Tom Schuster
  • Apoorva Singh
  • Tiago Morais Morgado
  • zombie
  • wouter
  • kwan
  • Kevin Jones
  • Aastha
  • Masatoshi Kimura
  • asamuzaK
  • Christophe Villeneuve

You can read more about their work in our recognition page.

The post Add-ons Update – 2017/10 appeared first on Mozilla Add-ons Blog.

Legacy Add-on Support on Firefox ESR

Firefox

Earlier this year, we shared with you our compatibility plan for Firefox. As anticipated, Firefox 57 will be released in late November, only allowing add-ons using the WebExtensions API. However, we have received some questions from developers on how this timeline applies to the Firefox Extended Support Release (ESR).

To clarify how legacy extensions will work with the ESR release:

  • ESR 52 will be the last ESR release that supports legacy add-ons. Support for ESR 52 officially ends on June 2018.
  • The following ESR release (59), and any subsequent release, will not support legacy add-ons. There will be no override provided for this behavior.

AMO Support

AMO (addons.mozilla.org) will continue to support legacy add-on listings throughout the ESR 52 cycle. However, AMO will primarily focus on WebExtension add-on listings. This means some legacy features may also change during this time period. There are big changes coming to AMO, including a completely new design. Stay put for more updates on this.

The post Legacy Add-on Support on Firefox ESR appeared first on Mozilla Add-ons Blog.

Add-ons Update – 2017/09

Firefox

Here’s your monthly add-ons update.

The Review Queues

In the past month, our team reviewed 2,490 listed add-on submissions:

  • 2,074 in fewer than 5 days (83%).
  • 89 between 5 and 10 days (4%).
  • 327 after more than 10 days (13%).

244 listed add-ons are awaiting review.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Visit our wiki page for more information.

Compatibility Update

We published the blog post for 56 and the bulk validation has been run. This is the last one of these we’ll do, since compatibility is a much smaller problem with the WebExtensions API.

Firefox 57 is now on the Nightly channel and will soon hit Beta, only accepting WebExtension add-ons by default. Here are some changes we’re implementing on AMO to ease the transition to 57.

Recognition

We would like to thank the following people for their recent contributions to the add-ons world:

  • Amola Singh
  • yfdyh000
  • bfred-it
  • Tiago Morais Morgado
  • Divya Rani
  • angelsl
  • Tim Nguyen
  • Atique Ahmed Ziad
  • Apoorva Pandey
  • Kevin Jones
  • ljbousfield
  • asamuzaK
  • Rob Wu
  • Tushar Sinai
  • Trishul Goel
  • zombie
  • tmm88
  • Christophe Villeneuve
  • Hemanth Kumar Veeranki

You can read more about their work in our recognition page.

The post Add-ons Update – 2017/09 appeared first on Mozilla Add-ons Blog.