Update on Firefox support for Windows XP and Vista

Last year we announced that Windows XP and Vista users would be automatically moved to the Firefox Extended Support Release (ESR), ensuring them continued updates until at least September, 2017.

Today we are announcing June 2018 as the final end of life date for Firefox support on Windows XP and Vista. As one of the few browsers that continues to support Windows XP and Vista, Firefox users on these platforms can expect security updates until that date. Users do not need to take additional action to receive those updates.

We strongly encourage our users to upgrade to a version of Windows that is supported by Microsoft. Unsupported operating systems receive no security updates, have known exploits, and are dangerous for you to use.

For more information please visit the Firefox support page.

It’s your data, we’re just living in it

Let me ask you a question: How often do you think about your Firefox data? I think about your Firefox data every day, like it’s my job. Because it is.  As the head of data science for Firefox, I manage a team of data scientists who contribute to the development of Firefox by shaping the direction of product strategy through the interpretation of the data we collect.  Being a data scientist at Mozilla means that I aim to ensure that Firefox users have meaningful choices when it comes to participating in our data collection efforts, without sacrificing our ability to collect useful, high-quality data that is essential to making smarter product decisions.

To achieve this balance, I’ve been working with colleagues across the organization to simplify and clarify our data collection practices and policies. Our goal is that this will make it easier for you to decide if and when you share data with us.  Recently, you may have seen some updates about planned changes to the data we collect, how we collect it, and how we share the data we collect. These pieces are part of a larger strategy to align our data collection practices with a set of guiding principles that inform how we work with and communicate about data we collect.

The direct impact is that we have made changes to the systems that we use to collect data from Firefox, and we have updated the data collection preferences as a result.  Firefox clients no longer employ two different data collection systems (Firefox Health Report and opt-in Telemetry). Although one was on by default, and the other was opt-in, as a practical matter there was no real difference in the type of data that was being collected by the two different channels in release.  Because of that, we now rely upon a single system called Unified Telemetry that has aspects of both systems combined into a single data collection platform and as a result no longer have separate preferences, as we did for the old systems.

If you are a long-time Firefox user and you previously allowed us to collect FHR data but you refrained from opting into extended telemetry, we will continue to collect the same type of technical and interaction information using Unified Telemetry. We have scaled back all other data collection to either pre-release or in situ opt-in, so you will continue to have choices and control over how Firefox collects your data.

Four Pillars of Our Data Collection Strategy

There are four key areas that we focused on when we decided to adjust our data preferences settings.  For Firefox, it means that any time we collect data, we wanted to ensure that the proposal for data collection met our criteria for:

  • Necessity
  • Transparency
  • Accountability
  • Privacy

Necessity

We don’t collect data “just because we can” or “just because it would be interesting to measure”.  Anyone on the Firefox team who requests data has to be able to answer questions like:

  • Is the data collection necessary for Firefox to function properly? For example, the automatic update check must be sent in order to keep Firefox up to date.
  • Is data collection needed to make a feature of Firefox work well? For example, we need to collect data to make our search suggestion feature work.
  • Is it necessary to take a measurement from Firefox users?  Could we learn what we need from measuring users on a pre-release version of Firefox?
  • Is it necessary to get data from all users, or is it sufficient to collect data from a smaller sample?

Transparency

Transparency at Mozilla means that we publicly share details about what data we collect and ensure that we can answer questions openly about our related decision-making.

Requests for data collection start with a publicly available bug on bugzilla. The general process around requests for new data collection follows this process: people indicate that they would like to collect some data according to some specification, they flag a data steward (an employee who is trained to check that requests have publicly documented their intentions and needs) for review, and only those requests that pass review are implemented.

Most simple requests, like new Telemetry probes or experimental tests, are approved within the context of a single bug.  We check that every simple request includes enough detail that a standard set of questions to determine the necessity and accountability of the proposed measurements.  Here’s an example of a simple request for new telemetry-based data collection.

More complex requests, like those that call for a new data collection mechanism or require changes to the privacy notice, will require more extensive review than a simple request.  Typically, data stewards or requesters themselves will escalate requests to this level of review when it is clear that a simple review is insufficient.  This review can involve some or all of the following:

  • Privacy analysis: Feedback from the mozilla.dev.privacy mailing list and/or privacy experts within and outside of Mozilla to discuss the feature and its privacy impact.
  • Policy compliance review: An assessment from the Mozilla data compliance team to determine if the request matches the Mozilla data compliance policies and documents.
  • Legal review: An assessment from Mozilla’s legal team, which is necessary for any changes to the privacy policies/notices.

Accountability

