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...
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.
https://web.dev/patterns/files/open-a-directory
I can select Downloads
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.
I think the point is that as long as the user is sharing things on purpose and not by accident, it should be allowed. Selecting the root of the home directory would probably share a lot of things the user didn't really intend to share (because a lot of apps just dump random config files and stuff in there), but if they specifically select a subfolder they probably have a good idea of what that folder contains.
(Sorry for not testing. Chrome-hater)
All for the sake of "dear user safety".
* 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.
Root of the home directory is also excluded.
But obviously yeah, nothing's going to prevent you from giving a website access to your .ssh directory if you explicitly select it.
Personally I don't have a problem with that. The ability to upload files has been a thing on the web for forever and I don't think there's ever been anything that stopped users from uploading their private key. Possibly some users have gotten phished that way, but at a certain point you have to accept responsibility for your own actions, otherwise you start ceding control of your life to a corporate nanny state.
That desperately needs something like the Public Suffix List [1] - a community-managed list where authors of software can blacklist directories containing sensitive files or such files directly for all browsers implementing this feature.
If I were to design such a list, it would include ~/.ssh, ~/.aws, ~/.config, ~/Library, ~/.{ba,z}sh{rc,_profile,_history}, ~/.m2, ~/.npm, ~/.npmrc, ~/.profile at the very least. Because users will get phished.
And while I do hate Mozilla, Google is to be disliked even more.
Not truly supported across all mobile browser currently, but it's certainly better than just one year ago.
* Global 75.2%
Mainly missing Safari and Firefox
... unless you have the weight of Google.
App developers will often choose not to sandbox their applications because it's a lot easier (and sometimes faster) do to all file management yourself, but the APIs are there and ready to be used.
I was thinking about desktop OS's, actually.
You don't need to use that Windows API. You can just access any file you want. There is no reason a music player, for example, needs to access ~/Pictures. An arbitrary program requiring access to all your files is a huge red flag, but it's a red flag that users aren't allowed to see. Proper filesystem permissions would fix that.
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.
Its also easily possible to have sensitive files misplaced, especially for a general non-technical user that would be the one falling for a browser hijacking attack
My biggest concern here is the write permission.
what are websites gonna steal, debian binaries and libraries?
all my important stuff are in my home directory, which is owned (read+write) by me, the same user running the browser.
https://developer.mozilla.org/en-US/docs/Web/API/Window/show...
What are the many ways could this possibly go wrong?
This API returns a handle to the selected directory, giving the webpage ongoing read/write access to the directory.
You couldn't use the former to e.g. create a local-first notes app that stores its files on disk.
It's very cool though, and worth learning about for anyone who's unfamiliar.
I have a demo page showing what it can do here: https://tools.simonwillison.net/webkitdirectory
APIs that encourage websites to store user data in files are a positive thing.
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.
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.
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...
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 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.
"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.
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
