[go: up one dir, main page]

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
Labels: , ,

Custom Tabs is a browser feature, introduced by Chrome, that is now supported by most major browsers on Android. It gives apps more control over their web experience, and makes transitions between native and web content more seamless without having to resort to a WebView. Similar to when using the browser, users frequently want to share the content that is rendered inside the Custom Tabs.

Custom Tabs do not provide a default sharing experience and many apps don’t provide a way for users to share content at all. This results in a poor user experience where users must find the share action from the overflow menu in the browser. This action takes the user outside of the app and opens the link in the browser, resulting in decreased app engagement.

In Chrome 88 we're running an experiment to automatically add a default share action in certain scenarios. For example, where an app has not specified its own Action Button, we will display one in the top bar. Where a site has specified its own top bar Action Button, a default share action is added to the overflow menu.


A default Action Button that shares the URL is added to the top bar when the application doesn’t provide one.

What do I need to do to enable the new default share action button in?Nothing! The default Action Button will be automatically added to the application, as long as the application doesn’t set its own. Since this change will happen in the browser, it will be automatically applied to all apps using Custom Tabs.

Please note: this is a change in Chrome’s behavior and we hope other browsers will add similar functionality.


How can I opt-out from the share icon showing in my App?
Starting with androidx.browser version 1.3.0, developers can use the setShareState() method from the CustomTabsIntent.Builder to disable the default share:

val customTabsIntent = CustomTabsIntent.Builder()

        .setShareState(CustomTabsIntent.SHARE_STATE_OFF)

        .build();


As part of this change, the addDefaultShareMenuItem() and setDefaultShareMenuItemEnabled() methods from CustomTabsIntent.Builder have been deprecated and developers should use setShareState() instead.


If your application uses Custom Tabs, we’d like to hear your feedback, and you can reach out to us using this form.


Posted by André Bandarra, Developer Relations Engineer and Chirag Desai, Product Manager

Labels: , , ,


Last year we announced a new initiative (known as Privacy Sandbox) to develop a set of open standards to fundamentally enhance privacy on the web. With Privacy Sandbox we’ve been exploring privacy-preserving mechanisms with the web community that protect user data and prevent intrusive cross-site tracking. Our aim is to preserve the vitality of the open web by continuing to enable the rich, quality content and services that people expect, but with even stronger guarantees of privacy and safety. Today we’re sharing progress on this long-term initiative and asking for your continued help in increasing the privacy of web browsing.

In January we shared our intent to develop privacy-preserving open-standards that will render third-party cookies obsolete. Since then, Google and others have proposed several new APIs to address use cases like fraud protection, ad selection, and conversion measurement without allowing users’ activity to be tracked across websites. Following web community input, some of these solutions are now available for experimental testing via Chrome origin trials:
  • Click Conversion Measurement API opened up for testing in September and aims to enable marketers to know whether an ad click resulted in a conversion (for example, a purchase or a sign-up) on another site, without connecting the identity of the user across both sites.
  • Trust Tokens opened up for testing in July and is intended to support a number of use cases evaluating a user’s authenticity, including combating fraud.

If you integrate APIs into your products and services, you can register for access to these and other APIs through Chrome origin trials. We encourage ecosystem stakeholders to participate and share their feedback and results. Developing and implementing web standards which change the core architecture of the web is a complex process, so we are taking a long-term, collaborative approach.


We’re also continuing our work to make current web technologies more secure and private.
  • Earlier this year Chrome started limiting cross-site tracking by treating cookies that don’t include a SameSite label as first-party only, and requiring cookies to be labeled and accessed over HTTPS in order to be available in third-party contexts. With this update — which Edge and Firefox are in the process of adopting — third-party cookies are no longer sent for the 99.9% of registered domains that do not require them, improving privacy and security for the vast majority of sites on the web.
  • In a release early next year, Chrome will also strengthen protection against additional types of network attacks that could hijack the users’ privileged credentials to perform malicious actions on their accounts. 

We’re also rolling out changes in Chrome to mitigate deceptive and intrusive tracking techniques, such as fingerprinting.
  • In September we rolled out an update to prevent inadvertent sharing of information such as users' names and access tokens. When users navigate from one site to another we are reducing the information from the originating page’s URL that is sent to the destination site by default.
  • Also in September, we extended support of Secure DNS in Chrome beyond desktop to Android. Secure DNS is designed to improve user safety and privacy while browsing the web by automatically switching to DNS-over-HTTPS if the user's current provider supports it.
  • Coming soon, we’re also closing the ability for a site to observe other sites that a user might have visited through caching mechanisms.

