Beginning in M86, Chrome will warn users when they try to complete forms on secure (HTTPS) pages that are submitted insecurely. These “mixed forms” (forms on HTTPS sites that do not submit on HTTPS) are a risk to users’ security and privacy. Information submitted on these forms can be visible to eavesdroppers, allowing malicious parties to read or change sensitive form data. 

Specifically, Chrome will be making the following changes to communicate the risks associated with mixed form submission:

• Autofill will be disabled on mixed forms.
  Note: On mixed forms with login and password prompts, Chrome’s password manager will continue to work. Chrome’s  password manager helps users input unique passwords, and it is safer to use unique passwords even on forms that are submitted insecurely, than to reuse passwords.

• When a user begins filling out a mixed form, they will see warning text alerting them that the form is not secure.

          

• If a user tries to submit a mixed form, they will see a full page warning alerting them of the potential risk and confirming if they’d like to submit anyway.

Before M86, mixed forms were only marked by removing the lock icon from the address bar. We saw that users found this experience unclear and it did not effectively communicate the risks associated with submitting data in insecure forms.

On today’s web, URLs remain the primary way users determine the identity and authenticity of a site, yet we know URLs suffer from usability challenges. For example: there are myriad ways that attackers can manipulate URLs to confuse users about a website’s identity, which leads to rampant phishing, social engineering, and scams. In one study, more than 60% of users were fooled when a misleading brand name appeared in a URL’s path.

Different browsers approach this challenge in a number of ways, including showing only the domain by default, or visually highlighting the registrable domain (the “most significant” part of the domain name). In Chrome 86, we’re likewise going to experiment with how URLs are shown in the address bar on desktop platforms (animation below). Our goal is to understand -- through real-world usage -- whether showing URLs this way helps users realize they’re visiting a malicious website, and protects them from phishing and social engineering attacks.

An experiment in Chrome 86 shows the domain name by default and full URL on hover

Prefer to see the full URL?

If you find yourself in the experimental group, and you’d like to view the full URL for a given site, you’ll have two options. First you can hover over the URL, and it will expand fully. Second, you can right-click on the URL, and choose “Always show full URLs” in the context menu (screenshot below); enabling this setting will show the full URL for all future sites you visit. (Notably: Enterprise-enrolled devices won’t be included in this Chrome 86 experiment.)

A setting in the context menu allows you to always show full URLs in the address bar

We welcome your feedback!

If you’re not randomly assigned to this Chrome 86 experiment, and you’d like to try it out, please install Chrome Canary or Dev channel, open chrome://flags in Chrome 86, enable the following flags, and re-launch Chrome:

• #omnibox-ui-reveal-steady-state-url-path-query-and-ref-on-hover

• #omnibox-ui-sometimes-elide-to-registrable-domain

• Optionally, #omnibox-ui-hide-steady-state-url-path-query-and-ref-on-interaction to show the full URL on page load until you interact with the page.