Chrome Dev Summit day 1 is all wrapped up and we hope you enjoyed discussing what developers can do to build high-quality web experiences today. Now, in day 2 we will give you a preview of the new technologies the Chrome team will be working on over the next year.

Modern navigation on the web

Today, moving from page to page on the web feels like a long, slow transition - users have to stare at a white screen as their site loads and if they’re on a bad network, they’re disappointed when they see...nothing.

We want to enable developers to deliver a zero-friction, seamless experience to their users on the web and we’re excited to share two new specifications that we’ve been working on - Web Packaging and Portals.

One way to make loading fast is to get content as close to the user as possible, such as in edge caches. But the rise in HTTPS had the side effect of making this harder to achieve. And while AMP enables us to have privacy preserving pre-rendering of content with lightning fast load times, it came with the nagging issue of the browser not showing the publisher’s URL. Building on the AMP model, we introduced Web Packaging that gives the browser a proof of origin for the resources that it renders. This is achieved through Signed Exchanges, a subset of the full Web Packaging proposal.

So as long as the package is properly signed with a key that corresponds to the domain, it is presented to the user as having come from that domain. This enables privacy-preserving preloading and makes edge caching much easier, because now your content can be distributed to multiple caches without the need for an explicit DNS relationship with that cache. And we’re excited to see that Signed Exchanges are already available for origin trial. One of the first places you can see this in action is with the Google Search developer preview for signed exchange AMP content.

While instant loading is great, Portals take away the entire perception of navigation between pages by enabling multi-page sites to act like single-page applications through the same level of fluid transitions. It’s best when seen in action:

It’s still early in the development of the spec and we’d love your feedback on how we can make them more relevant for your use case.

Smooth user experience without losing developer experience

Having buttery smooth interactions is important, and as Mariko said yesterday, you can never add enough butter. However this level of UX often comes with a bitter trade-off, one that none of us like - bad developer experience. But we believe that it IS possible to break this dead-lock and that is where we’ll be spending a lot of our time in the coming year.

The Houdini APIs, such as the CSS Paint API, Animation and Layout Worklets give developers an unprecedented level of control to build new and modern interfaces.

And to give developers a well-lit path and ensure that they don’t regress from their performance goals as they build in incremental features, we’re working to build Feature Policy that catch common mistakes and give developers a signal during staging and more importantly in production. For more on this, tune in to Jason’s talk later today.

Performance at scale

Focusing on performance is critical today. Frameworks play a very important role in achieving lasting improvements at scale. We’ve already seen some great work done by various frameworks over this past year, and we want to collaborate and support their efforts in 2019.

So we’re excited to announce that starting today, we’ll be making feedback from framework teams a standard part of the Chrome Intent to Implement process. We want to use this process to include the voice of frameworks within the features that we prioritize.

Secondly, to really strengthen this collaboration, we’re launching a fund with an initial amount of $200,000 to support the development of performance related features in third party frameworks. We’ll share performance goals that we’d love to see “on by default” in frameworks. We’re excited to see what the developer community will come up with given their experience working with frameworks and the wider ecosystem. And based on the potential impact of the proposal, we’ll support your work through direct funding.

We’ll have more to share on this in the coming weeks. In the meantime, developers can go to this link to register interest. Applicants can start an RFC on the github repo of the project they intend to modify and would be considered only if the project’s core maintainers sign-off on the feature.

Meanwhile, stay tuned on the livestream to watch the rest of the sessions of day two of Chrome Dev Summit 2018!

At Google, we know that speed matters and we provide a variety of tools to help everyone understand the performance of a page or site. Historically, these tools have used different analysis engines. Unfortunately, this caused some confusion because the recommendations from each tool were different. Today, we’re happy to announce that Pagespeed Insights (PSI) now uses Lighthouse as its analysis engine. This allows developers to get the same performance audits and recommendations everywhere: on the web, from the command line, and in Chrome DevTools. PSI also incorporates field data provided by the Chrome User Experience Report (CrUX). Version 5 of the PageSpeed Insights API will now provide CrUX data and all of the Lighthouse audits. Previous versions of the PSI API will be deprecated in six months.

