Chromium Blog

An Update on the Lock Icon

Tuesday, May 2, 2023

Editor’s note: based on industry research (from Chrome and others), and the ubiquity of HTTPS, we will be replacing the lock icon in Chrome’s address bar with a new “tune” icon – both to emphasize that security should be the default state, and to make site settings more accessible. Read on to learn about this multi-year journey.

Browsers have shown a lock icon when a site loads over HTTPS since the early versions of Netscape in the 1990s. For the last decade, Chrome participated in a major initiative to increase HTTPS adoption on the web, and to help make the web secure by default. As late as 2013, only 14% of the Alexa Top 1M sites supported HTTPS. Today, however, HTTPS has become the norm and over 95% of page loads in Chrome on Windows are over a secure channel using HTTPS. This is great news for the ecosystem; it also creates an opportunity to re-evaluate how we signal security protections in the browser. In particular, the lock icon.

The lock icon is meant to indicate that the network connection is a secure channel between the browser and site and that the network connection cannot be tampered with or eavesdropped on by third parties, but it’s a remnant of an era where HTTPS was uncommon. HTTPS was originally so rare that at one point, Internet Explorer popped up an alert to users to notify them that the connection was secured by HTTPS, reminiscent of the “Everything’s Okay” alarm from The Simpsons. When HTTPS was rare, the lock icon drew attention to the additional protections provided by HTTPS. Today, this is no longer true, and HTTPS is the norm, not the exception, and we've been evolving Chrome accordingly.

For example: we know that the lock icon does not indicate website trustworthiness. We redesigned the lock icon in 2016 after our research showed that many users misunderstood what the icon conveyed. Despite our best efforts, our research in 2021 showed that only 11% of study participants correctly understood the precise meaning of the lock icon. This misunderstanding is not harmless — nearly all phishing sites use HTTPS, and therefore also display the lock icon. Misunderstandings are so pervasive that many organizations, including the FBI, publish explicit guidance that the lock icon is not an indicator of website safety.

When shown Chrome UI in research studies, users would look at the padlock to evaluate the trustworthiness of a hypothetical ecommerce site. We showed the site controls to experiment participants. The overlaid heat-maps represent the click patterns of respondents who were asked to indicate any information which was perceived helpful in the scenario.

The lock icon is currently a helpful entry point into site controls in Chrome. In 2021, we shared that we were experimenting with replacing the lock icon in Chrome with a more security-neutral entry point to site controls. We continued to mark HTTP as insecure in the URL bar. Users in the experiment opened the site controls more, and they didn't express any confusion that can follow major UI changes.

Site controls currently accessible from the lock icon.

Based on these research results from ourselves and others, and the broader shift towards HTTPS, we will be replacing the lock icon in Chrome with a variant of the tune icon. We think the tune icon:

Does not imply "trustworthy"
Is more obviously clickable
Is commonly associated with settings or other controls

We plan to replace the lock icon with a variant of the tune icon, which is commonly used to indicate controls and settings.

Replacing the lock icon with a neutral indicator prevents the misunderstanding that the lock icon is associated with the trustworthiness of a page, and emphasizes that security should be the default state in Chrome. Our research has also shown that many users never understood that clicking the lock icon showed important information and controls. We think the new icon helps make permission controls and additional security information more accessible, while avoiding the misunderstandings that plague the lock icon.

The new icon is scheduled to launch in Chrome 117, which releases in early September 2023, as part of a general design refresh for desktop platforms. Chrome will continue to alert users when their connection is not secure. You can see the new tune icon now in Chrome Canary if you enable Chrome Refresh 2023 at chrome://flags#chrome-refresh-2023, but keep in mind this flag enables work that is still actively in-progress and under development, and does not represent a final product.

Same page controls, new icon. The lock continues to exist as a precisely scoped entry point to connection security information, but with a new top-level access point.

We’ll be replacing the lock icon on Android at the same time as the broader desktop change. On iOS, the lock icon is not tappable, so we will be removing it entirely. On all platforms, we will continue to mark plaintext HTTP as insecure.

As HTTPS has become the norm, replacing the lock icon has long been a goal both of Chrome and the broader security community. We’re excited that HTTPS adoption has grown so much over the years, and that we’re finally able to safely take this step, and continue to move towards a web that is secure-by-default.

