Unable to login on garena.com with Standard ETP
Categories
(Core :: Privacy: Anti-Tracking, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox108 | --- | wontfix |
firefox109 | --- | fix-optional |
People
(Reporter: ctanase, Assigned: cboozarjomehri)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
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:
- 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
- Login with your account.
- 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:
- Reproducible on both Firefox Beta and Nightly with Standard ETP
- Same behaviour in Private
- Switching between ON/OFF the ETP might fix the issue
Comment 1•2 years ago
|
||
We block js.datadome.co
as a fingerprinter which causes this breakage.
Updated•2 years ago
|
Comment 2•2 years ago
|
||
Haven't had time to look into this yet. Keeping the NI. Thanks Tim!
Comment 3•2 years ago
|
||
Also reproducible on Desktop on Mac using Nightly 109.
Comment 4•2 years ago
|
||
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•2 years ago
|
||
Anyhow, I don't think this is particularly urgent. A workaround is disabling ETP for the site using the toggle in the protections panel.
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
|
||
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?
Assignee | ||
Comment 7•2 years ago
|
||
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)"
Assignee | ||
Comment 8•2 years ago
|
||
@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
Assignee | ||
Comment 9•2 years ago
|
||
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
Assignee | ||
Comment 10•2 years ago
|
||
Patrick from disconnect confirmed it's classified correctly so balls in garena's Court
Updated•2 years ago
|
Updated•2 years ago
|
Description
•