6 ms·

window.showDirectoryPicker opens up a whole new world

113 points by steveharrison 3mo ago

steveharrison 3mo ago
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!
- zb3 3mo ago
  [flagged]
  - reddalo 3mo ago
    Firefox may not be the best browser, but it's the last full-featured non-commercial independent browser still available (excluding forks like Waterfox). If we want a free and open internet, we need to protect Firefox at all costs.
    - coldpie 3mo ago
      Please don't give trolls attention. Just downvote & move on.
      - gchamonlive 3mo ago
        But it's fun
    - zb3 3mo ago
      > non-commercial They inject various unwanted integrations (like pocket in the past). > independent Independent from who, Google? Well, no, not even independent from Google, that's the truth.
- Ajedi32 3mo ago
  Yes, I think this modern trend towards storing user data in app/website-specific databases instead of in files has been bad for consumer freedom. Files are naturally portable and provide a interface for inter-operating with competing software in a way that data stored in the cloud or an app-specific database does not. APIs that encourage websites to store user data in files are a positive thing.
acbart 3mo ago
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.
- Yiin 3mo ago
  sounds like vscode issue more than anything else
  - tantalor 3mo ago
    Usability issues? In vscode? No...
yread 3mo ago
But webkitdirectory="true" could already do that, no?
- deleted 3mo ago
  [deleted]
- justusthane 3mo ago
  No, they're very different. Using webkitdirectory="true" on an <input> element just allows you to select a directory to e.g. upload it to the server. It's a one-time operation. 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.
- simonw 3mo ago
  That's read-only. 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 https://tools.simonwillison.net/webkitdirectory
qwertytyyuu 3mo ago
Read, sure, already can do that with file upload. Write sounds like a disaster waiting to happen
jaen 3mo ago
Unfortunately currently only supported by Chrome/Chromium: https://developer.mozilla.org/en-US/docs/Web/API/Window/showDirectoryPicker https://developer.mozilla.org/en-US/docs/Web/API/Window/show...
- inigyou 3mo ago
  (intentionally, because it's a massive security risk and only Google doesn't care about endpoint security)
- AlienRobot 3mo ago
  Chromium has around the same market share as Windows, so at this point I feel people are targeting it as a web application development platform just as people target Windows.
explodes 3mo ago
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.
- explodes 3mo ago
  Looks like these safeguards are in place: * 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.
  - ptx 3mo ago
    Those are some pretty flimsy safeguards. I don't keep my secrets in system directories and using HTTPS doesn't mean the site isn't malicious.
    - Ajedi32 3mo ago
      > I don't keep my secrets in system directories 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.
  - mschuster91 3mo ago
    > System and root directories cannot be selected. 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. [1] https://en.wikipedia.org/wiki/Public_Suffix_List https://en.wikipedia.org/wiki/Public_Suffix_List
bigrocketapps 3mo ago
Currently using this in socket2.me Not truly supported across all mobile browser currently, but it's certainly better than just one year ago.
- tantalor 3mo ago
  https://caniuse.com/mdn-api_window_showdirectorypicker https://caniuse.com/mdn-api_window_showdirectorypicker * Global 75.2% Mainly missing Safari and Firefox
  - asdfsa32 3mo ago
    This new IE6 called Chrome, I hate it.
  - chrismorgan 3mo ago
    You say “mainly missing Safari and Firefox”, but the better way to look at it is “only Chromium”. There is only one implementation, and the other two major implementers have explicitly rejected it. And we don’t standardise things without at least two implementations.
    - skeledrew 3mo ago
      > we don’t standardise things without at least two implementations ... unless you have the weight of Google.
znpy 3mo ago
> 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.
- bigrocketapps 3mo ago
  If you tried this out in Linux, for example, the system would block you from selecting folders that contain files that are flagged as dangerous or "system files". I'm assuming this was implemented across all OSes.
  - blharr 3mo ago
    That does not sound at all reassuring, that the only safeguard is the system blocking access and that the API has no safeguard. 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
    - bigrocketapps 3mo ago
      I have not checked the source code to tell you if the system is the one blocking access or the browser-level API itself. I'm guessing it's the browser. The only reason I mentioned Linux is that's where I tested it and I'm sure there are differences across OSes. My biggest concern here is the write permission.
  - znpy 3mo ago
    i give zero F about whatever is in my /usr, /var/lib and /opt folders. 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.
