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-l... 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/UserAge... [2] https://bugs.webkit.org/show_bug.cgi?id=215845