Showing posts with label chrome. Show all posts

Guidance to developers affected by our effort to block less secure browsers and applications

Posted by Lillan Marie Agerup, Product Manager

We are always working to improve security protections of Google accounts. Our security systems automatically detect, alert and help protect our users against a range of security threats. One form of phishing, known as “man-in-the-middle”, is hard to detect when an embedded browser framework (e.g., Chromium Embedded Framework - CEF) or another automation platform is being used for authentication. MITM presents an authentication flow on these platforms and intercepts the communications between a user and Google to gather the user’s credentials (including the second factor in some cases) and sign in. To protect our users from these types of attacks Google Account sign-ins from all embedded frameworks will be blocked starting on January 4, 2021. This block affects CEF-based apps and other non-supported browsers.

To minimize the disruption of service to our partners, we are providing this information to help developers set up OAuth 2.0 flows in supported user-agents. The information in this document outlines the following:

  • How to enable sign-in on your embedded framework-based apps using browser-based OAuth 2.0 flows.
  • How to test for compatibility.

Apps that use embedded frameworks

If you're an app developer and use CEF or other clients for authorization on devices, use browser-based OAuth 2.0 flows. Alternatively, you can use a compatible full native browser for sign-in.

For limited-input device applications, such as applications that do not have access to a browser or have limited input capabilities, use limited-input device OAuth 2.0 flows.

Browsers

Modern browsers with security updates will continue to be supported.

Browser standards

The browser must have JavaScript enabled. For more details, see our previous blog post.

The browser must not proxy or alter the network communication. Your browser must not do any of the following:

  • Server-side rendering
  • HTTPS proxy
  • Replay requests
  • Rewrite HTTP headers

The browser must have a reasonably complete implementation of web standards and browser features. You must confirm that your browser does not contain any of the following:

  • Headless browsers
  • Node.js
  • Text-based browsers

The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox.

The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins. We do not allow sign-in from browsers based on frameworks like CEF or Embedded Internet Explorer.

Test for compatibility

If you're a developer that currently uses CEF for sign-in, be aware that support for this type of authentication ends on January 4, 2021. To verify whether you'll be affected by the change, test your application for compatibility. To test your application, add a specific HTTP header and value to disable the allowlist. The following steps explain how to disable the allowlist:

  1. Go to where you send requests to accounts.google.com.
  2. Add Google-Accounts-Check-OAuth-Login:true to your HTTP request headers.

The following example details how to disable the allowlist in CEF.

Note: You can add your custom headers in CefRequestHandler#OnBeforeResourceLoad.

    CefRequest::HeaderMap hdrMap;
    request->GetHeaderMap(hdrMap);
    hdrMap.insert(std::make_pair("Google-Accounts-Check-OAuth-Login", "true"));

To test manually in Chrome, use ModHeader to set the header. The header enables the changes for that particular request.

Setting the header using ModHeader

Related content

See our previous blog post about protection against man-in-the-middle phishing attacks.

Highlighting great user experiences on the mobile web

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”. 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.

Helping people spot the spoofs: a URL experiment

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