1401542 - Storage Inspector state retains deleted Cookies and Indexed DB databases

Status: NEW

(DevTools :: Storage Inspector, defect, P3)

Description

[Christiane Ruetten [INACTIVE]]

STR:
- Create fresh profile
- Go to http://cr.23bit.net/idb.html
- Reload a few times to accumulate visit timestamps in Indexed DB
- Open Storage Inspector (Shift-F9)
- Select website under Cookies and click "+" (below "Debugger") to add a few random cookies
- Select website under Local Storage and click "+" to add some random data
- Select website under Session Storage and click "+" to add some random data
- Go to about:preferences#privacy and click `Site Data / Clear All Data`, then `Clear Now`
- Go back to Storage Inspector and re-open (or use refresh button) to update its view

Expected result:
- Data under Cookies is deleted
- Databases under Indexed DB are deleted
- Data under Local Storage is deleted
- Data under Session Storage is deleted

Actual result:
- Data under Cookies persists
- Database structure under Indexed DB persist, just all the rows are dropped.
- Data under Local Storage is deleted
- Data under Session Storage is deleted


This allow Websites to track users through persisting cookies, and also to use Indexed DB database names as a form of persistent super cookie, potentially circumventing cookie policies.

Comment 1

[Christiane Ruetten [INACTIVE]]

This is topically related to bug 1047098.

Comment 2

[Christiane Ruetten [INACTIVE]]

Whether or not this dialog should delete cookies, too, may be debatable (and I'd argue that as a user "Clear All Site Data" to a user means everything including cookies), but persisting the Indexed DB database structure is clearly a serious information leak. If a conscious decision is made that cookies should not be touched, the user should at least be made aware of what has and has not been deleted.

Comment 3

[Fischer [:Fischer]]

(In reply to Christiane Ruetten [:cr] from comment #0)
> STR:
> - Create fresh profile
> - Go to http://cr.23bit.net/idb.html
> - Reload a few times to accumulate visit timestamps in Indexed DB
> - Open Storage Inspector (Shift-F9)
> - Select website under Cookies and click "+" (below "Debugger") to add a few
> random cookies
> - Select website under Local Storage and click "+" to add some random data
> - Select website under Session Storage and click "+" to add some random data
> - Go to about:preferences#privacy and click `Site Data / Clear All Data`,
> then `Clear Now`
> - Go back to Storage Inspector and re-open (or use refresh button) to update
> its view
> 
> Expected result:
> - Data under Cookies is deleted
> - Databases under Indexed DB are deleted
> - Data under Local Storage is deleted
> - Data under Session Storage is deleted
> 
> Actual result:
> - Data under Cookies persists
After closing and opening Storage Inspector, I could observe no cookie.
Clicking the "refresh" button on Storage Inspector, cookies would not dissapear.
> - Database structure under Indexed DB persist, just all the rows are dropped.
The same case as Cookie.
Do you observe the same phenomenon? 
> - Data under Local Storage is deleted
> - Data under Session Storage is deleted
> 
> 
> This allow Websites to track users through persisting cookies, and also to
> use Indexed DB database names as a form of persistent super cookie,
> potentially circumventing cookie policies.

Comment 4

[Fischer [:Fischer]]

(In reply to Fischer [:Fischer] from comment #3)
> (In reply to Christiane Ruetten [:cr] from comment #0)
> > Actual result:
> > - Data under Cookies persists
> After closing and opening Storage Inspector, I could observe no cookie.
  To be clear, this means closing then opening the whole devtool panel
> Clicking the "refresh" button on Storage Inspector, cookies would not dissapear.

Comment 5

[Christiane Ruetten [INACTIVE]]

Thanks for digging deeper. You are correct. We may be looking at an artifact of Storage Inspector pertaining some storage state, and not an issue with cleaning the user profile. I got into the habit of using the new reload button in Storage Inspector instead of double-shift-F9 since I discovered it.

For further testing I amended my test JS to not just create the "SiteVisits" database, but also a randomly named one. So every time idb.html is reloaded, two databases are generated: `SiteVisits` and `Random-$RND`, both getting a timestamp written to in a table. Reloading the page now accumulates not just new rows in SiteVisits/site_visits, but also another fresh random database with a single table and timestamp inside.

I can confirm that after generating the data as described in STR,

- clicking `reload` buttons in Storage Inspector
  - persists Cookies
  - persists Indexed DB Database structure (not rows)
  - shows Local Storage clear
  - shows Session Storage clear

- closing and re-opening Storage Inspector (the old way)
  - shows Cookies clear
  - persists (some) Indexed DB Database structure (not rows)
  - shows Local Storage clear
  - shows Session Storage clear

That begs a few questions:

1. Why does Storage Inspector keep seeing those cookies until it is fully reloaded?

2. Why does Storage Inspector, despite full reloading, keep seeing the empty "SiteVisits", and the SiteVisits database only (with the random ones gone)

3. Is that SiteVisits remnant just in Storage Inspector's mind, or is it really still in the profile?

Comment 6

[Christiane Ruetten [INACTIVE]]

Testing with a patched Firefox 58 that clears all the data reveals that state persistence is likely happening in Dev Tools / Storage Inspector, so this is most likely not an issue with the UI code for Preferences / Site Data.