Our process includes a set of controls that hold us accountable for our data collection. We take the precaution of ensuring that there is a person listed who is responsible for following the approved specification resulting from data review, such as designing and implementing the code as well as analyzing and reporting the data received.  Data stewards check to make sure that basic questions about the intent behind and implementation of the data we collect can be answered, and that the proposed collection is within the boundaries of a given data category type in terms of defaults available.  These controls allow for us to feel more confident about our ability to explain and justify to our users why we have decided to start collecting specific data.

Privacy

We can collect many types of data from your use of Firefox, but we don’t consider them equal. We consider some types of data to be more benign (like what version of Firefox you are using) than others (like the websites you visit). We’ve devised a four-tier system to group data in clear categories from less sensitive to highly sensitive, which you can review here in more detail.   Since we developed this 4-tier approach, we’ve worked to align this language with our Privacy Policy and at the user settings for Privacy in Firefox.   (You can read more about the legal team’s efforts in a post by my colleagues at Legal and Compliance.)

What does this mean for you?

We hope it means a lot and not much at the same time.  At Firefox, we have long worked to respect your privacy, and we hope this new strategy gives you a clearer understanding of what data we collect and why it’s important to us.  We also want to reassure you that we haven’t dramatically changed what we collect by default.  So while you may not often think about the data you share with Mozilla, we hope that when you do, you feel better informed and more in control.

Firefox Roadmap for Flash End-of-Life

This morning, Adobe announced its roadmap to stop supporting Flash at the end of 2020. Working with Adobe and other browser vendors, Mozilla has prepared a roadmap for Flash support in Firefox, and guides for site authors to make their final transition away from Flash technology. By managing this transition carefully, announcing it years in advance, and providing options for transition, Mozilla will help make the web faster, safer, and better for everyone.

To provide guidance for site authors and users that continue to rely on Flash, Mozilla has updated its ​published roadmap​ for Flash in Firefox. Starting next month, users will choose which websites are able to run the Flash plugin. Flash will be disabled by default for most users in 2019, and only users running the Firefox Extended Support Release (ESR) will be able to continue using Flash through the final end-of-life at the end of 2020. In order to preserve user security, once Flash is no longer supported by Adobe security patches, no version of Firefox will load the plugin.

As part of improving Firefox performance and security this year, Firefox users will choose which sites may run the Flash plugin. This choice will give users the ability to keep using legacy sites that require Flash, while letting modern sites shine with blazingly fast HTML speed. This change was announced ​last year​ and will ship in Firefox next month. Firefox users will still have the opportunity to enable Flash on specific sites that require it. It is possible to test this behavior today by ​downloading Firefox beta​ and ​changing the Flash setting in the Firefox Add-ons manager​. Because each browser implements this feature slightly differently, MDN Web Docs lists the ​differences in Flash activation​ among the major browsers as a guide for authors.

Screenshot of Spellstone on the Web

The Spellstone game has already migrated from Flash to HTML.

Over the years, Flash has helped bring the Web to greatness with innovations in media and animation, which ultimately have been added to the core web platform. The end of Flash offers an opportunity to bring legacy design and content in the Flash format into an new era using HTML and web technologies. If you are a site author currently using Flash to implement video, games, chat, file upload or clipboard access on your site, the web platform now has fast, secure, and reliable features which can do all of these tasks. Browser makers have prepared a guide to help website authors transition away from Flash to the open web. This transition guide​, published through MDN Web Docs, provides documentation and links to open web APIs, libraries, and frameworks to help make updating to the web platform a great experience.

Chart: Kongregate shows that adoption of HTML games increased from zero in 2010 to 50% of all game updates this year.

HTML is being rapidly adopted for web games. Image provided courtesy of Kongregate.

Game developers that formerly built games for Flash are quickly switching to HTML and seeing great results. Last week, Kongregate published​ data about the transition to HTML and the trends in game technologies used on their web gaming platform. Mozilla works closely with games publishers and developers to ​advance the state​ of games on the Web, and ​continues to ​develop technologies such as WebAssembly which allow developers to achieve near-native performance. For more information about building great web games, see ​MDN Web Docs​.

This year, Firefox will become the fastest it has ever been. Reducing Flash usage now is an important part of making the web and Firefox better together, and will support the end of Flash in 2019 and 2020. The security and privacy features users have come to expect, combined with a new interface and added functionality, will streamline and modernize the browser experience for Firefox users.

 

Update on Firefox Support for Windows XP and Vista

In approximately March, 2017, Windows XP and Vista users will automatically be moved to the Firefox Extended Support Release (ESR).

Firefox is one of the few browsers that continues to support Windows XP and Vista, and we expect to continue to provide security updates for users until September 2017. Users do not need to take additional action to receive those updates. In mid-2017, user numbers on Windows XP and Vista will be reassessed and a final support end date will be announced.

