When trying to sign into my Google account, I see: """ This browser or app may not be secure. Learn more https://support.google.com/accounts/answer/7675428?hl=en Try using a different browser. If you’re already using a supported browser, you can try again to sign in. """ Hopefully they are just looking at our user agent header, and we can add a quirk as usual.
More context: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/157 https://lists.webkit.org/pipermail/webkit-dev/2020-November/031604.html
(In reply to Michael Catanzaro from comment #0) > Hopefully they are just looking at our user agent header Looks like we're blocked even if we send a Chrome UA. I'll keep trying stuff, but we might be screwed.
macOS quirk works, so they are simply discriminating based on UA header, as usual. However, limiting the quirk to accounts.google.com does not work. I'll continue to investigate. I think last time we had to send the quirk to youtube.com or something that seemed strange and unrelated in order to make logins work, but youtube.com doesn't seem to be involved this time around.
(In reply to Michael Catanzaro from comment #3) > macOS quirk works, so they are simply discriminating based on UA header, as > usual. Um, sorry... this is not true. It worked for me only by coincidence after I hacked WebKit to use the macOS quirk for all requests. So there is nothing we can do with UA quirks. Google is doing some deeper level of fingerprinting to block WebKitGTK.
Created attachment 458768 [details] Screenshot/proof
I had no problem to try 3 times to login with the latest Epiphany TP and my account.
(In reply to Fujii Hironori from comment #6) > I had no problem to try 3 times to login with the latest Epiphany TP and my > account. Hmmm, interesting, it actually works for me too in Tech Preview. But my devel build does not work at all. Biggest difference is HTTP/2 (my devel build uses libsoup 3) vs. HTTP/1 (Tech Preview is stuck on libsoup 2). But who knows what the difference is.
(In reply to Michael Catanzaro from comment #7) > But my devel build does not work at all. Biggest difference is HTTP/2 (my > devel build uses libsoup 3) vs. HTTP/1 (Tech Preview is stuck on libsoup 2). > But who knows what the difference is. HTTP/1.1 vs. HTTP/2 is not the problem. I'm blocked either way. But I did find a solution: clear cookies. I guess it stored a cookie to decide to permablock me. Lovely. What I don't know is why it did this.
Unfortunately I'm not able to figure out how to get Google to block me again. Maybe they already rolled back whatever change happened here? Or maybe they are doing some alpha/beta testing, and I deleted the cookie that had me in the test group? I've not noticed users complaining yet, so maybe it's not an emergency after all?
(In reply to Michael Catanzaro from comment #7) > Hmmm, interesting, it actually works for me too in Tech Preview. Now I'm blocked in Tech Preview too. I think they are indeed alpha/beta testing whether to block us or not. I don't think we can solve this by any technical means, since we don't know what basis they are using to block us. My wild guess would be TLS handshake fingerprinting, but who knows. We need to pursue nontechnical resolutions with Google.
(In reply to Michael Catanzaro from comment #10) > Now I'm blocked in Tech Preview too. I think they are indeed alpha/beta > testing whether to block us or not. I'm still blocked in Tech Preview. I will avoid clearing website data to ensure that I remain blocked for now, so that we remain able to reproduce.
One more thing: I've noticed some users complaining that they're getting blocked from signing in via gnome-online-accounts, so I don't think this only affects me, or only Epiphany. I don't have references, though. I'll keep any eye out so that I can save a link next time I notice somebody complaining about this.
Trying to a few data points, in case it helps... I cannot manage to get myself blocked (meaning: I can log-in), tested with the following * Ephy 42.2 + WebKitGTK 2.36.1, existing profile dir * Ephy 42.2 + WebKitGTK 2.36.1, new (empty) profile dir * Ephy 42.2 + WebKitGTK almost ToT (r293886), empty profile dir * Ephy TP, empty profile dir In case it may be related, this was testing with an account that has a custom domain, and I get the login pages in Finnish language, not in English. (FWIW, but unrelated: this has always which annoying because I do not want to get Finnish content when going to gmail.com or google.com; for that I would have chosen google.fi 🤷️)
(In reply to Michael Catanzaro from comment #11) > I'm still blocked in Tech Preview. I will avoid clearing website data to > ensure that I remain blocked for now, so that we remain able to reproduce. Err, now I am mysteriously no longer blocked in Tech Preview anymore. We remain bamboozled. Adrian just managed to get himself blocked, though, so at least it's no longer just me. I expect he will provide more details shortly.
(In reply to Adrian Perez from comment #13) > Trying to a few data points, in case it helps... I cannot manage to > get myself blocked (meaning: I can log-in), tested with the following > > * Ephy 42.2 + WebKitGTK 2.36.1, existing profile dir > * Ephy 42.2 + WebKitGTK 2.36.1, new (empty) profile dir > * Ephy 42.2 + WebKitGTK almost ToT (r293886), empty profile dir > * Ephy TP, empty profile dir > > In case it may be related, this was testing with an account that has > a custom domain, and I get the login pages in Finnish language, not > in English. (FWIW, but unrelated: this has always which annoying > because I do not want to get Finnish content when going to gmail.com > or google.com; for that I would have chosen google.fi 🤷️) Using a regular @gmail.com account, and switching the GMail language to en_US indeed I got blocked, using Ephy TP, but not with Ephy installed from distribution packages. One difference here between distro packages and TP is that Arch Linux is nowadays building WebKitGTK with soup3 and it supports HTTP/2, while the TP build in Flatpak AFAIR still uses soup3 (and has no HTTP/2 support). I tried setting SOUP_FORCE_HTTP1=1 in the environment and then Ephy 42.2 with WebKitGTK 2.36.1 _also_ got blocked. In this case using the “Try Again” button worked. Last but not least, one more comment: to switch from Finnish to English-US I need to choose the language *twice*, first in the login entry page, which redirects to https://www.google.com/gmail/about/, then clicking the “Sign In” button shows the login entry page *in Finnish again*, and choosing English-US a second time stays in the same page but finally in English. No idea if this can be some related symptom.
Per my email to webkit-dev@ on this topic, I'm still finding the appropriate team to discuss this issue with. This is my first experience navigating these login issues, so please bear with me. At the same time, let me please point to this help article, which colleagues on the Chrome team suggested: https://support.google.com/accounts/answer/7675428 The important thing to notice: embedded browsers are disallowed from signing in to Google accounts. See the mention of Chromium Embedded Framework at the end of the article. This was an intentional security measure instituted to prevent third-party applications from interposing on sign-in. I don't think this is a new security measure - it's been in place for at least a couple of years. Unfortunately, WebKitGTK as a library falls within this categorization. I'm still discussing with colleagues how the system Epiphany browser, based on WebKitGTK, interacts with this policy. Will update this bug with more information as I learn it.
(In reply to Kenneth Russell from comment #16) > I'm still discussing with colleagues how the system Epiphany browser, based > on WebKitGTK, interacts with this policy. Will update this bug with more > information as I learn it. Note there is no difference between WebKit in a web browser like Epiphany vs. WebKit in an embedded web view widget. Detecting such a difference would be impossible.
Update: I have not been blocked anymore since Monday. Somebody at Google is still investigating to see what went wrong, so leaving this bug open for now.
(In reply to Michael Catanzaro from comment #18) > Update: I have not been blocked anymore since Monday. Spoke too soon. Blocked again now. Maybe it blocks me when it sees that I have signed out and then attempted to sign into the same account again in a short period of time? I left a comment on https://bugs.chromium.org/p/angleproject/issues/detail?id=7288, then signed out, then realized I should have offered to test the change locally before it gets merged. But I cannot sign in again, because my browser "this browser or app may not be secure," even though it worked fine ten minutes ago....
Oh, there's actually a Try Again button that I can use to bypass the warning! It's not a hard block, just a soft block. That said, it is unacceptable for this to ever be displayed to someone using the latest version of an upstream WebKit port, at least unless Google is able to identify a specific technical deficiency that we can fix. I will leave this bug open.
This should probably be fixed now by changes on Google's side. Please reopen if you see this again.