Open / Write File without File Picker (Ex: Store E2E encryption keys)

[dtruffaut]

Context

Nowadays E2E encryption is hard, because you need persistent storage on client. Safari's policy of 7 days cap removal puts storage at risk (cookies, cacheAPI, localStorage, IndexedDB) & makes it even harder. It is important to notice that E2E encryption keys are not cache nor tracking mechanics. E2E encryption keys are user data. If lost, user cannot access it's data anymore. They are vital.

Problem

Write

While File System Access might be a solution, you cannot write a file directly, even after being granted the permission.

The way this API currently is it forces you to display a file picker just to get a file handler. The API was refined with a suggestedName attribute, so you can hint the File picker what name you want to write. This is great for scenarios where we want user to make a choice concerning the destination of the file we will write.

But there are scenarios where asking to the user this extra intellectual step simply produces friction at the moment (even if the feature will be available at a later step of the product lifecycle)

For example, asking user where it wants to store its E2E encryption key is not practical during enrollement phase, where you want as little steps as possible to reduce the friction. You just want to enable security as fast as possible, and ensure keys will be saved on file system so they will never be wiped by error by accidentally clearing cache in Dev Tools.

In this scenario, what you want is to be able to get a file handle without a file picker, just like in C++ or NodeJS where you have a openFile / writeFile methods so a program / script can open a file without extra UI (apart from initial permission). You know, the path and the file name you want to write in (generally, "documents/myappname.json"), so just do it.

Once you are reinsurred and encryption keys are backed up on disk, you can propose user in its app parameters to specify where it wants to save its profile with encryption keys inside, and perform the migration, let's say, on a USB disk if user say so.

New users want to go fast, where returning users want extra flexibility.

Open

Same observation, at application startup, you want to be able to read a file without any extra UI if permission was previously granted permanently ( See #297 ), and the way you achieve this is through a OpenFile method that gives you a file handle without a file picker.

Solution

Provide openFile / writeFile methods that allow developers to work on file handlers without a file picker, and in that case, change the wording of the permission popin.

[tomayac]

Would the Origin Private File System work for this scenario?

[dtruffaut]

The origin restriction is great and reminds me what IndexedDB does. If it is not affected by the [ Clear site data ] button in dev tools, it fits this E2E encryption keys storage scenario.

Edit : Yes it works for this scenario

That said, I think there will be extra cases where devs want to write in other known paths, like auto-patching an installed game without asking user where the game is installed. The game path will be stored in the private origin, but the patcher will write in the game directory. There is no need for user intervention here, past the first permission, since patching is required for anti-cheat, units balancing, bug fix. Example : Steam / Battle.net (Starcraft, Diablo...). The interface is already written in Electron (NodeJS). It could just be a PWA. Battle.net World of Warcraft update

For now I'll close this ticket