deleted 3mo ago
[deleted]
AlienRobot 3mo ago
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.
- asdfsa32 3mo ago
  MacOS has this and what happens is that you get into the habit of just clicking through it. It won't help with ransomware, only backups would.
  - AlienRobot 3mo ago
    That just means it's poorly designed. There has to be a way to design this in such way it works.
    - asdfsa32 3mo ago
      You would have to either make it very hard to use or change human psychology unfortunately.
- jeroenhd 3mo ago
  Which operating system do you mean? Flatpak has this already, Android enforces this kind of API for shared files, Windows UWP has pretty much the exact same API (https://learn.microsoft.com/en-us/uwp/api/windows.storage.pickers.folderpicker?view=winrt-28000 https://learn.microsoft.com/en-us/uwp/api/windows.storage.pi...). 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.
  - AlienRobot 3mo ago
    Flatpak is probably the worst way to "have" this possible. It's completely opaque to both app and user. If you ever tried to run an .exe through flatpak'd bottles, you'll run into an issue where .dll's aren't found because you didn't install flatseal first to configure permissions. That's not operating-system level integration. That is actually very poor design that a user requires a separate app (flatseal) to configure how the sandbox works. 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.
cicko 3mo ago
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.
- libria 3mo ago
  They also popularized XMLHttpRequest. Sometimes a flexible idea can trend to the greater ecosystem.
- steve1977 3mo ago
  ActiveX something something!
buckle8017 3mo ago
A whole new world of phishing.
streptomycin 3mo ago
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 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.
- sharperguy 3mo ago
  You could implement it this way: - the first time you select a directory it must be empty - you can drag files in there afterwards - the directory gets whitelisted for future use Probably has bad usability, but would be more secure.
- NooneAtAll3 3mo ago
  fortunately*
- benregenspan 3mo ago
  I'd love for Google to figure out something comparable for the Drive API (currently it's not possible to grant read/write access to a single folder; you need to grant access to the entire drive!): https://issuetracker.google.com/issues/36760598?pli=1 https://issuetracker.google.com/issues/36760598?pli=1 I think the fact that the above issue has been open for a very long time is one indication of how difficult and sensitive this type of access control API is. The Google Drive API could be a proving ground for getting the UX right for this (including tricky details like how to manage persistent access to a folder with clear disclosure and user controls).
  - ethbr1 3mo ago
    Is it really that complicated? Why not just create per-domain browser-controlled folders (cert-linked?) that are abstracted into a simple read/write API via the browser (with subfolders allowed under that domain's root), disallow cross-domain access... and then build browser-mediated linking for use cases where you want to flow files from (non-domain) to (domain) to (non-domain)? So essentially local storage with better integration with the actual filesystem, that's browser-controlled. Allowing websites to have arbitrary (even user-approved) access directly to the real filesystem seems like a bad idea, when most use cases could be handled by a browser-mediated filesystem-like abstract view.
rvz 3mo ago
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?
- Anduia 3mo ago
  "Choose your browser cache folder to improve performance"
  - codedokode 3mo ago
    Choose .autostart directory to install a video codec needed to play this video.
    - pmontra 3mo ago
      Or "to save the pictures of those girls." There are infinite ways to make people open the doors of their storage.
ptx 3mo ago
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-system-access https://developer.chrome.com/docs/capabilities/web-apis/file... [2] https://wicg.github.io/file-system-access/#privacy-wide-access https://wicg.github.io/file-system-access/#privacy-wide-acce...
- Ajedi32 3mo ago
  Root directory would be on that blacklist for sure. 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.
  - EnergyAmy 3mo ago
    That's not at all specific. What individual files and directories?
    - Ajedi32 3mo ago
      All of them, unless they're also on the list of examples to exclude (like the Downloads folder). 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.
- jaffathecake 3mo ago
  > So websites can now nag users to allow access to the root of their local disk No, Chrome doesn't allow this. Here's a simple demo: https://output.jsbin.com/kekekac/quiet https://output.jsbin.com/kekekac/quiet - note that you can't select root, Downloads etc.
ang_cire 3mo ago
[dead]
sarreph 3mo ago
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.
- streptomycin 3mo ago
  That is similar to https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system https://developer.mozilla.org/en-US/docs/Web/API/File_System... except AFAIK that does not allow any way to access it as a normal directory outside the browser.
steve1977 3mo ago
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.
- coldpie 3mo ago
  I used to think like this too, but somewhat surprisingly to myself, I have actually come around to deciding the web API is the most user-forward API that closed-source software can target, and it is actually good for end users for closed-source software to target it. This is because web API software is distributed as plaintext to be interpreted by software under user's control, the browser. This gives a ton of power to the user. We as end users can develop browser extensions, CSS hacks, and so on, to make this closed-source software work better for us. I frequently do this; why can't I paste into this password text box? Screw it, I go into dev tools and enable pasting into it. Who decided grey-on-grey text was a good idea? Screw it, I got into dev tools and make the text black. Why can't I copy the text on this page? Screw it, I go into dev tools and yank it straight from the DOM. Why does this stupid animation take so long? Screw it, I go develop a greasemonkey script to set the animation timer value to 0. This is all quite easy with web API software, but would be be extremely difficult with a compiled binary. This is to say nothing about the cross-platform benefits. No one's shipping a HaikuOS binary, but most web apps work just fine there, depending on browser feature support. I think it is also a good choice for open-source software for the same reason. It provides a common, well-tooled API for users to hack the software they are using. But open-source software has other hackable options that make it less of a strong argument there. Native toolkits definitely have a lot of nice features that the web API doesn't (yet) have, and there's a ton of value in the consistency native toolkits provide. But I think I've come around to valuing hackability over those features, so I'm actually now a web API fan. Again, surprising myself with this switch :)
  - Ajedi32 3mo ago
    There are a lot of things to like about the web as an application platform. The security model is a big one for me. There aren't many other application platforms out there where you can just download random apps off the internet and run them with zero worries they'll screw up your system. Plus the web is an open standard, works on desktop and mobile, and has multiple competing independent open source implementations.
