All Feeds | XSL | RSS | Embed | Edit

Intent to Explain: Demystifying the Blink Shipping Process

If you’re a standards-curious web developer, you may have wondered how features get added to browsers, or even how the Chrome team decides what they will work on. You probably also have, at least at some point, thought to yourself “I have this urgent problem but I’ll have to work around it for the foreseeable future, because browsers are just too slow to bring in changes”. You may have even added some expletives when no one was around.

If that description sounds accurate, this is the post for you! This post will describe the Blink process, how browser engineers (both inside and outside of Google) use it in order to ship features in Chromium, what considerations are taken when deciding to ship a new feature, as well as some considerations that impact what features get worked on, and how you can play a role in all of this!

Project goals

The Chromium project is the open source project on which Chrome is built, and on which other browsers are also based: Samsung Internet, Opera, Brave, Vivaldi, and last (to join the project) but not least, Microsoft Edge. The project enables all those different browsers to share a single implementation of the web platform, and at the same time, keep their unique characteristics and focus.

Blink is the rendering engine used by Chromium. It is the part of the project that descends from WebKit (the rendering engine Safari uses), and which is mostly (but not exclusively) responsible for the Chromium’s Web Platform implementation. The goal of Chromium and Blink inside it is to continuously improve the web platform as a whole.

How does Blink improve the web platform?

If we want the web to thrive in the long term, we need to make sure that our users consider it safe and pleasant to use, and that it supports all the capabilities developers need in order to easily make their users (and businesses) are happy.

Any improvement to the platform needs to take backwards compatibility and cross-browser interoperability into account. There’s a lot of web content out there that will never change. The risk of breaking some of it needs to be weighed against the user benefits of shipping that new feature or removing that risky old one. Similarly, in cases where Blink is the first engine to ship a feature or to remove it, we should make sure other browser vendors can follow. We do that by ensuring shipped features designs are widely reviewed, and have specifications and tests to guide future implementers.

The Chromium project is rather large, and is being worked on by many different entities. Therefore it needs to control which features get shipped, while being even-handed in that decision process. We achieve that through a simple process that guides contributors as they evolve the platform to ensure maximum long-term compatibility and interoperability.

What features get worked on?

Chromium is an open source project that’s being worked on by over 2000 engineers from ~55 different organizations. Of course, Google is responsible for the bulk of Chromium - 92% of commits to the project (data) come from Google,  although about 20% of contributors are not Google-affiliated.
With a project of this magnitude, each of the involved companies and contributors are naturally pushing their own slightly different agenda and priorities. Even within Google’s Chrome team there are multiple ways to prioritize which problems are most urgent to tackle and solve. One area that is consistent, is that we work with the ecosystem and developer partners to understand and address their needs. We do that by creating compatibility dashboards, collaborating with frameworks, and observing development patterns in the wild.

The MDN survey is a great example of how the ecosystem can help shape the priorities that a browser vendor has. We’re still in the process of analyzing the results, but it was clear that compatibility is a top priority for developers and we will commit to keep improving on it. We also plan to create more ways to gather structured data on developer needs and hardships.

As you can imagine, with all these priorities from different contributors, it's important for us to be clear about how a feature goes from inception to shipping.

So, what are the typical phases of creating a new web platform feature and shipping it in Chromium?

The very first step before getting started would be to figure out what we need to be working on and which user or developer problems are the most burning ones. That is typically done by talking to partners, looking at current development patterns and consulting with web developers and framework authors to get a better understanding of what the platform can do better to address their and their users’ needs.
Once we know which problem we want to tackle, we can start incubating it!

What does “incubating” mean?

Over the years, we found that the best way to design and prototype a new platform feature is through incubation - getting a strong grasp of the use cases a feature is trying to solve as a first step, and then rapidly iterating over the design in a public forum that includes browser engineers and domain experts. Only once we are certain that a feature solves important use-cases and have high confidence that it solves it the right way, we bring that feature to an official track at a Standard Development Organization, such as a W3C Working Group, the WHATWG, or TC39.

Not all incubations turn up to be standards though. Some incubations fail and some prototypes never make it out to the hands of users. That is perfectly fine and by design. The web platform cannot afford features that don’t solve real user or developer problems to creep in, and we want to make sure those features never make it to be a permanent part of the platform. 

Step 1 - Initial research
At this phase, we establish a better understanding of the problem space, by gathering up the specific use-cases we want our future solution to tackle and the constraints under which the solution must operate.

At the end of that phase, engineers are expected to publish an explainer that outlines the above, and maybe have a very rough sketch of what a solution may look like. The explainer is published in a relevant public forum (e.g. the WICG discourse) in order to solicit feedback from the web community at large. Such feedback can include missed-out use-cases, further constraints that can impact the design, or simply statements of support for solving the problem.

It’s important at this stage to focus on the problem, and not over-index on any one possible solution - and this is one of the places we haven’t always been perfect.

Step 2 - Design & Prototype

Now that we have better grip of the problems we’re trying to solve and the constraints in which we operate, we can start designing the feature and what it may look like. Ideally, the design team would include browser engineers from interested vendors as well as problem space experts from the web developer or framework developer community.

Once we have an initial rough design, it might be a good idea to start building and committing  code (behind a flag and turned off by default) in order to better understand the solution’s feasibility and complexity.

That’s when engineers should send out an “Intent to Prototype” email to blink-dev (previously, “Intent to Implement”), in order to notify the relevant code owners that work is underway in that area. Note that such an intent doesn’t mean that the feature is shipping soon, or that it will ship at all for that matter. It just means that this is a problem space that’s being explored, and code is landing to that end. 

That’s also a good point in time to make sure the feature will get a wider review, by filing for a TAG review.

Step 3 - Experiment & iterate

Once code starts to land behind a flag, it’s a good time for interested web developers to start playing around with the solution by turning on the feature flag and testing it out.
Feedback on the initial implementation is critical in order to make sure the eventual design would work well for developers and users alike.
For some features, such experimentation is enough for developers to get a good handle on what’s the solution looks like, and how well it addresses the problem.

In other cases, it’s critical to gather data from the field regarding the solution, to see how well it works in broader deployment to fulfill user’s needs, or get a better understanding of its performance characteristics at scale.

Step 3.5 - Origin Trial

In those cases, a browser engineer can request an Origin Trial (by sending out an Intent to Experiment email), which enables interested developers to test the feature out in broader deployment to users who have not turned on the feature flag. Once an Origin Trial is in place, developers can register for the trial, and enable the feature (in production) for their domains. That enables them to gather data on the user impact of the feature, and report it back to the design team, confirming or refuting their assumptions regarding the solution’s viability.

Note that an Origin Trial is a temporary experiment, and there’s a good chance that the feature will significantly change before it will be enabled by default, or even that the effort will be dropped altogether. Developers interested in participating should take that into account, and not rely on the feature being available to their users beyond the scope of the trial.

Step 4 - ship it!

Once the previous steps were completed with success and the team believes the feature is ready to be turned on by default, that’s when they can submit an Intent to Ship.

That’s a part of the process that’s a bit more strict.

In order to ship a feature by default, engineers need approval for the feature to ship from 3 API owners.

What’s an “API owner”?
API owners are a set of trusted Chromium engineers, who are responsible for enforcing the Blink process guiding principles. Each feature we’re trying to ship has some user and developer benefits, otherwise we probably wouldn’t be working on it. Shipping new features can introduce interoperability risks, if other browsers don’t follow us. The API owners are tasked with applying our compatibility and interoperability principles and help evaluate each shipping feature with regards to its risk/benefit tradeoff. They then provide their approval on “Intent to Ship” threads for new shipping features, if they think the benefits outweigh the risks. Those approvals are provided in the form of “LGTM” (“Looks Good To Me”) replies on intent threads.

Note that LGTMs are not required for Intent to Prototype. For an Intent to Experiment, approval from a single API owner is sufficient, as the risk they pose is fairly contained.

As part of the “Intent to Ship” request, chromium engineers need to provide clear signals regarding the risk and benefit tradeoff of the feature.

Note that the fact that an “intent to ship” is sent indicates the team’s estimate of the feature being ready to ship, but it does not necessarily mean that the feature will ship shortly, or at all.

Some features take a long time to go through the intent process, in order to prove that the risk they pose is low enough to justify shipping. Others get held up addressing feedback from other vendors or from wide-review forums. 

In other (rare) cases, features can be rejected by the API owners, and their proponents then need to look for alternative ways to resolve the problem, which won’t hit the same concerns that got their initial intent rejected.

Removing features

Finally, while adding new feature certainly grabs most people’s attention, an equally important part of the intent process is to deprecate and remove legacy web platform features. In those cases, the main risk is breaking existing content, and the benefits are typically around improving user’s security, privacy and performance. The project’s willingness to take some compatibility risk and remove features is critical to our risk/benefit calculus also when launching features first - if we got it wrong and late feedback causes us to change course, we typically can figure out a path to deprecate those features to get us back on track to interoperability.


The Chromium’s project goal is to make sure the web platform remains a healthy and successful platform.
For that, we believe the platform needs to make significant progress in the face of shifting developer and user expectations, as well as adapt to the changing market forces and constraints. At the same time, we need that progress to be done in a responsible manner both inside the Chromium project and when it comes to our collaboration with the wider ecosystem.

The Blink process’ role is to keep the balance between those different requirements, and to help ensure the web is a thriving platform for generations to come.

Posted by Yoav Weiss, Wrangler of processes and Advocate of developers.

Chrome Dev Summit 2019: Elevating the Web Together

As the largest open ecosystem in history, the Web is a tremendous utility, with more than 1.5B active websites on the Internet today, serving nearly 4.5B web users across the world. This kind of diversity (geography, device, content, and more) can only be facilitated by the open web platform.

Users uniquely experience the Web as one as they navigate from site to site, and thus the responsibility is with all of us to work on delivering quality experiences that reach all.

At this year’s Chrome Developer Summit (CDS), we are focusing on giving developers the capabilities to reach the bar that our users demand. To help further foster the diversity and capability for web developers, we’ve been working closely with the ecosystem to make enhancements to the web platform, improve developer experience, and make meaningful updates to the browser itself.

Enhancing the versatility of the Web

Our vision is to make loading disappear for all our users. At I/O this year, we previewed Portals, which allows developers to create seamless experiences by pre-rendering content and optionally embedding it in the page to change the way users navigate across the web. We’re pleased to see the new style navigation from early partners like Fandango have been testing on their site already. Portals is available behind the chrome://flags/#enable-portals flag for developers to experiment with.
Fandango Portals demo

At CDS this year, we’re previewing Web Bundles, an infrastructural API that will allow developers to distribute their web content across any format - email, FTP, or even USB, without any compromises. Not only does this unlock delivery of web content at lightning fast speeds, it will also allow for peer-to-peer distribution even when users are offline. In the future, APIs like Background Periodic Sync and Content Indexing will allow developers to proactively cache and surface relevant web content for people even if they’re not on an active internet connection. Web Bundles is now available behind the experimental flag, and the other two are now available as origin trials.

Consumption of web content has never been more diverse; while the rise of mobile-first in developing markets has been well documented, we’re now seeing an increase in cross-device computing with the youth across the globe. We’re committed to making the platform powerful enough for developers to create amazing modern experiences that users expect while taking advantage of the frictionless of the web. By focusing our efforts on enabling fully capable web applications, we’ve been working to bring many primitives to the platform, including:  

There’s a lot more that we’re working on in this space and we can’t wait to see what you build with these capabilities. You can read all about our latest work in our blog on supporting new web experiences.

Enabling developer success no matter the framework or CMS

As web developers, we’re on a collective journey providing people their best, unique web experience. This collective responsibility makes accurate, actionable data on the health of the web increasingly important.

CDS gives us a checkpoint to see how we are doing and have a discussion on where we go next. We use the HTTP Archive to see how the web is built and the Chrome User Experience Report to see how it is experienced. Over the past year, we’re seeing a positive growth in the percentage of sites with fast First Contentful Paint and fast First Input Delay, our core metrics for loading and interactivity.

Measuring user experience quality is multi-faceted, today we introduced two new metrics to give developers a holistic view of how their sites are performing. Largest Contentful Paint (how quickly users see the most meaningful page content) and Cumulative Layout Shift (how stable a page feels).

