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.

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...

[2] https://webkit.org/standards-positions/#position-28

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.

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.

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...

Unfortunately currently only supported by Chrome/Chromium:

https://developer.mozilla.org/en-US/docs/Web/API/Window/show...

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?

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

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.

[0] https://github.com/minht11/local-music-pwa

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!

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.

Some of the permissions problems related to window.showDirectoryPicker have been frustrating. I'm developing a client-side Python web framework, and during development I need to mount the library locally; I hand off the directory to Pyodide using this API. But that doesn't work in VSCode's internal browser, apparently because the API just simply isn't able to be approved.

I'm not sure if this is meant to be ironic?

"You can also create folders within the app and move photos into them, and it all happens on your filesystem."

Why, yes. But you can also do that with Finder.

And if you want to work with local data, why use the often inferior web-based widgets and toolkits instead of native ones?

This seems to be the worst of both worlds so to speak.

But webkitdirectory="true" could already do that, no?

Currently using this in socket2.me

Not truly supported across all mobile browser currently, but it's certainly better than just one year ago.

photopea.com already does this...

It's a full photoshop-like image (svg, gif, and video too) editor that runs completely on the browser, and has the ability to load a folder as you "Local Projects" folder.

I'm surprised nobody commented this already

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?

Too many prompts and not an official API. Back in the day, IE also had tons of "great" and novel ideas, including COM+ something something.

A whole new world of phishing.

Read, sure, already can do that with file upload. Write sounds like a disaster waiting to happen

everything is Chrome in the future

I wish we had this in the operating system. It would solve an immense number of risks such as data deletion from bugs and even ransomware.

> Chrome introduced a new API, window.showDirectoryPicker() that allows the user to grant access to a directory on their computer and allow a website to read/write everything inside.

I mean, what could go wrong?

It's not like an user is tricked into uploading a file from a folder (let's say, the main "Documents" folder) and some malicious website steals all the files over there.

[flagged]

[dead]