PageSpeed Insights provides the following information:

Lab Data. PSI fetches and analyzes the page using Lighthouse, which simulates how a mobile device loads a page. It computes a set of performance metrics for the page (such as First Contentful Paint and Time to Interactive) and summarizes these metrics with a performance score from 0-100. Scores are categorized into three levels; 90 and up is considered to be a good score.

Field Data. PSI also displays real-world performance metrics (First Contentful Paint and First Input Delay) for the page and its origin. (As a result, we’ve also deprecated the origin: query in PSI). Note that not all sites may have field data available for display. The data set relies on a version of the Chrome User Experience Report that is updated daily and is aggregated over the previous 28 days. Keep in mind that the metrics here may be different from the ones in the Lab Data section as they capture a wide spectrum of real-world network conditions and devices used by Chrome users.

Opportunities.PSI provides suggestions on how to improve the page’s performance metrics. Each suggestion in this section estimates how much faster the page will load if the improvement is implemented.

Diagnostics.This section provides additional information about how a page adheres to best practices for web development.

The PSI v5 API now returns this new analysis together with CrUX data, and all Lighthouse category data (Performance, Progressive Web App, Accessibility, Best Practices, and SEO) for a given URL.

We have more information about the changes in our FAQ. If you have any questions, please use Stack Overflow and tag your question with the pagespeed-insights tag.

Today, we’re welcoming the web community to the 2018 edition of the Chrome Dev Summit. Over the next two days we will celebrate the evolution of the platform and share updates on our efforts moving the web forward with the help of the entire ecosystem.

Chrome’s 10th birthday gave us an opportunity to reminisce about how much Chrome and the web have evolved over the past decade. We love seeing how rich the content, apps, and games you build have become.

Amongst other updates that we’ve made to Chrome, one that we work very hard at is making the browser fast. We see speed as one of the defining and most important features of the web. No other platform can match how quickly a user can go from discovery to the actual experience and move between websites, but this breaks down if the sites take too long to load or if the UI is janky.

Thus, we'd like to collaborate even more with the web developer community in delivering delightfully fast experiences to our end users, from the moment they click on a link.

Fast from the first click

HTTPArchive shows that since 2011, sites are using on an average of 8x more JavaScript. We’re starting to see the CPU becoming one of the main performance bottlenecks, especially with more and more code often compiled and executed on under-powered mobile devices.

Businesses who focus on the first load (and beyond) are increasingly seeing great results by focusing on the use of Performance Budgets. These budgets can be based on the byte size of your JavaScript, CSS, images and other resources, as well as other loading metrics. For example, you could specify that Time-to-Interactive will not exceed 5s on an emulated 3G network and specific class of mobile phone.

Consistently staying within budget as you add features over time isn’t easy. After Wayfair noticed their own regressions, they built an internal performance budgeting system for their developers to track their performance scores. Since then, their page speeds have continuously become faster, and they’ve seen a year-over-year conversion rate increase of more than 10%.Pinterest revamped their mobile web experience focusing on performance and saw an uplift in user sentiment and engagement. Their mobile website is now their top platform for sign-ups! You can see their journey here:

Buttery smooth beyond the click

Optimizing the loading speed of your webpage is important, but so is ensuring that the page delivers a smooth, interactive user experience as it loads and after it’s displayed. This means responding to all user input quickly, in less than a 1/10th of a second, and ensuring that the user interface doesn’t “jank”— meaning the UI doesn’t pause and then jump suddenly.

Over the past decade, we’ve been evolving Chrome so that it can off-load as much work as possible from the main thread. For example, now we decode images and parse JavaScript separately, and with Web Workers you can execute long running JavaScript without blocking up the UI.