In the meantime, we strongly encourage our users to upgrade to a version of Windows that is supported by Microsoft. Unsupported operating systems receive no security updates, have known exploits, and are dangerous for you to use.  For planning purposes, enterprises using Firefox should consider September 2017 as the support end date for Windows XP and Vista.

For more information please visit the Firefox support page.

Update on Multi-Process Firefox

About four months ago, we launched multi-process Firefox to a small group of Firefox 48 users. Shortly after the carefully measured roll-out, we increased to approximately 50% of our user base. That included almost every Firefox user not using extensions. Those users have been enjoying the 400% increase in responsiveness and a 700% improvement when web pages are loading.

With Firefox 49 we deployed multi-process Firefox to users with a select set of well tested extensions. Our measurements and user feedback were all positive and so with Firefox 50 we deployed multi-process Firefox to users with a broader set of extensions, those whose authors have marked them as multi-process compatible.

Beyond Firefox 50, we have more work to do to enable multi-process Firefox for users with as yet unsupported extensions. In Firefox 51, if all testing goes according to plan, we’ll be enabling multi-process Firefox for users with extensions that are not explicitly marked as incompatible with multi-process Firefox.

In parallel to work enabling multi-process for more people using Firefox, we’re also working on additional longer term multi-process features that will further improve responsiveness and bring significant security benefits.

The first of those longer term multi-process features is to go from one content process to multiple content processes. The goal is to bring out the most from the multi process architecture, gain performance where it’s possible and minimize the impact of content process crashes. The first step is turning on a second content process in our Nightly channel. That gives us the opportunity to discover and squash bugs as we evaluate the right number of process to ultimately enable. That testing on Nightly is happening now.

The second long term multi-process feature is security sandboxing. Security Sandboxing makes use of child processes as a security boundary. Sandboxing work begins in Firefox 50 with the introduction of our first Windows sandbox. This is an early, laying the groundwork sandbox and is not yet hardened. Over the next few releases, the sandbox will be added to Mac and Linux and will become more restrictive and protective.

Multi-process Firefox has been a big undertaking but it’s already bringing positive results to our users in terms of responsiveness, stability, and security. Stay tuned to this channel for further updates as new multi-process capabilities are developed, tested, and deployed to Firefox users the world over.

What’s Next for Multi-process Firefox

By Asa Dotzler and Brad Lassey

Electrolysis is the project name for Mozilla’s efforts to split Firefox into multiple processes to improve responsiveness, stability, and security. The first phase of this work was to split Firefox into a UI process and a content process.

This first phase of enabling our multi-process architecture is making its way to some of our Firefox 48 users starting this week.  This is the biggest change we’ve ever made to Firefox, so we’re rolling it out slowly. For Firefox 48, we’re only enabling it for classes of users that our testing shows it works well for and to begin with, we’ll only enable it for 1% of those users so we can check on the stability and engagement data and make sure nothing new and bad is showing up. After that initial period, if all looks well, we’ll ramp up to 100% of those users, which will be about half of all Firefox 48 users.

Add-ons

If our Beta testing goes well, in Firefox 49 we will enable the multi-process architecture for users with a small set of add-ons that are known to work well with the multi-process architecture. In Firefox 50, again provided beta testing goes well, we plan to enable the multi-process architecture for users with add-ons that have either set a flag to say they are compatible or that were built with our new WebExtensions add-on API which is compatible by design. Eventually we will enable the multi-process architecture for all users and add-ons that are incompatible may no longer work. For this reason it is imperative that add-on authors update their add-ons to be compatible with the multi-process architecture.

Accessibility and touch screens

The next major multi-process update is scheduled for Firefox 51 when we’ll ship it to users with touchscreens, accessibility, and right to left browsers. That will conclude the first phase of our roll-out of the basic process separation that brings responsiveness to the Firefox UI, even when heavy pages are loading.

That’s not the end of our multi-process work. Not even close.

Multiple content processes

The second phase of this effort is to support multiple content processes. Where before we split content from UI so that pages loading wouldn’t slow down the UI, next up we’re splitting up the content processes so that one heavy page loading cannot slow down or hang pages loading in other tabs. This work is underway and should be available in the first half of 2017.

In parallel to work on multiple content processes, we’re also working on building a hardened sandbox for content processes. The goal for sandboxing is to restrict what access processes that host web content have to the browser and to the operating system. This will help secure Firefox against a range of potential exploits. If all goes well in testing, this work could see release this year.

Out of process add-ons

The final piece of this multi-process work will be to isolate extensions into their own sandboxed processes. Similar to how isolating and sandboxing web pages can help improve performance and prevent security exploits, putting extensions into their own process will make sure that an extension doesn’t slow down the browser or web pages and will help to prevent some classes of  attacks on Firefox that could happen through extensions. We’re still in the preliminary phase of this work.