Now, data is great, but insights that lead to fixes and improvements are better. We often get asked “What do I do with this information?” We’ve collaborated with many experts from the community on The Web Almanac, to give developers a holistic view of the health of the web. We launched over 17 chapters today and we’re excited to continue to identify and share more such insights.

Developers work incredibly hard to move their performance metrics in the right direction, so we are looking at ways to reward developers for going the extra mile. Today we are sharing some early explorations which surface speed signals in Chrome’s UI.

Frameworks, libraries and CMS’es form a critical part of the developer ecosystem and we’re keen to support them on their journey of creating instant and seamless for their users. Earlier this year we created Lighthouse Stack Packs for WordPress and React to support their developer ecosystems in build fast and reliable sites, and today we’ve increased the coverage include Angular, AMP as well as the ecommerce CMS, Magento, bring more actionable insights to developers irrespective of the tools developers use.

We’ve been excited to see that the Framework Fund has supported a number of meaningful projects that make it easier to hit the performance bars by default, and we’re looking forward to seeing more projects being funded this year.

Finally, we have launched Lighthouse CI to make sure that developers are given insights for each pull request. Developers can quickly hook up Lighthouse CI to their build pipeline to get a rich diff of the changes that they made and the impact it had on the quality of their site.

Making the browser work for you

We believe the web is for everyone, no matter their device type, internet speed or purchasing power.  To help ensure the platform remains accessible to all, we’re investing in performance and memory improvements to the browser, including bringing new features like Image Lazy Loading that is now going to be available to Chrome Lite users by default, and Paint Holding, shipping soon in Chrome.

The web needs to be a safe and trustworthy place for everyone. Furthering our initiatives around HTTPS encryption, we began working with the community to start blocking all mixed content - insecure HTTP subresources on HTTPS pages - by default, and also experimenting with DNS over HTTPS, which offers better security and privacy by encrypting the traffic between the browser and DNS provider

We are also following up on our I/O promise to make our existing third-party cookie controls more visible. Starting with the Chrome M79 Beta, we’re experimenting with a toggle for controlling third-party cookies on the Incognito New Tab Page. We are also working on redesigning our settings pages to make access to this control easier in regular mode. And finally, apart from continuing to make progress to improve the existing cookies infrastructure, we’re also continuing to develop our Privacy Sandbox, a secure environment for content that also protects user privacy.

We want to thank the entire web community for their continued investment in a platform that is so impactful to so many people around the world. We believe it is our collective responsibility to elevate the web experience for every user and in that spirit, let's celebrate the 'We' in Web.

Posted by Dion Almaer, Web Developer Ecosystem

Moving towards a faster web

Speed has been one of Chrome’s core principles since the beginning - we’re constantly working to give users an experience that is instant as they browse the web. That said, we have all visited web pages we thought would load fast, only to be met by an experience that could have been better. We think the web can do better and want to help users understand when a site may load slowly, while rewarding sites delivering fast experiences.

In the future, Chrome may identify sites that typically load fast or slow for users with clear badging. This may take a number of forms and we plan to experiment with different options, to determine which provides the most value to our users. 

Badging is intended to identify when sites are authored in a way that makes them slow generally, looking at historical load latencies. Further along, we may expand this to include identifying when a page is likely to be slow for a user based on their device and network conditions. 

Our early explorations will look at a number of Chrome surfaces, including the loading screen (splash screen), loading progress bar and context-menu for links. The latter could enable insight into typical site speeds so you’re aware before you navigate. 

Our plan to identify sites that are fast or slow will take place in gradual steps, based on increasingly stringent criteria. Our long-term goal is to define badging for high-quality experiences, which may include signals beyond just speed. 

We are building out speed badging in close collaboration with other teams exploring labelling the quality of experiences at Google. We believe this will ensure that if you are optimizing your site to be fast, your site will not be inconsistently badged from one surface to another.

We are being very mindful with our approach to setting the bar for what is considered a good user experience and hope to land on something that is practically achievable by all developers. We will publish updates to this plan as we approach future releases, but don’t wait to optimize your site. A number of resources are available for learning what opportunities are available to improve your site speed.
To evaluate performance, check:

To learn about performance best practices, check - our learning platform with guides and codelabs on how to get your pages loading instantly.

We are excited to reward you for your work and give our users more transparency into typical site performance. We hope this effort will encourage more sites on the open web to provide the best possible experiences to all users.

Posted by Addy Osmani, Ben Greenstein and Bryan McQuade from the Chrome team

Making new experiences possible on the web

The web that we know today has come a long way from its humble beginnings as simple interlinked documents; today it powers a huge number of rich services and applications.

Content consumption is at the heart of the web, however there are many tasks that people need to turn to native applications to accomplish. Our vision is that applications shouldn't require heavyweight downloads or updates. The web should be more than enough for any user experience. 

What Makes the Web Special for Apps
The greatest strength of the web is the incredible ease of access. Content and functionality is immediately available to users without any installs or setup required.  We have all enjoyed this ease of access for shopping, email, banking, connecting with friends, and much more, but there is no reason this ease of access can’t apply to practically any use case. Because of the hardened sandbox and progressive permission model of the web, users don’t have to worry about clicking a link the same way they need to worry about downloading an executable. 

The URL and linkability supercharge the distribution and virality of applications and makes collaboration easy. With a web application, users can share a link through any channel and the receiving user can click that string to quickly access the application. Users sharing the link don’t need to worry about whether the receiving user has the application installed or if their OS even supports it; the application is simply there and works everywhere. This ease of sharing and ease of access also dramatically widens the user acquisition funnel.

The web is a truly open platform. You control the availability of your site and no one can block your users from accessing it. The web is also built on open standards and every major renderer is open source. This means you aren’t dependent on any one specific company or OS and as new devices & platforms emerge the web will be supported there as well. 

Chromium's 3 Piece solution

Today, anyone with a browser can collaborate on complex designs, create CAD drawings, edit documents, watch endless videos, and play tons of games, but there are still gap compared to what native applications can do. These are tasks like complex editing, creativity tools, and advanced device communication. Chromium is pursuing WebAssembly, Advanced Capabilities, and Progressive Web Apps in order to close them.

WebAssembly: Powerful Portability  
Developers should be able to performantly bring existing investments in low-level languages like C++ to the web. The need for reliable, high performance for demanding workloads has also been a reason some apps avoid the web. Our answer to both these needs is WebAssembly.

WebAssembly uses a combination of low-level primitives and strong static typing to deliver predictable performance for low-level code, avoiding the performance cliffs and GC pauses. With additions like threads and SIMD, applications can make full use of modern, multi-core processors with advanced instruction sets. 

Because WebAssembly is a compilation target, it allows developers to bring their existing applications and libraries to the web without rewriting in JavaScript. The Emscripten toolchain offers a lot of porting support and has let applications such as AutoCAD & Sketchup come to the web, and the results are amazing. The web's advantages of easy sharing and collaboration, applied to advanced productivity apps, open up whole new ways of working.

Advanced Capabilities: Securely granting access to powerful capabilities 
For Web Apps to be as useful as native apps, they need to have access to the same device capabilities that native apps enjoy, like file system access, NFC communication, contact picker, geolocation, and many more

Exposing these capabilities in a user-understandable and safe way is a big challenge, but one that Chromium is committed to. The web works through a progressive permission model, where each capability is granted as needed through user permission and is as limited in scope as possible. This is in contrast to native apps, which can get full access to your file system, while web apps can only save back to folders and files you have explicitly shared and given write permission for. For capabilities like USB or Bluetooth, we allow the user to choose the specific device they would like to share.  

Progressive Web Apps: The native feel with web superpowers
Web apps need to behave like other applications and be in the places users expect them to be in order to earn a central place in our lives. Our answer is Progressive Web Apps (PWAs). 
PWAs can be installed and behave like any native app. Once installed they are launched from the same place as other installed apps and open in their own window. We are also working with Microsoft and Chrome OS to provide deeper integration such as appropriate storage management attribution. PWAs can even be listed in the Microsoft and Samsung Galaxy store and can utilize Trusted Web Activities to be in the Play store.   

Here’s to an ever advancing web
The web has come a long way since its original inception. The web is a truly unique platform with properties that benefit users and developers. Through the enabling technologies of WebAssembly, powerful capabilities, and PWAs, developers will be able to create any experience their users need and utilize the web’s amazing properties.

Posted by Thomas Nattestad, Product Manager, Awesome web experiences

Chrome 79 Beta: Virtual Reality Comes to the Web

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on Chrome 79 is beta as of October 31, 2019.

Virtual Reality Comes to the Web

The WebXR Device API is shipping in Chrome. Developers can now create immersive experiences for smartphones and head-mounted displays. Other browsers will be supporting these specs soon, including Firefox Reality, Oculus Browser, Edge and Magic Leap's Helio browser, among others.

This launch sets the foundation for immersive features to come, such as supporting augmented reality, tools, and expanding the real-world understanding of immersive experiences. Many experiences can be enhanced with immersive functionality. Examples include games, home buying, viewing products in your home before buying them and more. To get started with virtual reality and the new API, read Virtual reality comes to the web.

Origin Trials

This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

Support for rendersubtree Attribute

Adds the rendersubtree attribute to all HTML elements, which locks a DOM element for display. When rendersubtree is set to "invisible", the element's content is not drawn or hit-tested, allowing for rendering optimizations. The rendersubtree "activatable" token allows the browser to remove the invisible attribute, rendering the content, and making it visible.

Wake Lock API based on Promises

Adds an update of the Wake Lock API that introduce promises and wake lock types. The Wake Lock API brought a standard, secure, and safe way to prevent some device features such as the screen or CPU cycles from going into power saving state. This update addresses some of the shortcomings of the older API which was limited to screen Wake Lock and didn't address certain security and privacy issues.

Other Features in this Release

Adaptive Icon Display for Installed PWAs on Android

Android Oreo introduced adaptive icons, which enforced the same shape for all icons on the home screen and in the launcher. Before android O icons could be any shape and there was no background behind each icon. For example, gmail was rectangular, and Play was a triangle. Consequently, such icons were placed in a white circle. With adaptive icon display, Android will automatically mask irregularly shaped icons to fit properly.

Autofocus Support for any Focusable HTML/SVG Element

Adds the autofocus attribute to any focusable HTML or SVG element. The autofocus was previously supported for a limited number of HTML elements, and there were elements which could receive focus but didn't support the autofocus attribute. This feature fixes the inconsistencies.

Compute img/video Aspect Ratio from Width Or Height HTML Attributes

The aspect ratio of an image is now computed so that it can be used for sizing an image using CSS before it loads. This avoids unnecessary relayouts when the image loads.


The font-optical-sizing property
automatically sets the font size to the opsz - optical sizing axis of variable fonts that support optical sizing. This improves styling and legibility of fonts depending on font size because the font chooses a glyph shape that works optimally at the given font size. For example, the glyph contrast is improved in fonts in heading sizes when compared to the same font at body text size.

list-style-type: <string>

Allows a stylesheet to use an arbitrary character for the list style marker. Examples include "-", "+", "★" and "▸". Since CSS Level 2, list-style-type has supported keywords like disc or decimal to define the appearance of the list item marker.
Without this, developers are often forced to hide the real marker and insert the arbitrary marker using a ::before pseudo element via the content property. Unfortunately, the fake marker won't be nicely positioned by list-style-position.

Reject Worklet.addModule() with a More Specific Error

When Worklet.addModule() fails, a promise rejects with a more specific error object than it did previously. Worklet.addModule() can fail for various reasons, including, for example, network errors and syntax errors. Before this change, Worklet.addModule() rejected with AbortError regardless of the actual cause. That made it difficult for developers to debug worklets. After this change, Worklet.addModule() rejects with a clearer error such as SyntaxError.

Retrieve a Service Worker Object Corresponding to a Worker Itself

A service worker can now get its ServiceWorker object with self.serviceWorker in a service worker script and its current state with self.serviceWorker.state. A service worker instance previously had no way to get its current lifecycle state. This removes the need for the hack wherein the current lifecycle state is tracked with a global variable, a method that is error prone and doesn't correctly capture waiting periods.

Stop Evaluating Script Elements Moved Between Documents During Fetching

