search

WICG / file-system-access

Expose the file system on the user’s device, so Web apps can interoperate with the user’s native applications.
https://wicg.github.io/file-system-access/
Other
669 stars 66 forks source link

No way to track available space? #309

Open ftreesmilo opened 3 years ago

ftreesmilo commented 3 years ago

I can't seem to see how we can tell if the user has enough space to write a file...

tomayac commented 3 years ago

What you are looking for is await navigator.storage.estimate().

ftreesmilo commented 3 years ago

@tomayac No... that's not what I'm looking for. I've seen that most of my users have machines that have 2nd or 3rd drives for additional storage. I need to know for the directory they gave me... how much space is left? Will what I need to write fit? Should I ask them to pick a different folder?

Do they have a drive that has enough space for all the files in one folder?

This has to be dead simple for the users. I need to store a lot of data. > 10gig. The user will not know what to do to junction or symlink a folder in their chrome profile to where they have space (if that would even work for storage foundation) and they will have no patience for dealing with quota juggling if they are nearly out of space.

Webapps need a better interface for dealing with storage. I need storage that will perform well, allow me to give the user a good UX, and doesn't get in my way. If I need to jump through a hoop to have them install my app as a pwa to bypass some of your safety measures, so be it... but as it stands, none of your current apis do more than 1 of those things. storage foundation solved the performance issue... but the draconian FS "protection" and obfuscation is making it useless to me.

Please solve this. I want to stay onboard with PWAs. I want to see them improve. The platform has so much potential.

tomayac commented 3 years ago

Oh, I see. In this case the information returned by navigator.storage.estimate() is indeed not sufficient. I wonder if the solution is to make navigator.storage.estimate() aware of different drives (probably not), or if the File System Access API should be empowered to get this information somehow for a directory (not drive) the user already has access to (more likely).

pwnall commented 3 years ago

Reporting free disk space is complicated. If done naively, we end up exposing cross-origin resource sizes -- see https://crbug.com/960305

For this reason, navigator.storage.estimate() reports an origin's available quota. Quota is over-subscribed, so there's no guarantee that an origin can use up all its quota without running out of disk space.

ftreesmilo commented 3 years ago

@pwnall I 100% agree with you, we need to be careful here. However... I think you guys are a bit overzealous in your protection of the user. If they have granted me a directory on their machine, they have consented to me storing information on their machine. The whole point is that I can track the dataset I have on the machine.

I can see your desire to not allow fingerprinting to identify users via info from other origins... ok simple... make a method off the directory handle to get accurate free space based on the granted FS handle storage device. I don't need a global api with no user interaction. The user has already granted me access to write any amount of data to this particular folder.

I want to be a responsible dev and give them a good UX that shows them when they might need to move that folder to a new device due to storage concerns.

ftreesmilo commented 3 years ago

We need some middle ground or we will never have apis that meet the needs of application developers

pwnall commented 3 years ago

@ftreesmilo In this case, the problem isn't fingerprinting, it's outright exfiltration of data belonging to a different origin. The HEIST attack (Blackhat 2016) goes over some implications of being able to measure the size of resources in other origins.

At a high level, I think you're right about the need for some middle ground. I haven't found it yet, though.

The best I could come up with is a special mode (persistent COEP?) where we could safely expose a free disk space API to the origin. We'd need a way for an origin to opt into this mode, which would block opaque responses, so no such responses end up on disk (HTTP cache, Cache API, etc.). This mode would imply a client-side storage reset (so no old opaque responses survive on disk). This mode would also restrict cross-origin communication to other origins that opted into this mode, so it can't be bypassed by iframes and postMessage().

The problem with my idea is that the restrictions rule out the applications I know that might be interested in the free disk space API. This may become more palatable if the ecosystem migrates away from opaque responses, which may happen thanks to COEP gating some powerful capabilities.

ftreesmilo commented 3 years ago

@pwnall is this what you are referring to? https://tom.vg/2016/08/request-and-conquer/

This API doesn't have a quota, it's direct access to a folder. Meaning changes in storage should not affect another origin's quota especially if the navigator quota is fuzzed already (I was asking for a new api specific to this file-system-access). The folder might not even be on the same device as chrome profile / cache storage.

Since the user has to grant access to the folder, one would hope that only trusted apps would be allowed.

What about if the folder is on the same device as the chrome profile, you remove the size of the user's profile + some buffer to keep the profile change hidden. You can subtract that from both the total size of the device and the amount of free space.

It might change now and then... but hopefully not fast.