Impossible to log in to Twitch

[ruihildt]

trafficstars

When using the Mullvad browser, I am unable to log in as it states it is unsupported.

On their website they say to contact the browsers support team for issues related to non-supported browsers and as I could not find this issue being discussed elsewhere on the web I figured I'd email you to make you aware.

Your browser is not currently supported. Please use a recommended browser or learn more here.

[Thorin-Oakenpants]

https://bugzilla.mozilla.org/show_bug.cgi?id=1835987

twitch has always had issues: sometimes it was the mismatched OS in the HTTP header (on linux/mac we report windows), sometimes it was the version in the userAgent (but we no longer spoof that), sometimes it's just twitch being twitch (and users had to clear any site storage), but everyone can agree that it's something in RFP.

Seems from testing per target it is the TZ "spoofing"

[ruihildt]

So theoretically, if I set privacy.resistFingerprinting to falseand restart, you should be able to login to Twitch to Mullvad Browser?

WARNING!!!

Doing this completely defeats the privacy model of Mullvad Browser, don't do this! This question is just for debugging purposes.

[Thorin-Oakenpants]

That's what others have done at arkenfox (note we sanitize on close but AF users can retain site data via site exceptions since we're not in PB Mode - thus no need to login in each session) - i.e they flip RFP, reload and login, and then flip RFP back on

RFP is a global switch and you get can/will get weird behavior/results unless you reload sites - it's not meant to be a toggle, that's what the targets are for. And flipping it will affect every other open window/tab

• so yeah ... DON'T DO THIS

if you really need twitch, until and if we can ever resolve this, I suggest you just watch it in a secondary browser, you know, like Firefox - which has partitioning etc, and you're already logging in so it's not a huge deal

[ruihildt]

Do you think it's because UTC is used? Would using a timezone that actually exist (for example one of the country that uses GMT all year long) would solve the bug and be an acceptable choice to make?

[Thorin-Oakenpants]

I'm still a little wary of that result, but only because I didn't do the testing :) There's elements such as clearing all site data, or perhaps a flagged IP for extra scrutiny, that could effect the result.

I'd like to see someone set their system TZ to ~~UTC0~~ UTC and try and login on Firefox with a new profile (no extensions or pref flips)

---

Would using a timezone that actually exist

Well, UTC exists :) It's right there in the standards. If this is the actual cause then it smacks of overzealous anti-bot protection and discrimination against TB to be honest

UTC is unique (well, along with Factory), so there is no direct substitute

• https://arkenfox.github.io/TZP/tests/timezones.html
• 

It's the only one that is consistent all year round. Note this is using gecko's supported timezones (supportedValuesOf).

If I uncheck that option then we get a larger set that match

• 

But as I said, these aren't "supported" (outside of Factory) in gecko (I assume FF will just report what the OS says), and none are "supported" in chrome for example. So again, they will just stick out, IIUIC, and get flagged again when the bot catches up.