This is a huge project that will take several more releases to complete but we’ve got a great foundation in place with the first phase shipping to end users now. We’ll build on that foundation to bring even more responsiveness and security to Firefox over the coming months without sacrificing the memory usage advantage we have over our competitors. Stay tuned to this and other Mozilla blogs for updates as the biggest architectural change in Firefox’s history rides the trains to release.

Reducing Adobe Flash Usage in Firefox

Browser plugins, especially Flash, have enabled some of our favorite experiences on the Web, including videos and interactive content. But plugins often introduce stability, performance, and security issues for browsers. This is not a trade-off users should have to accept.

Mozilla and the Web as a whole have been taking steps to reduce the need for Flash content in everyday browsing. Starting in August, Firefox will block certain Flash content that is not essential to the user experience, while continuing to support legacy Flash content. These and future changes will bring Firefox users enhanced security, improved battery life, faster page load, and better browser responsiveness.

Over the past few years, Firefox has implemented Web APIs to replace functionality that was formerly provided only by plugins. This includes audio/video playback and streaming capabilities, clipboard integration, fast 2D and 3D graphics, WebSocket networking, and microphone/camera access. As websites have switched from Flash to other web technologies, the plugin crash rate in Firefox has dropped significantly:

Plugin crash rate in Firefox

Firefox will continue this trend by blocking specific Flash content invisible to users. This is expected to reduce Flash crashes and hangs by up to 10%. To minimize website compatibility problems, the changes are initially limited to a short, curated list of Flash content that can be replaced with HTML. We intend to add to this list over time.

Improving Firefox Performance

Later this year, we plan to expand this list to include the use of Flash to check content viewability, a common practice to measure advertising. This will improve Firefox performance and device battery life. We will make this change at the same time Firefox implements the equivalent HTML Intersection Observer API (Firefox bug 1243846) and recommend that content producers currently using Flash to measure viewability adopt this new API as soon as it is available.

In 2017, Firefox will require click-to-activate approval from users before a website activates the Flash plugin for any content. Websites that currently use Flash or Silverlight for video or games should plan on adopting HTML technologies as soon as possible. Firefox currently supports encrypted video playback using Adobe Primetime and Google Widevine as alternatives to plugin video.

We continue to work closely with Adobe to deliver the best possible Flash experience for our users. Our engineering partnership has led to improvements in high-DPI support on Windows, enhanced sandboxing, and an accelerated Flash rendering pipeline that improves performance and stability.

These changes are part of our ongoing efforts to make browsing safer and faster without sacrificing the Web experiences our users love. As we announced last year, Firefox plans to drop support for all NPAPI plugins, except Flash, in March 2017. The next major Firefox ESR (Extended Support Release) release, also scheduled for March, will continue to support plugins such as Silverlight and Java until early 2018, for those users who need more time for their transition.

We are experimenting with many other features and improvements that will make Firefox an even more awesome platform for discovery and collaboration. We welcome your feedback and feature requests.

Update on Firefox support for OS X

Mozilla will end support for Firefox on OS X 10.6, 10.7, and 10.8 in August, 2016. At that time, Firefox will continue to function on these platforms but will no longer receive new feature or security updates.

Firefox Extended Support Release (ESR) 45 will continue to support OS X 10.6, 10.7, and 10.8 until mid-2017, but this ESR release will be the last that supports them.

All three of these versions are no longer supported by Apple. Mozilla strongly encourages our users to upgrade to a version of OS X currently supported by Apple. Unsupported operating systems receive no security updates, have known exploits, and are dangerous for you to use.

What’s New in Firefox Beta

Today’s beta release of Firefox features a tool to view the open tabs that are synced across your desktop and mobile instances of Firefox.

Updates to Firefox for Android focus on a set of design changes that will make browsing safer and simpler for our users.

More information:

Firefox is the default browser for Linux users on Ubuntu, new snap format coming soon

At Mozilla, we strive to offer users a great experience based on transparency, choice and trust, and to make Firefox available across many platforms, devices and operating systems. Today, Mozilla and Canonical are renewing their partnership to make Firefox the default browser for Ubuntu users. We are proud to have been a partner of choice for Ubuntu for over a decade. Canonical and Mozilla share a similar heritage as open-source and community-supported organizations.

Ubuntu version 16.04 will include the introduction of the snap infrastructure. With the snap format, we will be able to continually optimize Firefox on Ubuntu. Like our rapid engineering release cycle, snap format will allow us to provide Linux users the most up-to-date features, in particular security patches, even after major Operating System ship dates.

Previously, a static version of Firefox would ship with each new Operating System version for the lifecycle of that OS. With the snap format, new features can be released to users of older OS versions too. Later this year, we will offer Firefox in snap format making it easier to push the browser directly to users rather than relying on an intermediary to accept updates before they reach users.