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:
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.
Modern browsers with security updates will continue to be supported.
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:
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:
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.
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:
accounts.google.com
Google-Accounts-Check-OAuth-Login:true
The following example details how to disable the allowlist in CEF.
Note: You can add your custom headers in CefRequestHandler#OnBeforeResourceLoad.
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
See our previous blog post about protection against man-in-the-middle phishing attacks.
Good morning! Only one minute to go until Darin Fisher, VP of Chrome kick's off this year's keynote at Chrome Dev Summit 2016. Join us as we take a look at the latest web advancements with over 20 sessions presented by Chrome engineers. We're live streaming all sessions and posting videos throughout the next two days.
Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Team
Security has always been critical to the web, but challenges involved in site migration have inhibited HTTPS adoption for several years. In the interest of a safer web for all, at Google we've worked alongside many others across the online ecosystem to better understand and address these challenges, resulting in real change. A web with ubiquitous HTTPS is not the distant future. It's happening now, with secure browsing becoming standard for users of Chrome.
Today, we're adding a new section to the HTTPS Report Card in our Transparency Report that includes data on how HTTPS usage has been increasing over time. More than half of pages loaded and two-thirds of total time spent by Chrome desktop users occur via HTTPS, and we expect these metrics to continue their strong upward trajectory.
Percentage pages loaded over HTTPS in Chrome
As the remainder of the web transitions to HTTPS, we'll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications, and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP.
As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we've posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance.
We've seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented "we were able to migrate Wayfair.com to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS." CNET, a large tech news site, had a similar experience. "We successfully completed our move of CNET.com to HTTPS last month," said John Sherwood, Vice President of Engineering & Technology at CNET. "Since then, there has been no change in our Google rankings or Google organic search traffic."
Webmasters that include ads on their sites also carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post, "saw no material impact to AdX revenue with the transition to SSL."
As migrating to HTTPS becomes even easier, we'll continue working towards a web that's secure by default. Don't hesitate to start planning your HTTPS migration today!
Roy Glasberg, Global Lead, Launchpad and Launchpad Accelerator
Last month, the second cohort of Launchpad Accelerator, Google’s high-touch global program for late-stage startups, came and conquered their app challenges with the help of mentors at Google HQ.
What did they learn that they’d like to share with developers across the world? Check out the video below for solutions from 3 different startups, and an in-depth review of MagicPin’s mobile web challenge and solution.
Startup:
MagicPin from India is a social network app that curates a local user base around locations, allowing merchants to connect with these specific audiences.
Mobile web challenge:
In India, downloading an app requires a high commitment. On average a user would keep 5 or 6 apps on their phone. According to Anshoo Sharma, Co-Founder and CEO, MagicPin, “If you want to be the next app that they download, there is a high barrier.”
Jordan Adler, Google Developer Advocate: “Devices in markets like India have limited space--on average 128 MB of memory--and when you add in system features only 40 bytes of user space is left. And if a typical APK is a few megabytes, you can only have a few apps before you have to stop downloading.”
Solution:
Jordan Adler: “One of the great things about Progressive Web Apps is you don’t have to request the commitment (to download an app) upfront. You can start to build a relationship with the user through the web interface, and over time the web app can become more like a native app, it can be housed on a device, cache content and work offline.”
Anshoo Sharma: “In the last 1.5 weeks we have been here we have already launched a micro version of our platform on Progressive Web Apps. And the experience is great! Without using the (mobile) app people can get as good an experience.”
About Launchpad Accelerator
Launchpad Accelerator is a six-month accelerator that enables late-stage app startups from emerging markets to successfully scale. Here's a two-minute video about the Accelerator.
Originally Posted on Chromium Blog
Originally posted on Google Chromium Blog
