User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20171002220106 Steps to reproduce: Log on https://discordapp.com/ (this a web app for chatting), erase cookies, cache, local storage, restart Firefox (normal or safe mode, doesn't matter). Actual results: Still logged on https://discordapp.com/ Expected results: https://discordapp.com/ should have forgotten me. Tried in private browsing, it's not remembering me This raise some questions: - how this website is still able to identify me ? - Is there some sort of "super" or "hidden" cookies (in IndexedDB ?) ? - Is this a bug in Firefox, or discordapp.com is using fingerprinting ? Confirmed by an other user on Nightly/Win10, see here: https://www.reddit.com/r/firefox/comments/76zrwb/how_httpsdiscordappcom_is_remembering_me/

Solved: when on https://discordapp.com/ F12 -> Storage -> then I removed everything. This should really be cleaned when we remove the cookies/local storage though, using dev tools is not very intuitive for the average user.

This doesn't reproduce for me. How are you clearing the history? Could you try it again? 1. Log into discord. 2. Close that tab 3. Clear Recent History (Ctrl-Shift-Delete). Select everything, check every box, Clear now. 4. Restart the browser 5. See if you are still logged in. Thanks!

Yes, That's working, but I don't want to lose my history, only the local data for this domain (that should be done automatically with Cookie AutoDelete by obviously this is not working).

I am surprised you can't reproduce, for me it's 100% reproducible, and an other user (see Reddit thread) says it's the same on Nightly.

So what method are you using for clearing the cookies that doesn't work?

The cookie manager of Firefox (and Cookie AutoDelete extension but it's irrelevant here because it's still the case without it). If I remove cookies from discordapp.com and discord.gg I'm still logged, so as I already explained, it seems "hidden" cookie or something else is still present. It works if I remove all cookies, but obviously I don't want that because I keep a dozen of cookies from the sites i want to stay logged. Don't you have seen the gif in the first post ?

I'd try a safe more or a clean profile to eliminate settings and addons. I can see a lot of addon buttons in the tool bar, some of them could interfere.

As stated in the first post, I've already tried.

[STR] 1. login to https://discordapp.com/ and close the tab 2. Go to about:preferences#privacy -> Site Data -> Settings, select "discordapp.com", click "Remove Selected", then click "Save Changes" 3. A warning dialog shows up and click "Remove" 4. open https://discordapp.com/ [Expected Behavior] on top-right corner there is a button shows "Login", click it will redirect to login page [Actual Behavior] on top-right corner it shows "Open", click it will redirect to chat window without login As mentioned in comment #1, removing the local storage via Storage Panel in devtool will really clean up the login data for that website. (Steps: open devtool in the tab of discordapp.com -> go to the "Storage" Panel -> expand "Local Storage" -> right click "https://discordapp.com/" entry -> click "Delete All") Apparently this website is using local storage instead of cookie to keep the login information. The real issue I see here is that removing site data from about:preferences#privacy doesn't remove the local storage as well. I found https://searchfox.org/mozilla-central/rev/091894faeac5b54b7e40b0a304c3d3268f7b645d/browser/components/preferences/SiteDataManager.jsm#87 says that this functionality is not done yet. Re-assign component to "Core::DOM" since both dependent bugs are in that component.

> The real issue I see here is that removing site data from > about:preferences#privacy doesn't remove the local storage as well. Exactly, the user will think everything is "cleaned", but actually no.

Thanks SC! I think this is related to bug 599724.

Is this issue supposed to be covered/fixed in bug 1047098 according to this line http://searchfox.org/mozilla-central/source/browser/base/content/sanitize.js#297 ?

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #12) > Is this issue supposed to be covered/fixed in bug 1047098 according to this > line > http://searchfox.org/mozilla-central/source/browser/base/content/sanitize. > js#297 ? about:preferences does not use sanitize.js but http://searchfox.org/mozilla-central/source/browser/components/preferences/SiteDataManager.jsm#236 There are 2 issues here: 1. if a website uses just localStorage, it doesn't appear in the list of sites with data. This happens because of: http://searchfox.org/mozilla-central/source/browser/components/preferences/SiteDataManager.jsm#87-89 2. We don't cleanup localStorage because it's not part of QuotaManager yet. In sanitize.js we cleanup all the localStorage data ignoring the time range. Here we could do something similar. Or, better, implement a subset of bug 1252998 doing: Services.obs.notifyObservers(null, "browser:purge-domain-data", principal.URI.host);

Should we try to get this into 57?

Absolutely. Patch is ready.

[Tracking Requested - why for this release]: We should clear this data when the user asks for it to be cleared.

Comment on attachment 8921516 [details] [diff] [review] notify.patch asuth, do you mind to take a look at this 1-line patch?

Comment on attachment 8921516 [details] [diff] [review] notify.patch Review of attachment 8921516 [details] [diff] [review]: ----------------------------------------------------------------- Restating: From my analysis in https://public.etherpad-mozilla.org/p/data-clearing-apis (search on "browser:purge-domain-data") we expect this to clear: - localStorage for the host - sessionStorage for the host - ServiceWorkers for the host, but just ending up as a single RemoveAndPropagate(domain) call, it lacks the undocumented principal equivalence logic in _removeServiceWorkers (That I guess tries to nuking SW's if they're only registered for other OriginAttribute partitions? That's weird.) - session store (tab persistence, including SessionStorage persistence) for the host This does mean that the call to _removeServiceWorkers will end up being sorta redundant, modulo the weirdness. But it should be idempotently safe.

(In reply to Andrew Sutherland [:asuth] from comment #19) > That I guess tries to nuking > SW's if they're only registered for other OriginAttribute partitions? > That's weird.) dropped word: tries to *avoid* nuking.

Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6019c89b317d Cleaning data per domain, must delete localStorage data, r=asuth

Privacy leak - please nominate this for Beta approval ASAP.

Comment on attachment 8921516 [details] [diff] [review] notify.patch Approval Request Comment [Feature/Bug causing the regression]: SiteDataManager.jsm [User impact if declined]: localStorage data is not deleted [Is this code covered by automated tests?]: no [Has the fix been verified in Nightly?]: yes. manually... [Needs manual test from QE? If yes, steps to reproduce]: follow the description of the bug [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: none [Why is the change risky/not risky?]: this patch sends a notification in order to purge a localStorage domain data. This notification is already used elsewhere in the codebase but not here. [String changes made/needed]: none

Comment on attachment 8921516 [details] [diff] [review] notify.patch Fix for privacy issue, let's uplift for beta 12.

Tracking just to make sure we get this into 57.

Thank you all.

I've tried to reproduce the issue on Firefox Nightly (2017-10-17), under Windows 10x64 and using the STR from Comment 0 and from Comment 9 without success, since the discordapp.com is not displayed in about:preferences#privacy -> Site Data -> Settings. Also I've tried to reproduce the issue using a HTML page, received from Andrea Marchesini [:baku], also without success. On latest builds, Firefox 57.0b14 and on Firefox 58.0a1 (2017-11-08) the issue is also not reproducible using both, STR form comments above and the test plan received from Andrea. Note that the issue can be tested using the attached HTML page, by opening it, and clicking on the 'click me' button. The same no. is displayed, no matter how many times the button is clicked, until Clearing All Data from about:preferences#privacy -> Site Data section and clicking the button again. Thanks Andrea for your help. Please let me know if I can help any further with this issue. Taking in consideration that I was not able to reproduce the issue on the affected build, but it's also not reproducible on latest builds, I'm marking this bug as WORKSFORME.