As always, we encourage you to give feedback on the web standards community proposals via GitHub and make sure they address your needs. And if they don’t, file issues through GitHub or email the W3C group. If you rely on the web for your business, please ensure your technology vendors engage in this process and that the trade groups who represent your interests are actively engaged.

We are appreciative of the continued engagement as we build a more trustworthy and sustainable web together. We will continue to keep everyone posted on the progress of efforts to increase the privacy of web browsing. 


Posted by Justin Schuh - Director, Chrome Engineering


Labels: , ,

Over the last decade, Chrome and the web development community have worked towards providing users with a fast, responsive and delightful browsing experience. Features like <link rel=preload> and native lazy-loading, to name but a few, are helping pages meet this mark. Historically, Chrome has also successfully encouraged the adoption of best-practices such as HTTPS by distinguishing secure from insecure browsing in Chrome's UI.



To help users identify great experiences as they browse, we are excited to announce that Chrome will begin to highlight high quality user experiences on the web, starting with the labelling of fast links via the link context menu on Chrome for Android. This change will be rolling out starting in Chrome 85 Beta.



Labelling is based on signals from the Core Web Vitals metrics that quantify key aspects of users’ experience, as experienced by real-world Chrome users. The Core Web Vitals metrics measure dimensions of web usability such as loading time, responsiveness, and the stability of content as it loads, and define thresholds for these metrics to set a bar for providing a good user experience. 



The changes that site owners make to improve on these aspects work towards making the web more delightful for users across all web browsers. Investing in these critical user-centric metrics helps to drive usability improvements for users and helps businesses see increased engagement.



Links to pages that have historically met or exceeded all metrics thresholds for the Core Web Vitals will be displayed with a new “Fast page” label. This is shown when a user long-presses a link prior to navigating to a page, and it indicates that most users navigating to it have a particularly good experience.




"Fast page" labelling may badge a link as fast if the URL (or URLs like it) have been historically fast for other users. When labelling, historical data from a site’s URLs with similar structure are aggregated together. Historical data is evaluated on a host-by-host basis when the URL data is insufficient to assess speed or is unavailable, for example, when the URL is new or less popular.



Our plan is to maintain alignment with Core Web Vitals as they evolve, so that we are always labeling pages that have optimized against the metrics that are most representative of a user's overall experience. As previously noted, developers should expect the definitions and thresholds of the Core Web Vitals to be stable, and updates to have prior notice and a predictable, annual cadence.



We anticipate that optimizing for the Core Web Vitals may require some investments in improving page quality. To help out, we updated our developer tools to surface information and recommendations: Lighthouse, DevTools, PageSpeed Insights, and Search Console team added a report dedicated to Core Web Vitals too.





Labelling is currently being rolled out to Chrome 85 beta, but if you would like to try labelling today, go to chrome://flags and enable “Context menu performance info and remote hint fetching”. Please note, this flag will only be available on Chrome for Android. Once fully rolled out, users will see labelling if they have Lite mode or “Make Searches and Browsing Better” turned on. Next, navigate to any qualifying page, such as the Wikipedia page for the Internet, and long-press on any link. 



We believe the web serves a critical role in our lives, and hope that fast labelling proves helpful to users who are on slow or spotty network connections. Over time, we may also experiment with labelling in other parts of Chrome’s UI. Ultimately, our goal is to provide users of the web with a healthy level of transparency into the experience they may have with a page. 



Chrome is committed to working with the ecosystem to ensure a thriving web, and the steps we take, such as the ones outlined above, are designed with these goals in mind.



By Addy Osmani, Ben Greenstein and Josh Simmons, fast page fans.
Labels: , , ,

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.


Thanks in advance for your thoughts! You can file bugs or feature requests on our bug tracker.



Posted by Emily Stark, Eric Mill, Shweta Panditrao, Chrome Security Team
Labels: ,

Last week, my calendar was constantly alerting me to the fact that many of us would be gathering at Google I/O, and it definitely made me sad that we can’t be together in person right now! We have been so impressed with the role that web developers have played in these trying times, as they focus on the fundamentals, make sure critical information is available, that commerce can come online, and that we can work and educate from home. Kudos to you all.
We want to help.
So, we’re planning a three day digital event - web.dev LIVE - where web developers can come together, from the comfort of their homes to hear about the latest, most helpful updates to the platform, learn modern web techniques and to connect with other developers — including those who are pushing the community forward and have been on the front line with COVID related work.


The event will take place from June 30th to July 2nd and will include short three-hour content streams (in English) hosted on web.dev/live.

Reaching you where you are. In your time zone.


