Expanding HTTPS-First Mode protections for more people
Our ultimate goal is to enable HTTPS-First Mode for everyone. To that end, we're expanding HTTPS-First Mode protections to several new areas:
We've enabled HTTPS-First Mode for users enrolled in Google's Advanced Protection Program who are also signed-in to Chrome. These users have asked Google for the strongest protection available, and HTTPS-First Mode helps avoid the very real threats of insecure connections these users face.
We're planning to enable HTTPS-First Mode by default in Incognito Mode for a more secure browsing experience soon.
We're currently experimenting with automatically enabling HTTPS-First-Mode protections on sites that Chrome knows you typically access over HTTPS.
Finally, we're exploring automatically enabling HTTPS-First Mode for users that only very rarely use HTTP.
Try it out
If you'd like to try out HTTPS upgrading or warning on insecure downloads before they roll out to everyone, you can do so in Chrome today by enabling the "HTTPS Upgrades" and "Insecure download warnings" flags at chrome://flags. And if you want stronger protections, you can also turn on HTTPS-First Mode by enabling "Always use secure connections" in Chrome security settings (chrome://settings/security)!
Information for Developers and Enterprise
If you're a developer, you can ensure your users don't see warnings or encounter failed upgrades on your sites by using HTTPS and ensuring that your site doesn't host content only accessible over HTTP. We encourage you to fully adopt HTTPS and redirect all HTTP URLs to their HTTPS equivalents. Even if you believe that your site does not host personal information, using HTTP puts your users at increased risk of network attackers injecting malicious content into their browsers. Malicious network attackers rely on insecure sites to get a foothold towards your users. We're exploring additional ways we can reduce the risk users experience by visiting insecure websites by, for instance, reducing the lifetime of cookies accessible over HTTP -- switching to HTTPS ensures that your users' experience will not be impacted by these future changes. If you can't support HTTPS yet, you can ensure that users can access your site by making sure that your server either does not respond to requests on port 443 at all, or uses HTTPS to redirect users back to HTTP.
Chrome has a longhistoryofworkingtowardsasecure-by-default web, and we're not stopping here. We're so close to the finish line, and we're excited to help the web get to HTTPS by default.
Big performance wins can be found by taking a step back and tweaking what you already have. Today’sThe Fast and the Curious post explores how we improved the scrolling experience of Chrome on Android, ultimately reducing slow scrolling jank by 2x. Read on to see how we discovered and evaluated the problem, and how that has helped us design a better browser experience going forward.
When measuring the performance of a browser, one might typically think of page load speed or Web Vitals. On mobile where touch interactions are common we also prioritize your interaction with Chrome to ensure it is always smooth and responsive including on new form factors like foldables. A significant focus of late has been on reducing jank while you scroll.
We recently improved the scrolling experience of Chrome on Android by 2x by filtering noise and reducing visual jumps in the content presented on screen. To get this result, we had to take a step back and figure out the problem of why Chrome on Android was lagging behind Chrome on iOS.
As we compared Chrome across platforms, we were hit with a particular observation. iOS Chrome scrolling was smooth and consistent whereas on Android, Chrome’s scrolling didn't follow your finger as closely. However, our metrics were telling us that while janks occurred occasionally, they weren’t as common as our perception when comparing with Chrome on iOS. Thus we had ourselves a mystery which needed some investigation.
Investigating input to output rate
Our metrics flagged that we often received input at an inconsistent rate; but since the input rate was greater than the display’s frame rate, we usually had at least one input event to trigger the production of a frame to display. However, this frame might have consumed fewer or more input events, which could result in inconsistent shifting of content on screen even while scrolling at a fixed speed.
This problem of different input rate vs frame rate is a problem that Chrome has had to address before. Internally, we resample input to predict/extrapolate where the finger was at a consistent point relative to the frame we want to produce. This should result in each frame representing a consistent amount of time and should mean smooth scrolling regardless of noise in the input events. The ideal scenario is illustrated in the following diagram where blue dots are real input events, green are resampled input events, and the displayed scroll deltas would fluctuate if you were to use the real input events rather than resampling.
Okay so we already do resampling so what's the problem?
A tale of woe and reimplementation
Input resampling inside of Chrome (and Android) were added back in 2019 as 90hz devices emerged and the problem above became more apparent (oscillating between 2 vs 1 input events per frame rather than consistently 2 input events per frame we usually see on 60hz devices). Android implemented multiple resampling algorithms (kalman, linear, etc.) and arrived at the conclusion that linear resampling (drawing a line between two points to figure out velocity and then extrapolate to the given timestamp) was good enough for their use cases. This fixed the problem for most Android apps, but didn't address Chrome.
Due to historical reasons and web spec requirements for raw input, Chrome uses unbuffered input and thus as devices started to appear with sampling rates that didn’t fit with input, Chrome had to implement some version of resampling. Below we see that each frame (measuring the time from input to it being displayed) consumes a different amount of input events (2 for the first, 3 for the second, and 1 for the third), if we assume input is consistently arriving and each is exactly 30 pixels of displacement then ideally we should smooth it out to 60 pixels per frame as seen below:
However, while we were investigating the original mystery we discovered that reality was very different from the ideal situation pictured above. We found that the actual input movement of the screen was quite spiky and inconsistent (more than we expected) and that our predictor was improving things but not as much as desired. On the left is real finger displacement on a screen (each point is an input event) and on the right the result of our predictor of actual content offset after smoothing out (each point is a frame)
Frames are being presented consistently on the right, but the rate of displacement spikes between one to another isn’t consistent (-50 to -40 followed by another -52 being especially drastic). Human fingers don’t move this discretely (at frame level precision). Rather they should slide and flex in a gradient, speeding up or slowing down gradually. So we knew we had a problem here. We dug deeper into Chrome’s implementation and found there were some fundamental differences in Chrome’s implementation (which was supposedly a copy of Android’s).
1. Android uses the native C++ MotionEvent timestamp (with nanosecond precision), but Chrome uses Java MotionEvent.getEventTime & MotionEvent.getHistoricalEventTime (milliseconds precision). Unfortunately, nanosecond precision was not part of the public API. However, rounding of milliseconds can introduce error into our predictor when it computes velocity between event timestamps.
2. Android’s implementation takes care when selecting the two input events so resampling is using the most relevant events. Chrome however uses a simple FIFO queue of input events, which can result in weird cases of using future events to predict velocity in the past in rare cases on high refresh rate devices.
We prototyped using Android’s resampling in Chrome, but found it was still not perfect for Chrome’s architecture resulting in some jank. To improve on it, we experimented with different algorithms, using automation to replay the same input over and over again and evaluating the screen displacement curves. After tuning, this landed at the 1€ filter implementation that visibly and drastically improved the scrolling experience. With this filter, the screen tracks closely to your finger and websites smoothly scroll, preventing jank caused by inconsistent input events. The improvement is visible in our manual validation, on both top-end and low-end devices (Here's a redmi 9A video example).
Going forward!
In Android 14, the nanosecondAPI for java MotionEvents will be publicly exposed in the SDK so Chrome (and other apps with unbuffered input) will be able to call it. We also developed new metrics that track the quality of the scroll predictors frame, by creating a test app which introduced pixel level differences between frames (and no other form of jank) and running experiments to see what people would notice. These analysis can be read about here and will be used going forward for more exciting performance wins and to make this a visible area for tracking against regressions. In the end, after tuning and enabling the 1€ filter, our metrics show a 2x reduction in visible jank while scrolling slowly! This improvement is going live in M116 as the default, but will be launched all the way back to M110 and brings Chrome on Android on par with Chrome on iOS!
The moral of the story is: Sometimes metrics don’t cover all the cases and taking a step back and investigating from the top down and getting the lay of the land can end with a superior scrolling experience for users.
With the latest release of Chrome for desktop we are introducing a redesign of the Chrome downloads experience to make it easier for you to interact with your recent downloads. Let's go behind the scenes and learn more about this redesign from Chrome Senior Product Manager Jasika Bawa.
What influenced your decision to redesign Chrome downloads?
Downloads are a core part of day to day web browsing, from getting the perfect cat themed background for your PC to saving a copy of your tax return. Over the years, we have listened to your feedback about the legacy Chrome downloads experience. We learned that while there was a lot about it that worked well for you, like strong support for core download journeys and built-in protection from potentially harmful files, it had its problems too. For example, it –
Occupied precious pixels at the bottom of the screen which squeezed the web content area, and was limited by screen width in how many files it could show at once
Didn't go away automatically, and only offered actions such as pause/resume and open in folder from a fixed overflow menu
Was no longer modern, interactive, and consistent with the look and feel of other browser UI or the browser ecosystem at large
All this made it clear that there was room for improvement for us to create a more intuitive experience for downloading in Chrome.
What does the redesign have to offer?
The new download tray is available to the right of the Chrome address bar and replaces the legacy downloads experience at the bottom of your screen. When a download is in progress, an animated ring helps you monitor it with a quick glance. The tray opens when you've finished downloading a file and automatically dismisses itself, making it easy to access quickly and allowing you to continue browsing uninterrupted.
With the download tray, you can see a list of all your downloads from the past 24 hours in any browser window, not just the one in which you originally downloaded a file. The tray also offers in-line options to open the folder a download is in, cancel a download, retry a download should it fail for any reason, and pause/resume downloads.
How will the new downloads experience help keep people safe online?
We always want to make sure you are safe when downloading files, so Chrome will continue to provide clear warning signs of potential malware or viruses to protect your device and accounts. In fact, the additional space and more flexible UI of the new Chrome downloads experience will give us the opportunity to provide even more context when Chrome protects you from a potentially malicious file, and enable us to build advanced deep scan options that we couldn't before. Be sure to watch the Google Security Blog for more details on these coming soon.
In addition to download warnings, the download tray being anchored next to the Chrome address bar helps create a clearer separation of trusted browser UI from web content, which was something we wanted to ensure with the redesign.
How did you think about making the transition to the new downloads experience easier?
It was important to us that all the functionality of the legacy Chrome downloads experience be made available in the new one. For example, you can still drag a downloaded file to another folder, program, or website, and perform actions like "Always open" from the new download tray. If you want a more detailed view of your downloads, you can continue to access this by selecting the "Show all downloads" option in the download tray, by clicking "Downloads" from the Chrome three dot menu, or by typing chrome://downloads in the Chrome address bar.
We also took feedback from our early experiments seriously, and used it to make changes like adjusting the frequency with which the download tray opens. You can even choose to have the tray not open automatically at all, in Chrome settings.
Are there any steps developers need to take?
For developers, we'd like to highlight the opportunity to update any guidance or visuals you may have built to help guide users through their download journey. You may want to consider referencing the Download a file topic in the Google Chrome Help Center as a starting point.
For extension developers, it is worth noting changes to chrome.downloads extensions APIs in case you need to update your extensions – specifically, setShelfEnabled has been replaced by setUiOptions which lets you show or hide the new downloads experience.
We hope you'll enjoy this fresh coat of paint! We'll continue to build upon it in future releases to help you stay productive in Chrome while keeping you safe when downloading files from the web.
