Posted by steveharrison 1 day ago
It is a great API though, I wish the other browser vendors liked it! Because currently us PWA developers are really limited when trying to make apps that work with local data, at least in non-Chrome browsers.
Also, there is a risk of a site writing malware executable, and Linux currently has no sandboxing for such executables so the system would be completely owned once the user runs the program. So the directory should not allow storing executables.
I think the WebKit take on this is good and a better fit for most apps. They instead implemented Origin Private File System. Which is based on the same API bits but the folder is only accessible by the website. The downside is the user loses some control over the files:
- can’t see what’s being stored
- can’t easily backup those files
- has to use that web app to access the files
- usual nonsense about important files being classed as “cookies” or some nonsense by cache cleaning tools, leading to users deleting their data without realising it
Origin Private File System is for files that the app manages internally and that normally, the user should never touch - like stuff in /var or AppData for native applications. Hence why browsers make no guarantees where on disk they will store those files or even if they'll store them as files at all.
But I think that's not really very interesting, because it's not offering anything new you couldn't already do with localStorage or indexedDB, just with a file-like API. Hence why browsers also put it in the same "ephemeral local data" bucket as those APIs.
The directory picker API would offer a new ability, namely to "open a directory" in user-managed space and work with it like an IDE would. But I can see why the security risks are too large for that.
Why not use some human-readable path like ~/Internet/example.com/ ? In this case the user could see the files.
Firstly if an app does want a space that’s filesystem shape but does not want users/apps to have access for security or consistency reasons ( think Spotify offline storage of songs ).
Secondly if the user has access they can do the “easy” thing and just throw lots of files in, including things which are sensitive anyway.
It’s interesting to look at how Android and iOS have handled filesystem sandboxing in relation to this.
Then they should not store anything on user's device.
> Secondly if the user has access they can do the “easy” thing and just throw lots of files in, including things which are sensitive anyway.
OS could add a warning when copying the files into the folder.
> It’s interesting to look at how Android and iOS have handled filesystem sandboxing in relation to this.
Many apps on Android request "media access" which allows accessing all user files.
I think the fact that the above issue has been open for a very long time is one indication of how difficult and sensitive this type of access control API is. The Google Drive API could be a proving ground for getting the UX right for this (including tricky details like how to manage persistent access to a folder with clear disclosure and user controls).
Why not just create per-domain browser-controlled folders (cert-linked?) that are abstracted into a simple read/write API via the browser (with subfolders allowed under that domain's root), disallow cross-domain access... and then build browser-mediated linking for use cases where you want to flow files from (non-domain) to (domain) to (non-domain)?
So essentially local storage with better integration with the actual filesystem, that's browser-controlled.
Allowing websites to have arbitrary (even user-approved) access directly to the real filesystem seems like a bad idea, when most use cases could be handled by a browser-mediated filesystem-like abstract view.
This part already exists, that's the "Origin-private file system".
> ...and then build browser-mediated linking for use cases where you want to flow files from (non-domain) to (domain) to (non-domain)?
That's pretty much what the directory picker is - or would have been. Apparently it doesn't satisfy the security worries of some.
- the first time you select a directory it must be empty
- you can drag files in there afterwards
- the directory gets whitelisted for future use
Probably has bad usability, but would be more secure.
Claude can stay in his own lane, I want to know how I can use this during development to simulate uploading photos, so Chrome only is okay for my purposes. But I want to know how to do it, not how much better Claude is than me, forever able to do anything I can do but better.
So tell the clanker to explain to you in detail about how the system works? It's a piece of code that does what you tell it to, treat it as so.
both Mozilla[1] and Apple[2] are opposed to it
encouraging people to build apps that only work in google web browsers actively harms the web and sends a signal to google that they can in fact keep doing this
[1] https://mozilla.github.io/standards-positions/#native-file-s...
I agree with the comments about how much of a security risk this poses. But, isn't that the case with any binary or executable files and apps we download from the internet anyway?
It would be cool if you could have a specially-demarcated directory (e.g. even inside the application like `~/Applications/Chrome/<website>/local_files`) which you can just open super easily with a button from Chrome, and just copy files over into that directory as needed. Would provide the benefits of a more secure enclave with the flexibility of being on the filesystem.
* System and root directories cannot be selected. * Can only being activated after user action. * Requires https. * Double-confirmation for write access.
No API like this could ever be bulletproof, but it's a start I guess.
Very cool API though, and it really does open up a whole new world of possibilities.
Root of the home directory is also excluded.
But obviously yeah, nothing's going to prevent you from giving a website access to your .ssh directory if you explicitly select it.
Personally I don't have a problem with that. The ability to upload files has been a thing on the web for forever and I don't think there's ever been anything that stopped users from uploading their private key. Possibly some users have gotten phished that way, but at a certain point you have to accept responsibility for your own actions, otherwise you start ceding control of your life to a corporate nanny state.
That desperately needs something like the Public Suffix List [1] - a community-managed list where authors of software can blacklist directories containing sensitive files or such files directly for all browsers implementing this feature.
If I were to design such a list, it would include ~/.ssh, ~/.aws, ~/.config, ~/Library, ~/.{ba,z}sh{rc,_profile,_history}, ~/.m2, ~/.npm, ~/.npmrc, ~/.profile at the very least. Because users will get phished.
My Nix Home Manager settings for XDG directories:
xdg.userDirs = {
enable = true;
createDirectories = true;
desktop = "${config.home.homeDirectory}/var/desktop";
documents = "${config.home.homeDirectory}/opt/docs";
download = "${config.home.homeDirectory}/var/download";
music = "${config.home.homeDirectory}/opt/art/music";
pictures = "${config.home.homeDirectory}/opt/art/visual/picture";
publicShare = "${config.home.homeDirectory}/var/public";
videos = "${config.home.homeDirectory}/opt/art/visual/video";
templates = "${config.home.homeDirectory}/opt/templates";
};~/Pictures and ~/.ssh are as far apart as they can be while staying in the user's home directory. I guess you could stick stuff in... /var or something, but that seems worse overall.
And while I do hate Mozilla, Google is to be disliked even more.
From what I gather from the docs [1], this API gives you a FileSystemDirectoryHandle object, and then you just call getDirectoryHandle() on that to recursively read the the entire filesystem. The spec [2] has some vague suggestions about blacklisting certain particularly sensitive files, which doesn't seem reassuring.
[1] https://developer.chrome.com/docs/capabilities/web-apis/file...
[2] https://wicg.github.io/file-system-access/#privacy-wide-acce...
No, Chrome doesn't allow this.
Here's a simple demo: https://output.jsbin.com/kekekac/quiet - note that you can't select root, Downloads etc.
https://web.dev/patterns/files/open-a-directory
I can select Downloads
There is a reason why it’s Chromium browsers only, don’t you think?
Well, yes.
The alternative is to give any malicious ad the ability to drive-by-download malware onto your machine.
A malicious ad would probably have an easier time tricking you into downloading and running an executable, which is something that has actually happened many times IRL. Worry about that before worrying about theoretical exploits that nobody has actually exploited in an API shipped in the world's most popular web browser for the past 6 years.
https://web.dev/patterns/files/open-a-directory
At least it got the number of files in the selected directory including Program Files and Windows\System32
I didn't click upload, so ...
None.
Because I don't use Chrome.
It's spyware.
It's like the eraly claims that MacOS has no viruses. No the bad guys jsut didn't care enough because the ROI wasn't big enough
Those "vague suggestions" actually seem to include some pretty specific examples.
> A user’s entire "home" directory. Individual files and directories inside the home directory should still be allowed, but user agents should not generally let users give blanket access to the entire directory.
I think the point is that as long as the user is sharing things on purpose and not by accident, it should be allowed. Selecting the root of the home directory would probably share a lot of things the user didn't really intend to share (because a lot of apps just dump random config files and stuff in there), but if they specifically select a subfolder they probably have a good idea of what that folder contains.
(Sorry for not testing. Chrome-hater)
All for the sake of "dear user safety".
https://developer.mozilla.org/en-US/docs/Web/API/Window/show...
Why not just make the API create a new directory rather than selecting one? There's still a risk people create a directory in a shared location - but at least they're only risking the new directory then, right?
Regarding security I think Chrome got right balance on this: you always need to select folder, sensitive ones are excluded, on repeat visits if you try to access a file, it asks you permission again, you can't get full filename paths and so on.
Claude Opus on its own with filesystem tools built around the FileSystemDirectoryHandle API [3] makes for a pretty decent coding agent - I've been using the app to write itself live on its own development server ever since it got the ability to edit its own files, which is some of the most fun development I've done recently. I think writing your own harness is probably the most fun thing you can do with an LLM, which is why so many people do it - getting the model to add and then start using a new tool you had an idea for in the same chat is always fun.
[1] which seems like the best scenario for it in terms of the security/privacy issues it poses
[2] I ended up creating an MCP server rooted to a specific local directory - which I can expose to them via Cloudflare Tunnel - and a browser extension which adds a folder picker button to their chat interfaces, so I can get an almost-equivalent experience. This is really ugly in ChatGPT but works as well as I'm used to in Claude.
[3] as a bonus, the tools you write against this API will also be compatible with the Origin private file system (OPFS) API if you want to give your chats a virtual filesystem for the model to write to, or to copy user-attached files into
APIs that encourage websites to store user data in files are a positive thing.
If we want a free and open internet, we need to protect Firefox at all costs.
They inject various unwanted integrations (like pocket in the past).
> independent
Independent from who, Google? Well, no, not even independent from Google, that's the truth.