Planning a completely digital event has been an interesting challenge. While we can’t bring everyone together physically, we can still bring great content straight to your couch, kitchen or hammock-in-the-backyard. A digital event also gives us the opportunity to break out of physical constraints. We are no longer limited by space for attendance, and anyone, literally anywhere in the world, can “join” us at the click of a button (Oh and we, as part of the web community, should be proud of making that happen. Everyday!)

To really make this a regionally inclusive event, we will “travel” to three different time zones so we can answer your questions real-time, in your active hours. Each day will have unique content so you’re welcome to join us on all three days or watch the content on demand later, but developers in any timezone will have the team actively answering questions at least once through the event.

When will the event be live each day?
We have a ton of great content and fun stuff in store for you, so head to web.dev/live and sign up to get notified about the event.


Posted by Dion Almaer, Karaoke Lead for the Web Ecosystem


Labels: , , , , ,



With Chrome 83, we’ve started rolling out Secure DNS, a feature built on top of a secure DNS protocol called DNS-over-HTTPS, which is designed to improve your safety and privacy while browsing the web. More concretely, Chrome will automatically switch to DNS-over-HTTPS if your current DNS provider supports it, and provide manual configuration options for users who wish to use a specific provider. DNS-over-HTTPS introduces a significant change to the Domain Name System (DNS), a system designed more than 35 years ago that is central to how the web works even to this day. It’s the sort of change that requires careful planning and collaboration, which explains why it took us a little more than 2 years, gathering test data, listening to feedback, and addressing some misconceptions, to arrive at a design that put our users first with reasonable defaults and accessible controls.



Unencrypted DNS


When you want to access your favorite website, your browser first needs to determine which server is hosting it, a step known as “DNS lookup”. When DNS was first introduced, the internet was in its infancy, and the web did not yet exist. There was no e-commerce, no online banks, and many people did not yet see a strong need for encryption on the web. It took until 1994 for encryption to take-off with the introduction of the HTTPS protocol. Nowadays, the HTTPS protocol is almost ubiquitous and provides strong security and privacy guarantees. It helps you browse or transact on the web without fear of having your credit card or personal information stolen by other internet users, even when using a public WiFi connection. Unfortunately, DNS, on the other hand, until recently has remained unencrypted.



With unencrypted DNS, an attacker connected to the same network can observe other users’ browsing habits.

Benefits of DNS-over-HTTPS

Chrome’s Secure DNS feature uses DNS-over-HTTPS to encrypt the DNS communication, thereby helping prevent attackers from observing what sites you visit or sending you to phishing websites. As the name suggests, Chrome communicates with the DNS service provider over the HTTPS protocol, the same protocol used for communicating with websites in a safe and secure manner. HTTPS is particularly appealing because it provides the following protections:
  • Authenticity: Chrome can verify that it is communicating with the intended DNS service provider and not a fake service provider that’s controlled by an attacker.
  • Integrity: Chrome can verify that the response it got from the DNS service provider hasn’t been tampered with by attackers using the same network, thereby stopping phishing attacks.
  • Confidentiality: Chrome can talk to the DNS service provider over an encrypted channel which means that attackers can no longer rely on DNS to observe which websites other users are visiting when sharing the same connection, e.g. public WiFi in a library.

With DNS-over-HTTPS, an attacker can no longer rely on DNS to observe other users’ browsing habits.



The introduction of DNS-over-HTTPS gives the whole ecosystem a rare opportunity to start from a clean and dependable slate, making it easier to pursue further enhancements relying on DNS as a delivery mechanism. Thus far, the unencrypted nature of DNS has meant that features that extend DNS could randomly fail due to causes such as network equipment that may drop or modify newly introduced DNS fields. As DNS-over-HTTPS grows, it will put this concern aside because it benefits from the aforementioned HTTPS properties and sets a new reliable baseline to build upon.


Responsibly deploying DNS-over-HTTPS

Changing how DNS works is a non-trivial task. In particular, with more than 35 years of history, a lot of additional services and features have been built on top of DNS. For instance, some Internet Service Providers offer family-safe filtering via DNS. So, while we would love to have everyone benefit from Secure DNS immediately, we also know that we have to get there in a way that doesn’t break user expectations. Navigating these goals led us to the “same-provider DNS-over-HTTPS upgrade” approach that we experimented with at the end of 2019. The successful experiment gave us confidence about the performance and stability aspects for both Chrome’s Secure DNS and our partners’ DNS-over-HTTPS services. It also highlighted opportunities to improve the auto-upgrade success rate.

