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!

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.

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

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.

Currently using this in socket2.me

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

Unfortunately currently only supported by Chrome/Chromium:

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

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

Using an example that is similar to what is shown in the article's videos, this could be awesome for a "blender in the cloud" for render farms. Imagine just having your blender file, read and written to, with a simple web interface

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.

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.

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.

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?

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

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.

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.