Discord uses local storage in some way that hides from "manage cookies and site data"
Categories
(Firefox :: Settings UI, defect, P3)
Tracking
()
People
(Reporter: yumpusamongus, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
-
Log in to a Discord account.
-
Go to about:preferences#privacy -> Manage Data...
-
Type "discord" in the search box.
-
Remove All Shown, confirm.
-
Refresh the Discord tab.
Actual results:
Discord account is still logged in.
Expected results:
Discord account should be fully logged out and all discord-related state discarded. To Discord's, server, this should be completely indistinguishable from a newly-created Firefox profile that has never visited the Discord website before.
|
Reporter | |
Comment 1•5 years ago
|
||
Further information: This is likely caused by whatever malware technique(s) Discord is using to discourage third-party clients. The thing they're doing is probably a fully-general way of hiding tracking cookies from the browser UI. I feel that Firefox should be able to protect its users from this form of malware. Perhaps persistent data objects could be tagged with whatever URL was in the bar when they were created, so that they would show up in the search?
The particular user story here is that my browser somehow got logged into a guest Discord account rather than my normal account, and I ended up having to use Google to figure out how to log out through their blackhat UI.
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
Hey ewright, is this something your team would be interested in looking into? It sounds like Discord has found a creative way to "mark" a browser that's immune to clearing site data.
|
||
Comment 3•5 years ago
|
||
I'm very interested in this but I don't think we can prioritize it right now. I'll add it to the backlog...
|
||
Updated•5 years ago
|
I can confirm that this malware (which is quite an apt name) is certainly based on cookies. It is not based on IP or fingerprinting to my knowledge (based on changing my IP, window size, extension list, resolution). I've spent the last hour or so going through their minifed JS and trying out different things, and my results are below, maybe you can help me narrow it further.
- The console logs an object that has the structure:
{ "tokenManagerHasToken": <bool>, "storageHasToken": <bool>}. The latter is certainly the local storage/session storage based on how this value changes, but I'm not sure what the token manager is. - The behavior specified in the original bug report is true when the cookies blocked in the privacy prefs is "Cross site and social media trackers", but when "All cookies" are blocked, reloading yields the expected behavior. "All third-party cookies" also yields the expected behavior, and "Cookies from unvisited websites" yields the faulty behavior.
I want to help with this issue because I believe it's a serious privacy breach. Users who are deleting website data do so believing that sessions are cleared.
|
||
Comment 5•4 years ago
|
||
(In reply to Rahul from comment #4)
I want to help with this issue because I believe it's a serious privacy breach. Users who are deleting website data do so believing that sessions are cleared
What happens if you
- use a new profile or clear everything (Ctrl-Shift-Del, all time, tick everything)
- enable LSNG (
dom.storage.next_gen) =true - restart the browser
- retest
Discord relies on token field on localStorage for auth, that field gets read and kept in-memory. I can confirm that by manually triggering beforeunload event that Discord tries to set the token field again.
One part of why this is happening is because their desktop app would remove the token field when DevTools is opened, which is their attempt on preventing token leakage from innocent users being misled to open it.
Firefox should kill the tab before clearing cookies/data. Then perhaps reload the page. The problem is allowing a "cleared" page to continue executing after the clear action.
|
||
Comment 9•3 years ago
|
||
It seems expected behavior that a still open page can store its data.
And what is if you close Discord, open about:preferences#privacy and then delete all discord.com data?
Partly-offtopic: I would consider it a design failure that one can't use the detailed Devtools WebStorage UI from about:preferences#privacy for closed websites.
|
||
Comment 10•3 years ago
|
||
(In reply to Darkspirit from comment #9)
And what is if you close Discord, open about:preferences#privacy and then delete all discord.com data?
If that approach clears out local storage then you'd be logged out of Discord.
|
|
||
Comment 11•3 years ago
|
||
Thanks for investigating this, we can close as a duplicate of bug 1543052. I agree that we should suggest closing open tabs when clearing data, but we currently don't have the resources to tackle this.
Description
•