- By David Adrian, Serena Chen, Joe DeBlasio, Emily Stark, and Emanuel von Zezschwitz, and the rest of Chrome Trusty Transport from the Chrome Security team

More ways we’re making Chrome faster

Thursday, April 13, 2023

From the beginning of Chrome, one of our 4 founding principles has been speed, and it remains a core principle that guides our work. Today’s The Fast and the Curious post shares how recent technical improvements to Chrome have helped us reach a new performance milestone on the Speedometer browser benchmark across platforms.

Speed is a critical factor in determining your experience while browsing the Web. The faster the browser, the more enjoyable your browsing experience will be. With the latest release of Chrome, we went deep under the hood of Chrome’s engine to look for every opportunity to increase the speed and efficiency, from improved caching to better memory management.

Improved HTML Parsing & optimizing specific features

We discovered some targeted optimizations for the highly used JS `Object.prototype.toString` and `Array.prototype.join`functions. We also implemented targeted improvements in CSS’s InterpolableColor.

`innerHTML` is a very common way of updating the DOM via JavaScript so we added specialized fast paths for parsing. To our happy surprise, it seems some of this work will also be benefitting WebKit, which will include it in their engine as well. Our goal is always to create a better web experience for all web users so we’re happy to see this work having expanded impact!

More efficient pointer compression & allocations in V8 & Oilpan

Pointer compression is used to save memory in both V8 and Oilpan (the garbage collector for DOM objects). We made optimizations to how we compress and decompress pointers, and we avoid compressing high-traffic fields. Given how frequently these operations are done, it has a wide spread impact on performance. We also moved frequently accessed objects like JavaScript’s `undefined` to the beginning of the memory bases, allowing them to be accessed using faster machine code.

The improved features and efficient pointer compression collectively gave us a 10% increase in Apple’s Speedometer 2.1 browser benchmark over the course of three months.

Getting the Most out of High-End Mobile Devices

Chrome on Android has always been optimized for a small footprint, but the Android ecosystem is diverse and contains devices with varying levels of capabilities. To maximize the performance of Chrome on high-end devices, we are now targeting them with a version of Chrome that uses compiler flags tuned for speed rather than binary size.

For capable devices, these versions of Chrome run the Speedometer 2.1 benchmark 30% faster.

Posted by Thomas Nattestad, Senior Product Manager, and Andrew Grieve, Software Engineer

How WebAssembly is accelerating new web functionality

Monday, April 3, 2023

WebAssembly is fundamentally changing how new developer capabilities and functionality can be created on the web. In order to maintain browser interoperability, new web capabilities need to go through a rigorous standardization process and cross browser implementations. Decades of major investment has pushed the browser functionality to astonishing heights, but this process can take time and the web doesn’t need to have every capability built in. After years of investing in lower level capabilities that act as building blocks for higher level functionality, we are seeing a new dawn of expanded functionality at a dramatically expanded pace.

WebAssembly

WebAssembly is a portable bytecode format compiled from other languages to offer maximized performance. By leveraging WebAssembly, developers can take libraries and functionality from other platforms and performantly bring them to the web, without requiring any reimplementation. WebAssembly also offers advanced computation primitives like parallelizable threads and Single Instruction Multiple Data (SIMD) that enable it to maximize the performance from the CPU.

With WebAssembly offering portability plus performant access to the CPU the web now has the necessary low level building blocks for a huge variety of new functionality to be built. All of this, of course, rests on the incredible foundation that is the full web platform—full of powerful capabilities, rendering methods, and much more.

Real world examples

We’ve dedicated a whole blog post to showcasing just a small proportion of the new functionality being made available thanks to WebAssembly.

Some of these examples are functionality that tried to go through the standard process but didn’t make it for a variety of reasons. Other examples are being actively standardized and implemented across browsers.

FFMPEG on Wasm is enabling web apps to work effectively with videos. WebCodecs is a standardized alternative that offers similar encoding and decoding support, but it hasn’t been shipped across browsers yet.
WebAssembly powers background blurring for VC calls in Google Meet and there is now a dedicated standards proposal for this functionality
Web SQL was standardized and even shipped in Chrome for many years but never adopted sufficiently across browsers. SQLite on Wasm will replace Web SQL which will eventually be removed from Chrome.
Universal Scene Descriptor (USD) is shipping in Safari but isn’t available in other browsers.

