

Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- We are introducing new and exciting ways to expose environment variables and PII every day! Introducing features like this while we are in the midst of uncontrolled supply chain attacks feels like a not great idea.by rightlane
- Phishers and exploit developers are celebrating and jumping for joy over yet another way to deploy their payload to their victims.
What are the many ways could this possibly go wrong?
by rvz - "Choose your browser cache folder to improve performance"by Anduia
- I'm really excited about window.showDirectoryPicker and the local-first web apps it will enable. There's lots of talk about local-first sync engines, but the best sync engine is one you don't even manage, like the user's file system / cloud storage service!
- Yes, I think this modern trend towards storing user data in app/website-specific databases instead of in files has been bad for consumer freedom. Files are naturally portable and provide a interface for inter-operating with competing software in a way that data stored in the cloud or an app-specific database does not.
APIs that encourage websites to store user data in files are a positive thing.
by Ajedi32 - A few people have suggested adding a blacklist for dangerous directories or validating directories are empty first.
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?
by danhardman - I think the intended use case is for things like "give my music player access to my music library" or "open a project directory in this IDE", which wouldn't work well if every app were confined to its own directory.by Ajedi32
- I'm using this API in the internal [1] model-independent LLM chat app I work on at an F100, and it ruined using the Claude and ChatGPT web interfaces for me outside of work [2] because I'm used to being able to point the model at a folder so it can be directed to find and pull in relevant context itself, being able to add folder mid-chat and saying "you do it", and being able to have the model run code to work with local files of any size your browser can handle (every time we released a new version people would drag in their huge Excel files and go "still doesn't work" as we used to extract and context stuff the contents, but now it can poke around in them directly to find sheets/headers/structure and write code to do whatever they wanted).
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
by insin - Cool use-case!
- Unfortunately currently only supported by Chrome/Chromium:
https://developer.mozilla.org/en-US/docs/Web/API/Window/show...
by jaen - (intentionally, because it's a massive security risk and only Google doesn't care about endpoint security)by inigyou
- Chromium has around the same market share as Windows, so at this point I feel people are targeting it as a web application development platform just as people target Windows.by AlienRobot
- So websites can now nag users to allow access to the root of their local disk and then read all their files and settings, all their SSH keys and other passwords?
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...
by ptx - Let's not forget that, at the same time, Google forces every developer of any Android app to register in the Google database using an ID scan, otherwise no one can install it.
All for the sake of "dear user safety".
by cnr - Is the camera roll excluded? I bet I am not the only one who has a passport picture in there. I don’t know about other people’s camera rolls, but I bet it is occasionally more saucy than mine.
(Sorry for not testing. Chrome-hater)
by superjan - Root directory would be on that blacklist for sure.
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.
by Ajedi32 - > So websites can now nag users to allow access to the root of their local disk
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.
by jaffathecake - I am using this api for music player[0] in the browser. Biggest share of my users are using Chromebooks, where besides Android apps are not much alternatives. If this API was not available closest thing would be to make an Electron app, which has much more broad system access to users device than a website using showDirectoryPicker.
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.
by no_way - First time I've heard about this. I'll have to look into the security model around it. I'm curious what safeguards are in place to prevent click jacking. I know showing a file picker """should""" be enough of a warning to users to be careful, but it's not hard to imagine a world where a couple of fish accidentally bite the bait of an allow-button, or because they followed instructions they incorrectly trusted.by explodes
- This is something you should explain to the Firefox critics.by cicko
- Looks like these safeguards are in place:
* 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.
by explodes - I think something that is a mix between localStorage or IndexedDB and access to the user's filesystem would be better.
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.
by sarreph - That is similar to https://developer.mozilla.org/en-US/docs/Web/API/File_System... except AFAIK that does not allow any way to access it as a normal directory outside the browser.by streptomycin
- it's a bit of a shame that TFA does not mention that this is a non-standard API pushed by google only (all three editors of the draft are google engineers)
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...
by nasso_dev - This isn't new, the API has been around for several years. Unfortunately Mozilla and Apple say they are never going to implement it because of security concerns https://github.com/mozilla/standards-positions/issues/154
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.
by streptomycin - fortunately*by NooneAtAll3
- Ah, but it is new to Claude. Claude has main character vibes, so it is always about Claude. Isn't he clever?
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.
by Theodores - You could implement it this way:
- 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.
by sharperguy - I'd love for Google to figure out something comparable for the Drive API (currently it's not possible to grant read/write access to a single folder; you need to grant access to the entire drive!): https://issuetracker.google.com/issues/36760598?pli=1
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).
by benregenspan - Firefox position is completely valid. I think a safe option would be to allow access only to a specific directory like "~/Internet files" or something like this. This way the user could grant the access but not to sensitive files. And add an option in about:config to lift the restriction for power users.
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.
by codedokode