Let the user access any file in their computer

[photopea]

My website www.Photopea.com uses the file-system-access API. Very often, people write me, that they want to access a specific folder, but the Chrome browser does not allow them to. It is a regular folder like Downloads, Documents, Desktop, etc.

In order to move web apps closer to native apps, I think there must be a way for the user to access any directory and any file in their device (thourgh a web app, which does it through an API).

A browser can ask the user five times (in different ways), if they really want to give a website XYZ.com an access to a folder, or make them fill a survey to check, if they know what a file and a folder is, and that the user truly understands what it means to let a program access your data. But there must be a way.

Now, if I want to make a program, which analyzes my whole hard drive (e.g. to make an alternative to GIT), and that program will be used only by me, and web development is the only thing I know, I can not make such a program.

[tomayac]

(Some prior discussion happened in https://github.com/photopea/photopea/issues/5261.)

[youk]

It's not a place to advertise your web-sites.

[jimmywarting]

dupl of https://github.com/WICG/file-system-access/issues/381

[guillaumebrunerie]

Now, if I want to make a program, which analyzes my whole hard drive (e.g. to make an alternative to GIT), and that program will be used only by me, and web development is the only thing I know, I can not make such a program.

You can, but you have to use the drag and drop API (drag and drop the folder representing your hard drive). There are no restrictions there as far as I know.

[photopea]

After a long consideration, I have decided to stop using the File System Access API in www.Photopea.com

Telling web developers, that ther is this great new API, which lets you (and your users) modify files easily, but not telling them, that it will not open a huge number of important directories, it is like giving someone a brand new plane, but not telling them that it can fly only for 1 minute.

You can see the people complaining here https://github.com/photopea/photopea/issues/5261, https://github.com/photopea/photopea/issues/5276, https://github.com/photopea/photopea/issues/5277, https://github.com/photopea/photopea/issues/5282, https://www.reddit.com/r/photopea/comments/10eg3vm/cant_open_files_in_this_folder_because_it/ , and I have received about 7 emails complaining about it.

[youk]

Great. Finally you'll stop posting links to your photopee.

[tomayac]

@photopea This is very unfortunate. I looked at the issues, and it's not entirely clear what happened in some of them. Also the ones that described clearly the system files constraint, we both could not reproduce. I will ping the team about this. My suspicion still is that the problem occurs only under certain circumstances in education, where a "home" directory is mapped to something on the network, but not the local hard drive, and that this then causes the API to think it's dealing with system files.

[photopea]

I still think the user should have a right to modify any file, even a system file. Users should have a right to take the responsibility for their files. Otherwise, we have no chance to reach the capabilities of non-web software.

Any user can open any system file in a Notepad, type random letters, and save it. But a browser is less capable than a Notepad today.

[bradisbell]

@tomayac There are many projects that cannot even be realized because this API has been intentionally limited. The UX issues around restricting what users can do on their own filesystem are enough to prevent me and my team from even building some things, and some features on existing products.

As you discuss with your team, please consider that there are many use cases your team could not be aware of because they could not be built. Please consider the overall approach of letting users be in control.

[guillaumebrunerie]

@photopea I'm a bit confused, could you explain why you need access to a whole directory just to save a single file? Or is there something else you want to do with the folder?

Are you using showDirectoryPicker or showOpenFilePicker/showSaveFilePicker?

From what I understand, the restriction on the Downloads folder is only if you want to access the whole folder, but individual files in the Downloads folder should be allowed, as long as you use the file pickers and not the directory picker.

[photopea]

I do not need access to a whole directory. I am using showOpenFilePicker() and Chrome shows an error attached in my first post.

[guillaumebrunerie]

I just tried and there is no issue selecting a file in the Downloads folder with showOpenFilePicker, it works perfectly fine. The error message attached in your first post only happens with showDirectoryPicker, as showOpenFilePicker doesn’t let you select a directory (it just enters the directory).

[photopea]

This error does happen with showOpenFilePicker() (not with Downloads folder, but some different folder, I could not reproduce it myself, but there were 15 people reporting it).

@tomayac probably knows more about how Chrome works

[guillaumebrunerie]

I don't see how it could happen with any folder at all because showOpenFilePicker doesn't let you pick a folder to begin with, it only lets you select files. If it does, it sure sound like a bug in Chrome rather than a problem in the specification.

[tomayac]

The problem seems to be limited to environments like education setups where a user’s home directory is on the network, not the local disk.

[jimmywarting]

Never the less i think a more appropriate error message need to be displayed as to why it can't be selected. The current reason for why you aren't able to pick xyz is very defuse.

I remember trying out to pick the download folder when it was empty and the error message was still:

localhost:3000 can't open this folder because it contains system files

So that wasn't the case. it should have been:

localhost:3000 are not allowed access to "~/Downloads" because it may leak sensitive information.

And you make it sound like it's the domains fault. a better wording would be:

localhost arn't allowed access to open "c:\windows" because it contains system files

And for the download folder it could be useful to explain a workaround:

localhost:3000 are not allowed access to "~/Downloads" because it may leak sensitive information. You can create a sub-folder inside the download folder and pick that one instead.

[guillaumebrunerie]

Bugs in Chrome's implementation of this specification should be reported on Chrome's bug tracker. The bug tracker here is for issues in the specification itself. I already reported the misleading error message here: https://bugs.chromium.org/p/chromium/issues/detail?id=1405817. If there is another Chrome bug when it comes to network-mounted folders, it should be reported there as well.

[a-sully]

If there is another Chrome bug when it comes to network-mounted folders, it should be reported there as well.

Correct, and crbug.com/1408321 was recently filed to track this (star it for updates). We're well aware of the problem and should have a fix up soon.

I also just wanna say that I empathize with the feelings expressed on this thread and others. I want this API to be maximally useful and to enable you all to build the best applications on the web. But of course there are also people out there who will try to use these same tools to cause harm. Sometimes what seems like a reasonable restriction has unintended consequences - it was not our intention to block network-mounted folders, for example. We're working to correct this mistake.

I'm personally really excited about the future of this API (stay tuned for updates on #72 and #297 👀) and I hope you'll stick along for the ride :)

[photopea]

This issue was not supposed to be about a bug in Chrome.

I would like the specification to be changed, so that it puts the responsibility to the user (and not their agent) for their files. As the web grows, web apps will be made to solve more and more types of tasks. Therefore, I think no files should be restricted in an API like this, and it must be specified clearly in the specification.