Advantages of this new development paradigm

Faster iteration speed

Because functionality doesn’t have to go through standards and get approval before shipping, iteration cycles go from taking years down to days or even hours. Approaches like Origin Trials help enable more experimentation but still require weeks or months for iterations. When you change the iteration rate of something, you fundamentally change the thing itself.

Some fields like machine learning are advancing so fast that it is incredibly hard for standards-based approaches to keep up. By the time one design has gone through standardization and cross browser implementation, the field has moved on to something new which would have to go through the whole process again.

That being said, standardization is still essential for many things (see disadvantages section below) and when feasible, standardizing should absolutely be attempted.

Immediate support across browsers

Because wasm is supported across browsers, the functionality built on top of it will work across all browsers immediately as well. Interop and cross browser implementation of features is the biggest pain point for developers and by moving functionality to these lower level primitives, we’ll remove much of this concern.

Improved security

Because this functionality is built on top of incredibly hardened security sandboxes, there is substantially improved security compared to natively implemented APIs. Flash for example was removed from the web in large part because it was just too difficult to harden the complex plugin sufficiently, but now it can be run in WebAssembly, eliminating almost all security concerns.

Disadvantages and limitations

As with any new solution to complex problems, WebAssembly is not without disadvantages and limitations. Some of these are inherent and some have some promising solutions.

This won’t replace JavaScript for most web development

WebAssembly won’t replace JavaScript or make it obsolete, but rather extend its capabilities.

WebAssembly in the browser is still entirely dependent on JavaScript and needs to interface through JavaScript to access other web functionality. Libraries and new functionality enabled by WebAssembly will be utilized through JavaScript APIs. While there are some proposals that could enable wasm to wasm module communication and direct interfacing with Web APIs, this is still in the early stages of development.

Bundle size of pages

By moving more logic and functionality into userland, the size of pages will increase as well. This is a large problem as lower bundle size is the most important thing for a good user experience. As a result, developers should think carefully before ballooning their bundle size with this functionality, and it may be more relevant for larger web apps than smaller ecommerce or blog sites. This has long been an issue for JavaScript-heavy frameworks and is something where more solutions could be possible to improve the situation.

Another potential mitigation here is to look at the popular functionality being shipped in userland and use that as an input about what functionality should be standardized to ship with the browser itself. By being battle-hardened in userland, browsers will have higher confidence and validation on what they should ship, dramatically simplifying the standards and implementation work. WebCodecs replacing wasm compiled FFMPEG or the handwriting recognition API to replace the wasm compiled option are perfect examples of this.

Device capability access

WebAssembly and other primitives are largely computation mechanisms and don't give any kind of root system access to the OS or device itself. Functionality like hardware access (USB or Bluetooth), screen or window management, input controls, file system, clipboard, and much more still require platform level APIs to access. Chromium’s Fugu project is specifically aiming to enable all of these cases for Chromium-based browsers, but implementations across other browsers would still be needed here.

Conclusion

WebAssembly is already enabling new functionality in the browser, but more than that it represents a fundamentally new approach to how functionality gets developed. The best way to improve a thing is to improve how you improve it and then basking in second order growth. As with any new paradigm there are advantages and disadvantages, but overall this is a powerful new approach for browsers and developers everywhere. I can’t wait to see what we all build together with it.

By Thomas Nattestad, Product Manager - WebAssembly

Do more with Chrome on a single charge on MacBooks

Tuesday, February 28, 2023

From the beginning, we designed Chrome to be efficient. Being efficient is not just about loading pages as fast as possible, it’s also about doing it with the least amount of resources possible. Today’s The Fast and the Curious post explores how we improved Chrome to maximize battery life on Mac, so you can enjoy browsing and watching videos longer than ever before.