How buttery smooth can you make your web apps today? Especially if you have non-trivial workloads? Our team set out to explore just this, and the end result is a new application launching today called Squoosh. This powerful image compression tool launches almost instantly, and then manages a smooth UI even when it’s doing heavy work, including using Web Assembly to do more with codecs the browser doesn’t have baked in. Tune in to Jake and Mariko's session later today to learn how they did it.

But there is even more to do here, and we are excited about up-coming platform APIs, such as Worklets , Virtual Scroller, and even a scheduler, that help developers build smoother experiences more easily. You’ll hear more about many of these tools and techniques in our Day 2 keynote and beyond.

Capable with deeper integrations

We’ve seen that PWAs make it easy to delight your users, grow engagement and increase conversions. Now with deeper integrations to the host OS and the ability to load and run faster than ever, your PWAs can really shine, yet most of these integrations have been focused on mobile-first, or even mobile-only.

Over the last 6 months we’ve been renewing our investments in providing these same set of capabilities across all desktop platforms. Chrome OS has given us a fantastic surface to really push the boundaries of the web, and based on these learnings we are expanding our Desktop PWA support across Chrome for Windows and Linux, with Mac support targeted to land in Chrome 72.

As we bring more and more capabilities to both mobile and desktop, we want to include the voice of the community to ensure we prioritize features that are important to the community. So today we are sharing our plan to get the capabilities YOU need on the web, and how we can work together to make sure we are solving your real world needs.

Helping you as a web.dev

We know that you want one place that consolidates all the reference information for modern Web APIs, and this is why we continue to collaborate with MDNon improving the core reference documentation of the web.

We have also heard that you would like more hands on guidance on how to deliver on the principles that make a web experience great. So today, we’re excited to announce a new approach: web.dev.

Through a partnership with Glitch, a deep integration with our Lighthouse tool and best-practice guidance from our team, web.devhelps you improve your site through direct and targeted best-practice and the ability to monitor your sites over time to ensure that you are always able to keep your site fast, resilient and accessible.

As we were working on web.dev, we were inspired by other amazing content on the web that help you learn. Dave Geddes, who created Flexbox Zombies and CSS Grid Critters, created a new learning game. Service Workies helps you understand Service Workers soup to nuts. The first chapter of the adventure is rolling out in beta now. We partnered with Dave to make sure the full adventure can be free to all, so check it out now and whatever you do, listen to Grannie!

Web design, right in the browser

At Chrome Dev Summit we cover all of the updates to our developer centric tools and libraries that you know and love, but we also want to show you a new, early experiment that we would love your feedback on.

We remember the impact that Firebug had when it hit the scene, and how it showed how the browser could be the developer tool platform itself. Now we are also thinking about design on the web, and just as Lighthouse started as a Chrome extension to explore, we have another extension, Project Visbug, which allows you to design — right in the browser. You can download it now, but before you do see it in action right here:

Tune into ourlivestreamor watch the videos on the Chrome Developers Youtube channel to follow the rest of the sessions of the day and watch this space for our Day 2 wrap up blog where we will have some more exciting announcements.

Since the beginning of Chrome we have worked to provide a solid foundation for modern web applications. Those capabilities have enabled new experiences on the web that were never thought possible. WASM is enabling new classes of games and productivity apps like Sketchup and AutoCAD, WebRTC enables new ways to communicate, and service workers allow developers to create reliably fast web experiences regardless of network conditions.However, there are some capabilities, like file system access, idle detection, and more that are available to native but aren’t available on the web. These missing capabilities mean some types of apps can't be delivered on the web, or are less useful. To cope, some developers build native apps, or use wrappers like Cordova or Electron to access the underlying capabilities of the device.We strongly believe that every developer should have access to the capabilities they need to make a great web experience, and we want to support them as they do.

Closing the gap

We want to close the capability gap between the web and native and make it easy for developers to build great experiences on the open web. Meanwhile we need to preserve everything that is great about the web. We will rapidly bring new, powerful, portable, and standardized capabilities that unlock key verticals on both mobile and desktop. Giving developers these new tools will empower the open web as a place where any experience can be created, and make the web a first class platform for developing apps that run on any browser, with any operating system, and on any device.We plan to design and develop these new capabilities in an open and transparent way, using the existing open web platform standards processes while getting early feedback from developers and other browser vendors as we iterate on the design, to ensure an interoperable design.Per our practice of open design and public iteration, look for many proposals for new designs to surface at the W3C's Web Incubator Community Group.