Chrome no longer evaluates scripts or fire error and load events if <script> elements are moved between documents during fetching. Script elements can still be moved between documents, but they won't be executed. This prevents possible security bugs caused by exploitation of <script> elements moved between documents.

Deprecations, and Removals

This version of Chrome introduces the deprecations and removals listed below. Visit for lists of current deprecations and previous removals.

-webkit-appearance Keywords for Arbitrary Elements

Changes -webkit-appearance keywords to work only with specific element types. If a keyword is applied to a non-supported element, the element takes the default appearance.

Addressing some misconceptions about our plans for improving the security of DNS

Whenever you type a URL into your browser (for example “”), this information is sent to a domain name system (DNS) provider that converts that request into the unique numerical “IP address” (e.g. that identifies websites on the Internet. Your browser then uses that numerical IP address to take you to the site you were looking for. Unfortunately, today the requests from your browser to the DNS provider are not encrypted (which makes you vulnerable to passive monitoring by strangers) nor authenticated (which makes you vulnerable to online attackers). This is especially true when you’re connected to public WiFi, for example at a cafe or airport, since anyone else using the network can see and track the websites you visit and maybe redirect your browser to a malicious website.

In September, we announced an experiment in Chrome to improve online privacy and security by enabling secure DNS connections with DNS-over-HTTPS (DoH) for users already using DNS providers that support it. DoH is being developed by the Internet standards community as a step toward better security and privacy by encrypting the traffic between your browser and your DNS provider. It improves privacy by removing one of the ways used by malicious actors to observe the browsing habits of other users on the same network. DoH is also a significant security improvement, as it helps stop man-in-the-middle attacks on DNS lookups. Many privacy-minded organizations, journalists, other browser providers and internet service providers (ISPs) agree that these changes will improve your privacy and security.

Unfortunately, there has been some misinformation and confusion about the goals of our approach and whether DoH will impact existing content controls offered by ISPs. The confusion comes from two particular claims and we want to address both.

The first claim is that Google is going to redirect user DNS traffic to Google's own DNS or another DoH-compliant DNS provider. That is incorrect. Because we believe in user choice and user control, we have no plans to force users to change their DNS provider. Today, there are many independent DNS providers, although ISPs serve approximately 97% of user DNS needs. As long as these service providers keep catering to user needs and concerns, it will remain a diverse ecosystem. We’re simply enabling support in Chrome for secure DoH connections if a user’s DNS provider of choice offers it. Chrome will check if the user’s DNS provider is among a list of participating DoH-compatible providers and if so, it will enable DoH. If the DNS provider is not on the list, Chrome won’t enable DoH and will continue to operate as it does today. As DoH adoption increases, we expect to see the number of DoH-enabled DNS providers grow.

The second claim we’ve seen is that the secure DoH connection will limit the family-safe content controls offered by some ISPs. In fact, any existing content controls of your DNS provider, including any protections for children, should remain active. DoH secures the URL data only while it’s in transit between your browser and the DNS provider, so your provider’s malware protection and parental control features will continue to work as they have in the past. As a proof point, CleanBrowsing offers the same parental control features on its DoH service as it does on its unencrypted service.

As we said last month, we’re taking an incremental approach with this experiment, and our current plan is to enable DoH support for just 1% of our users, provided that they are already using a DoH compliant DNS provider. This will allow Google and DoH providers to test the performance and reliability of DoH. We’ll also monitor feedback from our users and from other stakeholders, including ISPs. Most managed Chrome deployments such as schools and enterprises are excluded from the experiment by default. We also offer policies for administrators to control the feature. Finally, Chrome users may opt-out of the DoH experiment entirely by going to chrome://flags/#dns-over-https, starting in Chrome 79.

We are optimistic about the opportunities DoH offers for improving user privacy and security, but we also understand the importance of DNS and that there could be implementation concerns we haven’t foreseen. That’s why we plan to move carefully and transparently. We’re open to feedback and welcome constructive collaboration and engagement. We are committed to ensure that the deployment of DoH does not create unintended consequences and we will continue to work with stakeholders including ISPs, DNS providers, and Internet and child safety advocates as we make progress.

Posted by Kenji Baheux, Chrome Product Manager

Automatically lazy-loading offscreen images & iframes for Lite mode users

In Chrome 76, we introduced native lazy-loading for images and iframes via the `loading` attribute - a developer opt-in. In Chrome 77, Chrome Android users with  Lite Mode (Data Saver) enabled will benefit from native lazy-loading of images and iframes automatically.

Lite mode has allowed Chrome to reduce users’ data usage by up to 60 percent, often by compressing the pages users request before downloading them. 

Web pages commonly have images or embedded content that is out-of-view near the bottom of the page, and users typically don’t scroll all the way down to discover them. Today, devices need to use resources loading this content, which is challenging for users on a limited data-plan or with a spotty network connection.

When a user has Lite Mode enabled on Chrome for Android, Chrome will defer the load of below-the-fold images and iframes until the user scrolls near them. This is done without requiring developer action. Automatic lazy-loading helps to reduce network data use and memory use. It may also increase site speed, by prioritizing content visible to the user.

In our experiments, native lazy-loading of images and iframes yields a ~10% reduction in bytes downloaded per page at the 75th percentile and an 8% reduction in overall downloaded bytes for the median user. Automatic lazy-loading also led to a 1-2% improvement in First Contentful Paint at the median, a 2% improvement in First Input Delay at the 95th percentile and a 0.7% improvement in median memory reduction per page. We expect increased benefits as we tune the feature.

Chrome’s native lazy-loading has different distance thresholds after which deferred content will start loading, based on factors such as the effective connection type. This distance is chosen so that content we’ve deferred almost always completes loading by the time it becomes visible. 

Any <iframe> or <img> with the `loading` attribute value of `auto` will also be eligible for Lite Mode’s automatic lazy-loading. This includes <picture> elements and CSS background images.  

It is important to note that automatic lazy-loading of images and iframes is only done if a user has Lite Mode enabled. Lite Mode is most heavily used in areas of the world with poor and expensive connectivity and we believe it is users in these regions that will benefit the most from the feature. Sites wishing to learn what percentage of users have Lite Mode turned on can monitor truthy values from the  SaveData JavaScript API in their analytics.

To enable Lite mode, select Settings > Lite mode and toggle the setting to On. We look forward to this feature helping users keep their page loads just a little bit lighter.

Posted by Addy Osmani, Scott Little and Raj T - lazy Chrome engineers.

Developers: Get Ready for New SameSite=None; Secure Cookie Settings

UPDATE (10/28/2019): We've revised the 2nd and 3rd bullet points in the section "How to Prepare; Known Complexities" below.
In May, Chrome announced a secure-by-default model for cookies, enabled by a new cookie classification system (spec). This initiative is part of our ongoing effort to improve privacy and security across the web.
Chrome plans to implement the new model with Chrome 80 in February 2020. Mozilla and Microsoft have also indicated intent to implement the new model in Firefox and Edge, on their own timelines. While the Chrome changes are still a few months away, It’s important that developers who manage cookies assess their readiness today. This blog post outlines high level concepts; please see SameSite Cookies Explained on for developer guidance.

Understanding Cross-Site and Same-Site Cookie Context

Websites typically integrate external services for advertising, content recommendations, third party widgets, social embeds and other features. As you browse the web, these external services may store cookies in your browser and subsequently access those cookies to deliver personalized experiences or measure audience engagement. Every cookie has a domain associated with it. If the domain associated with a cookie matches an external service and not the website in the user’s address bar, this is considered a cross-site (or “third party”) context.

Less obvious cross-site use cases include situations where an entity that owns multiple websites uses a cookie across those properties. Although the same entity owns the cookie and the websites, this still counts as cross-site or “third party” context when the cookie’s domain does not match the site(s) from which the cookie is accessed.
When an external resource on a web page accesses a cookie that does not match the site domain, this is cross-site or “third-party” context.

In contrast, cookie access in a same-site (or “first party”) context occurs when a cookie’s domain matches the website domain in the user’s address bar. Same-site cookies are commonly used to keep people logged into individual websites, remember their preferences and support site analytics.

When a resource on a web page accesses a cookie that matches the site the user is visiting, this is same-site or “first party” context.

A New Model for Cookie Security and Transparency

Today, if a cookie is only intended to be accessed in a first party context, the developer has the option to apply one of two settings (SameSite=Lax or SameSite=Strict) to prevent external access. However, very few developers follow this recommended practice, leaving a large number of same-site cookies needlessly exposed to threats such as Cross-Site Request Forgery attacks.

To safeguard more websites and their users, the new secure-by-default model assumes all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access. When the SameSite=None attribute is present, an additional Secure attribute must be used so cross-site cookies can only be accessed over HTTPS connections. This won’t mitigate all risks associated with cross-site access but it will provide protection against network attacks.

Beyond the immediate security benefits, the explicit declaration of cross-site cookies enables greater transparency and user choice. For example, browsers could offer users fine-grained controls to manage cookies that are only accessed by a single site separately from cookies accessed across multiple sites.

Chrome Enforcement Starting in February 2020

With Chrome 80 in February, Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies. Only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections. The Chrome Platform Status trackers for SameSite=None and Secure will continue to be updated with the latest launch information.

Mozilla has affirmed their support of the new cookie classification model with their intent to implement the SameSite=None; Secure requirements for cross-site cookies in Firefox. Microsoft recently announced plans to begin implementing the model starting as an experiment in Microsoft Edge 80.

How to Prepare; Known Complexities

If you manage cross-site cookies, you will need to apply the SameSite=None; Secure setting to those cookies. Implementation should be straightforward for most developers, but we strongly encourage you to begin testing now to identify complexities and special cases, such as the following:

  • Not all languages and libraries support the None value yet, requiring developers to set the cookie header directly. This Github repository provides instructions for implementing SameSite=None; Secure in a variety of languages, libraries and frameworks.
  • Some browsers, including some versions of Chrome, Safari and UC Browser, might handle the  None value in unintended ways, requiring developers to code exceptions for those clients. This includes Android WebViews powered by older versions of Chrome. Here’s a list of known incompatible clients.
  • App developers are advised to declare the appropriate SameSite cookie settings for Android WebViews based on versions of Chrome that are compatible with the  None value, both for cookies accessed via HTTP(S) headers and via Android WebView's CookieManager API, although the new model will not be enforced on Android WebView until later.
  • Enterprise IT administrators may need to implement special policies to temporarily revert Chrome Browser to legacy behavior if some services such as single sign-on or internal applications are not ready for the February launch.
  • If you have cookies that you access in both a first and third-party context, you might consider using separate cookies to get the security benefits of SameSite=Lax in the first-party context.
SameSite Cookies Explained offers specific guidance for the situations above, and channels for raising issues and questions.

To test the effect of the new Chrome behavior on your site or cookies you manage, you can go to chrome://flags in Chrome 76+ and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments. In addition, these experiments will be automatically enabled for a subset of Chrome 79 Beta users. Some Beta users with the experiments enabled could experience incompatibility issues with services that do not yet support the new model; users can opt out of the Beta experiments by going to chrome://flags and disabling them.

If you manage cookies that are only accessed in a same-site context (same-site cookies) there is no required action on your part; Chrome will automatically prevent those cookies from being accessed by external entities, even if the SameSite attribute is missing or no value is set. However we strongly recommend you apply an appropriate SameSite value (Lax or Strict) and not rely on default browser behavior since not all browsers protect same-site cookies by default.

Finally, if you’re concerned about the readiness of vendors and others who provide services to your website, you can check for Developer Tools console warnings in Chrome 77+ when a page contains cross-site cookies that are missing the required settings:

A cookie associated with a cross-site resource at (cookie domain) was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at and”

Some providers (including some Google services) will implement the necessary changes in the months leading up to Chrome 80 in February; you may wish to reach out to your partners to confirm their readiness.

Posted by Barb Palser, Chrome and Web Platform Partnerships

Recent Site Isolation improvements

In July 2018 we launched Site Isolation in Chrome as a way to secure desktop browsers against the risk of side-channel attacks like Spectre. We recently published a USENIX Security conference paper highlighting the benefits of this launch. Today, we are pleased to announce further improvements we've rolled out in Chrome 77:

Site Isolation on Android

Chrome 77 has brought Site Isolation and its benefits to Android users. Like Site Isolation on desktop, this launch leverages OS processes to make it harder for attackers to steal data from other websites. In particular, it offers the most effective defense against Spectre-like CPU vulnerabilities.

We wanted to ensure that Site Isolation does not adversely affect user experience in a resource-constrained environment like Android. This is why, unlike desktop platforms where we isolate all sites, Chrome on Android uses a slimmer form of Site Isolation, protecting fewer sites to keep overhead low. More specifically, Site Isolation is turned on only for high-value sites where users log in with a password. This protects sites with sensitive data that users likely care about, such as banks or shopping sites, while allowing process sharing among less critical sites.

Once Chrome observes a password interaction on a website, future visits to that site will be protected by Site Isolation. That means the site will be rendered in its own dedicated renderer process, walled off from other sites. Navigations to other sites will cause a tab to switch processes, and cross-site iframes are put into a different process, becoming "out-of-process iframes." Chrome keeps a list of isolated sites stored locally on the device and clears the list whenever users clear their browsing history or other site data. To bootstrap, Chrome also isolates a crowdsourced list of sites where mobile users have been entering passwords most frequently.

For the most part, Site Isolation is a behind-the-scenes architectural change that should not change the experience for users or developers. As on desktop platforms, it does cause Chrome to create more processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 3-5% total memory overhead in real workloads. We continue to work hard to optimize this behavior to keep Chrome both fast and secure.

In Chrome 77, password-triggered Site Isolation has been enabled for 99% of users (with a 1% holdback to monitor and improve performance) on Android devices that have a sufficient amount of RAM (currently 2GB). While we investigate how to bring this support to more devices, users who desire the most complete protection for their devices may manually opt in to full Site Isolation via chrome://flags/#enable-site-per-process, which will isolate all websites but carry higher memory cost.

In the future, we plan to add support for more ways of detecting when a site should be protected by Site Isolation. For example, we're working on allowing website operators to opt in any site to Site Isolation, without requiring user login.

Containing Compromised Renderers

On desktop platforms, Site Isolation in Chrome 77 now helps defend against significantly stronger attacks. Our initial launch targeted Spectre-like attacks which could leak any data from a given renderer process. Site Isolation can now handle even severe attacks where the renderer process is fully compromised via a security bug, such as memory corruption bugs or Universal Cross-Site Scripting (UXSS) logic errors.

For example, suppose an attacker discovered and exploited a memory corruption bug in Chrome's rendering engine, Blink. The bug might allow them to run arbitrary native code within the sandboxed renderer process, no longer constrained by the security checks in Blink. However, Chrome's browser process knows what site the renderer process is dedicated to, so it can restrict which cookies, passwords, and site data the entire process is allowed to receive. This makes it far more difficult for attackers to steal cross-site data.

In Chrome 77, Site Isolation helps protect many types of sensitive data from such compromised renderer processes:
  • Authentication: Cookies and stored passwords can only be accessed by processes locked to the corresponding site.
  • Network data: Site Isolation uses Cross-Origin Read Blocking to filter sensitive resource types (e.g., HTML, XML, JSON, PDF) from a process, even if that process tries to lie to Chrome's network stack about its origin. Resources labeled with a Cross-Origin-Resource-Policy header are also protected.
  • Stored data and permissions: Renderer processes can only access stored data (e.g., localStorage) or permissions (e.g., microphone) based on the process's site lock. 
  • Cross-origin messaging: Chrome's browser process can verify the source origin of postMessage and BroadcastChannel messages, preventing the renderer process from lying about who sent the message.

We are continuing to improve compromised renderer protections in several ways:

  • Bringing these protections to Chrome for Android. This requires extra work to handle the case where only certain sites are isolated.
  • Protecting CSRF defenses. Sec-Fetch-Site and Origin request headers can be verified to prevent compromised renderers from forging them.
  • Protecting more types of data. We are investigating how to protect additional data types by default with Cross-Origin Read Blocking.
  • Removing exceptions. We are working to remove cases where these protections may not yet apply. For example, a small set of extensions still have broader cross-site access from content scripts, until they update to the new security model. We have already worked with extension authors to bring the affected Chrome user population down from 14% to 2%, as well as harden other extension security issues. Also, Site Isolation does not apply to Flash, which is currently disabled by default and is on a deprecation path.

We're excited about the improvements this brings to Chrome's overall security model. As a result, we are broadening the scope of the Chrome Vulnerability Reward Program to also cover cross-site data disclosure attacks that involve compromised renderers. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards than the usual amount for information disclosure bugs. We are grateful for the contributions from security researchers that we have received so far, and we look forward to working together further to improve the state of web security.

Posted by Alex Moshchuk and Łukasz Anforowicz, Site Isolators

DM Verity Algorithm Change

One of the foundational security features of Chromebooks is Verified Boot, which protects our users from potentially malicious software being run on their devices. The last chain of verification in this process is to validate the integrity of the root file system (rootfs). This blog post describes a recent enhancement to this rootfs validation to increase the cryptographic strength against attackers. This enhancement was carefully implemented to ensure that it didn’t negatively impact the startup time of Chromebooks.

Chrome OS uses DM Verity [1] to verify the rootfs authenticity. This is to protect against malicious software such as rootkits [2], as well as accidental corruptions. The underlying structure leverages a cryptographic hash tree approach along with a kernel crypto API. With the hash tree approach individual hashes of small blocks constituting the rootfs are computed first. Then the hash tree is built up to compute and verify a final hash value [3]. This incremental approach makes the verification process less resource intensive, and consequently faster.

Until recently, the underlying hash algorithm used by DM Verity in Chrome OS has been SHA1. However, SHA1 has been found to be vulnerable to attacks a few years ago [4] and more recently research by Google and the larger security community has demonstrated that SHA1 collisions are not just theory anymore but can happen in practice [5, 6, 7]. This necessitates the replacement of SHA1 with SHA2 or SHA3 when the use scenarios makes the attacks defined in the research studies feasible.

On the other hand, the risks to DM Verity due to collision attacks are arguably low. This is because DM Verity uses a hash tree structure with disk data blocks as leaves to obtain the final hash. And to turn the collision attack into an exploit for DM Verity, the attacker would need to develop malware that would fit into a single and specific block and produce the same hash value as the original block using a chosen prefix attack. This would be computationally expensive.
We decided to proactively upgrade DM Verity in Chrome OS to use SHA256 instead. Moving to SHA256 was difficult because it is computationally more expensive than SHA1 and potentially would have increased Chromebook boot time. This is why we spent significant time tuning our implementation and measuring its performance impact on a wide range of Chromebooks to ensure that you will get very similar performance with SHA256 that you had with SHA1 when you boot your Chromebook as shown here:

Kernel boot time comparison in ms for (1)Veyron-minnie, (2)Cyan, (3)Octopus, (4)Sarien, (5)Samus, (6)Clapper, (7)Eve, (8)Bob

With this change in place your Chromebook will be safer and remain blazing fast. This migration from SHA1 to SHA256 in DM Verity is ready to go and will be on Chromebooks starting with M77.

Posted by Betul Soysal, Chrome OS security software engineer


  5. Stevens, Marc, Elie Bursztein, Pierre Karpman, Ange Albertini, and Yarik Markov. "The first collision for full SHA-1.(2017)." URL http://shattered. it/static/shattered. pdf 167 (2017): 169-177.
  6. Mezher, Monique, and Ahmed Ibrahim. "Introducing Practical SHA-1 Collisions to the Classroom." Proceedings of the 50th ACM Technical Symposium on Computer Science Education. ACM, 2019.
  7. Leurent, Gaëtan, and Thomas Peyrin. "From Collisions to Chosen-Prefix Collisions Application to Full SHA-1." In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pp. 527-555. Springer, Cham, 2019.

No More Mixed Messages About HTTPS

Today we’re announcing that Chrome will gradually start ensuring that https:// pages can only load secure https:// subresources. In a series of steps outlined below, we’ll start blocking mixed content (insecure http:// subresources on https:// pages) by default. This change will improve user privacy and security on the web, and present a clearer browser security UX to users.

In the past several years, the web has made great progress in transitioning to HTTPS: Chrome users now spend over 90% of their browsing time on HTTPS on all major platforms. We’re now turning our attention to making sure that HTTPS configurations across the web are secure and up-to-date.

HTTPS pages commonly suffer from a problem called mixed content, where subresources on the page are loaded insecurely over http://. Browsers block many types of mixed content by default, like scripts and iframes, but images, audio, and video are still allowed to load, which threatens users’ privacy and security. For example, an attacker could tamper with a mixed image of a stock chart to mislead investors, or inject a tracking cookie into a mixed resource load. Loading mixed content also leads to a confusing browser security UX, where the page is presented as neither secure nor insecure but somewhere in between.

In a series of steps starting in Chrome 79, Chrome will gradually move to blocking all mixed content by default. To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://. Users will be able to enable a setting to opt out of mixed content blocking on particular websites, and below we’ll describe the resources available to developers to help them find and fix mixed content.


Instead of blocking all mixed content all at once, we’ll be rolling out this change in a series of steps.

Resources for developers

Developers should migrate their mixed content to https:// immediately to avoid warnings and breakage. Here are some resources:

Posted by Emily Stark and Carlos Joan Rafael Ibarra Lopez, Chrome security team

Chrome UI for Deprecating Legacy TLS Versions

Last October we announced our plans to remove support for TLS 1.0 and 1.1 in Chrome 81. In this post we’re announcing a pre-removal phase in which we’ll introduce a gentler warning UI, and previewing the UI that we’ll use to block TLS 1.0 and 1.1 in Chrome 81. Site administrators should immediately enable TLS 1.2 or later to avoid these UI treatments.

While legacy TLS usage has decreased, we still see over 0.5% of page loads using these deprecated versions. To ease the transition to the final removal of support and to reduce user surprise when outdated configurations stop working, Chrome will discontinue support in two steps: first, showing new security indicators for sites using these deprecated versions; and second, blocking connections to these sites with a full page warning.

Pre-removal warning

Starting January 13, 2020, for Chrome 79 and higher, we will show a “Not Secure” indicator for sites using TLS 1.0 or 1.1 to alert users to the outdated configuration:

The new security indicator and connection security information that will be shown to users who visit a site using TLS 1.0 or 1.1 starting in January 2020.
When a site uses TLS 1.0 or 1.1, Chrome will downgrade the security indicator and show a more detailed warning message inside Page Info. This change will not block users from visiting or using the page, but will alert them to the downgraded security of the connection.

Note that Chrome already shows warnings in DevTools to alert site owners that they are using a deprecated version of TLS.

Removal UI

In Chrome 81, which will be released to the Stable channel in March 2020, we will begin blocking connections to sites using TLS 1.0 or 1.1, showing a full page interstitial warning:

The full screen interstitial warning that will be shown to users who visit a site using TLS 1.0 or 1.1 starting in Chrome 81. Final warning subject to change.

Site administrators should immediately enable TLS 1.2 or later. Depending on server software (such as Apache or nginx), this may be a configuration change or a software update. Additionally, we encourage all sites to revisit their TLS configuration. In our original announcement, we outlined our current criteria for modern TLS.

Enterprise deployments can preview the final removal of TLS 1.0 and 1.1 by setting the SSLVersionMin policy to “tls1.2”. This will prevent clients from connecting over these protocol versions. For enterprise deployments that need more time, this same policy can be used to re-enable TLS 1.0 or TLS 1.1 and disable the warning UIs until January 2021.

Posted by Chris Thompson, Chrome security team

Chrome 78 Beta: a new Houdini API, native file system access and more

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Find more information about the features listed here through the provided links or from the list on Chrome 78 is beta as of September 19, 2019.

CSS Properties and Values

CSS variables are getting more power with CSS Properties and Values API Level 1. With it, you can register your variables as full custom properties, ensuring they're always a specific type, and letting you set a default value, or even, animate them.

Take the image below, for example.

What you're seeing is a transition created with a CSS custom property. In addition to being impossible without the new API, this transition is also type safe. For details and access to the code used to generate this image, see Smarter custom properties with Houdini's new API.

Native File System

The new Native File System API, now in an origin trial, enables developers to build powerful web apps that interact with files on the user's local device such as IDEs, photo and video editors, text editors, and more. After a user grants access, this API allows web apps to read or save changes directly to files and folders on the user's device. It does all this by invoking the platform's own open and save dialog boxes. The image below shows a web page invoked using the open dialog box on Mac.

To learn more, see sample code, and a text editor demonstration app, see The Native File System API: Simplifying access to local files for details.

See the Origin Trials section for information on signing up and for a list of other origin trials in this release.

Origin Trials

This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including those described here, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

Signed Exchange Subresource Prefetching and Loading by Extending the HTTP Link Header.

Signed Exchanges allow a distributor to provide content signed by a publisher and displayed in such a way that user agents show the publisher's URL, and scripts access the publisher's local storage. The URLs of subresources are fixed in the signed top-level HTML file, which prevents their loads from taking advantage of any signed versions that might be prefetched from the distributor's origin. To allow the subresources to be prefetched from the same distributor as the top-level page,the publisher needs to change the subresource URLs in the HTML to point to each distributors’ URL and needs to sign for each distributor. The intent of this is to allow publishers to create a single signed top-level HTML file that allows its subresources to be prefetched from a variety of distributors.

SMS Receiver API

Websites use SMS messages as a way to verify phone numbers by sending a one-time-password for manual entry into a form (or for copy and paste). Native platforms offer an API that gives programmatic access to such messages that allows users to skip manual interaction with the form.
The SMS Receiver API allows websites to access SMS messages that are delivered to the user's phone specifically addressed to the origin (via a special formatting convention).

Other Features in this Release

Apply Opacity for the Default Style of INPUT/TEXTAREA placeholder

Changes the default style for ::placeholder from #757575 to rgba(0, 0, 0, 0.54).

Extend Byte-for-Byte Update Check to all Service Worker importScripts() Resources

Byte-for-byte checks are now available for service worker scripts imported by importScripts(). Currently, service workers update only when the service worker main script has changed. In addition to not conforming to the latest spec, this forces developers to build workarounds such as adding hashes to the imported script's urls.

Faster Web Sockets

Chrome 78 improves the download speed of ArrayBuffer objects when used with WebSocket objects on desktop. We have seen the following improvements in our own testing. Results depend on network speed and hardware so your results may be vary.

More restrictive hasEnrolledInstrument() for Autofill Instruments

Improves the authorization of transactions by requiring unexpired cards and a billing address. This improves the quality of autofill data and increases the chances that PaymentRequest.hasEnrolledInstrument() returns true. This improves the user experience on transactions that use autofill data.


In cases where there is something wrong with the payment response's data (for example, the shipping address is a PO box), the retry() method of a PaymentResponse instance now allows you to ask a user to retry a payment.

Percentage Opacity

Adds support for percentage values to the opacity properties, specifically, opacity, stop-opacity, fill-opacity, stroke-opacity, and shape-image-threshold. For example, opacity: 50% is equivalent to opacity: 0.5. This brings consistency and spec compliance. The rgba() function already accepts percentage alpha value, for example rgba(0, 255, 0, 50%).

Redact Address in PaymentRequest.onshippingaddresschange Event

Removes fine-grained information from the shipping address before exposing it to a merchant website in the ShippingAddressChange event. PaymentRequest.onshippingaddresschange is used to communicate the shipping address a user has selected to the merchant so they can make adjustments to the payment amounts such as shipping cost and tax. At this point, the user has not fully committed to the transaction, so the principle should be to return as little information as possible to the merchant. The redaction removes recipient, organization, addressLine and phoneNumber from the shipping address because these are not typically needed for shipping cost and tax computation.


Adds a media session action handler for the seekto action. An action handler is an event tied specifically to a common media function such as pause or play. The seekto action handler is called when the site should move the playback time to a specific time.

User Timing L3

Extends the existing User Timing API to enable two new use cases:

Deprecations, and Removals

XSS Auditor

XSS Auditor has been removed from Chrome. The XSS Auditor can introduce cross-site information leaks and mechanisms to bypass the Auditor are widely known.

Experimenting with same-provider DNS-over-HTTPS upgrade

Update: Due to a last minute technical issue, we have postponed this experiment to Chrome 79.

As part of  our long standing commitment to making the web safer to use, we will be conducting an experiment to validate our implementation of DNS-over-HTTPS (aka DoH) in Chrome 78. As the name implies, the idea is to bring the key security and privacy benefits of HTTPS to DNS, which is how your browser is able to determine which server is hosting a given website. For example, when connected on a public WiFi, DoH would prevent other WiFi users from seeing which websites you visit, as well as prevent potential spoofing or pharming attacks. This experiment will be done in collaboration with DNS providers who already support DoH, with the goal of improving our mutual users’ security and privacy by upgrading them to the DoH version of their current DNS service. With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active.

More concretely, the experiment in Chrome 78 will check if the user’s current DNS provider is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service from the same provider. If the DNS provider isn’t in the list, Chrome will continue to operate as it does today. The providers included in the list were selected for their strong stance on privacy and security, as well as the readiness of their DoH services, and also agreed to participate in the experiment. The goals of this experiment are to validate our implementation and to evaluate the performance impact. 

Our experiment will run on all supported platforms (with the exception of Linux and iOS) for a fraction of Chrome users. On Android 9 and above, if the user has specified a DNS-over-TLS provider in the private DNS settings, Chrome may use the associated DoH provider, and will fallback to the system private DNS upon error.

By keeping the DNS provider as-is and only upgrading to the provider’s equivalent DoH service, the user experience would remain the same. For instance, malware protection or parental control features offered by the DNS provider will continue to work. If DoH fails, Chrome will revert to the provider’s regular DNS service. Opting-out of the experiment will be possible from Chrome 78 by disabling the flag at chrome://flags/#dns-over-https.

Most managed Chrome deployments are excluded from the experiment.  For enterprise and education customers, we invite administrators to read the upcoming release notes for details about DoH policies which will be published on our Chrome Enterprise blog.

With 35 years of history, DNS is used by multiple parties, and enables diverse use cases. In particular, we are aware of how DNS can play an important role in ISP-provided family-safe content filtering. So, we are and will continue to take an incremental approach where we respect any active user-facing features such as family-friendly filters, with steps informed by discussions involving key stakeholders, e.g. ISPs, DNS providers, and organizations with expertise in online safety. We will also take into account performance and reliability statistics sent by users who have agreed to help improve Chrome’s features and performance, as well as user feedback.

This experiment is the humble first step of a long collaborative journey to improve our users’ privacy, security, and safety. We can’t wait to see how DoH performs in the wild, and welcome your feedback!

Kenji Baheux, Chrome Product Manager

Potential uses for the Privacy Sandbox

Today on The Keyword, we outlined our vision for an initiative aimed at evolving the web with architecture that advances privacy, while continuing to support a free and open ecosystem. In order to work toward that vision, we have begun publishing a series of explainers that are intended to be shared and iterated on across the community.

Below, we’ve summarized each of these early proposals, which we are collectively referring to as the Privacy Sandbox.

User information

First, let’s identify how user information is currently used in the ad ecosystem so that we can explore the development of the Privacy Sandbox’s privacy preserving APIs.

Ad Selection

One of the most challenging questions is what your browser could do to allow a publisher to pick relevant content or show a relevant ad to you, while sharing as little information about your browsing history as possible.

We're exploring how to deliver ads to large groups of similar people without letting individually identifying data ever leave your browser — building on the Differential Privacy techniques we've been using in Chrome for nearly 5 years to collect anonymous telemetry information. New technologies like Federated Learning show that it's possible for your browser to avoid revealing that you are a member of a group that likes Beyoncé and sweater vests until it can be sure that group contains thousands of other people.

Conversion Measurement

Publishers and advertisers need to know if advertising actually leads to more business. If it’s driving sales, it’s clearly relevant to users, and if it’s not, they need to improve the content and personalization to make it more relevant. Users then benefit from ads centered around their interests, and advertisers benefit from more effective advertising.

Both Google and Apple have already published early stage thinking to evaluate how one might address some of these use cases. These proposals are a first step in exploring how to address the measurement needs of the advertiser without letting the advertiser track a specific user across sites.

Fraud Prevention

Publishers today often need to detect and prevent fraudulent behavior, for instance false transactions or attempts to fake ad activity to steal money from advertisers and publishers. Many companies, including Google, work to detect and prevent fraud, and that’s especially true of ad companies and ad fraud.

Some of the tools used to legitimately fight fraud today use techniques that can benefit from using more privacy safe mechanisms. One example is the PrivacyPass token, introduced by CloudFlare for Tor users, which is now moving through the standards process.

Protecting the Sandbox Boundary

Our experience has shown us that removing certain capabilities from the web causes developers to find workarounds to keep their current systems working rather than going down the well-lit path. We’ve seen this recently in response to the actions that other browsers have taken to block cookies - new techniques are emerging that are not transparent to the user, such as fingerprinting.

With fingerprinting, developers have found ways to learn tiny bits of information that vary between users, such as what device they have or what fonts they have installed. By combining several of these small data points together they can generate a unique identifier which can then be used to match a user across websites. Unlike cookies, users cannot clear their fingerprint, and this means that even if a user wishes not to be identified, they cannot stop the developer from doing so. We think this subversion of user choice is wrong.

As referenced in May at I/O, we are actively taking steps to prevent fingerprinting. We are proposing the implementation of what we call a privacy budget. With a privacy budget, websites can call APIs until those calls have revealed enough information to narrow a user down to a group sufficiently large enough to maintain anonymity. After that, any further attempts to call APIs that would reveal information will cause the browser to intervene and block further calls.

We appreciate you taking the time to read through our early proposals for building the Privacy Sandbox. We understand it is ambitious and can’t overstate how important it is that this be refined and improved as a result of collaboration across the industry, including other browsers and publishers. We look forward to hearing your thoughts!

Posted by Justin Schuh - Director, Chrome Engineering

Chrome Dev Summit is now open for registration!

We’re excited to announce that registration for the seventh Chrome Dev Summit is now open and you can request your invite here today! During the Summit, we will share our vision for and updates on our work towards moving the web platform forward and of course, have a bit of fun. ‘Cuz what’s Chrome Dev Summit, without some fun? 

Event details:
Date: Nov 11-12, 2019
Venue: Yerba Buena Center for the Arts in San Francisco, CA

What’s happening?

Over the two days, we will focus on the latest best practices, tools and updates coming to the web platform and give developers a chance to hear directly from the Chrome product engineering teams. 

Similar to last year, we’ll have a single track of content in one hall so everyone can enjoy all the sessions and have meaningful discussions. We’re also bringing back the Forum where you’ll be able to enjoy demos of the latest web technologies and developer tools as well as engage with the Chrome team as well as folks from the community.

We’ll be adding more details on the event site, as we move closer to the event, so watch out for more in the coming weeks and months.

Can’t attend in person? 

As always, we want to ensure that Chrome Dev Summit stays inclusive and exciting for everyone, regardless of whether you’re joining us in person or online. We’ll be livestreaming the entire two days of content for our online attendees and will also include some exciting livestream-only content. 

Sign up here so we can send you updates on the livestream and other related info around the event.

The Chrome team is committed to making the Web the best platform to give everyone in the world universal access to content and apps. We want to make it easier for developers to bring best-in-class content and experiences to their users, by making it more powerful and by reducing the cost of development. And we hope to do this as responsible citizens of the community, working with others to uphold our principles of promoting the open web.

We look forward to seeing you in San Francisco for yet another awesome Chrome Dev Summit!

Posted by Paul Kinlan, Content-Herder-and-Speaker-Wrangler-in-Chief

Chrome 77 Beta: New performance metrics, new form capabilities, capabilities in origin trials and more

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on Chrome 77 is beta as of August 8, 2019.

New Performance Metrics

Largest Contentful Paint

It has not always been easy for developers to measure how quickly the main content of a web page loads and is visible to users. The usefulness of existing metrics varies. Some metrics are only measurable in a lab, while others tell nothing about content that users care about. Consider the example below, taken from a DevTools performance audit. At the time of the first contentful paint, there's no content on screen that a user can interact with.

Largest Contentful Paint attempts to provide more meaningful data by using the largest content element as a proxy for when the main content of the page is likely visible to users.

You're probably asking questions like what does the new metric track? When is the metric reported? How do I improve it if it's slow? For answers to these and other questions, see "Largest Contentful Paint" on

First Input Timing

The PerformanceEventTiming interface provides timing information about the latency of the first discrete user interaction, specifically one of key down, mouse down, click, or the combination of pointer down and pointer up. Pointer down may be the start of scrolling, which is not tracked. This is a subset of the EventTiming API, but will be exposed in advance because it provides key metrics to help measure and optimize responsiveness.

New Form Capabilities

Many websites use custom form controls to either add features that aren't available in standard controls or to tailor a form's design. A drawback of custom controls is that data must be stored in hidden <input> elements.

Two new features support custom form controls. The formdata event lets sites use JavaScript instead of hidden <input> elements to add data to a form. With this feature, site builders add a formdata event listener to a form element. The passed event includes a FormData object containing the data being submitted, which can now be modified.

The formdata event only lets sites interact with the submission process. Form-associated custom elements let site creators build custom elements that act like built-in form controls, providing capabilities such as enabling input validation or submitting data to the server.

To learn more and to see example code, read More capable form controls on

Origin Trials

This version of Chrome introduces the origin trials listed below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones listed below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

A Contact Picker for the Web

The Contact Picker API is a new, on-demand picker that allows users to select entries from their contact list and share limited details of the selected entries with a website. It allows users to share only what they want, when they want, and makes it easier for users to reach and connect with their friends and family. See A Contact Picker for the Web for details.

Other features in this release

Enter Key Hint

The enterkeyhint content attribute
is an enumerated attribute for <form> elements that specifies what action label (or icon) to present as the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key to make it more helpful for users. The attribute takes one of enter, done, go, next, previous, search, or send.

Feature Policy Control over Document.domain

The document-domain policy governs access to document.domain. It is enabled by default, and, if disabled, attempting to set document.domain will throw an error.

Layout Instability Monitoring

Adds the LayoutShift interface
to the Performance API, allowing developers to monitor changes to a DOM element's on-screen position.

Limit the "referer" Header's Length to 4kB

Strips the referer header down to an origin when it's size exceeds 4kB.
Servers will often behave in unexpected ways when presented with an overly-long referer header. This is unfortunate, because referer is one header whose length attackers generally retain control over when generating no-cors requests.

Limit registerProtocolHandler() url Argument to http/https

The registerProtocolHandler() now only accepts URLs with http or https schemas. Because the intent of the API is to allow an endpoint to handle something like an SMS message, for example, it doesn't make much sense for handlers to be data URLs, blob URLs, and so on.

New Features for Intl.NumberFormat

This change improves Intl.NumberFormat by adding support for measurement units, currency and sign display policies, and scientific and compact notation.

Overscroll Behavior Logical Longhands

Adds CSS flow-relative properties for controlling overscroll behavior through logical dimensions. flow-relative properties are those that are interpreted relative to the flow of content. The new properties are overscroll-behavior-inline and overscroll-behavior-block.

PerformanceObserverInit Buffered Flag

Adds a buffered flag to observer.observe() so that PerformanceObserver can receive entries created before the call is executed.


Adds the incecandidateerror event which provides detailed information about WebRTC ICE candidate gathering failures, including the ones defined by STUN (RFC5389) and TURN (RFC5766).

Diagnosing ICE connectivity issues without access to detailed gathering failures can be a challenge. Support for ICE candidate errors is targeted towards better connectivity troubleshooting and network diagnostics.

Adds a method for triggering an ICE restart which causes a WebRTC connection to try to reconnect. This feature is already available in Chrome by passing the iceRestart argument to createOffer(). restartIce() is a version of this method that works regardless of signalingState.

Service Workers

Preserve Request Priorities through Service Worker
Preserves a request's original priority when it passes through a service worker. Previously, all requests going through a service worker would get "High" priority. This means render-blocking style sheets would have their priority clamped, while less important resources would get boosted.

Service Workers Support Basic HTTP Authentication
Displays HTTP authentication dialog boxes even if the request was from a service worker. This shows the native login dialog shown when an HTTP 401 response is received.

Stop Action for Media Sessions

Adds stop as a MediaSessionAction for calls to MediaSession.setActionHandler(). An action is an event tied specifically to a common media function such as pause or play. The stop action handler is called when the site should stop the playback and clear the state if appropriate. Samples are available on GitHub.

Web Payments: Throw a TypeError on Invalid "basic-card" Data

The PaymentRequest constructor now throws a TypeError when invalid supportedNetworks or supportedTypes are specified for basic card payment.

See Deprecations and Removals for an additional Web Payments update item. For more about recent web payments updates, see W3C Payment API changes in Chrome 77.

Interoperability Improvements

Support Step Timing Functions jump-start|end|both|none

Adds support for a richer set of step animations. Firefox already supports jump-* step timing functions. The step timing functions jump-both, jump-none, jump-start and jump-end were introduced to the spec for easing functions in 2018. Two of these, jump-start and jump-end are aliases for start and end. The remaining two provide increased flexibility for step transitions by enabling step functions in which both or neither endpoint has a discontinuous step. Previously, one and only one of the two endpoints could have a step discontinuity. Adding support in Chromium improves cross-browser interoperability.

white-space: break-spaces

Adds the break-spaces value for the white-space property which specifies that any sequence of preserved white space that would otherwise overflow a line and hang (as per the CSS Text Module spec's Trimming and Positioning rules) must be broken.

With white-space: pre-wrap it's possible to wrap and preserve white space sequences in the middle of a text line. However, if there is a sequence at the end of the line, it either collapses or hangs, maybe overflowing its box area. The new value overflow-wrap: break-spaces allows authors to wrap and preserve these white space sequences. This can be also useful for textarea or contenteditable elements, so that white space sequences added by spacebar press events are handled properly and generate line breaks if needed. Finally, there is an ongoing effort to enhance interoperability of the line breaking CSS properties (white-space, word-break and overflow-wrap) and this new value was defined precisely to achieve that.

Deprecations, and Removals

Card Issuer Networks as Payment Method Names

Remotes support for calling PaymentRequest with card issuer networks (e.g., "visa", "amex", "mastercard") in the supportedMethods field.

Deprecate Web MIDI Use on Insecure Origins

Web MIDI use is classified into two groups: non-privilege use, and privilege use with sysex permission. Until Chrome 77, only the latter use prompts users for permission. To reduce security concerns, permissions will always be requested regardless of sysex use. This means that using Web MIDI on insecure origins will no longer be allowed.

Deprecate WebVR 1.1 API

This API is now deprecated in Chrome, being replaced by the WebXR Device API, which is expected to ship in Chrome 78. The WebVR Origin Trial ended on July 24, 2018.

WebVR was never enabled by default in Chrome, and was never ratified as a web standard. The WebXR Device API is the replacement API for WebVR. Removing WebVR from Chrome allows us to focus on the future of WebXR and remove the maintenance burden of WebVR, as well as reaffirm that Chrome is committed to WebXR as the future for building immersive web-based experiences. Removal is expected in Chrome 79.

Project Strobe: Updates to Our User Data Policy

On May 30, Google announced the next iteration of Project Strobe, a root-and-branch review of third-party developer access to user data. This announcement included the following two updates to our User Data Policy:

The policies for these two changes are now published to the updated User Data Policy. They will go into effect on October 15, 2019.

To ensure compliance with this policy update, we suggest developers check their extensions per the guidelines below. After October 15, 2019, items that violate these updates to the User Data policy will be removed or rejected from the Web Store and will need to become compliant to be reinstated. We will continue to take action on violations of the User Data Policy in its current form.

You can find more information in the updated User Data FAQ. Thank you for joining us in building a better web with transparency, choice and control for both users and developers.

Posted by Alexandre Blondin and Swagateeka Panigrahy, Chrome Product & Policy

Easier Payments with Chrome

People have high expectations for their shopping experience on the web — whether booking a vacation, or buying tickets to a hot concert before they’re gone. They want a fast, seamless, and safe experience that works across all their devices.

That’s why today we are making payments in Chrome more convenient: When you’re signed into Chrome on your laptop, you’ll be able to use payment methods previously saved to your Google Account to fill in checkout forms. And you can use this feature without having to turn on Chrome sync. You'll also be able to use the payment info you’ve saved in your Google Account across your devices in Chrome where you’re signed in, and wherever Google Pay is accepted.

You are always in control: When you’re signed-in and Chrome offers you the option of using a card from your Google Account, it will ask you to confirm the card’s CVC. If you choose to save a new card to your account, you will receive a confirmation email from Google Pay with additional information. You can manage and delete the cards in your account at anytime by going to your Google Account > Payments & subscriptions > Payment methods.

Using this new feature doesn’t turn on Chrome sync. And of course, if you prefer to save your payment methods only locally on your device, you can still do that: Add your card in Chrome Settings  > Payment methods > Add. When you sign into any Google website, you’re also signed into Chrome with the same account. You can turn off "Allow Chrome sign-in" altogether in settings. 

Every time you open your browser, you have a task in mind to accomplish. We’ve built Chrome to help you do that as quickly and safely as possible, whether you are completing a search, viewing a website, or making a purchase. This feature is just one more way we are improving this experience for everyone.

Posted by Sabine Borsay, Chrome Product Manager

WebAssembly brings Google Earth to more browsers

About 14 years ago, Google Earth gave users a rush of excitement by allowing them to  zoom right in on their childhood homes. But that could happen only once they downloaded and installed the application. Earth was released as a native application because rendering the whole world in real time required advanced technologies that weren’t available in the browser. 

As the Web progressed, we wanted Earth to be available on the platform so it could reach as many people as possible and let them experience the entire world at their fingertips. Web apps offer a better user experience because they’re linkable, meaning you can share access to the whole experience with a single click; they’re secure, since users aren’t at risk of viruses that can come with software downloads; and they’re composable, meaning we can embed them in other parts of the web.

In WebAssembly (Wasm), the W3C web standard for bringing native code to the web, the Earth team found a solution to allow Google Earth to move across multiple browsers—something we’ve been working on for a while now. Earth first came to the Web about two years ago using Native Client (NaCl), a Chrome-only solution—at the time. It was the only way to run native code in the browser and offer the performance users expect in modern web applications. But cross-browser compatibility is not as easy as we would like, since not every browser supports new technologies the same way. 

Using WebAssembly, we see more possibilities not just for making apps more accessible across browsers, but smoothing out the online experience, as we’ve seen with Google Earth. You can check out the Earth preview beta to see what the Earth team has achieved and read about their technical implementation here.

How WebAssembly works with threaded applications
If you plan to work in WebAssembly, it’s important to understand some of the specifics, particularly around threading.

Some browsers offer multi-threading support and others don't. In the case of Google Earth, it is constantly streaming data to the browser, decompressing it and making it ready for rendering to the screen. Being able to do this work on a background thread has shown a clear improvement in the performance of Earth in the browser.

The Chromium-based browsers—including Chrome, the forthcoming version of Edge, and Opera—all offer support for WebAssembly (some with multi-threading, others without). Once the new version of Edge based on Chromium ships, apps in WebAssembly will work as well in Edge as they do in Chrome. Firefox offers good support for WebAssembly, but had to disable support for multi-threading due to a SharedArrayBuffer issue. And while Opera is based on Chromium, the current version of Opera only offers single-threaded support of WebAssembly. Safari has a strong implementation of WebAssembly, but it lacks full support for WebGL2. Our deep-dive technical post offers more details about WebAssembly support across the browsers.

Emscripten: The tool that enabled Earth to port to the browser
Taking an application that was originally created for native operating systems and bringing it to the web is no small task. The Emscripten toolchain helps developers compile their C++ into WebAssembly, also also emulates many of the OS interfaces that native applications use. For example, an application may use the POSIX API fopen which tells the OS to open a file. Emscripten sees this call and offers the correct behavior through browser technologies such as local storage.  It does the same thing for turning OpenGL calls into WebGL calls. Along with many other features, it dramatically eases the work of bringing a native app to the web.

Emscripten has been used to port other applications to the web, such as the 35-year-old AutoCAD codebase and more recent applications like Sketchup.

What’s coming next for WebAssembly
There are several features coming to WebAssembly in the future that Earth will use to improve the web experience:

SIMD support: SIMD (single instruction, multiple data) lets a single CPU instruction act on multiple pieces of data. When it’s set up in the right way, SIMD allows for high throughput of data processing. When the first set of SIMD support arrives later this year for WebAssembly, we hope it will dramatically improve Earth’s performance. 

Dynamic linking: This feature will give Earth the chance to optimize load time, and opens the door to embedding Earth in other web pages and online experiences. Currently, all modules that interact have to be compiled at the same time. With dynamic linking, you can break up an application into many modules and ship a very small client, then load all the other parts over time (known as lazy loading).

Better debugging: Today, Wasm supports source maps so that developers can see their source code in the developer tools. That’s a great first step, but we want to also allow developers to inspect variables and see proper stack traces.

Earth has now taken a major step by adopting a cross-browser standard that lets them bring the application to more browsers—with more improvements coming in the future. Consider trying out WebAssembly for yourself and your native code to reach all your users with a consistent, performant experience.

Posted by Thomas Nattestad, Product Manager for Web Assembly, V8 and Web Capabilities

New Chrome Protections from Deception

Chrome was built with security in mind from the very beginning. Today we’re launching two new features to help protect users from deceptive websites. The Suspicious Site Reporter Extension will improve security for Chrome users by giving power users an easy way to report suspicious sites to Google Safe Browsing. We’re also launching a new warning to protect users from sites with deceptive URLs.

We designed Chrome to be secure by default, and easy to use by everyone. Google Safe Browsing has helped protect Chrome users from phishing attacks for over 10 years, and now helps protect more than 4 billion devices every day across multiple browsers and apps by showing warnings to people before they visit dangerous sites or download dangerous files. We’re constantly improving Safe Browsing, and now you can help.

Safe Browsing works by automatically analyzing the websites that we know about through Google Search’s web crawlers, and creating lists of sites that are dangerous or deceptive. With the Suspicious Site Reporter extension, you can help Safe Browsing protect web users by reporting suspicious sites. You can install the extension to start seeing an icon when you’re on a potentially suspicious site, and more information about why the site might be suspicious. By clicking the icon, you’re now able to report unsafe sites to Safe Browsing for further evaluation. If the site is added to Safe Browsing’s lists, you’ll not only protect Chrome users, but users of other browsers and across the entire web.

Help us protect web users by reporting dangerous or deceptive sites to Google Safe Browsing through the Suspicious Site Reporter extension.

One way that deceptive sites might try to trick you is by using a confusing URL. For example, it’s easy to confuse “” with “”. In Chrome 75, we’re launching a new warning to direct users away from sites that have confusing URLs.

Starting in the current version of Chrome (75), you’ll see a warning when the page URL might be confused for URLs of sites you’ve visited recently.

This new warning works by comparing the URL of the page you’re currently on to URLs of pages you’ve recently visited. If the URL looks similar, and might cause you to be confused or deceived, we’ll show a warning that helps you get back to safety.

We believe that you shouldn't have to be a security expert to feel safe on the web, and that many Chrome power-users share our mission to make the web more secure for everyone. We’ll continue improving Chrome Security to help make Chrome easy to use safely, and are looking forward to collaborating with the community to further that goal. Install the new extension and start helping protect web users!

Posted by Emily Schechter, Chrome Product Manager

Chrome 76 Beta: dark mode, payments, new PWA features and more

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Find more information about the features listed here through the provided links or from the list on Chrome 76 is beta as of June 13, 2019.

Dark mode

Many operating systems now support inverted color schemes with a system setting referred to as ‘dark theme' or ‘dark mode', depending on the system.

The prefers-color-scheme media query allows a website or web app to adopt the preferred display mode of the user. Use the query in your CSS code like so:

@media (prefers-color-scheme: dark) {
body {
color: white;
background-color: black;

What is left out of this is the explanation? For that, read the article titled Hello Darkness, My Old Friend.

Payments API

Over the last few versions of Chrome we've rolled out a number of improvements to the payments APIs. These APIs provide a way to interact with proprietary payment systems without needing to build your own user interactions. Changes in Chrome 75 included replacing hasEnrolledInstrument() with canMakePayment() and removal of languageCode from the billing address. With the detailsPromise option Chrome 75 gives a means of performing a quick server call before showing payment details to the buyer.

Chrome 76 brings three changes to the payment realm. Now implemented are features that allow a merchant website or web app to respond when a user changes payment instruments. Additionally, the PaymentRequestEvent has a new method called changePaymentMethod() and the PaymentRequest object now supports an event handler called paymentmethodchange. You can use both to notify a merchant when the user changes payment instruments. The former returns a promise that resolves with a new PaymentRequest instance.

Additionally, Chrome now makes it easier to use the payments APIs for self-signed certificates on the local development environment. To do this, launch Chrome from a command line with the —ignore-certificate-errors flag.

For detailed information about these features, read Web Payments Updates.

Improvements for Progressive Web Apps

Install Progressive Web Apps on the desktop with ease

On desktop, there is typically no indication to a user that a Progressive Web App is installable, and if it is, the install flow is hidden within the three dot menu.

In Chrome 76, we're making it easier for users to install Progressive Web Apps on the desktop by adding an install button to the omnibox.

If a site meets the Progressive Web App installability criteria, Chrome shows an install icon in the omnibox. There is no extra work required from developers. Clicking the button prompts the user to install the PWA.

Control the Add to Home Screen mini-infobar

In Chrome 76, we're giving you control over the add to home screen mini-infobar.

Chrome shows the mini-infobar the first time a user visits a site that meets the Progressive Web App installability criteria. Developers want to prevent the mini-infobar from appearing, and provide their own install promotion instead.

To do this, listen for the beforeinstallprompt event, and call preventDefault()
on it. Then, update your UI to notify the user by adding an install button or other element. Depending on your app, there are several different patterns you can use to promote installation of your PWA.

The add to home screen mini-infobar is still a temporary measure. We are experimenting with new UI patterns for giving Progressive Web App users the ability to install, and do this in a way that reduces clutter in the browsing experience.

Updating WebAPKs more frequently

When a PWA is installed on Android, Chrome automatically requests and installs a WebAPK. Chrome periodically checks to see if the manifest has changed, and if a new WebAPK is required. Starting in Chrome 76, Chrome will check the manifest more frequently: checking every day, instead of every three days. If any of the key properties have changed, Chrome will request and install a new WebAPK.

Other features in this release


Adds Animation.updatePlaybackRate(), which lets you seamlessly transition the playback rate of an animation such that there is no visible jump in the animation. Current time is preserved at the instance the new playback rate takes effect.

Async clipboard: read and write images

Implements programmatic copying and pasting of images for the Async Clipboard API. This change also updates and navigator.clipboard.write() to comply with the specification. Programmatic copying and pasting of images is Chromium's top starred bug.

Escape key is not a user activation

The escape key is no longer treated as a user activation. Browsers prevent calls to abusable APIs (like popup, fullscreen, vibrate, etc.) unless the user activates the page through direct interactions. Not all interactions trigger user activation. For example, clicking on a link or typing in a textbox does, but swiping fingers on a screen or hovering with the mouse cursor does not. Since users never intend to interact with the page through the escape key, it should not trigger user activation.

Fetch Metadata

Introduces a new HTTP request header that sends additional metadata about a request's provenance (is it cross-site, is it triggered from <img>, etc.) to the server to allow it to make security decisions which might mitigate some kinds of attacks based on timing the server's response (XSS leaks and others).

For example, it is unlikely that a bank's "Transfer all money" endpoint would be referenced from an <img> tag, and likewise unlikely that is going to be making any legitimate requests whatsoever. Ideally, the server could reject these requests a priori rather than deliver them to the application backend.


Adds the form.requestSubmit() function, which requests form submission. It includes interactive constraint validation, dispatches a submit event, and takes a reference to the submitter button.

ImageCapture support for focusDistance constraint

The Image Capture API provides a means to set the focusMode to manual which is not useful if you cannot set the focus distance. This change provides an interface for getting focus range values and setting focus distance value.

Implement Animation.pending

Adds the pending attribute to the Web Animations API. A pending animation is one that is waiting on an asynchronous operation that affects the play state. Adding support for this attribute does not affect the rendering or timing of animations, but simply exposes the signal.

IndexedDB transaction explicit commit API call

Adds a commit() function to IDBTransaction objects, which explicitly marks a transaction as not accepting further requests. Currently, IndexedDB only commits a transaction after all associated requests have had their completion event handlers executed, and no new requests have been queued by the event handlers. Developers can use the explicit commit() function to shave a few event loop cycles off of the latency of their transactions.

The primary benefit of explicit commit is that it increases the throughput of read and write requests made on an object store. This is a clear performance benefit in terms of the rate at which operations can be processed. Additionally, the increase in speed is advantageous because it adds stability to IndexedDB by reducing the probability that a disruptive event occurs within the lifetime of a transaction.


DateTimeFormat dateStyle and timeStyle
Adds dateStyle and timeStyle options to functions on Intl.DateTimeFormat, specifically formatToParts() and resolveOptions(). These options provide a compact way to request the appropriate, locale-specific date and time of given length styles.

Locale sensitive BigInt.prototype.toLocaleString and allow Intl.NumberFormat format/formatToParts to take BigInt.
Changes BigInt.prototype.toLocaleString() to locale-sensitive number formatting and changes Intl.NumberFormat.prototype.format() and formatToParts() to accept BigInt as input.

Media capabilities in workers

Enables the Media Capabilities API in all types of workers to help website and web apps pick the best media to stream from a worker. The information can then be used to create the MediaStream from a worker.


Adds Promise.allSettled(), which returns a promise that is fulfilled with an array of promise state snapshots, but only after all the original promises have settled, in other words after it has either resolved or rejected.

Simpler reading methods for Blob interface

Adds three new methods to the Blob interface to perform read operations: text(), arrayBuffer(), and stream().


Exposes information about the SCTP transport that is used to carry WebRTC data channels such as max-message-size and max channels.

Allows changing the association between the track associated with an RTCRtpSender and streams. Stream association causes tracks in the same stream to be synchronized. This is useful, for example, if during a call a user switches from a front-facing camera to a back-facing camera and the application uses RTCRtpSender.replaceTrack(). On the receiving end the new track must be associated with the existing stream and synchronized with its auto track.

Adds the setCodecPreferences() method, which overrides the default codec preferences used by the user agent. This allows applications to disable the negotiation of specific codecs. It also allows an application to cause a remote peer to prefer the codec that appears first in the list for sending.

white-space: break-spaces

The white-space:break-spaces value allows authors to specify that any sequence of preserved white space that would otherwise overflow a line and hang (as per the CSS Text Module specification's Trimming and Positioning rules) must be broken.


Remove feature policy: lazyload

The lazyload feature policy was intended to allow developers to selectively control the lazyload attribute on the <iframe> and <img> tags to provide more control over loading delay for embedded contents and images on a per origin basis.

The policy is removed in favor of a newer feature policy for loading, namely loading-frame-default-eager which is more aligned with how the loading attribute will be used. The removal applies to both the Feature-Policy header and the <iframe> allow attribute.

Remove outputs from MediaStreamAudioDestinationNode

According to the specification, the MediaStreamAudioDestinationNode in the Web Audio API should have no outputs. Chrome's implementation has a single output which has been removed.

Remove insecure usage of DeviceMotionEvent

Chromium has been showing deprecation warnings since 2015 whenever the API is used in a non-secure browsing context. Chrome now restricts the API to secure browsing contexts. This change brings Chromium's implementation in line with the privacy and security recommendations in the specification, and is aligned with the effort to deprecate powerful features on insecure origins.

Remove insecure usage of DeviceOrientationEvent

Chromium has been showing deprecation warnings since 2015 whenever the API is used in a non-secure browsing context. Chrome now restricts the API to secure browsing contexts. This change brings Chromium’s implementation in line with the privacy and security recommendations in the specification, and is aligned with the effort to deprecate powerful features on insecure origins.

Web Request and Declarative Net Request: Explaining the impact on Extensions in Manifest V3

The Story So Far
As part of an effort to increase user security and privacy, Chrome is planning a number of changes to the extensions platform. We announced some of these changes last October, and have provided additional context on them today. These changes to the platform are being implemented as part of Manifest V3 – the next version of the Chrome Extensions platform.

One of these changes is to move away from the blocking version of the Web Request API towards a new API, called Declarative Net Request. There’s been a lot of confusion and misconception around both the motivations and implications of this change, including speculation that these changes were designed to prevent or weaken ad blockers. This is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers.

In order to improve the security and privacy guarantees of the extensions platform, we are rethinking some of the extension platform's core APIs. That's why we're planning to replace the blocking Web Request API with the Declarative Net Request API.

How Web Request Works

With Web Request, Chrome sends all the data in a network request to the listening extension - including any sensitive data contained in that request like personal photos or emails. The extension has a chance to evaluate the request, and then tells Chrome what to do with the request: allow it, block it, or send it with some modifications. As a result, extensions that leverage the Web Request API typically have access to read and manipulate everything a user does on the web.

While this API is used by good actors to implement powerful features like content blockers, it can also be - and has been - abused. Because all of the request data is exposed to the extension, it makes it very easy for a malicious developer to abuse that access to a user’s credentials, accounts, or personal information. Since January 2018, 42% of malicious extensions use the Web Request API.

In addition to these safety concerns, there are also significant performance costs. In most cases, these costs are not from the evaluation of the extension script processing events, but rather from everything else coordinating the script. That overall performance impact can be very large, even for an extension written as performantly as possible where the JavaScript execution time is negligible.

As it’s designed today, the blocking version of the Web Request API requires a persistent, long-running process, and is fundamentally incompatible with “lazy” processes - processes that can be set up or torn down as-needed, conserving valuable system resources. There are also significant costs associated with the serialization of the request data, the inter-process communication needed to send that data to the extensions, and the processing of extension responses.

Enter Declarative Net Request

The Declarative Net Request API works differently than the Web Request API. Instead of Chrome sending all the information about a request to the listening extensions at the time of the request, extensions register rules that tell Chrome what to do if certain types of requests are seen.

This approach has advantages for both user security and privacy, as well as performance. With a declarative approach, Chrome does not need to expose any sensitive data to the extension. The browser can perform the action requested by the extension without sending it all the data associated with the network request, because the extension already specified the conditions under which different actions are taken. This enables the extension to perform content blocking without needing access to all of a user’s personal information.

This has significant performance implications. Most importantly, a persistent, long-running process is no longer necessary because rules are registered before requests are made rather than needing to process them at runtime. This also cuts down on the cost of serializing all the request data and shuttling the inter-process messages to the listening extensions. These performance improvements will make extensions significantly more viable on resource-constrained platforms.

Why Not Both?
In addition to the performance concerns raised above, the Chrome team strongly believes that users should not have to expose their emails, photos, social media, or any other sensitive data to an extension if the extension doesn’t actually need that access to perform its function. And historically, when extension developers are given the choice between capability and security, the vast majority of developers choose capability. We've seen this repeatedly on the extensions platform with event pages, optional permissions, and activeTab.

Enterprises, schools, and businesses often require different network and software controls to comply with corporate policies. Additionally, these organizations typically have administrators whose role it is to understand and set up their environments.

Chrome provides enterprise controls through its administrator policies. The blocking version of the Web Request API remains available for managed extensions because of the deep integrations that enterprises may have between their software suites and Chrome. System administrators can continue to manage Chrome in enterprise environments for free using OS-provided mechanisms to deploy Chrome policies.

Moving Forward
Declarative Net Request, and the whole of Manifest V3, is still very much in design and development. We are continuing to iterate on it, responding to community feedback and working with developers to help support different use cases.

Since the original announcement of the Declarative Net Request API, we have added significant functionality to the API as a result of these discussions. The Declarative Net Request API now allows for the registration and removal of dynamic rules - specified at runtime rather than statically in the manifest. We’ve also added the capability to remove common tracking headers, such as Referer, Cookie, and Set-Cookie.

We are actively exploring other ways to expand this API, including adding methods to get feedback about matched rules, and support for richer redirects leveraging URL manipulation and regular expressions. Additionally, we are currently planning to change the rule limit from maximum of 30k rules per extension to a global maximum of 150k rules.

We will continue working with the developer community moving forward. We understand that adopting Manifest V3 will require developers to update their extensions and we will continue to support them through this transition.

Posted by Simeon Vincent, Developer Advocate for Chrome Extensions

Taking Action on Deceptive Installation Tactics

Privacy, security and transparency are at the forefront of all the work we do on Chrome. In October, we announced changes aimed at ensuring Chrome extensions are trustworthy by default, but the work doesn’t end there. 

As part of our commitment to transparency, we are announcing a new policy targeting deceptive installation tactics for extensions on the Chrome Web Store. We’ve seen that the path to downloading a Chrome extension influences user trust in all extensions. One bad experience can affect a user’s interest in the many great extensions our developers create. Setting the right expectations for what an extension does, from the start, helps create a healthy and thriving ecosystem of extensions, developers, and passionate users.

Last year, to improve user transparency we deprecated inline installation and began requiring all extension installs to go through the Chrome Web Store. This change has helped reduce user complaints about unwanted extensions by 18 percent. However, we still receive user feedback about deceptive extension install flows. As user transparency is an important part of our ecosystem, we are continuing to push these initiatives forward by prohibiting extensions that benefit from deceptive install tactics with the following policy:

Extensions must be marketed responsibly. Extensions that use or benefit from deceptive installation tactics will be removed from the Chrome Web Store.

Deceptive installation tactics include:

Please audit all of your install traffic to ensure it is compliant before July 1st, 2019. You can also find an FAQ on the new policy in the Chrome Developer Center.

Today, we also announced additional policies to further protect users as part of Google’s Project Strobe. We will be requiring that extensions request the narrowest permissions needed to implement their features, and requiring more extensions to post privacy policies and handle user data securely. Read more about those changes in the Keyword post and the Chrome Developer Center FAQ.

Posted by Swagateeka Panigrahy and Benjamin Ackerman, Chrome Policy and Anti-Abuse Team

Google I/O 2019: What's new with Chrome and the Web

The web celebrated its 30th anniversary this year, and what an amazing three decades they have been. We’ve seen the platform go from powering simple hypertext documents, to one that enables rich, immersive, and dynamic experiences that are at the forefront of design.

Looking forward, the world’s needs continue to evolve, and that motivates us to continue our participation with the global web community to adapt and improve the platform to meet the needs of the future. Our efforts are focused on making the web faster and more powerful, while keeping our users’ trust and safety front and center.

Vision for an Instant Web

Speed matters on the web. We’ve found that users are highly sensitive to loading speed and this can have a direct impact on the business.

So we’ve been working hard to make the browser faster and lighter so developers can do more with their experience. By focusing on startup bottlenecks, we were able to improve the loading speed on Chrome’s startup by 50% on low-end devices; and 10% across devices. We also improved scrolling performance by 18% and through V8, JavaScript memory usage reduced by up to 20% for real world apps.

Apart from making the browser more efficient, we’ve also been adding more features to the platform to take the burden away from developers. And we’d like to share a few of these here:

Speaking of navigations, Portals, is a new technology that we believe will fundamentally change the way users traverse the web. Portals are similar to iframes and allow content to be embedded directly in a page, but unlike standard iframes, they can be ‘activated’ to become the top-level page, enabling instant transitions across the web. Advanced experiences can even hold pieces of the original page’s UI privately and securely, so that you can provide seamless overlays that still hold our ideals of the origin model.

At I/O, we shared our vision of how developers would be able to use Portals and associated APIs to support pre-fetching, enhanced transitions and the exchange of contextual information between sites. And now that Portals API is available behind a flag in Chrome Canary, we’re excited to see what developers will build with this new primitive.

Another technology that we’re particularly excited about is Web Packaging, a bold new contract between web developers and web servers. With Web Packaging, the model for loading pages changes from the browser requesting the page from the origin’s server to it being able to load from anywhere — even potentially other peer devices.

This gives the browser the flexibility to preload content and load pages instantly while doing so in a privacy preserving way. Signed Exchanges, the first phase of this vision is now available in Chrome for developers to use.

These are some of the things that we’re doing to make the web more instant, but its success is predicated on developers making their experiences fast and maintaining that performance. So we’ve added a bunch of tools to help.

In 2017, we launched the Chrome UX report to give developers a better sense of how their users truly experience their webpages by providing them real world metrics. The report is now includes a data set of nearly 6 million origins and is powering more of our tools, including the latest Speed Report in the Google Search Console. The report is currently in beta and you can register here to join the program and share your feedback.

To give developers an even wider array of real world metrics, the Firebase team have broadened their Performance Monitoring tool to also cover web apps.

And to stay on the rails for performance, we’ve seen many top sites implement ‘performance budgets’ within their build environments, and that is why we’ve built performance budgets directly into Lighthouse, so that you can get alerted to performance regressions before they hit your production site.

Creating a more powerful web

Our vision is to allow you to do absolutely anything that you want your users to do, on the web. So we’ve been working hard over the last year to close the capability gap by focusing on the features that get your experiences closer to your users.

Working closely with the community to address the most pressing and critical needs, we’re bringing many of these features to fruition at a great pace. Some of the capabilities that we’re most excited about include File system access, Unlimited Quota and the SMS based authentication feature that is particularly important for developers working in markets where “one-time passwords” are an important part of the authentication process.

And while we continue our momentum here, we’ve already launched the Web Share Target API allowing your apps to be integrated into the native system sharing, and opened up Shape Detection APIs that enable experiences like the Web Perception toolkit that we launched at I/O today. The toolkit allows developers to integrate with the mobile camera and enable people to use their website more effectively.

With mobile gaining many such strong capabilities, we also wanted to enable developers who build quality web experiences to get more reach. So we’ve launched Trusted Web Activities, that allow developers to integrate their web content into Android apps. And businesses like OYO Rooms, India’s biggest affordable hotels network, are already using Trusted Web Activities to power a lite version of their experience, a common pattern that we’re seeing amongst partners in some markets.

But the thing that we’re most excited about is the progress that we’ve made on desktop capabilities, with technologies like Web Assembly and individual media and productivity APIs unlocking many new use cases. Hulu and Google’s Duo are great examples of what’s possible on the web today. And we’re excited to have our friends at Slack join in and fully committed to roll out an offline-enabled web-powered version of their desktop app later this year.

PWAs on desktop came to ChromeOS last year, to enable web apps that need full window support and common desktop app capabilities. And now we’re excited to have extended support to Windows, Mac, and Linux.

We’re excited to see the momentum for PWAs on desktop and we wanted to ensure that we do our part to ensure that users can identify high quality PWAs and install them easily, so we’ve improved discoverability by bringing a new “Install” button directly into Chrome’s UI, within the Omnibox. This is one step to support developers building amazing experiences to get more engagement with their loyal users and we hope to continue doing more here.

In this landscape of massive device fragmentation, we wanted to see if it is possible for us to build an experience that could work across all devices, from the lowest-end feature phones to the large screen desktops. So we built a fun game - Proxx, that uses preact for UI, Comlink to be able to use workers and do more off the main thread. And yes, it works across all devices and performs well even on the most constrained ones. And because it's on the web, you can play it right here; but maybe after you're done reading. :)

Over the next year we will continue to open up even more of the capabilities that enable the next generation of games, productivity, media and social apps to come to the web, all whilst ensuring that the core principles of user safety and trust are preserved.

Bringing transparency, choice and control

User experience is extremely important to us and their safety and privacy remains at the heart of it. At I/O, we shared important upcoming changes to how Chrome will handle cookies in order to enable choice over tracking, and that enhance web security and privacy generally. And later this year, we will preview new features in Chrome that give users transparency and control over how they are tracked on the web.

We believe these changes will help improve user privacy and security on the web — but we know that it will take time. So we’re committed to working with the web ecosystem to understand how Chrome can continue to support these positive use cases and to build a better web.

Improving your developer experience

As the scope of the web platform increases and the demand from users to have ever faster, safer and more capable experiences at their fingertips it should be easier, not harder to build high-quality sites.

We built to bring our measurement tools, aka, Lighthouse and guidance all in one place. We’ve improved the site that now provides over 200 easy to follow guides for performance, safety, accessibility, resilience, and more. And at I/O, we announced our intent to build guidance for the tools that you use, starting with React.

And we’re adding the same level of personalization to Lighthouse, to give developers reports and improvement tips for the framework that they use. We’ve built in guidance for Wordpress and will be adding more over the rest of 2019 and beyond.

The web has come a long way over the last 30 years and we’re excited to be working with the developer community and other browsers with a shared mission to bring universal access to information and services to more people than ever.

Posted by Ben Galbraith and Dion Almaer