[webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks

Michael Catanzaro mcatanzaro at gnome.org
Tue Nov 17 10:42:25 PST 2020


Hi,

Today I received a Google Developers email with subject "[Action 
Required] Starting January 4, 2021, we will block all sign-ins to 
Google accounts from embedded browser frameworks." It linked to this 
Google blog post:

https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html

Summary: Google will attempt to block logins from "CEF-based apps and 
other non-supported browsers." Presumably "non-supported browsers" 
likely includes non-Safari WebKit, considering how much time I spend 
trying to develop user agent quirks to suppress Google's unsupported 
browser warnings on Gmail, Google Docs, etc. I guess we will find out 
on January 4.

Google says: "The browser must identify itself clearly in the 
User-Agent. The browser must not try to impersonate another browser 
like Chrome or Firefox." We cannot comply with this because user agent 
spoofing is required for compatibility with various Google websites. I 
am continually fighting to maintain our user agent quirks for Google 
domains, see e.g. [1] or [2]. Even if we were to remove all user agent 
quirks, it would still be impossible for Google to distinguish between 
a desktop browser and an embedded browser framework, since the user 
agent header is going to be the same: Epiphany doesn't even append 
"Epiphany" anymore, in order to maximize the chances that websites will 
treat us like Safari. Even if we did, there are many other WebKit-based 
browsers that would be impacted (off the top of my head: eolie, surf, 
etc.)

So we'll see what happens on January 4. If our users get locked out of 
google.com, I'll try to come up with new quirks if possible, but if 
Google is really determined to block non-Safari WebKit, it will win. 
E.g. it's easy to do JS feature detection (scary) or TLS handshake 
fingerprinting (extremely scary) and see we are not really the browser 
that our user agent quirk claims to be. We are largely toothless here, 
unfortunately. If Google continues to discriminate solely on the basis 
of the user agent header, and doesn't adopt any more advanced 
discrimination mechanisms, then we will survive, although it would help 
if Apple is willing to take a hard stance and adopt the same set of 
cross-platform quirks in Safari, which would "work" by causing Safari 
to break in the same way as non-Safari WebKit... probably not very 
palatable, but if adopted well in advance of this Jan 4 flag date, it 
would at least make it *harder* for Google to hurt non-Safari WebKit. 
(Adopting the quirks *after* the flag date would likely just 
immediately break Safari.)

But if Google does this properly and uses more sophisticated browser 
fingerprinting techniques, Epiphany is done for. This could be an 
existential threat for non-Safari WebKit browsers. Nobody is going to 
be interested in using a browser that doesn't support Google websites. 
Google's expressly-stated goal is to block embedded browser frameworks 
and non-supported browsers from signing into Google accounts. The blog 
post says: "This block affects CEF-based apps and other non-supported 
browsers." It says: "We do not allow sign-in from browsers based on 
frameworks like CEF or Embedded Internet Explorer." Clearly CEF is the 
main target, but I guess WebKit (and likely also QtWebEngine) is at 
risk too; even if we're not mentioned directly, it seems pretty clear 
that WebKitGTK, WPE, PlayStation and WinCairo ports, etc. are all 
likely non-grata.

So what should WebKit do about this? I don't know. Nothing has happened 
yet, so I guess we could wait and see what happens on January 4. Maybe 
this won't affect us at all. But my fear is that January 4 will arrive, 
we will be blocked, and more user agent quirks may or may not work. 
Even if WebKit is not blocked, we can be confident January 4 will be a 
sad day for browser diversity. I wonder if this is something that 
WebKit as a project could push back against... somehow. Maybe publish a 
statement supporting browsers based on embedded frameworks (WebKit, 
CEF, QtWebEngine)? Or some new WebKit project policy? Any suggestions?

Michael

[1] 
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/UserAgentQuirks.cpp?rev=269908
[2] https://bugs.webkit.org/show_bug.cgi?id=215845




More information about the webkit-dev mailing list