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.

[elringus]

I've found following related issues on crbug:

• https://bugs.chromium.org/p/chromium/issues/detail?id=1011533
• https://bugs.chromium.org/p/chromium/issues/detail?id=1354695

The last one looks especially promising; looks like persistent permissions are already being worked on.

[danqdinh]

This permanent permission is so necessary for apps with files, my app has to ask for permissions again and again at the first user interaction at app open.

[Rodeoclash]

I've found the new OPFS file storage has allowed me to work around needing to store the file permissions.

I'm still using the File System API to obtain a readable handle to a file, but once I have that, I'm then copying the file into the OPFS file storage via a worker.

https://github.com/Rodeoclash/vodon-player/blob/main/player/src/workers/file_storage.js#L18

This suits my purposes as it means that even if the user deletes the original file, I still have a reference to it. I realise this isn't going to suit all use cases (I can see where you would want to have a reference to a file that other tools aside from the browser may edit it) but in my case the OPFS works very well.

[Jaifroid]

I've found the new OPFS file storage has allowed me to work around needing to store the file permissions.

I'm still using the File System API to obtain a readable handle to a file, but once I have that, I'm then copying the file into the OPFS file storage via a worker.

This is interesting, but over at Kiwix, we deal with files/archives that can be as big as 90GB (yes, 90 Gigabytes - a complete copy of Wikipedia including images). I don't think a user would appreciate our copying such a file into some hidden store inside the browser. In general even our smaller archives can easily be around 1GB. It seems pointless doing all this copying when what we really want is to persist a file handle that the user has picked. If we can copy a whole file into OPFS, why can't we simply copy the handle itself and persist it, rather than the underlying file? It's manifestly no less secure, as the user has granted permission to access the file.

[tomayac]

Work on this feature request is happening, as was pointed out by @a-sully in #14 (comment), but never here. This very issue is the one to stay subscribed to.

[Rodeoclash]

So it's turned out my original plan to use the OPFS file storage to work around this isn't going to be a suitable solution for two reasons:

1. It's fairly slow copying files. This isn't the fault of the OPFS, my users have large multi-gb video files that are slow even copying them in an SSD using Windows File Explorer.
2. You get a fairly large impact on harddrive space. Basically, every video file a user wants to work with is duplicated twice on their system. Worse, it's very hard to know where the space is going because it's hidden within Chrome.

I've resorted to restoring access to the file handles on restart of the tab. It's not ideal as a user might have to individually click on 5 (or more!) different video thumbnails and activate the dropdown.

videos needing manual user intervention to restore access

after access has been restored

One downside is needing to handle the edge case of a file being moved while the site has been closed, however, this isn't too painful and a "replace file" or similar option would allow them to repick the new location of the file.

Looking forward to more (hopefully positive) developments with this!

[jimmywarting]

I originally planed to use SharedWorker to remember the state of the application (and remembering file handle permission), but most often you only have one tab to that origin open. so a simple page reload won't keep the SharedWorker alive. which i think is a design flaw in the spec somewhere.

this was pointed towards a band-aid 🩹 as towards not having to have "a special tab open" solution other have mention

I think there should be some time of grace period (even for just 5s) for a shared worker to stay alive after all tabs are closed so page reload keeps the shared worker alive

https://stackoverflow.com/questions/9336774/do-shared-web-workers-persist-across-a-single-page-reload-link-navigation

[a-sully]

FWIW I don't think a page reload should clear file system permissions in the first place; that behavior is a quirk of the current Chromium implementation (which, as hinted at above, will be changing soon!). I've filed https://crbug.com/1445420 to track fixing the clear-on-reload behavior

[bhavers]

@a-sully, is there any update on the implementation efforts of a security model for File System API to persists permissions permanently (for installed PWAs)? thx

[a-sully]

Hi @bhavers,

It took a while to find the right privacy and security model, but I'm very pleased with what we settled on. We'll be sharing more developer-focused details as we get closer to launch.

Implementation is in progress and can be tracked at https://crbug.com/1011533. Star the bug if you want to receive updates!

[jimmywarting]

I'm curious how the new UI will look like. even just a wireframe would be 👌

