We all benefit from an open web that is secure, powerful, and fast. Over
the past year, we’ve focused our efforts on strengthening the web in three
areas:
Rethinking how we can deliver a safe and secure web
Adding the capabilities you need to build powerful, rich, and diverse applications
Optimizing for performance, for users and developers alike
This post is a synopsis of the updates we shared during today’s keynote at
Chrome Dev Summit.
To help you get the most out of your Google Account, Chrome on Android will soon let you sign in with a single tap, even when not using sync. When you sign in to a Google service like Gmail, you can now choose to sign in to Chrome with one of your Google Accounts on the device – with a single tap and without having to re-enter your credentials. If you prefer to sign in without adding your account to the device, you can simply dismiss the dialog. And if you want a temporary browsing session, the menu provides a quick way to open Incognito mode.
Easier payments with Chrome on Android
When you sign in to Chrome on your Android phone using the new single tap option, you’ll soon be able to autofill the payment methods stored in your Google Account for a more convenient shopping experience. Chrome will ask you to confirm the card’s CVC or let you authenticate with biometrics, and then you’re good to go. You can also save a new credit card to your account to use it across all your devices. Each time you save a card to your account, you will receive a confirmation email. You can manage and delete the cards at any time by going to your Payment methods in your account.
Easier Password Management on Chrome desktop
We’ve heard your feedback for more flexibility when it comes to having access to passwords saved to your Google Account. Over the next couple of months, accessing and managing your passwords safely across your devices will become even easier. This can all be done simply by signing in to your Google Account, regardless of whether sync is enabled. You’ll be able to autofill passwords on sites that you previously saved to your account, and when you save a new password, Chrome will let you choose where you want to save it — on the device or in your Google Account. If you choose your account, you can access it on all your devices.
With this change we’re also bringing Chrome’s password generation feature to more people, helping them create strong and unique passwords for the many online accounts people manage when using Chrome.
Keep an eye out for these features over the coming months, and as always, be sure to keep tabs on our blog for future updates.
In Chrome 73, with Signed HTTP Exchange, we launched the first phase of a long term effort designed to bring instant experiences to the whole web, through improved prefetching and pre-rendering techniques that are privacy and developer friendly. As a quick refresher, Signed HTTP Exchange makes it possible to create “portable” content, i.e. content that other parties can deliver on your behalf with the assurance that it will remain unaltered and properly attributed to your origin. This offers several advantages such as the ability to speed up page loads, increasing the availability of popular or critical content when the origin servers can’t keep up with the demand, and can also help reduce a publisher’s data transfer costs since the bytes are served by a third party.
In Chrome 86 for Android, we ran a proof-of-concept experiment to test a different approach that we hope will be a complementary option to Signed HTTP Exchange. While Signed HTTP Exchange can already be used to enable instant experiences, they require some extra work and setup which isn’t yet always trivial. We are always on the lookout for innovation opportunities, and with this new approach, our goal is to make it easier to achieve instant experiences across the whole web, thereby helping the community better understand the value of such experiences, and consequently motivating further investment in instant techniques or efforts meant to lower the barriers to adoption of such techniques.
The experiment consisted of prefetching the critical resources for a subset of the most likely cross-site navigations in Chrome for Android, and showed an improvement of 40% on the Largest Contentful Paint page load time metric, without revealing potentially identifiable information, such as the user’s IP address, and without requiring extra work from developers to start seeing some benefits. Given the successful proof of concept experiment, we feel ready to share more details about the approach and start engaging with the community to iterate on a viable web platform solution. But before we do, let us take you for a walk down memory lane.
“Loading a page without prefetching”
Lessons learned from prefetching and prerendering
Prefetching is a way to speed up page loads by downloading the bits and pieces that make up a web page (e.g. HTML documents, Javascript, Stylesheet, Images, etc.) in anticipation of a user navigating to said webpage. Pre-rendering is taking things a bit further by drawing and running the web page ahead of time, off-screen, so that by the time the user navigates to the web page, it’s ready to go and displays instantly.
Prefetching or pre-rendering web pages is not a brand new idea. In fact, most modern browsers have such features. For instance, Chrome for desktop had a feature called “Instant Pages” from 2011 until 2017 when it was replaced with NoState Prefetch. Here are some of the key reasons that made us take a step back with regards to pre-rendering at the time:
Pre-rendering was an all or nothing approach where calls to unsupported web features would result in completely abandoning pre-rendering. The intent was to avoid annoyances such as having sounds or permission prompts coming out of nowhere, but in practice, this meant that most websites were not compatible with pre-rendering and that web developers could inadvertently fall outside of the set of pre-rendering compatible web features, and lose all the benefits as a result.
Not all pages can be safely pre-rendered. For instance, pre-rendering a link to a page that logs you out of your favorite website would be a bad experience. Because it is non trivial to dissociate pages that are consequence-free vs. those that aren’t, this meant that we were only able to safely apply pre-rendering to a narrow subset of links on the web.
These hurdles meant that pre-rendering was only used by, and for, a handful of websites. Even today, with the NoState Prefetch approach, the feature is only used on 1.4% of all page loads. Given the significant upsides (e.g. 40% faster page loads with prefetching), we believe that the ceiling ought to be much higher. To start, we decided to set our sights on addressing a significant impediment to the use of prefetching, and by extension pre-rendering: preserving privacy while improving page load performance.
Prefetching and privacy
A fundamental challenge with prefetching another website is that it inherently happens before the user has signaled their interest, i.e. by visiting said website. So, if your browser, or favorite websites, were to prefetch links to pages on other websites that you might be interested in, it exposes potentially identifiable information, such as your IP address or cookies, to the servers hosting those websites. This approach to prefetching is problematic because it allows the prefetched websites to learn something new about you, such as your interest in some content or product. In practice, as we have said earlier, this heavily limits the usage of prefetching to a small number of cases where prefetching a page doesn’t reveal new information to its publisher.
“Naively prefetching websites can result in leaking user’s interest in some content or product”
In essence, the challenge here is to find an approach which upholds the following privacy principle: “None of the parties involved can learn anything new about the user as a result of prefetching a website”. For the experiment, we’ve addressed this challenge by having Chrome use a “private prefetch proxy” which consists of a CONNECT proxy, a set of rules governing its usage, and additional measures to ensure that the prefetches can not be personalized to the user.
Private prefetch proxy
At a high level, Chrome gives the name of a website to the CONNECT proxy which then creates a secure communication channel between Chrome and that website. By design, the proxy was operated for and by Google, and was restricted to navigations originating from Google owned surfaces, thereby ensuring that the proxy could only see information that’s already accessible such as the names of the websites prefetched from surfaces that we authored. The end-to-end encrypted communication channel provided by the CONNECT proxy means that the proxy is only able to relay further requests without being able to see the content of the communication. Furthermore, given that the content of the communication is encrypted end-to-end between Chrome and the destination site, it also means that intermediaries can’t see the prefetched domains, nor the content of the prefetched resources. Likewise, since the proxy is relaying the prefetching requests, the destination website only sees the IP address of the proxy, not the user’s IP address. Finally, prefetching was restricted to websites that had no cookies or other local state, thereby preventing the destination site from identifying a user via information previously stored on their device.
“Prefetching websites via a CONNECT proxy prevents leaking user information”
Rebuilding pre-rendering on a solid foundation
As mentioned in the introduction, our goal is to bring instant experiences to the whole web through prefetching and pre-rendering techniques that are privacy and developer friendly. This proof of concept experiment and the follow-up discussions with the community represent small, but nevertheless important, steps toward that goal. Indeed, any pre-rendering feature is inherently built on top of a prefetching capability, which must abide by the same privacy principles. There are a few more challenges that we’ll need to solve to bring back an improved, privacy and developer friendly, pre-rendering feature. To be clear, we see this successful proof of concept experiment as a positive signal for iterating on a viable web platform solution, so that more websites can both benefit from, and take advantage of the approach outlined in this blog post. We are hopeful that what we’ve learned from past efforts, as well as new learnings we’ve gained thanks to this proof-of-concept experiment, will help foster a fruitful collaborative effort with the rest of the community.
Posted by Michael Buettner (Software Engineer), and Kenji Baheux (Product Manager)
In this release, we’re improving how Chrome understands and manages resources with Tab throttling, occlusion tracking and back/forward caching, so you can quickly get to what you need when you need it.
Tab throttling and Occlusion Tracking
Knowing what tabs you’re using helps Chrome manage your computer’s resources more efficiently to get things done. We’ve made significant improvements by preventing background tabs from waking up your CPU too often, and no longer rendering tabs that you can’t see.
We investigated how background tabs use system resources and found that JavaScript Timers represent >40% of the work in background tabs. Reducing their impact on CPU and power is important to make the browser more efficient. Beginning in M87, we’re throttling JavaScript timer wake-ups in background tabs to once per minute. This reduces CPU usage by up to 5x, and extends battery life up to 1.25 hours in our internal testing. We’ve done this without sacrificing the background features that users care about, like playing music and getting notifications.
Next, we’re bringing Occlusion Tracking--which was previously added to Chrome OS and Mac--to Windows, which allows Chrome to know which windows and tabs are actually visible to you. With this information, Chrome can optimize resources for the tabs you are using, not the ones you’ve minimized, making Chrome up to 25% faster to start up and 7% faster to load pages, all while using less memory.
These updates will be gradually rolling out in M87 and our next release, M88.
Back/forward cache
How many times have you visited a website and clicked a link to go to another page, only to realize it's not what you wanted and click the back button? On mobile devices, this happens a lot: 1 in 5 navigations are a back/forward navigation. This is where a back/forward cache shines! It’s a browser optimization which enables instant back and forward navigations. In Chrome 87, our back/forward cache will make 20% of those back/forward navigations instant, with plans to increase this to 50% through further improvements and developer outreach in the near future. Here is how it works:
Back/forward cache is one of our long wished-for feature requests in Chrome and now with Chrome 87 we will gradually launch it to Chrome for Android users. Head over to this technical article to learn more about how we added back/forward cache within Chrome's multi-process architecture and if you're a web developer, learn how to make the most of the back/forward cache on your website.
Posted by Mark Chang, Chrome Product Manager
Data source: Real world data anonymously aggregated from Chrome pre-stable channels.
Mobile UI for quiet notifications on abusive websites. The new UI discourages users from allowing notifications from these websites.
This UI exactly matches the UI that was previously announced for Chrome 84. The only difference is in Chrome 86 we will begin blocking notification permission requests when sites have a pattern of sending abusive notification content.
Why are we doing this?
Abusive notification prompts are one of the top user complaints we receive about Chrome. Our goal with these changes is to improve the experience for Chrome users and to reduce the incentive for abusive sites to misuse the web notifications feature.
How will Chrome detect sites sending abusive notification content?
Google’s automated web crawling service will occasionally subscribe to website push notifications if the push permission is requested. Notifications that are sent to the automated Chrome instances, using Safe Browsing technology, will be evaluated for abusive content, and sites sending abusive notifications will be flagged for enforcement if the issue is unresolved.
What happens if abusive notifications are detected from my website?
When a site is found to be in “Failing” status for any type of notification abuse, Search Console will send an email to registered site owners and users in the site's Search Console at least 30 calendar days prior to the start of enforcement. During the 30 day grace period websites can address the issue and request another review.
What should I do if my website failed the abusive notification review?
The Search Console help center has a guide for how to fix abusive notifications and request another review of your website.
Are any further abusive notification protections planned?
Prior to the release of Chrome’s abusive notifications protections, many users have already unintentionally allowed notifications from websites engaging in abusive activity. In an upcoming release, Chrome will revert the notification permission status from “granted” to “default” for abusive origins, preventing further notifications unless the user returns to the abusive origin and re-enables notifications.
We’ll be listening for feedback from users and developers about the effectiveness of current enforcements and may make further changes based on that feedback.
