window.showDirectoryPicker opens up a whole new world

steveharrison 108 points 97 comments June 22, 2026
steveharrison.dev · View on Hacker News

Discussion Highlights (20 comments)

steveharrison

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!

acbart

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.

yread

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

explodes

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.

bigrocketapps

Currently using this in socket2.me Not truly supported across all mobile browser currently, but it's certainly better than just one year ago.

jaen

Unfortunately currently only supported by Chrome/Chromium: https://developer.mozilla.org/en-US/docs/Web/API/Window/show...

znpy

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

AlienRobot

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.

cicko

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.

buckle8017

A whole new world of phishing.

streptomycin

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.

rvz

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?

ptx

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

sarreph

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.

steve1977

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.

qwertytyyuu

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

nasso_dev

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

rightlane

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.

functionmouse

everything is Chrome in the future

llosio

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

Semantic search powered by Rivestack pgvector
11,301 stories · 106,340 chunks indexed