[GRMule]

This is a positive development; for web applications to be first-class apps, they need a way to store data in a way that isn't subjected to the vagaries of what the user agent chooses to do. A use case I can present; building a web app for government users to conduct inspections related to licensed activities, with full offline capability. Right now, we're using indexedDb, but certain users can have a LOT of case files and I always cringe waiting for the bug report about someone's inspection results being pruned by the browser because a magic threshold was reached that I can't mitigate or predict. It's embarrassing as a web developer to note that the old MS Access system they were using before, (or the cluster of MS Excel sheets) that we "modernized", would never throw away data because it was a certain number of days old or an internal percentage of a percentage of disk storage was reached.

[tomayac]

📢 PSA: We're removing one of the biggest annoyances when working with the File System Access API: the constant re-prompting for permission to access files even when the user granted permission before.

You can now allow your users to have their file system permissions persisted, both for files and folders:

https://developer.chrome.com/blog/persistent-permissions-for-the-file-system-access-api.

What this means is that, for example, if you're a Web-based IDE like VS Code, you can now get permanent access to /Users/tomayac/projects.

[bradisbell]

@tomayac Thank you for announcing these changes. This is definitely a step in the right direction. However, I still think it's hostile to the users.

Triggering a prompt for permanent permissions requires multiple visits and requests. Why can't the user grant permanent permissions upon first visit?

[Jaifroid]

I'm also very pleased with the new permanent permissions, at least in theory. In practice, I have so far failed to trigger them in a copy of Chrome 122 in which I tried this out. Even after installing my PWA, permission prompts still show every time I launch the app. Hopefully just teething problems.

[tomayac]

Triggering a prompt for permanent permissions requires multiple visits and requests. Why can't the user grant permanent permissions upon first visit?

It's the current security compromise we agreed on.

In practice, I have so far failed to trigger them in a copy of Chrome 122 in which I tried this out. Even after installing my PWA, permission prompts still show every time I launch the app.

Did you follow all required steps? Did you toggle the flag just to be sure? Note that the stable channel is at 120, it's supposed to roll out in 122 stable.

[Jaifroid]

Did you follow all required steps? Did you toggle the flag just to be sure? Note that the stable channel is at 120, it's supposed to roll out in 122 stable.

Ah no, I was assuming it would be already in 122 dev channel. I'll try with flags. Thanks.

[anaestheticsapp]

Great news! Is this Chrome only or will this work on Edge as well (couldn't find the flags)?

[tomayac]

Great news! Is this Chrome only or will this work on Edge as well (couldn't find the flags)?

Since there's no API-level change (but just a user-agent-level change of how permissions are handled), user agents are free to follow this Chrome-specific behavior or not. Checking with the latest Edge Canary, it looks like Edge hasn't rolled this out so far, but I'm obviously not entitled to speak for the Edge team other than as an external observer. Maybe @slightlyoff or @diekus know if there're plans to follow Chrome here?!

[Jaifroid]

I confirm it's working in Chrome 122 dev if I turn on the flags. Sweet!
(Tested in Windows Sandbox, for a completely clean install.)

[Jaifroid]

I've just started noticing these Permissions in Edge 122 stable (the three-way choice), so yes, it's confirmed to work in Edge. No flags set (Edge doesn't have them, seemingly). Interestingly, in an installed PWA I didn't have to answer even that one-time dialogue box. On a non-installed PWA I got the prompt, but it is indeed one-time if the user chooses "Allow on every visit".

Has this officially landed in all Chromiums > 122 now, or has Edge taken some, ahem, shortcuts and pushed this fully to Edge official builds?

[a-sully]

Has this officially landed in all Chromiums > 122 now

Yup! Please refer to @tomayac's announcement (also linked above) for more details: https://developer.chrome.com/blog/persistent-permissions-for-the-file-system-access-api

I'll note this recently-launched feature involved no changes to the File System specification; it's "just" a bookkeeping change related to how the user agent maintains its file system permission states

Given that I don't expect any further spec changes (and this feature is now supported in Chromium browsers!) I think it's safe to close this issue :)

Now go forth and build cool things! 🚀 📁