UASwitcher.js ignored

[anonymous1184]

Related to #868

Screenshot:

I've tried to switch the UA, but is not working (any browser/OS combination yields the same UA).

• UA used: 80.0.3987.163
• UA reported: 80.0.3987.141

Regarding the original Google issue:

• Persists with or without content blocking enabled.
• AdGuard for Mac/Windows enabled/disabled.
• DNS filtering enabled/disabled.

[PalmerAL]

Are you editing the UASwitcher.js file directly in the package? If so, that won't work; instead, you need to clone the repository, edit the file, and then build a new package: https://github.com/minbrowser/min#building-binaries

It seems like in order to get Google signin to work, you need to use a Firefox user agent, and not just a different version of Chromium. I don't have any suggestions beyond that unfortunately; I spent a decent amount of time investigating this, and I wasn't able to determine why it's being blocked or how we could avoid it (but if you figure it out, let me know!)

[anonymous1184]

TL;DR

• In order to change the UA, Min needs to be re-built.
• Some Google accounts refuses to let users log (even with custom UA).

---

Fresh builds, UA set for Firefox (Windows then Linux), clean profile and nothing.

Same happens if I go full-paranoid with the "Stealth" options in AdGuard, UA is changed but Google refuses to let me access certain accounts.

Accounts have the same security settings: 2-FA (Authenticator, Google prompt and phone text/call). The only thing different in the accounts is the age, the first one is from the early days of the closed beta testing of GMail, others are from about 10 years or so.

I'm sad, I really enjoy this browser... but first was the issue with DRM, now this. Slowly big-ass companies are limitting options to users. Is frustrating.

[PalmerAL]

Did you make sure the Firefox UA was actually taking effect (try this)? For everyone else with this problem, switching the UA has worked, so it would be interesting if it didn't - although since we don't know how the detection works, it's entirely possible.

I agree it is frustrating.

[anonymous1184]

Yes, I checked if the UA was in effect and indeed it was for both builds. Funny thing is that I can log with IceCat, that leds me to think that maybe is not the UA what is being parsed, maybe is feature detection plus geolocation.

Since the good ol' days of IE6, ActiveX, Java applets... I never used UA parsing, always went with the feature testing to save a couple headaches. I remember that AdBlocking wasn't a thing and pretty much the defacto extension in those days were UA-switchers.

I cleaned up the build environment and the builds themselves, however I can go again and test with a few locations from my VPN (didn't think about it before). That will rule out UA and geolocation. Other testing should include a my old account, a new account; both with and without hardened security. But since its 4:56am and my friday deployment went kapum I don't think I can pull it before the next weekend. I'll update when I got the chance.

[PalmerAL]

Thanks for testing this out! Let me know what you find out.

The code for the sign-in page is so heavily obfuscated that it's really difficult to figure out what's happening. Once you enter your username, it makes a request to https://accounts.google.com/_/lookup/accountlookup, which either returns your account name or that the browser is blocked. However, even if I make all the request headers identical to Chrome, this will return success for Chrome and failure for Min. There's a deviceinfo property in the request, but that seems to be identical in both requests, so the difference must be somewhere else in the response, which is encoded using some kind of non-standard encoding. I guess at some point I'll dig through their JS more and see if I can find out where that's coming from.

[anonymous1184]

Related: #657, #868, #961, #962

I pulled an all nighter and finalized a full round of testing, as follows:

I've made sure to be logged out everywhere. Before setting a new location I manually disabled/enabled the network interface to avoid any keep-alive mechanism that could result in carrying over session data. Deleted Min profile folder and always used private mode.

• With/without hardened security: same results.
• 4 locations (US, Latam, East/West EU) same results.
• Old account and a brand new account: same results.

Meaning that Google is NOT checking geolocation or account security level. Its only User Agent (weird).

User agents:

• Latest Firefox: works.
• Latest Chromium Edge: works
• With Min/Electron version: works.
• Invalid UA (TAB char): half-assed*.
• Default (no Min and Electron versions, identical to Chrome): fails.

*GMail sends to HTML version, account settings cannot be accessed (see image). I guess a miriad of sites will simply break.

Image

Perhaps Google wants to avoid browsers spoofing its golden boy? IDK, the thing is that if UA is changed Google breaks, else, Yahoo does. What about considering again your first idea in #657? Stripping Min/Electron parts for the sites that break; something like this:

https://github.com/electron/electron/blob/v0.36.9/docs/api/session.md#seswebrequest

But if is an either/or situation... there's a lot more people using Gmail than Yahoo Mail. Just my 2c, nothing against YM users.

• March 2020: https://emailclientmarketshare.com/
• Whole 2019: https://litmus.com/blog/infographic-the-2019-email-client-market-share