Let’s Encrypt: One more step on the road to TLS Everywhere

Principle 4 of the Mozilla Manifesto states: Individuals’ security and privacy on the Internet are fundamental and must not be treated as optional.

Unfortunately treating user security as optional is exactly what happens when sites let users connect over insecure HTTP rather than HTTP over TLS (HTTPS). What insecure means here is that your network traffic is totally unprotected and can be read and/or modified by anyone who shares a network with you, including random people sharing Starbucks or airport WiFi.

One of the biggest reasons that web sites don’t deploy TLS is the requirement to get a digital certificate — a cryptographic credential which allows a user’s browser to know it’s talking to the right site and not to an attacker. Certificates are issued by Certificate Authorities (CAs) often using a clumsy and error-prone manual process. A further disincentive to deployment is that  most CAs charge a fee for their certificates, which not only prices some people out of the market but also interferes with automatic issuance and renewal.

Mozilla, along with our partners Akamai, Cisco, EFF, and Identrust decided to do something about this situation. Together, we’ve formed a new consortium, the Internet Security Research Group, which is starting Let’s Encrypt, a new certificate authority designed to bring security to everyone. Let’s Encrypt is built around a few key principles:

  • Free: Certificates will be offered at no cost.
  • Automatic: Certificates will be issued via a public and published API, allowing Web server software to automatically obtain new certificates at installation time and without manual intervention.
  • Independent: No piece of infrastructure this important should be controlled by a single company. ISRG, the parent entity of Let’s Encrypt, is governed by a board drawn from industry, academia, and nonprofits, ensuring that it will be operated in the public interest.
  • Open: Let’s Encrypt will be publishing its source code and protocols, as well as submitting the protocols for standardization so that server software as well as other CAs can take advantage of them.

Let’s Encrypt will be issuing its first real certificates in Q2 2015. In the meantime, we have published some initial protocol drafts along with a demonstration client and server at: https://github.com/letsencrypt/node-acme and https://github.com/letsencrypt/heroku-acme. These are functional today and can be used to issue test certificates.

It’s been a long road getting here and we’re not done yet, but this is an important step towards a world with TLS Everywhere.

VP8 and H.264 to both become mandatory for WebRTC

WebRTC is one of the most exciting things to happen to the Web in years: it has the potential to bring instant voice and video calling to anyone with a browser, finally unshackling us from proprietary plugins and installed apps. Firefox, Chrome, and Opera already support WebRTC, and Microsoft recently announced future support.

Unfortunately, the full potential of the WebRTC ecosystem has been held back by a long-running disagreement about which video codec should be mandatory to implement. The mandatory to implement audio codecs were chosen over two years ago with relatively little contention: the legacy codec G.711 and Opus, an advanced codec co-designed by Mozilla engineers. The IETF RTCWEB Working Group has been deadlocked for years over whether to pick VP8 or H.264 for the video side.

Both codecs have merits. On the one hand, VP8 can be deployed without having to pay patent royalties. On the other hand, H.264 has a huge installed base in existing systems and hardware. That is why we worked with Cisco to develop their free OpenH264 plugin and as of October this year, Firefox supports both H.264 and VP8 for WebRTC.

At the last IETF meeting in Hawaii the RTCWEB working group reached strong consensus to follow in our footsteps and make support for both H.264 and VP8 mandatory for browsers. This compromises was put forward by Mozilla, Cisco and Google. The details are a little bit complicated, but here’s the executive summary:

  • Browsers will be required to support both H.264 and VP8 for WebRTC.
  • Non-browser WebRTC endpoints will be required to support both H.264 and VP8. However, if either codec becomes definitely royalty free (with no outstanding credible non-RF patent claims) then endpoints will only have to do that codec.
  • “WebRTC-compatible” endpoints will be allowed to do either codec, both, or neither.

See the complete proposal by Mozilla Principal Engineer Adam Roach here. There are still a few procedural issues to resolve, but given the level of support in the room, things are looking good.

We believe that this compromise is the best thing for the Web at this time: It lets us move forward with confidence in WebRTC interoperability and allows people who for some reason or another really can’t do one of these two codecs to be “WebRTC-compatible” and know they can interoperate with any WebRTC endpoint. This is an unmitigated win for users and Web application developers, as it provides broad interoperability within the WebRTC ecosystem.

