(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 data (for example, blobs stored in IndexedDB) in quota-manager-managed storage. > 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?
Bug 1996001 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(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, blobs stored in IndexedDB) in quota-manager-managed storage. > 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?
(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 quota-manager-managed storage. > 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?
(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?