You could always test if GMT works (I don't have a twitch account), but I think it's a losing cause

@tomrittervg

---

sidenote: if we restrict dates to say 2000+ (so we allow for some backwards compat for calendars) then the diffs fall away and we have these matching in supportedValuesOf (most differences are due to old-timey changes)

Africa/Abidjan
Africa/Accra
Africa/Bamako
Africa/Banjul
Africa/Bissau
Africa/Conakry
Africa/Dakar
Africa/Freetown
Africa/Lome
Africa/Monrovia
Africa/Nouakchott
Africa/Ouagadougou
Africa/Timbuktu
America/Danmarkshavn
Atlantic/Reykjavik
Atlantic/St_Helena
Factory
UTC

So a case could be made to be Atlantic/Reykjavik for all users, for example - it ~~would~~ edit wouldn't (send coffee) really affect 99.9% of use cases different to UTC - edit: to be clear, I mean most users are looking at today's date/time or recent/upcoming dates (e.g. in their calendar or sporting events etc) - so "old-timey" pre-2000 dates would be rarely used this way (for time precision)

[Thorin-Oakenpants]

Atlantic/Reykjavik is also supported in chrome ... good lord, we might inadvertently unleash twitch hell on Iceland if we did this and no-one wants that :-(

[ruihildt]

I meant exist, as being a recognizable named timezone. :)

Which arguably would be impossible to use a blocking parameter, since a whole "legitimate" named timezone would be blocked. It would be worth it if it was to defeat some bots which uses UTC by default.

But if they purposefully block Tor Browser, then it's no use indeed.

[Thorin-Oakenpants]

The reason for UTC is it's stable all year round, so users can always work out their real time from +/- from UTC. But I doubt any OS uses UTC or GMT for that matter as their TZ, so there is no solution short of using some thing like Atlantic/Reykjavik or - Africa/Dakar` ... which are used, so yes, I get your point

I will see at what point in time any of those differed:

OK, these

• Africa/Abidjan, Africa/Accra, Africa/Bamako, Africa/Banjul, Africa/Conakry, Africa/Dakar, Africa/Freetown, Africa/Lome, Africa/Nouakchott, Africa/Ouagadougou, Africa/Timbuktu, Atlantic/Reykjavik, Atlantic/St_Helena
• ^ are identical to UTC except before 1912, where they differ by 16.133333 minutes

[Thorin-Oakenpants]

so I would argue that yes we could use one of these instead and it wouldn't make any difference to today's usage of UTC, but it may be confusing to users - depends how a website shows dates/times

[ruihildt]

So I tested if the timezone was the only discriminating factor, by testing those two scenarios:

• Test 1: creating a new Firefox profile (Developer Edition, so 115.0b5) on Fedora 38, connection without VPN, passing the UTC timezone to the Firefox process at launch time (See: https://stackoverflow.com/a/26100074)
• Test 2: creating a new separate profile, using my default system timezone

(I also checked the timezone was indeed UTC in Test 1.)

And...I was blocked in Test 1 but not in Test 2.^^"

[Thorin-Oakenpants]

So this looks promising. I took a 10 minutes break outside and put my evil hat on

• maybe they're also checking offsets? so maybe it's all the zeros - but I doubt they do that - scripts are not that complex
• this made me think
  • we could use any of those timezones I listed in https://github.com/mullvad/mullvad-browser/issues/96#issuecomment-1591669151
  • i.e we report the resolvedOptions.timeZone
    • we could even randomize it per eTLD+1 etc
  • but we use UTC under the hood, except that doesn;t really make any difference IMO since only < 1912 is affected and only by 16minutes
• I was also thinking about how this affects timezoneNames and locales: and I think it's OK because we set locale to match language which is equivalency
  • ^ this is covered under the deterministic TZP checks (still adding them in)

[Thorin-Oakenpants]

passing the UTC timezone to the Firefox process at launch time (See: https://stackoverflow.com/a/26100074)

In windows, I just change the TZ via system settings and restart FF :)

[Thorin-Oakenpants]

https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/189

[ruihildt]

I did a last test before moving on, and using Chromium with UTC timezone makes it also show the same error message. Without UTC it also works fine.

[Thorin-Oakenpants]

thanks, that pretty much confirms it's at least UTC - I wonder if it does the same with Factory or GMT etc, not that it matters

PS: it wouldn't surprise me if it was added BECAUSE of TB

[ruihildt]

It's probably UTC+Linux.

If GMT or another named timezone works, do you see a downside to try it for a specific release?

[Thorin-Oakenpants]

GMT is not a supportedValueOf in gecko so I'm not sure if that will affect anything, but otherwise it is an exact match for UTC. The problem is that it isn't used in real-world (IIUIC) so we will only end up in an arms race with the anti-bot script

Someone with a twitch account should check windows - I don't think it's linux (or mac) specific. Lots of ways to test that, but it doesn't matter because we should use the same TZ for all platforms for simplicity

[Thorin-Oakenpants]

both TZ and mismatched userAgent-vs-header are resolved in 13.5 - both of which "helped" cause twitch to throw hissy fits