Permanent permission (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

While File System Access might be a solution, the permission granted is temporary, and lost when tab is closed. In some ways it is identical to Session storage, at the slight difference you can retrieve data by re-authorizing the app to access.

A tab can be closed by error. Even if tabs are closed intentionally, when I close my Facebook or Twitter tab, I do not intend to be logged out. It is just to make some space on the tab bar, then retrieve the exact state later on when I revisit facebook. Memorizing the state is extremely important to enable seamless experiences.

For user data stored on device (raw data or E2E encryption keys), the current mechanic consisting of re-asking you the permission to write on disk is clunky, annoying. You know this is your device because you are logged in at OS-level, so of course it is you using the app. You don't need to re-allow the app to access file every time you re-open the tab.

Imagine if Word, Excel or Powerpoint would ask user "Can I access SSD, please ?" or "Can I access external USB drive, please ?" every time user logs in. User would say : "I have 64 GB of RAM and my computer can't even remember that... Meh ?"

This is particularly true when using E2E encryption keys, which is data you need to access first to ensure security of communications. They must be among the first items loaded. We should not re-ask authorization for activating security.

Imagine if your browser was asking you "Are you sure you want to enable HTTPS ?". User would say : "Of course, security is a basic feature and should be enabled by default... Meh ?"

Solution

Provide an option that allows developers to enable permanent permission, and in that case, change the wording of the permission popin.

[slaymaker1907]

@dtruffaut please see my proposal #295 because I think it could help for your usecase. While IndexedDB can be cleared after say 7 days, you could store serialized file handles on the server (in the proposal, these are supposed to be encrypted and safe to save/share since it is limited per machine per domain).

I don't think it is a good idea to give permanent permissions with no popup, but I do think there is a lot of merit in minimizing the number of file picker popups.

[Lioric]

persistent storage without persistent permission makes no sense, so YES permanent permission for file access is needed. The ergonomics of asking the user every single time the app/page is opened makes the file-system-access api not a real option

Our app handles 100's of information units, and users can modify, create or comment them, and the dynamic most of the time is to open the app/page just to add or modify info or comments and then close it, and asking for permission every single time a small modification is made renders this api completely unusable for our use case

[MichaelDimmitt]

Disclaimer: still checking out the library, have not incorporated this into an app yet.

I think the key thing here is if you added the file to a users device (phone)
what happens if you add an update that deletes the file. Or modifies the file into a virus? It might make sense to persist file storage until a version bump happens.

What happens when a good site turns bad?
chrome extension the great suspender is an example,
they sold their extension to someone else and then future updates started contacting external apis.

I was going to comment this later after using the project for a while.
But scared I would forget to post a response.

If I am lacking context feel free to disregard.

[x-077]

Hello @slaymaker1907 ,

On a similar topic, could you maybe look at #289 and advise ?

As it's also related to storage / user permission, maybe you will be able to help me .

Thank you

[anaestheticsapp]

The File System Access API is great but I feel uptake has been limited so far because of the repeated pop-up of permission prompts. This was the most common complaint in my rota PWA which I developed for my hospital. Because of the size of the department, the file stored on a network drive had to be updated multiple times a day. Staff maintaining the rota typically open the app, make the change, and close it again. The time spent clicking through permission prompts each day was considerable. For now, we had to revert back to using a database on the intranet. Having an option to remember permissions for users who have installed a Progressive Web App would be great.

[fernap3]

Throwing another use case here:

I have a music player app in which a user can select a folder to scan for audio files to upload. I persist the chosen directory handle in IndexedDB so the user can come back to the app at a later time and rescan their music folder for uploads. It just feels a bit clunky to need to prompt the user to give access to the directory they already gave access to previously.

[Rodeoclash]

Another use case here is that I'd like to be able to use a service worker to persist files in the background to a users computer. This could be in the form of a long running process on the server which periodically emits completed files. As these files are quite large, I'd like them to download in the background to a nominated directory on the users computer then notify them when the file is ready to use.

[ryanhamilton]

+1 To add another use case:
I want to create an IDE that allows developers to edit their local files regularly.
Each browser tab can be a different file, users will open and close tabs in the editor part of the IDE as they want.
If they unwittingly close all IDE tabs, it will be strange to have to re-ask for access.
It would probably cause them to have to leave one "special tab" open somewhere.
At a minimum for file-system-access to be useful, it would need to maintain permissions while any browser window is open otherwise it's too confusing and puts too much burden on the user to track tabs.

[cmbkla]

Another use case and +1, a PWA that offlines case data (inspection history, contacts, etc) for government inspectors doing field work in low-internet access areas. The size and number of the cases needed to be available offline precludes using indexedDB, File System Access would be ideal for storing individual case data bundles on the device file system. With the current model, the users would need to re-confirm access to these files each time they return to the application to update the data related to a physical inspection that is in progress. Quite cumbersome, given that the device is dedicated strictly to the entry of this data -- it is not a personal or multi-purpose device.

For PWA to be a feasible alternative to native applications, it needs first-class access to the file system for data storage.