haeseong 3mo ago
[flagged]
nasso_dev 3mo ago
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-system https://mozilla.github.io/standards-positions/#native-file-s... [2] https://webkit.org/standards-positions/#position-28 https://webkit.org/standards-positions/#position-28
rightlane 3mo ago
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 3mo ago
everything is Chrome in the future
llosio 3mo 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
- steveharrison 3mo ago
  Nice one!
danhardman 3mo ago
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?
- Ajedi32 3mo ago
  I think the intended use case is for things like "give my music player access to my music library" or "open a project directory in this IDE", which wouldn't work well if every app were confined to its own directory.
  - danhardman 3mo ago
    I guess, but it seems pretty typical to expect to install a new software or start a new project and require some form of loading/importing content in. It wouldn't exactly destroy the experience or at least the trade-off seems worth it imo
no_way 3mo ago
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 https://github.com/minht11/local-music-pwa
- steveharrison 3mo ago
  [dead]
insin 3mo ago
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
- steveharrison 3mo ago
  Cool use-case!

113 points by steveharrison 3mo ago

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!

zb3 3mo ago
[flagged]
- reddalo 3mo ago
  Firefox may not be the best browser, but it's the last full-featured non-commercial independent browser still available (excluding forks like Waterfox). If we want a free and open internet, we need to protect Firefox at all costs.
  - coldpie 3mo ago
    Please don't give trolls attention. Just downvote & move on.
    - gchamonlive 3mo ago
      But it's fun
  - zb3 3mo ago
    > non-commercial They inject various unwanted integrations (like pocket in the past). > independent Independent from who, Google? Well, no, not even independent from Google, that's the truth.
Ajedi32 3mo ago
Yes, I think this modern trend towards storing user data in app/website-specific databases instead of in files has been bad for consumer freedom. Files are naturally portable and provide a interface for inter-operating with competing software in a way that data stored in the cloud or an app-specific database does not. APIs that encourage websites to store user data in files are a positive thing.

acbart 3mo ago

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.

Yiin 3mo ago
sounds like vscode issue more than anything else
- tantalor 3mo ago
  Usability issues? In vscode? No...

yread 3mo ago

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

deleted 3mo ago
[deleted]
justusthane 3mo ago
No, they're very different. Using webkitdirectory="true" on an <input> element just allows you to select a directory to e.g. upload it to the server. It's a one-time operation. 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.
simonw 3mo ago
That's read-only. 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 https://tools.simonwillison.net/webkitdirectory

qwertytyyuu 3mo ago

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

jaen 3mo ago

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

inigyou 3mo ago
(intentionally, because it's a massive security risk and only Google doesn't care about endpoint security)
AlienRobot 3mo ago
Chromium has around the same market share as Windows, so at this point I feel people are targeting it as a web application development platform just as people target Windows.

explodes 3mo ago

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.

