Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

window.showDirectoryPicker opens up a whole new world

steveharrison.dev

Post reply on HN
Print view View original

111–120 of 122 posts

Re: window.showDirectoryPicker opens up a whole new world

#111

Post by asdfsa32 »

recursive wrote: post #75
asdfsa32 wrote: post #27

Earlier quoted context omitted.

Chrome and friends (Edge, Opera) are basically the new IE6 and only people who are new or forgetful will disagree. I hate Mozilla for missing up so bad with their stewardship of Firefox time and again, but alas, it is the only reasonable option on the table. And while I do hate Mozilla, Google is to be disliked even more.

IE6 stagnated after MS won the browser wars. It didn't get an update for like 6 years. Chrome has become a monoculture too but I think it's one of another kind.

IE6 stagnated because that was ideal for Microsoft who was mainly in the business of desktop; Chrome is now eroding user privacy and becoming a rubbish OS because that is ideal for a Google's Ad revenue and web based business. It is the same.

Re: window.showDirectoryPicker opens up a whole new world

#112

Post by xg15 »

shortercode wrote: post #97
codedokode wrote: post #83

Earlier quoted context omitted.

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 executa…

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…

As I understood it, the two APIs have different purposes, so I don't think you can really compare them.

Origin Private File System is for files that the app manages internally and that normally, the user should never touch - like stuff in /var or AppData for native applications. Hence why browsers make no guarantees where on disk they will store those files or even if they'll store them as files at all.

But I think that's not really very interesting, because it's not offering anything new you couldn't already do with localStorage or indexedDB, just with a file-like API. Hence why browsers also put it in the same "ephemeral local data" bucket as those APIs.

The directory picker API would offer a new ability, namely to "open a directory" in user-managed space and work with it like an IDE would. But I can see why the security risks are too large for that.

Re: window.showDirectoryPicker opens up a whole new world

#113

Post by xg15 »

ethbr1 wrote: post #60
benregenspan wrote: post #53

Earlier quoted context omitted.

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

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 bet…

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

Re: window.showDirectoryPicker opens up a whole new world

#114

Post by codedokode »

shortercode wrote: post #107
codedokode wrote: post #101

Earlier quoted context omitted.

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

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 sensit…

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

Then they should not store anything on user's device.

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

OS could add a warning when copying the files into the folder.

> It’s interesting to look at how Android and iOS have handled filesystem sandboxing in relation to this.

Many apps on Android request "media access" which allows accessing all user files.

Re: window.showDirectoryPicker opens up a whole new world

#115

Post by Ajedi32 »

coldpie wrote: post #51
steve1977 wrote: post #44

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.

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…

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.

Re: window.showDirectoryPicker opens up a whole new world

#116

Post by KetoManx64 »

Theodores wrote: post #89
streptomycin wrote: post #25

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 br…

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.

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

Re: window.showDirectoryPicker opens up a whole new world

#117

Post by steveharrison »

llosio wrote: post #71

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

Nice one!

Re: window.showDirectoryPicker opens up a whole new world

#118

Post by steveharrison »

leptons wrote: post #88
croes wrote: post #74

Earlier quoted context omitted.

Yet. It’s not hard to imagine a case where it is a bad idea to give the browser access to the whole content of a directory. There is a reason why it’s Chromium browsers only, don’t you think?

Apple will never implement anything in a browser that could make a web app as capable as a native mobile app, they are simply too greedy. Firefox typically doesn't implement these things unless they have to because they don't have the resources that Google and Apple do.

I hadn't thought about this angle as to why WebKit hasn't implemented this, but yeah 100%.

Re: window.showDirectoryPicker opens up a whole new world

#119

Post by steveharrison »

no_way wrote: post #96

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 selec…

[dead]

Re: window.showDirectoryPicker opens up a whole new world

#120

Post by steveharrison »

insin wrote: post #108

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 l…

Cool use-case!
Post reply on HN