What are the initial capabilities?

We’ve identified and prioritized an initial set of capabilities we feel are critical to closing the gap between web and native, and have already started work on a handful of them. You can see the list by searching the Chromium bug database for bugs that are tagged with proj-fugu.Personally I’m really excited about the writable file API that make it possible to create web based editors, and event alarms that help perform arbitrary work at some point in the future. But there are plenty more: Web Share Target, Async cookies, Wake Lock, WebHID, user idle detection, just to name a few.

Early feedback is critical

We developed a process to make it possible to design and develop new web platform capabilities that meet the needs of developers quickly, in the open, and most importantly, work within the existing standards process. It’s no different than how we develop every other web platform feature, but it puts an emphasis on developer feedback.Developer feedback is critical to help us ensure we’re shipping the right features, but it’s easier to change course early in the process. That’s why we’re starting to ask for feedback earlier. When actionable technical and use-case feedback comes in early, it’s easier to course correct or even stop development, without having shipped poorly thought out or badly implemented features. Features being developed at WICG are not set in stone, and your input can make a big difference in how they evolve.It’s worth noting that many ideas never make it past the explainer or origin trial stage. The goal of the process is to ship the right feature. That means we need to learn and iterate quickly. Not shipping a feature because it doesn’t solve the developer need is OK.

Getting everyone involved

The first API we’re looking for feedback on is the writable files API. We want to hear about your use cases and how you expect the security model to work. And keep an eye on our new capabilities page on developers.google.com/web to see the list of capabilities that we’re working on, and how you can participate.The apps you want to build on the open web should only ever be limited by your imagination, never by missing capabilities. As we look to the future, the gap between web and native will get smaller as browser vendors add new capabilities to the web.Here’s to a more capable open web.Posted by Pete LePage, dreamer.

Every month, millions of Chrome users encounter pages with insufficient mobile subscription information. Surprising charges that come from unclear communication are a poor user experience. That’s why starting from Chrome 71 (December 2018), Chrome will show a warning before these pages, so that users can make informed decisions when signing up to mobile based subscription services. Users will be offered the choice to proceed to the page or go back if they were unaware that they were entering a billing page.

Unclear mobile subscriptions

Picture this: Andrea is browsing the web on a mobile connection to access a gaming page and they’re presented with a page that asks them for their mobile phone details.

They fill in the blanks with their mobile number and press Continue, and get access to the content.
The next month, the phone bill arrives and they see a charge they were not expecting. Was the subscription to the online gaming service really that expensive? Did they really agree to pay that specific price for the service? How much did they agree to be charged to access the content?

Clearer billing information for Chrome users

We want to make sure Chrome users understand when they are going through a billing flow and trust that they’ll be able to make informed decisions while browsing the web.
To adequately inform users, it’s important to provide a sufficient level of details within the billing page as outlined by our new mobile billing charges best practices. Pages that answer positively to the following questions generally provide sufficient information for users:

Is the billing information visible and obvious to users? For example, adding no subscription information on the subscription page or hiding the information is a bad start because users should have access to the information when agreeing to subscribe.

Can customers easily see the costs they’re going to incur before accepting the terms? For example, displaying the billing information in grey characters over a grey background, therefore making it less readable, is not considered a good user practice.

Is the fee structure easily understandable? For example, the formula presented to explain how the cost of the service will be determined should be as simple and straightforward as possible.

If Chrome detects pages that don’t provide sufficient billing information to users, the following warning will be displayed to the user on Chrome mobile, Chrome desktop and Android’s WebView:

