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

51–60 of 122 posts

Re: window.showDirectoryPicker opens up a whole new world

#51

Post by coldpie »

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

Re: window.showDirectoryPicker opens up a whole new world

#52

Post by simonw »

yread wrote: post #5

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

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

Re: window.showDirectoryPicker opens up a whole new world

#53

Post by benregenspan »

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…

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

Re: window.showDirectoryPicker opens up a whole new world

#55

Post by cnr »

ptx wrote: post #28

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…

Let's not forget that, at the same time, Google forces every developer of any Android app to register in the Google database using an ID scan, otherwise no one can install it.

All for the sake of "dear user safety".

Re: window.showDirectoryPicker opens up a whole new world

#56

Post by petcat »

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.

The best app is the one that is available on your platform.

Unfortunately I think the ubiquity of browser-based web apps are the only reason the Linux desktop is even remotely usable at this point.

Re: window.showDirectoryPicker opens up a whole new world

#57

Post by move-on-by »

jaffathecake wrote: post #35
ptx wrote: post #28

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…

> 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 - note that you can't select root, Downloads etc.

Ah yes, totally secure. I’m sure there will be no unforeseen problems or bypasses.

Re: window.showDirectoryPicker opens up a whole new world

#58

Post by bigrocketapps »

blharr wrote: post #37
bigrocketapps wrote: post #22

Earlier quoted context omitted.

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.

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

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.

Re: window.showDirectoryPicker opens up a whole new world

#59

Post by zb3 »

reddalo wrote: post #6
zb3 wrote: post #3

Earlier quoted context omitted.

[flagged]

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.

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

Re: window.showDirectoryPicker opens up a whole new world

#60

Post by ethbr1 »

benregenspan wrote: post #53
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…

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

Post reply on HN