IndexedDB - dom.indexedDB.enabled set to false doesn't work properly

UNCONFIRMED
Unassigned

Status

()

Core
DOM: IndexedDB
P5
normal
UNCONFIRMED
10 months ago
a month ago

People

(Reporter: duzopoh, Unassigned)

Tracking

50 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 months ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

Setting dom.indexedDB.enabled to false doesn't work properly. Some sites still store information to profile\storage\* folders. The sites don't work though, but that's not the issue here.

1) Set dom.indexedDB.enabled to false
2) Exit Firefox and delete all sites from the profile\storage\* folders (leave "chrome" and plugins DB's intact)
3) Start Firefox and load e.g. this online playable game http://www.chronerion.com/ceasing-to-be-her-demise/

You can also test this with netflix.com, mega.nz & google. All of them can save files to storage folder even if the IndexedDB is disabled.


Actual results:

After loading the online game page at http://www.chronerion.com/ceasing-to-be-her-demise/ the IndexedDB for that site is created as such:

profile\storage\temporary\http+++www.chronerion.com\.metadata   (1KB)
profile\storage\temporary\http+++www.chronerion.com\.metadata-v2   (1KB)
profile\storage\temporary\http+++www.chronerion.com\asmjs\metadata   (1KB)
profile\storage\temporary\http+++www.chronerion.com\asmjs\module15   (~85MB)


Google & Netflix create DB's in storage\default\ folder. Mega.nz to storage\temporary\.


Expected results:

No IndexedDB files should be created at all for the visited sites! Why is chronerion.com allowed to store ~85MB of files?


Is there a single Firefox developer/designer that would have end-users privacy in mind when implementing all kinds of new bells and whistles into Firefox?!

There's no way for the end-user to control IndexedDB, which is a yet another way for sites to track/fingerprint users.

And no, I won't "stop fiddling with about:config settings" until you Firefox developers start to take end-user privacy seriously and implement features to control all the myriad features that enable sites to undermine users privacy.

Updated

10 months ago
Component: Untriaged → DOM: IndexedDB
Product: Firefox → Core
profile/storage is managed by the quota manager subsystem, IndexedDB is just one of its clients.  See https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria#What_technologies_use_browser_data_storage and the rest of the article for some additional context.

In this case you're seeing the asm.js cache (which I think has been migrated to be built on IndexedDB in recent branches) client.  You'll also see quota manager storage used for sites using the DOM Cache API and Service Workers (which use the DOM Cache) API.

End-goal-wise, if you want to ensure sites don't use persistent storage, then you are likely better off using private browsing mode(s) because the (currently) non-quota-manager storage subsystems (ex: local storage, cookies) will also honor its guarantees.  If you desire persistence of some sites but also compartmentalization, the user contexts/containers effort may be of interest: https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers
(Reporter)

Comment 2

10 months ago
This is total & pure madness. So far I have tamed down everything else in Firefox that wants to use some kind of storage and thus allowing sites to fingerprint/track you. And now, again I found out about yet another method (asm.js) of sites to undermine users privacy with Firefox. The devs should be ashamed of the total mess they have done with implementing all new bells and whistles with no care for users privacy. Shame on you. Private browsing mode IS NOT an answer! FF needs to be more transparent and allow users to control ALL THE MYRIAD features that allow sites to fingerprint/track/whetever that undermines users privacy. This development ideology of not caring about users privacy has to stop. Orwell was an optimist. Little by little everything we humans do, we give away our privacy and one day we live in a totalitarian world.. if not already, but to a lesser degree. I'm appalled.

Comment 3

10 months ago
Hi duzopoh, Thanks for reporting this issue. I understand your frustration, but as comment 1 explains, the creation of data on disk is unreleated to the IDB API itself. Privacy of system information is best handled at the OS level - like by encrypting your hard disk so an nefarious third party can't see your actual file in your profile. Disabling IDB will prevent the API from working, but that should not prevent other parts of Firefox from working. I personally also think there's much we humans could/shall do to improve privacy protection; however speaking this specific issue, I'd say this bug is invalid according to the explanations above.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → INVALID
(Reporter)

Comment 4

10 months ago
Here we have a good example how Mozilla people doesn't understand AT ALL about end-users privacy!

"Privacy of system information is best handled at the OS level - like by encrypting your hard disk so an nefarious third party can't see your actual file in your profile."

If this is the level of understanding the problem.. I don't know what to say. Did it ever occur to you that privacy might also mean that websites couldn't track/fingerprint users?!?! Because this is what the IndexedDB/asm.js/cache/whatever **** enables them to do. It's yet another privacy hole, another "supercookie". AND FIREFOX USERS CAN'T CONTROL THIS STORAGE -> CAN'T CONTROL THEIR PRIVACY! Frankly, I'm DISGUSTED that you do not understand this at all. Though it explains why Firefox is so messy and not privacy friendly at all.