The warning is shown to users entering unclear billing pages.
When we identify such pages, we notify the webmaster through Search Console where there will be an option to let us know about the changes they’ve made to clarify the billing process. For websites that aren’t verified on Search Console, we will do our best to get in touch with the webmasters affected and will be available to answer questions in our public support forum available in 15 languages. Once an appeal has been sent via Search Console, we will review the changes and remove the warning accordingly.
If your billing service takes users through a clearly visible and understandable billing process as described in our best practices, you don’t need to make any changes. Also, the new warning in Chrome doesn’t impact your website’s ranking in Google Search.
If you have any questions, please come and have a chat with us in the Webmaster Help Forum.

Last year, after hearing from Chrome users, we launched a set of user protections against “abusive experiences” -- experiences designed to intentionally mislead and trick users into taking action on the web. These protections blocked pop-ups and new window requests from sites with certain abusive experiences like redirecting pages.

However, we've learned since then that this approach did not go far enough. In fact, more than half of these abusive experiences are not blocked by our current set of protections, and nearly all involve harmful or misleading ads. These ads trick users into clicking on them by pretending to be system warnings or “close” buttons that do not actually close the ad. Further, some of these abusive ad experiences are used by scammers and phishing schemes to steal personal information.

Two types of abusive experiences where a deceptive site control appears to do one thing, but has a different behavior when clicked. One looks like a play button on a video but sends the user to an unwanted download when clicked (left), and the other looks like a close button but instead opens unwanted pop-up windows (right).

As a result, today we are announcing expanded efforts to better protect users against these abusive experiences. Starting in December 2018, Chrome 71 will remove all ads on the small number of sites with persistent abusive experiences. Site owners can use the Abusive Experiences Report in their Google Search Console to see if their site contains any of these abusive experiences that need to be corrected or removed. Site owners will have a 30 day window to fix experiences flagged by the Report before Chrome removes ads.

With Chrome, users are always in control and can disable abusive sites filtering by going to their Chrome Settings.

Stronger protections ensure users can interact with their intended content on the web, without abusive experiences getting in the way.

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. View a complete list of the features in Chrome 71 on ChromeStatus.com. Chrome 71 is beta as of October 25, 2018.

International Relative Time Format

When writing (and speaking), phrases such as 'yesterday' or 'in three months' are common. Yet such phrases are not part of built-in date and time APIs. To fill this need, libraries provide utility functions to provide localized versions of such phrases. The downside to this approach is that using these functions on the web requires downloading lists of customary words or phrases for each supported language. This increases a library's bundle size and download time.

Chrome 71 introduces Intl.RelativeTimeFormat(), which shifts the burden to the JavaScript engine. A few examples show how this works.

This new API has a number of capabilities beyond what is shown here including such things as retrieving information for multiple languages, dealing with parts of a date or time individually (in other words, formatToParts()), and more. Read our article for details.

Other features in this release

Add FullscreenOptions

The Element.requestFullscreen() method can now be customized on Android using an optional options parameter. Its navigationUI parameter allows you to choose between making the navigation bar visible versus a completely immersive mode where no user agent controls are shown until a gesture is performed. Possible values are "auto", "show", and "hide". This value expresses an application preference, with "auto" meaning no preference. The UI may overrule this vale in any case.

Add 'persistent-storage' property to the Permission API

The "persistent-storage" property is a new permission for the Permission API. The permission state can already be queried with navigator.storage.persisted(), with this change navigator.permissions.query({name:"persistent-storage"}) can be used as well.

Async touchpad pinch zoom events

Async touchpad pinch zoom events are for improving the page pinch zoom performance. Currently, the touchpad pinch zoom exposes a control wheel event that allows JS to cancel it. With this change, if the user doesn't make a pinch action on the touchpad, effectively canceling the control wheel event, then following control wheel events are not cancelable. But JavaScript does not know which ctrl wheel is the first one in the sequence, so if you want to cancel pinch zoom, you need to cancel all of them.

COLR/CPAL font support