With the latest release of Chrome, we’ve made it possible to do more on your MacBook on a single charge thanks to a ton of optimizations under the hood. In our testing, we found that you can browse for 17 hours or watch YouTube for 18 hours on a MacBook Pro (13", M2, 2022). And with Chrome’s Energy Saver mode enabled, you can browse an additional 30 minutes on battery(1). Of course, we care deeply about all our users, not just those with the latest hardware. That’s why you’ll also see performance gains on older models as well.

Here’s a closer look at some of the changes we made:

Fine tuning iframes

We realized that many iframes live just a few seconds. As a result, we fine-tuned the garbage collection and memory compression heuristics for recently created iframes. This results in less energy consumed to reduce short-term memory usage (without impact on long-term memory usage).

Tweaking timers

Javascript timers were introduced at the beginning of the Web’s history. Since then, Web developers have access to more efficient APIs to achieve the same (or better!) results. But Javascript timers still drive a large proportion of a Web page’s power consumption. As a result, we tweaked the way they fire in Chrome to let the CPU wake up less often.

Similarly, we identified opportunities to cancel internal timers when they’re no longer needed, reducing the number of times that the CPU is woken up.

Streamlining data structures

We identified data structures in which there were frequent accesses with the same key and optimized their access pattern.

Eliminating unnecessary redraws

We navigated on real-world sites with a bot and identified Document Object Model (DOM) change patterns that don’t affect pixels on the screen. We modified Chrome to detect those early and bypass the unnecessary style, layout, paint, raster and gpu steps. We implemented similar optimizations for changes to the Chrome UI.

There’s always more work to be done. With the open-source benchmark suite, we’ll be able to tap the broader community of devs to help us to improve Chrome’s power consumption in 2023 and beyond.

Posted by François Doray, Software Developer, Chrome

___
1 Testing conducted in February 2023 using Chrome 110.0.5481.100 on a MacBook Pro (13”, M2, 2022 with 8 GB RAM running MacOS Ventura 13.2.1) and measured using our open-source benchmark suite.

Introducing passkeys in Chrome

Thursday, December 8, 2022

We announced in October that passkey support was available in Chrome Canary. Today, we are pleased to announce that passkey support is now available in Chrome Stable M108.

What are passkeys?

Passwords are typically the first line of defense in our digital lives. However, they are at risk of being phished, leaked in data breaches, and even suffering poor password hygiene. Google has long recognized these issues, which is why we have created defenses like 2-Step Verification and Google Password Manager.

To address these security threats in a simpler and more convenient way, we need to move towards passwordless authentication. This is where passkeys come in. Passkeys are a significantly safer replacement for passwords and other phishable authentication factors. They cannot be reused, don't leak in server breaches, and protect users from phishing attacks. Passkeys are built on industry standards, can work across different operating systems and browser ecosystems, and can be used with both websites and apps.

Using passkeys

You can use passkeys to sign into sites and apps that support them. Signing in with a passkey will require you to authenticate yourself in the same way that you unlock a device.

With the latest version of Chrome, we're enabling passkeys on Windows 11, macOS, and Android. On Android your passkeys will be securely synced through Google Password Manager or, in future versions of Android, any other password manager that supports passkeys.

Once you have a passkey saved on your device it can show up in autofill when you're signing in to help you be more secure.

On a desktop device you can also choose to use a passkey from your nearby mobile device and, since passkeys are built on industry standards, you can use either an Android or iOS device.

A passkey doesn't leave your mobile device when signing in like this. Only a securely generated code is exchanged with the site so, unlike a password, there's nothing that could be leaked.

To give you control over your passkeys, from Chrome M108 you will be able to manage your passkeys from within Chrome on Windows and macOS.

Enabling passkeys

For passkeys to work, developers need to build passkey support on their sites using the WebAuthn API. We’ve been working with others in the industry, especially Apple and Microsoft, members within the FIDO Alliance and the W3C to drive secure authentication standards for years.

Our goal is to keep you as safe as possible on the web and we’re excited for what the passkeys future holds. Enabling passkeys to be used in Chrome is a major milestone, but our work is not done. It will take time for this technology to be widely adopted across sites and we are working on enabling passkeys on iOS and Chrome OS. Passwords will continue to be part of our lives as we make this transition, so we’ll remain dedicated to making conventional sign-ins safer and easier through Google Password Manager.

Posted by Ali Sarraf, Product Manager, Chrome

Chromium Blog

An Update on the Lock Icon

More ways we’re making Chrome faster

How WebAssembly is accelerating new web functionality

Do more with Chrome on a single charge on MacBooks

Introducing passkeys in Chrome

Labels

Archive

Feed

May	JUN	Jul
	01
2022	2023	2024