It also puts a stake in the ground that what the community really needs is a codec that everyone agrees is royalty-free, and provides a continuing incentive for proponents of each codec to work towards this target.

Mozilla has been working for some time on such a new video codec which tries to avoid the patent thickets around current codec designs while surpassing the quality of the latest royalty-bearing codecs. We hope to contribute this technology to an IETF standardization effort following the same successful pattern as with Opus.

10 Years of Firefox and Innovation for the Web Platform

Today we are celebrating the 10th anniversary of Firefox and as a birthday present have lots of exciting new technologies for developers to try out.

Over the last 10 years Mozilla didn’t just build Firefox, we also helped build much of the Web that users experience today through Firefox and other browsers.

The Mozilla Project was created to wrestle control over the Web from Microsoft. Through its then dominant 98% browser market share with Internet Explorer 6, Microsoft had almost total control over the evolution of the Web. Mozilla didn’t tackle this situation merely through advocacy–telling the world why it is bad if a single corporation has disproportionate control over an ecosystem as important and central to our lives as the Web. Instead, we went to work to create a better, more powerful Web and a better, more powerful browser: Firefox. The competition and innovation Firefox brought to the Web has dramatically changed the open Web and browser landscape over the last 10 years.

Today, no single browser vendor has the same dominant market share Microsoft had. Users can choose from a number of browsers made by Microsoft, Google, Apple and of course Mozilla. The competition in the browser space is one of the clearest signs of the success of our mission over the last 10 years.

At Mozilla we don’t just build a consumer browser, we also build the Web itself. To overcome proprietary ecosystems the Web has to match or exceed the capabilities and performance of native platforms. Over the last 10 years we have pioneered many new Web technologies, and contributed to standardizing them.

Gaming

Gaming has become an important form of entertainment for many. In the past, gaming in the browser was dependent on plugins, restricting developers from distributing content widely on the Web. Mozilla has pioneered a number of new technologies to unlock the Web as an immersive platform for games, including WebGL, which is now ubiquitous among all modern browsers. And we created asm.js, a new JavaScript extension that enables near-native performance for game engines.

Performance Improvements

I am proud to say that Mozilla’s JavaScript engine now leads the market on JavaScript performance in pretty much all categories, offering a best in class gaming experience in the browser. We also enabled process separation in Nightly builds, providing additional performance and security benefits to Firefox users. And if you are using a 64-bit capable version of Windows, we will start shipping 64-bit builds of Firefox to Windows soon (on Mac we have been offering 64-bit builds for quite some time).

Advancing Audio and Video

Audio and Video on the Web are also making big leaps forward with the help of Mozilla. We are one of the leading proponents of WebRTC, a new Web API for real-time communication via audio, video and data channels. Together with our long time partner Telefonica, we are  bringing Firefox Hello, a WebRTC-based audio/video chat feature to Firefox soon. Firefox Hello allows people to communicate in real time without the need to download software or create an account.

Building out the Web

Our volunteer community continues to have a big role in advancing Firefox and the Web. Andre Natal from our Brazilian community has been contributing speech recognition functionality to Firefox and Firefox OS. This will allow users to interact with their desktop browsers as well as Firefox OS devices by simply using their voice. This Web Speech API is currently being added to our rendering engine Gecko.

Firefox Developer Edition

If you are a Web developer and excited to try out some of the technologies above, we have something special for you in celebration of our 10th anniversary. While we build the Web, it is developers who build the content and experiences the Web enables. In recognition of their efforts and our ongoing commitment to the Web developer community we are releasing a dedicated Firefox Developer Edition, made specifically for Web developers with many features that developers want enabled by default. The developer edition streamlines development workflow and adds new features that simplify the process of building for the entire Web, whether targeting mobile or desktop across many different platforms.

What the Future Holds