explodes 3mo ago
Looks like these safeguards are in place: * 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.
- ptx 3mo ago
  Those are some pretty flimsy safeguards. I don't keep my secrets in system directories and using HTTPS doesn't mean the site isn't malicious.
  - Ajedi32 3mo ago
    > I don't keep my secrets in system directories 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.
- mschuster91 3mo ago
  > System and root directories cannot be selected. 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. [1] https://en.wikipedia.org/wiki/Public_Suffix_List https://en.wikipedia.org/wiki/Public_Suffix_List

bigrocketapps 3mo ago

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

tantalor 3mo ago
https://caniuse.com/mdn-api_window_showdirectorypicker https://caniuse.com/mdn-api_window_showdirectorypicker * Global 75.2% Mainly missing Safari and Firefox
- asdfsa32 3mo ago
  This new IE6 called Chrome, I hate it.
- chrismorgan 3mo ago
  You say “mainly missing Safari and Firefox”, but the better way to look at it is “only Chromium”. There is only one implementation, and the other two major implementers have explicitly rejected it. And we don’t standardise things without at least two implementations.
  - skeledrew 3mo ago
    > we don’t standardise things without at least two implementations ... unless you have the weight of Google.

znpy 3mo ago

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

bigrocketapps 3mo ago
If you tried this out in Linux, for example, the system would block you from selecting folders that contain files that are flagged as dangerous or "system files". I'm assuming this was implemented across all OSes.
- blharr 3mo ago
  That does not sound at all reassuring, that the only safeguard is the system blocking access and that the API has no safeguard. 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
  - bigrocketapps 3mo ago
    I have not checked the source code to tell you if the system is the one blocking access or the browser-level API itself. I'm guessing it's the browser. The only reason I mentioned Linux is that's where I tested it and I'm sure there are differences across OSes. My biggest concern here is the write permission.
- znpy 3mo ago
  i give zero F about whatever is in my /usr, /var/lib and /opt folders. 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.

deleted 3mo ago

[deleted]

AlienRobot 3mo ago

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.

asdfsa32 3mo ago
MacOS has this and what happens is that you get into the habit of just clicking through it. It won't help with ransomware, only backups would.
- AlienRobot 3mo ago
  That just means it's poorly designed. There has to be a way to design this in such way it works.
  - asdfsa32 3mo ago
    You would have to either make it very hard to use or change human psychology unfortunately.
