[go: up one dir, main page]

For the past several years, more than 90% of Chrome users' navigations have been to HTTPS sites, across all major platforms. Thankfully, that means that most traffic is encrypted and authenticated, and thus safe from network attackers. However, a stubborn 5-10% of traffic has remained on HTTP, allowing attackers to eavesdrop on or change that data. Chrome shows a warning in the address bar when a connection to a site is not secure, but we believe this is insufficient: not only do many people not notice that warning, but by the time someone notices the warning, the damage may already have been done.


We believe that the web should be secure by default. HTTPS-First Mode lets Chrome deliver on exactly that promise, by getting explicit permission from you before connecting to a site insecurely. Our goal is to eventually enable this mode for everyone by default. While the web isn't quite ready to universally enable HTTPS-First Mode today, we're announcing several important stepping stones towards that goal.



Automatic upgrades


Chrome will automatically upgrade all http:// navigations to https://, even when you click on a link that explicitly declares http://. This works very similarly to HSTS upgrading, but Chrome will detect when these upgrades fail (e.g. due to a site providing an invalid certificate or returning a HTTP 404), and will automatically fallback to http://. This change ensures that Chrome only ever uses insecure HTTP when HTTPS truly isn't available, and not because you clicked on an out-of-date insecure link. We're currently experimenting with this change in Chrome version 115, working to standardize the behavior across the web, and plan to roll out the feature to everyone soon. While this change can't protect against active network attackers, it's a stepping stone towards HTTPS-First mode for everyone and protects more traffic from passive network eavesdroppers.



Warning on insecurely downloaded files


Building and expanding on our previous work removing support for mixed downloads, Chrome will start showing a warning before downloading any high-risk files over an insecure connection. Downloaded files can contain malicious code that bypasses Chrome's sandbox and other protections, so a network attacker has a unique opportunity to compromise your computer when insecure downloads happen. This warning aims to inform people of the risk they're taking. You will still be able to download the file if you're comfortable with the risk. Unless HTTPS-First Mode is enabled, Chrome will not show warnings when insecurely downloading files like images, audio, or video, as these file types are relatively safe. We're expecting to roll out these warnings starting in mid September.


Chrome will inform you if a file was downloaded insecurely.



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.


We know that enterprises and education networks have unique needs. These features can be turned on early, customized, or turned off entirely via the HttpsOnlyMode, HttpsUpgradesEnabled, HttpAllowlist, and InsecureContentAllowedForUrls policies. 



Part of our ongoing commitment


Chrome has a long history of working towards a secure-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.


Post by Joe DeBlasio, Chrome Security team

Teams across Google are working hard to prepare the web for the migration to quantum-resistant cryptography. Continuing with our strategy for handling this major transition, we are updating technical standards, testing and deploying new quantum-resistant algorithms, and working with the broader ecosystem to help ensure this effort is a success.


As a step down this path, Chrome will begin supporting X25519Kyber768 for establishing symmetric secrets in TLS, starting in Chrome 116, and available behind a flag in Chrome 115. This hybrid mechanism combines the output of two cryptographic algorithms to create the session key used to encrypt the bulk of the TLS connection:



In order to identify ecosystem incompatibilities with this change, we are rolling this out to Chrome and to Google servers, over both TCP and QUIC and monitoring for possible compatibility issues. Chrome may also use this updated key agreement when connecting to third-party server operators, such as Cloudflare, as they add support. If you are a developer or administrator experiencing an issue that you believe is caused by this change, please file a bug. The remainder of this post provides important background information to help understand this change as well as the motivations behind it.



The Post-Quantum Motivation


Modern networking protocols like TLS use cryptography for a variety of purposes including protecting information (confidentiality) and validating the identity of websites (authentication). The strength of this cryptography is expressed in terms of how hard it would be for an attacker to violate one or more of these properties. There’s a common mantra in cryptography that attacks only get better, not worse, which highlights the importance of moving to stronger algorithms as attacks advance and improve over time.


One such advancement is the development of quantum computers, which will be capable of efficiently performing certain computations that are out of reach of existing computing methods. Many types of asymmetric cryptography used today are considered strong against attacks using existing technology but do not protect against attackers with a sufficiently-capable quantum computer. 


Quantum-resistant cryptography must also be secure against both quantum and classical cryptanalytic techniques. This is not theoretical: in 2022 and 2023, several leading candidates for quantum-resistant cryptographic algorithms have been broken on inexpensive and commercially available hardware. Hybrid mechanisms such as X25519Kyber768 provide the flexibility to deploy and test new quantum-resistant algorithms while ensuring that connections are still protected by an existing secure algorithm. 


On top of all these considerations, these algorithms must also be performant on commercially available hardware, providing yet another layer of challenge to this already complex problem.



Why Protecting Data in Transit is Important Now


It’s believed that quantum computers that can break modern classical cryptography won’t arrive for 5, 10, possibly even 50 years from now, so why is it important to start protecting traffic today? The answer is that certain uses of cryptography are vulnerable to a type of attack called Harvest Now, Decrypt Later, in which data is collected and stored today and later decrypted once cryptanalysis improves. 


In TLS, even though the symmetric encryption algorithms that protect the data in transit are considered safe against quantum cryptanalysis, the way that the symmetric keys are created is not. This means that in Chrome, the sooner we can update TLS to use quantum-resistant session keys, the sooner we can protect user network traffic against future quantum cryptanalysis.



Deployment Considerations


Using X25519Kyber768 adds over a kilobyte of extra data to the TLS ClientHello message due to the addition of the Kyber-encapsulated key material. Our earlier experiments with CECPQ2 demonstrated that the vast majority of TLS implementations are compatible with this size increase; however, in certain limited cases, TLS middleboxes failed due to improperly hardcoded restrictions on message size.


To assist with enterprises dealing with network appliance incompatibility while these new algorithms get rolled out, administrators can disable X25519Kyber768 in Chrome using the PostQuantumKeyAgreementEnabled enterprise policy, available starting in Chrome 116. This policy will only be offered as a temporary measure; administrators are strongly encouraged to work with the vendors of the affected products to ensure that bugs causing incompatibilities get fixed as soon as possible.


As a final deployment consideration, both the X25519Kyber768 and the Kyber specifications are drafts and may change before they are finalized, which may result in Chrome’s implementation changing as well.


Posted by: Devon O'Brien, Technical Program Manager, Chrome security 
Labels:




Big performance wins can be found by taking a step back and tweaking what you already have. Today’s The 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 nanosecond API 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.


Post by: Stephen Nusko, Chrome Software Engineer


Labels: ,

Main image of blog post that showcases the new download experience for Chrome on the right side of the Chrome Address bar.


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.


GIF of the Chrome browser with the cursor clicking the “save” option of a web file. The download in progress icon appears with a progress ring around it. Once the file has finished downloading, the download tray opens automatically.



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.


GIF of the Chrome browser with the cursor opening the download tray to the right of the Chrome address bar. The download tray shows a file download in progress, and offers an in-line option to pause the download. The cursor clicks on the pause button, which turns into a play button. The cursor clicks on the play button to resume the download progress.



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.


Image asset of Chrome browser with zoom in of download tray showing a notification that a dangerous file was blocked from being downloaded.



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.


Image of the Downloads settings menu in Chrome browser when you can select the option to disable showing downloads when they're done.



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.


Posted by Joshua Cruz, Communications Manager