Here is how this “same-provider DNS-over-HTTP upgrade” approach works. Chrome maintains a list of DNS providers known to support DNS-over-HTTPS. Chrome uses this list to match the user’s current DNS service provider with that provider’s DNS-over-HTTPS service, if the provider offers one. By keeping the user’s chosen provider, we can preserve any extra services offered by the DNS service provider, such as family-safe filtering, and therefore avoid breaking user expectations. Furthermore, if there’s any hiccup with the DNS-over-HTTPS connection, Chrome will fall back to the regular DNS service of the user’s current provider by default, in order to avoid any disruption, while periodically retrying to secure the DNS communication. Finally, to avoid an issue that otherwise could arise for users running Windows, Chrome will also disable Secure DNS if Windows parental controls are enabled, so that any filtering software that relies on a regular DNS connection can continue to work while we collaborate with the ecosystem on ways for Secure DNS to co-exist with these filtering solutions.


If you are an IT administrator, Chrome will disable Secure DNS if it detects a managed environment via the presence of one or more enterprise policies. We’ve also added new DNS-over-HTTPS enterprise policies to allow for a managed configuration of Secure DNS and encourage IT administrators to look into deploying DNS-over-HTTPS for their users.


We believe that our approach strikes a good balance between moving security & privacy forward and maintaining user expectations. However, if this default behavior doesn’t suit your needs, head over to Chrome’s settings and search for Secure DNS to configure it to your liking. For instance, you can disable the feature altogether, or configure it in a no-fallback mode by choosing a specific DNS-over-HTTPS service provider among a list of popular options or by specifying a custom provider.
As ISPs and DNS service providers make progress on their DNS-over-HTTPS services, we expect to support more options in future milestones via our DNS-over-HTTPS program.

Chrome’s Secure DNS will progressively be made available on Chrome OS, Windows and Mac OS with Android and Linux coming soon.



Onwards


While these are early days, we are proud of playing a role in the adoption of DNS-over-HTTPS and helping our users benefit from a safer and more private way of browsing the web. At the same time, we also understand how intricate DNS is, which is why we’ve been and will continue to move carefully and transparently. As always, we’re open to feedback and welcome collaboration with stakeholders including ISPs, DNS service providers, and Online Child Safety advocates as we make further progress in securing DNS.


Posted by Kenji Baheux, Chrome Product Manager


Labels: , , ,

Chrome has always focused on creating the best possible experience for people browsing the web. We have a long history of protecting our users from annoying and harmful experiences—like blocking pop-up windows and warning users if a page has malware. For the last few years, we’ve worked to address a common complaint among Chrome users: annoying, intrusive ads. In 2018, we started removing the ads from websites that continually show intrusive ads that violate industry standards. Google also updated our own advertising offerings to ensure that we’re not selling or serving the kinds of ads that Internet users find the most annoying. Since then, we’ve seen ad blocking rates in North America and Europe drop significantly in Chrome. 
In order to determine which ads are the most intrusive to web experience, we rely on the Better Ads Standards which give companies like Google guidance based on feedback from people around the world. 
Today, the group responsible for developing the Better Ads Standards, the Coalition for Better Ads, announced a new set of standards for ads that show during video content, based on research from 45,000 consumers worldwide. 
There are many different types of ads that can run before, during, or after a video but according to the Coalition’s research, there are three ad experiences that people find to be particularly disruptive on video content that is less than 8 minutes long: 
Image Source: Coalition for Better Ads

Long, non-skippable pre-roll ads or groups of ads longer than 31 seconds that appear before a video and that cannot be skipped within the first 5 seconds.

Image Source: Coalition for Better Ads

Mid-roll ads of any duration that appear in the middle of a video, interrupting the user’s experience.


Image Source: Coalition for Better Ads

Image or text ads that appear on top of a playing video and are in the middle 1/3 of the video player window or cover more than 20 percent of the video content.

Does this affect my video content? 
The Coalition has announced that website owners should stop showing these ads to their site visitors in the next four months. Following the Coalition’s lead, beginning August 5, 2020, Chrome will expand its user protections and stop showing all ads on sites in any country that repeatedly show these disruptive ads. It’s important to note that YouTube.com, like other websites with video content, will be reviewed for compliance with the Standards. Similar to the previous Better Ads Standards, we’ll update our product plans across our ad platforms, including YouTube, as a result of this standard, and leverage the research as a tool to help guide product development in the future.
If you operate a website that shows ads, you should consider reviewing your site status in the Ad Experience Report, a tool that helps publishers to understand if Chrome has identified any violating ad experiences on your site. Starting this week, we’ll update the Ad Experience Report with information to help publishers resolve any issues with these new video standards currently on their site. For more information about this process, you can reference the Help Center and Community Forum.


Posted by Jason James, Product Manager
Labels: , ,