1799880 - Unable to login on garena.com with Standard ETP

Status: ASSIGNED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Calin Tanase]

Attachment: garena.png

Environment:
Operating system: Android 11 (OnePlus 6 A6000)
Firefox version: Nightly 108.0a1-20221108094235

Preconditions:
• Account created
• ETP set to Standard
• Clean profile

Steps to reproduce:

1. Go to https://authgop.garena.com/oauth/login?client_id=10017&redirect_uri=https%3A%2F%2Fshop.garena.ph%2Fapp%2F100082&response_type=token&platform=1&locale=en-PH&theme=white
2. Login with your account.
3. Observe the behaviour.

Expected Behaviour:
Account login is possible.

Actual Behaviour:
Account login is not possible, error message displayed "Please enable cookie, refresh the page and try again".

Notes:

1. Reproducible on both Firefox Beta and Nightly with Standard ETP
2. Same behaviour in Private
3. Switching between ON/OFF the ETP might fix the issue

Comment 1

[Tim Huang[:timhuang]]

We block js.datadome.co as a fingerprinter which causes this breakage.

Comment 2

[Paul Zühlcke [:pbz]]

Haven't had time to look into this yet. Keeping the NI. Thanks Tim!

Comment 3

[Neha Kochar [:neha]]

Also reproducible on Desktop on Mac using Nightly 109.

Comment 4

[Paul Zühlcke [:pbz]]

I can reproduce on Ubuntu too.
https://js.datadome.co/tags.js is blocked which is used in the registration step. Tom, do you think this is shim-able? The script is rather cryptic.

Comment 5

[Paul Zühlcke [:pbz]]

Anyhow, I don't think this is particularly urgent. A workaround is disabling ETP for the site using the toggle in the protections panel.

Comment 6

[[e-mail]]

With help from @twisniewski we found this chunk of code related to data dome in their index.html:
<!--for datadome -->
<script>
!function(a, b, c, d, e, f) {
a.ddjskey = e;
a.ddoptions = f || null;
var m = b.createElement(c)
, n = b.getElementsByTagName(c)[0];
m.async = 1,
m.src = d,
n.parentNode.insertBefore(m, n)
}(window, document, "script", "https://js.datadome.co/tags.js", "AE3F04AD3F0D3A462481A337485081");
</script>

This is loading the script. and based on that the script is probably going to read window.ddjskey and window.ddoptions

The tags.js which we are trying to shim is reading window.ddoptions, but the script is uglified so it's not clear what resource call is causing this issue.

Should we just allowlist this one or should we reach out to disconnect to reclassify or something else?

Comment 7

[[e-mail]]

Follow-Up:

There is an xhr_tags.js script which is setting a datadome cookie. Tom confirmed spoofing the cookie blocks the user so we suspect they are relying on the script sending them a cookie value to compare against server-side.

Since it is Captcha comparing across endpoints (one blocked, one not blocked potentially with other complications) the next question becomes "is datadome.co a fingerprinter worth blocking?"

Otherwise the best we can probably do is eventually let smartblock detect this case and offer something like "it looks like this site is using a Captcha, would you like to allow only that (rather than unblocking all potential trackers)"

Comment 8

[[e-mail]]

@PBZ provided a related disconnect bug covering a similar issue and the request to reclassify as content:
https://github.com/disconnectme/disconnect-tracking-protection/issues/306

Comment 9

[[e-mail]]

I have emailed Disconnect about potentially reclassifying the tracker though I agree it is a fingerprinting tracker and should remain as such. I have also notified garena.com of the issue and am awaiting response

Comment 10

[[e-mail]]

Patrick from disconnect confirmed it's classified correctly so balls in garena's Court