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...
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.
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?
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 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.
Unfortunately currently only supported by Chrome/Chromium:
https://developer.mozilla.org/en-US/docs/Web/API/Window/show...
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.
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.
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?
Read, sure, already can do that with file upload. Write sounds like a disaster waiting to happen
A whole new world of phishing.
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]
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.