In order to protect my privacy, I had to create a recurring task with Windows Task Scheduler that empties all "storage\*" folders created by websites. How very convenient. Because Firefox isn't taking user security seriously.

If anybody is interested about this solution, here's the command I used for "action" in the task:

CMD /C FOR /F "delims=" %I IN ('DIR /AD /S /B "<FULL PATH TO YOUR FIREFOX _ROAMING_ PROFILE ROOT FOLDER>\storage\http*"') DO RD /S /Q "%I"

One can set it to trigger e.g. every 1 hour. It cleans out only storage created by websites ("http*"). Addon/chrome/etc. folders are untouched.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(In reply to duzopoh from comment #4)
> Here we have a good example how Mozilla people doesn't understand AT ALL
> about end-users privacy!

I kindly ask you to please keep a polite tone.    

> "Privacy of system information is best handled at the OS level - like by
> encrypting your hard disk so an nefarious third party can't see your actual
> file in your profile."
> 
> If this is the level of understanding the problem.. I don't know what to
> say. Did it ever occur to you that privacy might also mean that websites
> couldn't track/fingerprint users?!?!

dom.indexedDB.enabled = "false" disables the API, then what is the problem? 

> Because this is what the
> IndexedDB/asm.js/cache/whatever **** enables them to do. It's yet another
> privacy hole, another "supercookie". AND FIREFOX USERS CAN'T CONTROL THIS
> STORAGE -> CAN'T CONTROL THEIR PRIVACY! Frankly, I'm DISGUSTED that you do
> not understand this at all. Though it explains why Firefox is so messy and
> not privacy friendly at all.

The sites can't access those databases, only Firefox can. If the sites could, in fact, access those, then we would have a problem. Trying to access the API yields the following exception: 

```
InvalidStateError: A mutation operation was attempted on a database that did not allow mutations
```

So sites can't access the API. However, Firefox is free to use IDB internally for those sites if it wants to (what you seem to be seeing). That's not a violation of privacy - that's just caching.   

Have you seen sites bypass this somehow? If yes, then we would have a real security/privacy issue. 

> In order to protect my privacy, I had to create a recurring task with
> Windows Task Scheduler that empties all "storage\*" folders created by
> websites. How very convenient. Because Firefox isn't taking user security
> seriously.

It's not clear who you are trying to protect yourself from? If you are trying to protect yourself from sites using IDB, then setting the preference achieves this goal. If you are trying to prevent someone looking at your computer's cache, then you need to encrypt your hard disk.
(Reporter)

Comment 6

10 months ago
(In reply to Marcos Caceres [:marcosc] from comment #5)
> > "Privacy of system information is best handled at the OS level - like by
> > encrypting your hard disk so an nefarious third party can't see your actual
> > file in your profile."
> > 
> > If this is the level of understanding the problem.. I don't know what to
> > say. Did it ever occur to you that privacy might also mean that websites
> > couldn't track/fingerprint users?!?!
> 
> dom.indexedDB.enabled = "false" disables the API, then what is the problem? 

It doesn't disable asm.js and other caches Andrew Sutherland mentions in his 1st comment.

> > Because this is what the
> > IndexedDB/asm.js/cache/whatever **** enables them to do. It's yet another
> > privacy hole, another "supercookie". AND FIREFOX USERS CAN'T CONTROL THIS
> > STORAGE -> CAN'T CONTROL THEIR PRIVACY! Frankly, I'm DISGUSTED that you do
> > not understand this at all. Though it explains why Firefox is so messy and
> > not privacy friendly at all.
> 
> The sites can't access those databases, only Firefox can. If the sites
> could, in fact, access those, then we would have a problem.

Here's a test site: http://tokkamobile.fi/tk2.html 

It uses only IndexedDB to store AND READ values! Not cookies/session-/localStorage nor any other way.

So, websites CAN USE IndexedDB as a method of tracking/fingerprinting the user.
(Reporter)

Comment 7

10 months ago
I'm not tech savvy and I don't understand the Firefox systems deeply. However, I see that the profile\storage* folders are being used by IndexedDB, therefore I complained about the setting working when set to false. How should I know what kind of else cache/whatever storage is located in the same folders? And as far as I know, Firefox users CAN'T disable those other caches! How is Firefox user friendly and cares about end-users privacy when FF developers have created this kind of mess?! And it's not the only horrible mess FF devs have created. There's a <beep> load of hidden prefs and features that end-users try to manage with addons, or by changing myriad amounts of about:config settings, in order to keep their privacy.

Updated

9 months ago
Priority: -- → P5

Comment 8

a month ago
(In reply to duzopoh from comment #6)
> It doesn't disable asm.js and other caches Andrew Sutherland mentions in his
> 1st comment.

Can anyone suggest which files are used to store those caches?

Thank you.
You need to log in before you can comment on or make changes to this bug.