1996001 - [meta] Encrypt sensitive storage

Status: ASSIGNED

(Core :: Security, enhancement, P3)

Description

[Nikolas Wipper [:nwipper]]

Currently, Firefox profiles are stored plainly on disk. That means that anyone with access to the files can read information like history, cookies and other profile information. Chrome already offers encryption for this data.

There are two main problems to solve this:

• Encrypt SQLite database
• Encrypt everything else

The SQLite database encryption is rather straight-forward, because there already exists a ObfuscatingVFS layer for it, that does all the heavy crypto work. This "only" needs to be enabled for all database connections.

Encryption for other file types isn't completely clear yet. One potential way is to use the existing stream encryption.

Comment 1

[Jan Varga [:janv]]

Is there already a plan for how encryption keys will be stored and managed for persistent profiles?

Comment 2

[Jan Varga [:janv]]

Also, is this meant to be a meta bug for encrypting the entire profile storage (history, cookies, etc.), or just IndexedDB? The description suggests the former, but the component points to the latter.

Comment 3

[Nikolas Wipper [:nwipper]]

For now encryption keys will be derived from the primary password, but there is a plan to have more sophisticated interaction with OS keystores, etc..

It's more of a meta bug. I wasn't sure which component to put it in, since there isn't a plain "Storage" one.

Comment 4

[Jan Varga [:janv]]

(In reply to Nikolas Wipper [:nwipper] from comment #3)

For now encryption keys will be derived from the primary password, but there is a plan to have more sophisticated interaction with OS keystores, etc..

Ok, thanks. So I guess the initial implementation won’t need to store per-SQLite and per-blob keys (for example, for blobs stored in IndexedDB) in a quota manager special database.

It's more of a meta bug. I wasn't sure which component to put it in, since there isn't a plain "Storage" one.

Yeah, but wouldn’t it be better to move this meta bug to a security/privacy-related component? Then you could file a separate bug for IndexedDB.

I also assume this has been discussed with the Workers & Storage team?

Comment 5

[Benjamin Beurdouche [:beurdouche]]

We could put the meta in DOM: Security if you prefer... :)

Comment 6

[Jan Varga [:janv]]

Yeah, DOM: Security is probably not bad component for this.

Comment 7

[Benjamin Beurdouche [:beurdouche]]

making Core: Security instead as this is not DOM specific