So what should I do if I want to make an app with this functionality? Do I have to tell users to download and run some executable? You can imagine a case where that is a bit riskier than a nicely sandboxed web app with permission to access one directory.
Well there is a permission dialog and you need to select the directory to grant access and common sensitive directories are blacklisted.
A malicious ad would probably have an easier time tricking you into downloading and running an executable, which is something that has actually happened many times IRL. Worry about that before worrying about theoretical exploits that nobody has actually exploited in an API shipped in the world's most popular web browser for the past 6 years.
That isn't how any of these things work, though. This kind of thing needs a permission to be granted by the user and it does not extend to third-party ads appearing on the site that it is granted to (banner ads have, for a long time, been sandboxed in iframes in the browser to prevent such exploits). I wish native applications had this level of isolation from each other.
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.
Apple is also on the W3C committee that approves new specs, where they abuse that power to prevent any spec that might cut into their app business from moving forward.
Just because a problem is not hard to imagine it doesn't mean that the problem is actually a problem in practice. It is worth asking if there are any signs of it existing for real.
I hear a lot of this "nothing has happened so far" from people who DUI before their first crash and people who use the same password on multiple sites before their first credential stuffing hack
to use your analogy you're claiming that half the population has been driving drunk for years and yet you aren't pointing to an increased rate of collisions on the road. This is not the same thing as an individual doing a dumb thing and getting away with it for a while.
Could it simply be because many use their smartphone to browse the web and of those many have an Apple device and Safari based browsers don't support that API?
It's like the eraly claims that MacOS has no viruses.
No the bad guys jsut didn't care enough because the ROI wasn't big enough
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.
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.
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
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.
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.
> 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.
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).
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.
> 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.
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.
That's exactly what they did at my college (non-California state school) 20 years ago. Special program for students from poor high schools who otherwise wouldn't be admitted, where they came in the summer before freshman year and had to pass some prep classes first. IDK what the actual long term results were, but seems like a better idea than nothing.
The tests will be made by AI as well, because professors who spend less time on making tests can spend more time on research and get hired/promoted more. For the same reason, professors won't care who is using AI to cheat on the test that was made by AI. Maybe some people will care, but not enough to do anything about it.
(Cheating was already rampant in many classes 20 years ago when I was in college, I can't imagine what it's like now.)
Yeah I have one semi-popular package and I am still doing local publish with 2fa because all this "trusted publishing" stuff seems really complicated and also seems to get hacked constantly. Maybe it's just too complicated for us to do securely and we should go back to the drawing board.
But in practice, nobody (well, nobody making lots of ad revenue from their website) uses AdSense exclusively. Most don't even use it at all - AdX is better as a header bidding fallback than AdSense. But those who do use AdSense as a fallback are using it in competition with many other ad networks.
In practice there's this one guy who likes to support ancient JS engines, and this one other guy who likes making lots of tiny packages which depend on his other tiny packages. They both see what they're doing as features, not bugs. And they are both very prominent devs with a lot of popular packages.
So unlikely to change unless everyone stops using their popular packages.
Every now and again people get worked up and try to bully them about it, which is unfortunate because they seem like generally good people, and their arguments in favor of their positions are pretty well documented.
reply