10 years ago, Mozilla started a long journey to set the Web free of Microsoft’s proprietary control, and today we have largely achieved that goal. The next phase of the struggle for an open Web is mobile where a new duopoly has arisen: iOS and Android. Just as we took on Microsoft 10 years ago with Firefox, we are looking to unseat Google’s and Apple’s dominance over the mobile space by creating a new smartphone OS that is built of the Web: Firefox OS. Since its launch last year Firefox OS has now spread to 24 countries all over the world, including our most recent launch in India. If you are using our Firefox OS developer phone, we are releasing a new developer build of Firefox OS 2.0 today.

We are also advancing the fundamental technologies of the Web through Servo and Rust. Servo is a new rendering engine for the next generation Web with advanced support for parallelism as well as improved security and reliability. We are able to accomplish this thanks to Rust, a new systems programming language which we have been building and which is gaining strong community support.

And, we have also started to explore the next frontier of the Web: Virtual Reality. We are pioneering new capabilities for VR on the Web and we are launching mozvr.com as a platform for technology demos and a place for developers to learn about how to bring VR experiences to the Web.

HTML5 reaches the Recommendation stage

Today HTML5 reached the Recommendation stage inside the W3C, the last stage of W3C standards. Mozilla was one of the first organizations to become deeply involved in the evolution and standardization of HTML5, so today’s announcement by the W3C has a special connection to Mozilla’s mission and our work over the last 10 years.

Mozilla has pioneered many widely adopted technologies such as WebGL which further enhance HTML5 and make it a competitive and compelling alternative to proprietary and native ecosystems. With the entrance of Firefox OS into the smartphone market we have also made great progress in advancing the state of the mobile Web. Many of the new APIs and capabilities we have proposed in the context of Firefox OS are currently going through the standards process, bringing capabilities to the Web that were previously only available to native applications.

W3C Standards go through a series of steps, ranging from proposals to Editors’ Drafts to Candidate Recommendations and ultimately Recommendations. While reaching the Recommendation stage is an important milestone, we encourage developers to engage with new Web standards long before they actually hit that point. To stay current, Web developers should keep an eye on new evolving standards and read Editors’ Drafts instead of Recommendations. Web developer-targeted documentation such as developer.mozilla.org and caniuse.com are also a great way to learn about upcoming standards.

A second important area of focus for Mozilla around HTML5 has been test suites. Test suites can be used by Web developers and Web engine developers alike to verify that Web browsers consistently implement the HTML5 specification. You can check out the latest results at:

http://w3c.github.io/test-results/dom/all.html
http://w3c.github.io/test-results/html/details.html

These automated testing suites for HTML5 play a critical role in ensuring a uniform and consistent Web experience for users.

