Re: [webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
On Tue, Nov 17, 2020 at 3:22 pm, Maciej Stachowiak wrote: This sounds obnoxious and potentially anti-competitive. But I think it’s restricted to OAuth flows, which would indeed only affect other sites that allow the user to sign in with their Google account. So that would be the thing to test. I tested oauth login this using my hacked-up ResourceRequestBase with gnome-online-accounts... and it still worked fine. So assuming the behavior on January 4 matches the behavior when we send this test header today, we should be OK... at least for now. I'm still rattled. The statement of intent is pretty clear: anything that's not a major browser is illegitimate and may be blocked. There's not really any significant technical reason to block CEF but not WebKit, after all. It's probably only a matter of time ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
This sounds obnoxious and potentially anti-competitive. But I think it’s
restricted to OAuth flows, which would indeed only affect other sites that
allow the user to sign in with their Google account. So that would be the thing
to test.
> On Nov 17, 2020, at 12:20 PM, Michael Catanzaro via webkit-dev
> wrote:
>
> On Tue, Nov 17, 2020 at 12:50 pm, Michael Catanzaro
> wrote:
>> Oh, I missed a very important point. There is a header we can use to test:
>> Google-Accounts-Check-OAuth-Login:true. I will try to figure out how to hack
>> up the libsoup backend to send that header with all requests and see what
>> happens
>
> I tested this hack:
>
> diff --git a/Source/WebCore/platform/network/HTTPHeaderNames.in
> b/Source/WebCore/platform/network/HTTPHeaderNames.in
> index cbc470412f9f..eb19ab00a054 100644
> --- a/Source/WebCore/platform/network/HTTPHeaderNames.in
> +++ b/Source/WebCore/platform/network/HTTPHeaderNames.in
> @@ -109,3 +109,5 @@ X-Temp-Tablet
> // These headers are specific to GStreamer.
> Icy-MetaInt
> Icy-Metadata
> +
> +Google-Accounts-Check-OAuth-Login
> diff --git a/Source/WebCore/platform/network/ResourceRequestBase.h
> b/Source/WebCore/platform/network/ResourceRequestBase.h
> index 6c9ce5cccefe..db234c37271f 100644
> --- a/Source/WebCore/platform/network/ResourceRequestBase.h
> +++ b/Source/WebCore/platform/network/ResourceRequestBase.h
> @@ -206,6 +206,7 @@ protected:
>, m_hiddenFromInspector(false)
>, m_isTopSite(false)
>{
> + addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin, "true");
>}
>
>ResourceRequestBase(const URL& url, ResourceRequestCachePolicy policy)
> @@ -221,6 +222,7 @@ protected:
>, m_hiddenFromInspector(false)
>, m_isTopSite(false)
>{
> + addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin, "true");
>}
>
>void updatePlatformRequest(HTTPBodyUpdatePolicy =
> HTTPBodyUpdatePolicy::DoNotUpdateHTTPBody) const;
>
>
> And confirmed in the web inspector to ensure the header is really sent. Login
> still works. So... maybe we will be OK? I'm not sure. I tested direct login
> via google.com. I'm confused as to how this change is in any way related to
> OAuth. Maybe it will only break for third-party websites that allow logging
> in with a Google account? I guess we'll find out
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
On Tue, Nov 17, 2020 at 12:50 pm, Michael Catanzaro
wrote:
Oh, I missed a very important point. There is a header we can use to
test: Google-Accounts-Check-OAuth-Login:true. I will try to figure
out how to hack up the libsoup backend to send that header with all
requests and see what happens
I tested this hack:
diff --git a/Source/WebCore/platform/network/HTTPHeaderNames.in
b/Source/WebCore/platform/network/HTTPHeaderNames.in
index cbc470412f9f..eb19ab00a054 100644
--- a/Source/WebCore/platform/network/HTTPHeaderNames.in
+++ b/Source/WebCore/platform/network/HTTPHeaderNames.in
@@ -109,3 +109,5 @@ X-Temp-Tablet
// These headers are specific to GStreamer.
Icy-MetaInt
Icy-Metadata
+
+Google-Accounts-Check-OAuth-Login
diff --git a/Source/WebCore/platform/network/ResourceRequestBase.h
b/Source/WebCore/platform/network/ResourceRequestBase.h
index 6c9ce5cccefe..db234c37271f 100644
--- a/Source/WebCore/platform/network/ResourceRequestBase.h
+++ b/Source/WebCore/platform/network/ResourceRequestBase.h
@@ -206,6 +206,7 @@ protected:
, m_hiddenFromInspector(false)
, m_isTopSite(false)
{
+ addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin,
"true");
}
ResourceRequestBase(const URL& url, ResourceRequestCachePolicy
policy)
@@ -221,6 +222,7 @@ protected:
, m_hiddenFromInspector(false)
, m_isTopSite(false)
{
+ addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin,
"true");
}
void updatePlatformRequest(HTTPBodyUpdatePolicy =
HTTPBodyUpdatePolicy::DoNotUpdateHTTPBody) const;
And confirmed in the web inspector to ensure the header is really sent.
Login still works. So... maybe we will be OK? I'm not sure. I tested
direct login via google.com. I'm confused as to how this change is in
any way related to OAuth. Maybe it will only break for third-party
websites that allow logging in with a Google account? I guess we'll
find out
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
Oh, I missed a very important point. There is a header we can use to test: Google-Accounts-Check-OAuth-Login:true. I will try to figure out how to hack up the libsoup backend to send that header with all requests and see what happens ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