Chrome now supportsCOLR/CPAL fonts which are a type of OpenType color font composed of layers of vector outline glyphs and color palette information into the final colored glyph. With this change, Chrome supports three color font formats cross-platform, the other two being CBDT/CBLC and SBIX. Because they are vector based, COLR/CPAL fonts provide for faster downloads and require less storage. An example of a COLR/CPAL font is the Twemoji color font.

To simplify the definition of solid color bands, two positions may be specified instead. For example:

linear-gradient(45deg, black 25% 50%, white 50% 75%)

Implement 'left' and 'right' values for 'text-underline-position'

Currently, in vertical flow for Chinese and Japanese, which side the underline appears on is not the same across browsers. To fix this, Chrome is adding support for 'left' and 'right' values of the 'text-underline-position' property. This property is part of the CSS3 Text Decoration spec which adds properties that implement new text decoration styling features such as lines, color, and style, including 'text-underline-position'.

JavaScript Modules: Credentials mode defaults to "same-origin"

The default credentials mode for module script requests is changing from "omit" to "same-origin", providing credentials to same-origin module script requests and their descendant scripts (static and dynamic imports). The current behavior can be surprising in that it's misaligned with other high-level features like the Fetch API, and in the web platform's current architecture, causes a second server connection. This is undesirable for developers looking to reduce latency.

TextEncoderStream and TextDecoderStream APIs

Text encoding and decoding supports streams to enable you to easily convert streams of binary data to text and vice-versa. An example of its usefulness is with readable streams. With a non-stream Response object, response.body.text() returns text. There is no equivalent for the ReadableStream returned by Response.Body, which can only return bytes. With the new API a streaming response body may be converted to text as so: Response.Body.pipeThrough(new TextDecoderStream()).

Unprefixed Fullscreen API

The Fullscreen API has features for entering, and exiting fullscreen mode as well as event handlers for monitoring such changes. A prefixed version of the API has been supported since Chrome 15. This update adds an unprefixed version of the API.

MediaElement and MediaStream nodes defined only for AudioContext

Chrome now only allows creation of MediaElementAudioSourceNode, MediaStreamAudioSourceNode, and MediaStreamAudioDestinationNode elements using an AudioContext. Previously these could be created using an OfflineAudioContext, but that does not comply with the spec. The behavior with an OfflineAudioContext is not well-defined and contrary to the real-time nature of the nodes themselves.

Interoperability improvements

Call capture event listeners in capturing phase at shadow hosts

To be interoperable with other browsers, Chrome now calls capture event listeners in the capturing phase at shadow hosts. Previously this was done in the bubbling phase on Chrome. A complete discussion may be read on the WHATWG repo on GitHub.

Improve :host, :host-context, and ::slotted specificity

Chrome now calculates the specificity for the :host() and :host-context() pseudo classes as well as for the arguments for ::slotted(). This brings it into compliance with the Shadow DOM v1 spec.
Shipping this will ensure interoperability between browsers since other browsers have or are about to ship this in their stable releases.

Deprecations and Removals

Chrome sometimes deprecates, removes, or changes features to increase interoperability with other browsers. This version of Chrome includes the following such changes.

Remove SpeechSynthesis.speak without user activation

The speechSynthesis.speak() method now fires an error if the document has not received user activation. This API is being abused by sites since it is one of the only remaining APIs which didn't adhere to autoplay policies in Chrome.

Remove importScripts() of new scripts after service worker installation.

Remove prefixed versions of several APIs

Remove URL.createObjectURL for MediaStream

The URL.createObjectURL() method has been removed from the MediaStream interface. This method has been deprecated in 2013 and superseded by assigning streams to srcObject.

Remove document.origin

The document.origin property has been removed. This property was only ever implemented in Chromium and WebKit. It is redundant with self.origin which can be used in both window and worker contexts and has wider support.

Incredibly, it’s been nearly a decade since we launched the Chrome extensions system. Thanks to the hard work and innovation of our developer community, there are now more than 180,000 extensions in the Chrome Web Store, and nearly half of Chrome desktop users actively use extensions to customize Chrome and their experience on the web.

