RESOLVED WONTFIX Bug 222039
[GTK] Remove all Google user agent quirks except for Google Docs
https://bugs.webkit.org/show_bug.cgi?id=222039
Summary [GTK] Remove all Google user agent quirks except for Google Docs
Michael Catanzaro
Reported 2021-02-17 07:17:28 PST
In bug #171941 I replaced our previous Google user agent quirks with a Linux x86_64 quirk, to deal with Google discriminating against non-Linux and non-x86_64 users. It's weird for a website to discriminate against *non-Linux* users, but Google was really doing it on multiple domains. FreeBSD users were not happy. Another problem was Google discriminating when the operating system ("Ubuntu", "Fedora") was included in the user agent. The Linux x86_64 quirk was added to address both issues by ensuring Google domains receive the most standard/vanilla user agent we could possibly send. That was nearly four years ago. I've been testing every major Google domain (Maps, Calendar, Gmail, Docs, Drive, YouTube) with FreeBSD and Fedora user agents. I've even tested removing "X11" from the user agent, which was previously required by Google Calendar and Google Maps. Even that works properly nowadays. So it seems Google has seriously improved its robustness to our user agent header, and we no longer need the Linux x86_64 quirk. Thank you Google. (Additional testing welcome, of course. It's very possible that I have missed something.) The one major exception is Google Docs, which still shows unsupported browser warnings. That now uses a Chrome browser quirk since bug #221845, which will be needed until Google Docs stops discriminating against WebKit users.
Attachments
Patch (6.38 KB, patch)
2021-02-17 07:51 PST, Michael Catanzaro
no flags
Michael Catanzaro
Comment 1 2021-02-17 07:45:09 PST
More things I've tested: replacing x86_64 with amd64 (used by FreeBSD) or aarch64 to ensure nondiscrimination against ARM users (some websites switch to mobile mode when they see ARM user agents). I've tried combining Fedora and FreeBSD into the same user agent. I've tried changing the operating system version to gibberish characters. At one point, I saw Google Maps fall back to a mobile interface, but I've tried several times to reproduce that with increasingly strange user agent strings and can't figure out how I managed that, so I think users will be fine.
Michael Catanzaro
Comment 2 2021-02-17 07:51:37 PST
EWS
Comment 3 2021-02-18 08:04:17 PST
commit-queue failed to commit attachment 420647 [details] to WebKit repository. To retry, please set cq+ flag again.
EWS
Comment 4 2021-02-18 10:58:30 PST
Committed r273084: <https://commits.webkit.org/r273084> All reviewed patches have been landed. Closing bug and clearing flags on attachment 420647 [details].
Michael Catanzaro
Comment 5 2021-03-08 06:29:59 PST
OK I messed up. It works with this user agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15 But drive.google.com and accounts.google.com both fail with this user agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15 Epiphany/605.1.15 I stopped sending the Epiphany version recently hoping it would improve web compat. It seems that it did indeed. The cost is that now I have to remember to add it back in order to test quirks, and I failed to do so when testing this. So the Linux desktop platform quirk is still needed for drive.google.com and accounts.google.com to override the browser's usual identification.
WebKit Commit Bot
Comment 6 2021-03-08 06:35:45 PST
Re-opened since this is blocked by bug 222905
Michael Catanzaro
Comment 7 2021-03-08 06:36:32 PST
WONTFIX for the time being. Should revisit in the future.
Michael Catanzaro
Comment 8 2021-03-08 06:47:52 PST
(In reply to Michael Catanzaro from comment #5) > So the Linux desktop platform quirk is still needed for > drive.google.com and accounts.google.com to override the browser's usual > identification. We could probably replace it with a quirk that simply removes the browser's identification. Faking the Linux desktop platform really seems to no longer be needed.
Michael Catanzaro
Comment 9 2021-03-09 08:33:02 PST
The adventure continues in bug #222978.
Note You need to log in before you can comment on or make changes to this bug.