At Mozilla, we envision a Web which can do anything you can do in a native application. The advancement of HTML5 marks an important step on the road to this vision. We have many exciting things planned for our upcoming 10th anniversary of Firefox (#Fx10), which will continue to move the Web forward as an open ecosystem and platform for innovation.

Stay tuned.

OpenH264 Now in Firefox

The Web is an open ecosystem, generally free of proprietary control and technologies—except for video.

Today in collaboration with Cisco we are shipping support for H.264 in our WebRTC implementation. Mozilla has always been an advocate for an open Web without proprietary controls and technologies. Unfortunately, no royalty-free codec has managed to get enough adoption to become a serious competitor to H.264. Mozilla continues to support the VP8 video format, but we feel that VP8 has failed to gain sufficient adoption to replace H.264. Firefox users are best served if we offer a video codec in WebRTC that maximises interoperability, and since much existing telecommunication infrastructure uses H.264 we think this step makes sense.

The way we have structured support for H.264 with Cisco is quite interesting and noteworthy. Because H.264 implementations are subject to a royalty bearing patent license and Mozilla is an open source project, we are unable to ship H.264 in Firefox directly. We want anyone to be able to distribute Firefox without paying the MPEG LA.

Instead, Cisco has agreed to distribute OpenH264, a free H.264 codec plugin that Firefox downloads directly from Cisco. Cisco has published the source code of OpenH264 on Github and Mozilla and Cisco have established a process by which the binary is verified as having been built from the publicly available source, thereby enhancing the transparency and trustworthiness of the system.

OpenH264

OpenH264 is not limited to Firefox. Other Internet-connected applications can rely on it as well.

Here is how Jonathan Rosenberg, Cisco’s Chief Technology Officer for Collaboration, described today’s milestone: “Cisco is excited to see OpenH264 become available to Firefox users, who will then benefit from interoperability with the millions of video communications devices in production that support H.264”.

We will continue to work on fully open codecs and alternatives to H.264 (such as Daala), but for the time being we think that OpenH264 is a significant victory for the open Web because it allows any Internet-connected application to use the most popular video format. And while OpenH264 is not truly open, at least it is the most open widely used video codec.

Note: Firefox currently uses OpenH264 only for WebRTC and not for the <video> tag, because OpenH264 does not yet support the high profile format frequently used for streaming video. We will reconsider this once support has been added.

Improving JPEG image encoding

Images are a big proportion of the data that browsers load when displaying a website, so better image compression goes a long way towards displaying content faster. Over the last few years there has been debate on whether a new image format is needed over the ubiquitous JPEG to provide better image data compression.

We published a study last year which compares JPEG with a number of more recent image formats, including WebP. Since then, we have expanded and updated that study. We did not find that WebP or any other royalty-free format we tested offers sufficient improvements over JPEG to justify the high maintenance cost of adding a new image format to the Web.

As an alternative we recently started an effort to improve the state of the art of JPEG encoders. Our research team released version 2.0 of this enhanced JPEG encoder, mozjpeg today. mozjpeg reduces the size of both baseline and progressive JPEGs by 5% on average, with many images showing significantly larger reductions.

Facebook announced today that they are testing mozjpeg 2.0 to improve the compression of images on facebook.com. It has also donated $60,000 to contribute to the ongoing development of the technology, including the next iteration, mozjpeg 3.0.

“Facebook supports the work Mozilla has done in building a JPEG encoder that can create smaller JPEGs without compromising the visual quality of photos,” said Stacy Kerkela, software engineering manager at Facebook. “We look forward to seeing the potential benefits mozjpeg 2.0 might bring in optimizing images and creating an improved experience for people to share and connect on Facebook.”

mozjpeg improves image encoding while maintaining full backwards compatibility with existing JPEG decoders. This is very significant because any browser can immediately benefit from these improvements without having to adopt new image formats, such as WebP.

The JPEG format continues to evolve along with the Web, and mozjpeg 2.0 will make it easier than ever for users to enjoy those images. Check out the Mozilla Research blog post for all the details.

Reconciling Mozilla’s Mission and the W3C EME

With most competing browsers and the content industry embracing the W3C EME specification, Mozilla has little choice but to implement EME as well so our users can continue to access all content they want to enjoy. Read on for some background on how we got here, and details of our implementation.

Digital Rights Management (DRM) is a tricky issue. On the one hand content owners argue that they should have the technical ability to control how users share content in order to enforce copyright restrictions. On the other hand, the current generation of DRM is often overly burdensome for users and restricts users from lawful and reasonable use cases such as buying content on one device and trying to consume it on another.

DRM and the Web are no strangers. Most desktop users have plugins such as Adobe Flash and Microsoft Silverlight installed. Both have contained DRM for many years, and websites traditionally use plugins to play restricted content.

In 2013 Google and Microsoft partnered with a number of content providers including Netflix to propose a “built-in” DRM extension for the Web: the W3C Encrypted Media Extensions (EME).

The W3C EME specification defines how to play back such content using the HTML5 <video> element, utilizing a Content Decryption Module (CDM) that implements DRM functionality directly in the Web stack. The W3C EME specification only describes the JavaScript APIs to access the CDM. The CDM itself is proprietary and is not specified in detail in the EME specification, which has been widely criticized by many, including Mozilla.

Mozilla believes in an open Web that centers around the user and puts them in control of their online experience. Many traditional DRM schemes are challenging because they go against this principle and remove control from the user and yield it to the content industry. Instead of DRM schemes that limit how users can access content they purchased across devices we have long advocated for more modern approaches to managing content distribution such as watermarking. Watermarking works by tagging the media stream with the user’s identity. This discourages copyright infringement without interfering with lawful sharing of content, for example between different devices of the same user.

Mozilla would have preferred to see the content industry move away from locking content to a specific device (so called node-locking), and worked to provide alternatives.

Instead, this approach has now been enshrined in the W3C EME specification. With Google and Microsoft shipping W3C EME and content providers moving over their content from plugins to W3C EME Firefox users are at risk of not being able to access DRM restricted content (e.g. Netflix, Amazon Video, Hulu), which can make up more than 30% of the downstream traffic in North America.

We have come to the point where Mozilla not implementing the W3C EME specification means that Firefox users have to switch to other browsers to watch content restricted by DRM.

This makes it difficult for Mozilla to ignore the ongoing changes in the DRM landscape. Firefox should help users get access to the content they want to enjoy, even if Mozilla philosophically opposes the restrictions certain content owners attach to their content.

As a result we have decided to implement the W3C EME specification in our products, starting with Firefox for Desktop. This is a difficult and uncomfortable step for us given our vision of a completely open Web, but it also gives us the opportunity to actually shape the DRM space and be an advocate for our users and their rights in this debate. The existing W3C EME systems Google and Microsoft are shipping are not open source and lack transparency for the user, two traits which we believe are essential to creating a trustworthy Web.

The W3C EME specification uses a Content Decryption Module (CDM) to facilitate the playback of restricted content. Since the purpose of the CDM is to defy scrutiny and modification by the user, the CDM cannot be open source by design in the EME architecture. For security, privacy and transparency reasons this is deeply concerning.

From the security perspective, for Mozilla it is essential that all code in the browser is open so that users and security researchers can see and audit the code. DRM systems explicitly rely on the source code not being available. In addition, DRM systems also often have unfavorable privacy properties. To lock content to the device DRM systems commonly use “fingerprinting” (collecting identifiable information about the user’s device) and with the poor transparency of proprietary native code it’s often hard to tell how much of this fingerprinting information is leaked to the server.

We have designed an implementation of the W3C EME specification that satisfies the requirements of the content industry while attempting to give users as much control and transparency as possible. Due to the architecture of the W3C EME specification we are forced to utilize a proprietary closed-source CDM as well. Mozilla selected Adobe to supply this CDM for Firefox because Adobe has contracts with major content providers that will allow Firefox to play restricted content via the Adobe CDM.

Firefox does not load this module directly. Instead, we wrap it into an open-source sandbox. In our implementation, the CDM will have no access to the user’s hard drive or the network. Instead, the sandbox will provide the CDM only with communication mechanism with Firefox for receiving encrypted data and for displaying the results.

CDM and sandbox architecture

Traditionally, to implement node-locking DRM systems collect identifiable information about the user’s device and will refuse to play back the content if the content or the CDM are moved to a different device.

By contrast, in Firefox the sandbox prohibits the CDM from fingerprinting the user’s device. Instead, the CDM asks the sandbox to supply a per-device unique identifier. This sandbox-generated unique identifier allows the CDM to bind content to a single device as the content industry insists on, but it does so without revealing additional information about the user or the user’s device. In addition, we vary this unique identifier per site (each site is presented a different device identifier) to make it more difficult to track users across sites with this identifier.

Adobe and the content industry can audit our sandbox (as it is open source) to assure themselves that we respect the restrictions they are imposing on us and users, which includes the handling of unique identifiers, limiting the output to streaming and preventing users from saving the content. Mozilla will distribute the sandbox alongside Firefox, and we are working on deterministic builds that will allow developers to use a sandbox compiled on their own machine with the CDM as an alternative. As plugins today, the CDM itself will be distributed by Adobe and will not be included in Firefox. The browser will download the CDM from Adobe and activate it based on user consent.

While we would much prefer a world and a Web without DRM, our users need it to access the content they want. Our integration with the Adobe CDM will let Firefox users access this content while trying to maximize transparency and user control within the limits of the restrictions imposed by the content industry.

There is also a silver lining to the W3C EME specification becoming ubiquitous. With direct support for DRM we are eliminating a major use case of plugins on the Web, and in the near future this should allow us to retire plugins altogether. The Web has evolved to a comprehensive and performant technology platform and no longer depends on native code extensions through plugins.

While the W3C EME-based DRM world is likely to stay with us for a while, we believe that eventually better systems such as watermarking will prevail, because they offer more convenience for the user, which is good for the user, but in the end also good for business. Mozilla will continue to advance technology and standards to help bring about this change.