5 ms·

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

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.
  - xg15 3mo ago
    > 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 This part already exists, that's the "Origin-private file system". > ...and then build browser-mediated linking for use cases where you want to flow files from (non-domain) to (domain) to (non-domain)? That's pretty much what the directory picker is - or would have been. Apparently it doesn't satisfy the security worries of some.
codedokode 3mo ago
Firefox position is completely valid. I think a safe option would be to allow access only to a specific directory like "~/Internet files" or something like this. This way the user could grant the access but not to sensitive files. And add an option in about:config to lift the restriction for power users. Also, there is a risk of a site writing malware executable, and Linux currently has no sandboxing for such executables so the system would be completely owned once the user runs the program. So the directory should not allow storing executables.
- deleted 3mo ago
  [deleted]
- shortercode 3mo ago
  Both sides are valid. Is it a security risk? In the right conditions yes. But on the other side of it there’s user consent, limited per domain access, and the capability to do multi file editor style apps. I think the WebKit take on this is good and a better fit for most apps. They instead implemented Origin Private File System. Which is based on the same API bits but the folder is only accessible by the website. The downside is the user loses some control over the files: - can’t see what’s being stored - can’t easily backup those files - has to use that web app to access the files - usual nonsense about important files being classed as “cookies” or some nonsense by cache cleaning tools, leading to users deleting their data without realising it
  - codedokode 3mo ago
    > The downside is the user loses some control over the files: Why not use some human-readable path like ~/Internet/example.com/ ? In this case the user could see the files.
    - shortercode 3mo ago
      Mmm so there’s 2 trade offs as far as I can see if you used a folder which both the user and app can access. Firstly if an app does want a space that’s filesystem shape but does not want users/apps to have access for security or consistency reasons ( think Spotify offline storage of songs ). Secondly if the user has access they can do the “easy” thing and just throw lots of files in, including things which are sensitive anyway. It’s interesting to look at how Android and iOS have handled filesystem sandboxing in relation to this.
Theodores 3mo ago
Ah, but it is new to Claude. Claude has main character vibes, so it is always about Claude. Isn't he clever? Claude can stay in his own lane, I want to know how I can use this during development to simulate uploading photos, so Chrome only is okay for my purposes. But I want to know how to do it, not how much better Claude is than me, forever able to do anything I can do but better.
- KetoManx64 3mo ago
  > But I want to know how to do it, not how much better Claude is than me, forever able to do anything I can do but better. So tell the clanker to explain to you in detail about how the system works? It's a piece of code that does what you tell it to, treat it as so.

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.
- xg15 3mo ago
  > 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 This part already exists, that's the "Origin-private file system". > ...and then build browser-mediated linking for use cases where you want to flow files from (non-domain) to (domain) to (non-domain)? That's pretty much what the directory picker is - or would have been. Apparently it doesn't satisfy the security worries of some.

codedokode 3mo ago

Firefox position is completely valid. I think a safe option would be to allow access only to a specific directory like "~/Internet files" or something like this. This way the user could grant the access but not to sensitive files. And add an option in about:config to lift the restriction for power users. Also, there is a risk of a site writing malware executable, and Linux currently has no sandboxing for such executables so the system would be completely owned once the user runs the program. So the directory should not allow storing executables.

deleted 3mo ago
[deleted]
shortercode 3mo ago
Both sides are valid. Is it a security risk? In the right conditions yes. But on the other side of it there’s user consent, limited per domain access, and the capability to do multi file editor style apps. I think the WebKit take on this is good and a better fit for most apps. They instead implemented Origin Private File System. Which is based on the same API bits but the folder is only accessible by the website. The downside is the user loses some control over the files: - can’t see what’s being stored - can’t easily backup those files - has to use that web app to access the files - usual nonsense about important files being classed as “cookies” or some nonsense by cache cleaning tools, leading to users deleting their data without realising it
- codedokode 3mo ago
  > The downside is the user loses some control over the files: Why not use some human-readable path like ~/Internet/example.com/ ? In this case the user could see the files.
  - shortercode 3mo ago
    Mmm so there’s 2 trade offs as far as I can see if you used a folder which both the user and app can access. Firstly if an app does want a space that’s filesystem shape but does not want users/apps to have access for security or consistency reasons ( think Spotify offline storage of songs ). Secondly if the user has access they can do the “easy” thing and just throw lots of files in, including things which are sensitive anyway. It’s interesting to look at how Android and iOS have handled filesystem sandboxing in relation to this.

Theodores 3mo ago

Ah, but it is new to Claude. Claude has main character vibes, so it is always about Claude. Isn't he clever? Claude can stay in his own lane, I want to know how I can use this during development to simulate uploading photos, so Chrome only is okay for my purposes. But I want to know how to do it, not how much better Claude is than me, forever able to do anything I can do but better.

KetoManx64 3mo ago
> But I want to know how to do it, not how much better Claude is than me, forever able to do anything I can do but better. So tell the clanker to explain to you in detail about how the system works? It's a piece of code that does what you tell it to, treat it as so.