jeroenhd 3mo ago
Which operating system do you mean? Flatpak has this already, Android enforces this kind of API for shared files, Windows UWP has pretty much the exact same API (https://learn.microsoft.com/en-us/uwp/api/windows.storage.pickers.folderpicker?view=winrt-28000 https://learn.microsoft.com/en-us/uwp/api/windows.storage.pi...). 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.
- AlienRobot 3mo ago
  Flatpak is probably the worst way to "have" this possible. It's completely opaque to both app and user. If you ever tried to run an .exe through flatpak'd bottles, you'll run into an issue where .dll's aren't found because you didn't install flatseal first to configure permissions. That's not operating-system level integration. That is actually very poor design that a user requires a separate app (flatseal) to configure how the sandbox works. 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.

cicko 3mo ago

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.

libria 3mo ago
They also popularized XMLHttpRequest. Sometimes a flexible idea can trend to the greater ecosystem.
steve1977 3mo ago
ActiveX something something!

buckle8017 3mo ago

A whole new world of phishing.

streptomycin 3mo ago

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

sharperguy 3mo ago
You could implement it this way: - the first time you select a directory it must be empty - you can drag files in there afterwards - the directory gets whitelisted for future use Probably has bad usability, but would be more secure.
NooneAtAll3 3mo ago
fortunately*
benregenspan 3mo ago
I'd love for Google to figure out something comparable for the Drive API (currently it's not possible to grant read/write access to a single folder; you need to grant access to the entire drive!): https://issuetracker.google.com/issues/36760598?pli=1 https://issuetracker.google.com/issues/36760598?pli=1 I think the fact that the above issue has been open for a very long time is one indication of how difficult and sensitive this type of access control API is. The Google Drive API could be a proving ground for getting the UX right for this (including tricky details like how to manage persistent access to a folder with clear disclosure and user controls).
- ethbr1 3mo ago
  Is it really that complicated? Why not just create per-domain browser-controlled folders (cert-linked?) that are abstracted into a simple read/write API via the browser (with subfolders allowed under that domain's root), disallow cross-domain access... and then build browser-mediated linking for use cases where you want to flow files from (non-domain) to (domain) to (non-domain)? So essentially local storage with better integration with the actual filesystem, that's browser-controlled. Allowing websites to have arbitrary (even user-approved) access directly to the real filesystem seems like a bad idea, when most use cases could be handled by a browser-mediated filesystem-like abstract view.

rvz 3mo ago

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?

Anduia 3mo ago
"Choose your browser cache folder to improve performance"
- codedokode 3mo ago
  Choose .autostart directory to install a video codec needed to play this video.
  - pmontra 3mo ago
    Or "to save the pictures of those girls." There are infinite ways to make people open the doors of their storage.

ptx 3mo ago

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-system-access https://developer.chrome.com/docs/capabilities/web-apis/file... [2] https://wicg.github.io/file-system-access/#privacy-wide-access https://wicg.github.io/file-system-access/#privacy-wide-acce...

Ajedi32 3mo ago
Root directory would be on that blacklist for sure. 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.
- EnergyAmy 3mo ago
  That's not at all specific. What individual files and directories?
  - Ajedi32 3mo ago
    All of them, unless they're also on the list of examples to exclude (like the Downloads folder). 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.
jaffathecake 3mo ago
> So websites can now nag users to allow access to the root of their local disk No, Chrome doesn't allow this. Here's a simple demo: https://output.jsbin.com/kekekac/quiet https://output.jsbin.com/kekekac/quiet - note that you can't select root, Downloads etc.

ang_cire 3mo ago

[dead]

sarreph 3mo ago

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.

streptomycin 3mo ago
That is similar to https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system https://developer.mozilla.org/en-US/docs/Web/API/File_System... except AFAIK that does not allow any way to access it as a normal directory outside the browser.

steve1977 3mo ago

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.

coldpie 3mo ago
I used to think like this too, but somewhat surprisingly to myself, I have actually come around to deciding the web API is the most user-forward API that closed-source software can target, and it is actually good for end users for closed-source software to target it. This is because web API software is distributed as plaintext to be interpreted by software under user's control, the browser. This gives a ton of power to the user. We as end users can develop browser extensions, CSS hacks, and so on, to make this closed-source software work better for us. I frequently do this; why can't I paste into this password text box? Screw it, I go into dev tools and enable pasting into it. Who decided grey-on-grey text was a good idea? Screw it, I got into dev tools and make the text black. Why can't I copy the text on this page? Screw it, I go into dev tools and yank it straight from the DOM. Why does this stupid animation take so long? Screw it, I go develop a greasemonkey script to set the animation timer value to 0. This is all quite easy with web API software, but would be be extremely difficult with a compiled binary. This is to say nothing about the cross-platform benefits. No one's shipping a HaikuOS binary, but most web apps work just fine there, depending on browser feature support. I think it is also a good choice for open-source software for the same reason. It provides a common, well-tooled API for users to hack the software they are using. But open-source software has other hackable options that make it less of a strong argument there. Native toolkits definitely have a lot of nice features that the web API doesn't (yet) have, and there's a ton of value in the consistency native toolkits provide. But I think I've come around to valuing hackability over those features, so I'm actually now a web API fan. Again, surprising myself with this switch :)
- Ajedi32 3mo ago
  There are a lot of things to like about the web as an application platform. The security model is a big one for me. There aren't many other application platforms out there where you can just download random apps off the internet and run them with zero worries they'll screw up your system. Plus the web is an open standard, works on desktop and mobile, and has multiple competing independent open source implementations.

haeseong 3mo ago

[flagged]

nasso_dev 3mo ago

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-system https://mozilla.github.io/standards-positions/#native-file-s... [2] https://webkit.org/standards-positions/#position-28 https://webkit.org/standards-positions/#position-28

rightlane 3mo ago

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 3mo ago

everything is Chrome in the future

llosio 3mo 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

steveharrison 3mo ago
Nice one!

danhardman 3mo ago

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?

Ajedi32 3mo ago
I think the intended use case is for things like "give my music player access to my music library" or "open a project directory in this IDE", which wouldn't work well if every app were confined to its own directory.
- danhardman 3mo ago
  I guess, but it seems pretty typical to expect to install a new software or start a new project and require some form of loading/importing content in. It wouldn't exactly destroy the experience or at least the trade-off seems worth it imo

no_way 3mo ago

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 https://github.com/minht11/local-music-pwa

steveharrison 3mo ago
[dead]

insin 3mo ago

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

steveharrison 3mo ago
Cool use-case!