The extensions team's dual mission is to help users tailor Chrome’s functionality to their individual needs and interests, and to empower developers to build rich and useful extensions. But, first and foremost, it’s crucial that users be able to trust the extensions they install are safe, privacy-preserving, and performant. Users should always have full transparency about the scope of their extensions’ capabilities and data access.

We’ve recently taken a number of steps toward improved extension security with the launch of out-of-process iframes, the removal of inline installation, and significant advancements in our ability to detect and block malicious extensions using machine learning. Looking ahead, there are more fundamental changes needed so that all Chrome extensions are trustworthy by default.

Today we’re announcing some upcoming changes and plans for the future:

User controls for host permissions

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

While host permissions have enabled thousands of powerful and creative extension use cases, they have also led to a broad range of misuse - both malicious and unintentional - because they allow extensions to automatically read and change data on websites. Our aim is to improve user transparency and control over when extensions are able to access site data. In subsequent milestones, we’ll continue to optimize the user experience toward this goal while improving usability. If your extension requests host permissions, we encourage you to review our transition guide and begin testing as soon as possible.

Changes to the extensions review process

Going forward, extensions that request powerful permissions will be subject to additional compliance review. We’re also looking very closely at extensions that use remotely hosted code, with ongoing monitoring. Your extension’s permissions should be as narrowly-scoped as possible, and all your code should be included directly in the extension package, to minimize review time.

New code readability requirements

Starting today, Chrome Web Store will no longer allow extensions with obfuscated code. This includes code within the extension package as well as any external code or resource fetched from the web. This policy applies immediately to all new extension submissions. Existing extensions with obfuscated code can continue to submit updates over the next 90 days, but will be removed from the Chrome Web Store in early January if not compliant.

Today over 70% of malicious and policy violating extensions that we block from Chrome Web Store contain obfuscated code. At the same time, because obfuscation is mainly used to conceal code functionality, it adds a great deal of complexity to our review process. This is no longer acceptable given the aforementioned review process changes.

Additionally, since JavaScript code is always running locally on the user's machine, obfuscation is insufficient to protect proprietary code from a truly motivated reverse engineer. Obfuscation techniques also come with hefty performance costs such as slower execution and increased file and memory footprints.

Ordinary minification, on the other hand, typically speeds up code execution as it reduces code size, and is much more straightforward to review. Thus, minification will still be allowed, including the following techniques:

In 2019, enrollment in 2-Step Verification will be required for Chrome Web Store developer accounts. If your extension becomes popular, it can attract attackers who want to steal it by hijacking your account, and 2-Step Verification adds an extra layer of security by requiring a second authentication step from your phone or a physical security key. We strongly recommend that you enroll as soon as possible.

For even stronger account security, consider the Advanced Protection Program. Advanced protection offers the same level of security that Google relies on for its own employees, requiring a physical security key to provide the strongest defense against phishing attacks.

Looking ahead: Manifest v3

In 2019 we will introduce the next extensions manifest version. Manifest v3 will entail additional platform changes that aim to create stronger security, privacy, and performance guarantees. We want to help all developers fall into the pit of success; writing a secure and performant extension in Manifest v3 should be easy, while writing an insecure or non-performant extension should be difficult.

Some key goals of manifest v3 include:

More narrowly-scoped and declarative APIs, to decrease the need for overly-broad access and enable more performant implementation by the browser, while preserving important functionality

Additional, easier mechanisms for users to control the permissions granted to extensions

Modernizing to align with new web capabilities, such as supporting Service Workers as a new type of background process

We intend to make the transition to manifest v3 as smooth as possible and we’re thinking carefully about the rollout plan. We’ll be in touch soon with more specific details.

We recognize that some of the changes announced today may require effort in the future, depending on your extension. But we believe the collective result will be worth that effort for all users, developers, and for the long term health of the Chrome extensions ecosystem. We’re committed to working with you to transition through these changes and are very interested in your feedback. If you have questions or comments, please get in touch with us on the Chromium extensions forum.