I, on the other hand, am actually annoyed that Mozilla doesn't support the File System Access API. I understand that there are security concerns that need to be evaluated more, but the API has to explicitly request for user permissions anyways and has to re-request user permissions when the tab is closed. I'd much rather live in a world where I can briefly use a web app to do some task than be forced to install a myriad of native desktop apps that have unsandboxed and unpermissioned access to everything on my system.
Origin private file system access seems cool, albeit a half measure. Seems like a better alternative than putting blobs into IndexedDB.
> but the API has to explicitly request for user permissions anyways
You mean, just like all other 200 [1] or so APIs that want to request that access?
It's a good thing some browser vendors don't look at these APIs in isolation, but look at the whole picture. So they see all the other APIs that also want to spring a pop up requesting access to something, and are concerned about confirmation fatigue.
[1] Exaggeration. Or maybe not. These days between all the hardware APIs chrome is pushing, and existing APIs like notifications and locations, and half-consensus APIs like file system access and MIDI there might be more than 200 hundred already.
Arguably looking at the whole picture means recognizing that some of these use cases will instead be done by traditional desktop apps that have far more invasive access often without needing to prompt the user for permission at all. In my view web browsers are a more secure and privacy-preserving option than that.
> In my view web browsers are a more secure and privacy-preserving option than that.
Indeed. That's precisely why some browser vendors don't want to give random access to your computer to any and all website. And don't want to give every app and site access to the data that should be private to a particular web site.
From this point of view sandboxing websites seems like a good compromise.
---
It's also strange that the argument I keep hearing is "but apps have unrestricted access, so to preserve security and privacy... let's give web sites the same access as native apps". It doesn't work lime this.
Browsers don't have the same access as native apps, and shouldn't. There are permission prompts, privacy controls and access limits. For example the File System Access API is not unfettered access, it's limited to only files and folders manually selected by the user and nothing else. This is not at all "random access to your computer", which is in fact what traditional desktop apps tend to have.
> Browsers don't have the same access as native apps, and shouldn't.
Indeed. That's why browser vendors (well, some of them) take a dim view of "oh just let them access anything, just pop a confirmation prompt in there"
> There are permission prompts, privacy controls and access limits.
And users are surely aware of those and can definitely understand where to find them, and what implications those have? Literally the entire history of computing tells us: no.
> This is not at all "random access to your computer"
It is. This is already done by MacOS with its incessant "app X wants to access files in Y". Even I, a programmer, and a power user, end up clicking "to hell with it, yes" more often than not. Especially if I'm in the middle of an important task.
> This is already done by MacOS with its incessant "app X wants to access files in Y".
Of course this happens a lot after installing a new machine. Once I have my machine running however, I don't encounter this anymore. I think it has to do with the fact that I very infrequently install new applications.
I've had this happen to me just twice in the past week. One was something to do with Zoom, and one I can't even remember what (I think an app I installed, but didn't run).
In at least one of those cases I was like "you want my Downloads? Fine, go away" because I was in the middle of some task :)
It becomes effectively "random" (arbitrary) when higher order effects take over. We saw this with ActiveX controls. It becomes a game of chicken that eventually leads to an imbalance where website operators always win.
Put "block this page from requesting any future permissions" checkbox in the confirmations, and create another API (I know...) so that good sites can request multiple permissions at once.
There are many sites which would really benefit from file system access and a unified API so that they don't have to resort to constant upload/download or roll their own virtual file system. It's more than worth slight inconvenience of another popup, and while it also makes scamming less tech-savvy people easier (e.g. if they store all their passwords in the "Documents" folder which the phishing site is now requesting access), there are already so many ways to scam these people that we need better solutions.
> Put "block this page from requesting any future permissions" checkbox in the confirmations, and create another API (I know...) so that good sites can request multiple permissions at once.
> The FTC’s complaint alleges that the company’s privacy policy deceptively failed to disclose that the app transmitted users’ precise location and unique device identifier to third parties, including advertising networks. In addition, the complaint alleges that the company deceived consumers by presenting them with an option to not share their information, even though it was shared automatically rendering the option meaningless.
> Upon first opening the app, they were shown the company’s End User License Agreement, which included information on data collection. At the bottom of the license agreement, consumers could click to “Accept” or “Refuse” the terms of the agreement. Even before a consumer had a chance to accept those terms, though, the application was already collecting and sending information to third parties – including location and the unique device identifier.
And just to be clear: the permission screen should make it really obvious that a site which can access the file system API can access files on your computer, which can be dangerous, and allow/encourage the user to only grant access to specific directories. If a site requests many permissions, they don't get to hide them within a big TOS, all requested permissions will be clearly shown. And the FileSystem API is already set up to transparently return a virtual file system (https://developer.mozilla.org/en-US/docs/Web/API/FileSystem), so sites won't know if the user doesn't grant access vs. gives them an empty folder.
There's no world in which "good sites" ask for many permissions in one go, and the bad ones don't.
> And just to be clear: the permission screen should make it really obvious that a site which can access the file system API can access files on your computer
When a site/app requests several permissions at once, this "really obvious" becomes a wall of text full of technical and non-technical implications that very few users will read or indeed understand.
We literally have this already on Android and to a somewhat lesser extent on iOS.
I agree - the File System Access API with full integration with local files and folders is essential for desktop web apps. Ours[1] supports File System Access for saving and opening projects in Chromium-based browsers, and our stats show a full 65% of users save that way. So it's also what real people actually want to use in browsers.
The OP already said 65% of users, it’s implicit that 35% of users don’t want to use it. It’s unclear to me why the views of you or that 35% should override the majority.
65% of people who were asked with what question and what panel and what information provided?
This whole idea is stupid. Another C program with and ability to run arbitrary code off the network written by idiots and nasty folk being given arbitrary filesystem access. Have we learned nothing? We need more controls (MAC / process sandboxing) not less.
Just because someone wants to do something to make their lives easier and asks a set of people what they want who says yes doesn't mean it's a good idea.
I say this as someone who has written desktop/web integration stuff over the years without this.
The File System Access API does not grant arbitrary file system access. At most it provides access to a folder manually chosen by the user, with limits on which folders can be accessed (e.g. root or entire documents folder is not allowed).
I suspect that the majority of those 65% of users (remember that most users are not tech savvy) just click ok on whatever popup appears, that does not mean that they want, but rather they don't understand.
Are you really saying that the users of Construct, a 2D game engine, are not tech savvy or do not really understand what they are doing by granting local file access?
Millions of people use powerful Excel features every day to literally run the world, and yet malicious macros in office documents are still a prime way to hack any business. User is not the same as information security expert.
To be clear, we also offer cloud save (e.g. to Google Drive), or downloading a copy of your project. Our software makes no particular effort to highlight any particular option. We see 65% of users freely choose the file system option, and most of the others use cloud save.
This is a logical fallacy and you should be ashamed of yourself for spreading it. You can "engineer" (manipulate) low information voters into voting a certain way. This means nothing.
?!? No one is voting on anything. The OP was quoting the stats of how many users used a feature when it was put in front of them. Are you suggesting they “engineered” their users to save files on the local file system when they didn’t actually want to? To what end? What purpose would that ever serve?
Only on Hacker News would “we offered users the ability to save to disk and 65% used it” be seen as a sinister conspiracy theory.
This is a point against your argument, not in its favour.
The percentages of users who use or don't use specific features, in isolation, cannot be effectively used to determine those users' opinions on the relative merits of those features. There are so many other factors at play that you really need to do some kind of explicit survey to determine whether, just as a for instance, some of those 65% would prefer a different way of saving files but don't have the choice (or think they don't), and, conversely, whether some of those 35% would be happy to use that feature, but don't know about it.
It’s indicative, that’s all. No one is claiming it’s a statistically significant survey to the nth degree or anything. This is how people iterate products. It’s Hacker News bread and butter. You put a feature in front of people and see how many use it. How many then return to use it again. OP said they put the two options on an equal footing and 65% chose local disk save. It’s an indicator, nothing more, nothing less.
I'm basically against the browser getting too much access, so what is missing in Firefox 111 for your use case? Is it just less convenient for end-users?
The key is the file and folder picker methods (showOpenFilePicker() etc), allowing the web app to interact with existing files and folders on the device. OPFS does not allow that, as it's internal storage in the browser, like IndexedDB.
Browsers have been able to get access to files on disk for longer now than many Web developers have even had careers—drag and drop was one of the first HTML5 APIs. Same with client-side processing for `<input type="file">` elements. (Directory access through the `webkitdirectory` attribute is another story, but it did eventually gain support from all major browsers—even if it's terribly named and the scary warnings about how it will "probably" go away on MDN haven't been updated.)
As for writing, you don't get unlimited unchecked writes the way that Chrome's proposed Filesystem Access API grants you, but you can trigger "checked" writes (that show a file save dialog) using `<a/>` elements with the `download` attribute. This is arguably a better user experience, because it keeps the user in the loop, giving them the opportunity to veto (or rename/relocate) the written file—which will be difficult or impossible to do if the Chrome team's proposed API became standard.
Overall, the File System Access proposal is a bad one that gets the developer vs user prioritization wrong (favoring the convenience and satisfaction of the former over preserving control for the latter), and I hope it doesn't become either a de facto or a de jure fixture of the Web platform soon. Here's to hoping for a future post to the Chrome Developers blog announcing that this is yet another experimental API of theirs that they have decided is going to be sunset in some future release.
This is access to some controlled contents that happen to come from the filesystem, with interaction explicitly initiated by the user every time. It gives the browser no access to the structure of the filesystem, no way to navigate it, and crucially no way to transparently read or write anything.
This is good isolation, I'd prefer it to be this way. OFS also gives equally good isolation, I'm fine with that.
Sharing between OFS and the rest of the user's file system should be possible, but only explicitly, a la iOS, Android, and the file upload / download dialog.
Please follow the discussion; we are not referring to the narrow "origin private file system" here.
> This is not access to the filesystem.
Wrong. I know what "this" is, thanks, and it is access to the filesystem. That's because "this" here—in the subthread you have just posted to—refers to Chrome's experimental implementation of the larger proposal (which is literally called "File System Access API"), not the limited subset described by the submission as having just gotten enabed in Firefox.
Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute, which are not filesystem access.
> That's how you end up with "March 2023 Report (Final) (Edited) (3).docx".
People having been doing that with Word and other local word processors using (SMB) file shares for decades. There's nothing special about web browsers that's causing it.
People using Word in this manner typically create a new filename only occasionally, not every single time they save. Browsers, on the other hand, will create a new filename every single time a download is initiated. That makes downloads impractical to use as a web app’s sole persistence mechanism; a few smaller web apps do so anyway but it’s rare.
And if they’re not the sole persistence mechanism, if downloads are just an export option separate from a ‘normal’ save, like you see in most web apps, then the 99.9% of users who don’t constantly export all their documents will have to deal with the consequences of the normal persistence mechanism. That is probably cloud storage, with associated centralization, privacy, and cost concerns, though it could also be browser-local temporary storage (cookies / localStorage / IndexedDB / origin-private file system), with reliability and portability concerns.
I'd rather have the inconvenience of clicking the file I want to overwrite than accidentally giving a web-app access to something I didn't intend to. Making mistakes should be hard and intentional.
I'm a real person, and I'm deeply concerned by a) the way Chrome is trying to become the de-facto "standard" for web apps and bully or dare the other major browsers into following suit or being seen as "out of date", and b) the level of access Chrome is trying to give to itself and web apps running in it. Google is already very clearly exercising its market dominance in search and other areas to try to gain ever more of our attention and data.
I'm insufficiently informed about the differences between File System Access API and Origin Private File Access to have an opinion on which of those I think is a better choice, but please remember that Your Experiences Are Not Universal.
The Origin Private File Access API seems to be a subset of the File System Access API. You can see Firefox 111 has been added to the browser compatibility chart here for most features:
For what it’s worth, mac apps have had disk access permission prompts (along with prompts for several other permissions) for a while now. Its permission system isn’t perfect, but it’s a far cry from unpermissioned access.
Windows and Linux do have a way to go in this regard, though. I’ve seen efforts from the Elementary OS team to include some form of permissions in their distro but I’ve not seen it elsewhere in desktop OSes aside from macOS.
Yeah this is my take too. I generally appreciate and support Mozilla, but this time I feel like they're on the wrong side. If I can use a webapp that persists a file to my filesystem, it means I can have a local backup without having to make an account for a site.
As a web developer I tried really hard to make an offline-only "progressive" web application.
It was a web-based clone of the "Strong" Android app - a simple fitness tracker that is basically an excel spreadsheet. I made for myself with no intentions of commercialising.
I stored all the records in IndexedDB but really wanted to persist them to the fs as a file. I was hoping to sync workouts at the user's discretion - put the "workouts" file on you Google Drive or whatever and just load it using the app when you use it.
It wasn't possible, best I could do was a manual import/export.
Worst part was, a few months after I made the app, Chrome dropped a bug on an update that wiped local storage on update, so I lost months of IndexedDB records.
I now look at apps like Google Sheets and Google Docs with disdain. Why can't they be distributed as a PWA that interacts with logical files that exist in my filesystem? Files I can generate from other applications (like performance profilers).
Combine FS access with using WASM as a compile target, suddenly you're writing native cross platform applications in C++, Rust or your language of choice - if WASM ever gets off the drawing board.
I feel like the web is an analogy for Fusion, the good part is always a decade away.
> Why can't they be distributed as a PWA that interacts with logical files that exist in my filesystem? Files I can generate from other applications (like performance profilers).
And files which other folks can generate, like marketing malware injected there by out-of-browser applications and/or shady OS vendors (who might pre-populate data for their own sites, as well as business partners' sites (for a fee, of course), under the pretense of "improving user experience").
If browser-accessible storage is accessible to arbitrary out-of-browser applications, arbitrary package updates and installers can _put stuff there_ or overwrite stuff which is already there. We can be certain that such things would rarely, if ever, be to users' benefit.
Obviously it would be behind a user access prompt.
With Google Sheets, one thing I find annoying is; I am unable to write/pre-format a bunch of data to a google sheets specific document (containing formulas, graphs, etc).
Instead, I must interact with the Google Sheets API, force the user to SSO, and programmatically assemble a sheet via the API.
It's difficult to distribute templates, and google sheet document links cannot be moved out of Google Drive. If they are, they cannot be recovered when they are moved back into Google Drive.
Macros are evaluated by Google's cloud compute and not locally on my machine, so they have some crazy convoluted way to implement macros.
This is the model a lot of web applications take - "anything happening in the browser is not happening on your computer". I want to view the web as an alternative to GTK, Cocca, WinUI - an ergonomic cross platform GUI toolkit.
Electron is evidence that I am not alone in that thought process. Giving the browser greater capabilities with a sensible user-prompt security model would allow PWAs to replace Electron - reducing the overhead of running several Chromium instances to access applications that are just web apps which need FS access.
I as a user on the other hand don’t want a browser to host “applications” that have arbitrary access to a folder on my file system. I’m okay with it having implicit access to locked down folder if the operating system makes it impossible for any file in that folder to be an executable and if when you double click on that file, it can only launch the web page that saved it. The latter is to prevent web apps from saving files like bash scripts, macros, etc that can be easily executed.
Of course, and that's sensible. It's just about drawing a balance of safety and utility.
Implicit persistent file system storage based on origin is fine, given scripts cannot automatically execute things there. Could use it to store sqlite databases or whatever.
Access to folders and such (like through the filesystem API) also makes sense because it's via a user prompt.
Giving the browser more powers would eliminate the demand for platforms like Electron - which are basically inefficient unsandboxed PWAs
> Worst part was, a few months after I made the app, Chrome dropped a bug on an update that wiped local storage on update, so I lost months of IndexedDB records.
That is the state of web currently. I don't care if FAANG or some standard committee have RFC saying that the storage is persistent, if it is NOT a file on the system it can just go away much like cookies or cache. Just think of what Safari did to indexdb of sites that is NOT bookmarked on the screen.
Saving user's work to IndexedDB turned in to a real problem for us for a similar reason: sometimes users go in to their browser settings and click an option with wording like "clear cookies", and then it also wipes IndexedDB and all their saved work. I don't know if that applies to OPFS, but saving to the real file system (rather than just OPFS) seems a lot safer, and also integrates well with other tools, like backup software.
I've also long felt that "cookies" is a really poor term - these days it really refers to "storage on your local device accessed by websites", and the confusion literally leads to data loss.
and element.click() followed by document.body.removeChild(element);
This works perfectly fine for saving single files. FileSystem access API is useful when entire directory needs to be stored and perhaps without the standard SaveAs.. UI.
I wonder if the argument is here then to make the browsers as secure as a desktop app by giving them all the possibilities of a desktop app?
Giving web and desktop apps the same access - temporarily or permanently alike, no difference - to local data and system will make both the same secure. Or the web one being even less secure as that is inherently remote centered while the desktop could be restricted to local.
Ultimately nothing is secure with a non-paranoic user nowadays so idealisticly no reason not allowing the same access to a web app. But oh there is! Knowing that one does not need to worry at least about a surely web app digging around in the local system above desktop apps that may or may not send local data somewhere is better. Should mitigate the risks not aggravate!
Btw. desktop apps has no unpermissioned access to everything on your system.
I don’t like OPFS much more; almost less, in fact.
“It is not intended that the contents be easily user-accessible” is different from “it is intended that the contents not be easily user-accessible”, and they sure seem to be trying for the latter when they don’t need to, especially given that we know it’ll be a short matter of time until OPFS is being abused in some way.
If your app is complex enough to need something like this, you probably should make it native anyway (the browser interface is going to get in the way). Don't try to turn the browser into an OS !
(I probably shouldn't give any support to Windows by even mentioning it, but doesn't it have built-in sandboxing and especially permissions too these days ? What else the "run as an admin" command is about ??)
The existence of two apps that spent countless man-years implementing their apps to run in the browser doesn't make them a good example. Same goes for VS Code which inevitably comes up in these discussions.
You’re looking at it from an engineering perspective, I’m looking at it from the user perspective.
I’m not saying the web is the technically best platform to implement a native app, I’m saying that users want to use these complex apps on the web. Making a native app that has to be installed is limiting your audience.
> I’m not saying the web is the technically best platform to implement a native app, I’m saying that users want to use these complex apps on the web. Making a native app that has to be installed is limiting your audience.
As someone who has used Figma since it’s inception I’ve always hated the web interface. I like software being it’s own application with its own suite of tools and shortcuts that are only beholden to the OS, not the OS + Browser.
I've had tons of friends, family, and co-workers complain that Google Docs' performance is astonishingly shit, and the UI terrible. I know one non-nerd writer who does all his writing in some old-ass version of OpenOffice (yes, not even LibreOffice) specifically because he finds Google Docs' poor performance intolerable—so bad that a giant, slow hog like OpenOffice is much better! For my part, I use Pages, because it's got about 2% the effective impact on my overall system responsiveness, of having a Google Docs tab open, and doesn't have painful input latency like GDocs.
It's free and available everywhere, so you're not imposing on anyone when you share a doc with them. That's the appeal. ~Nobody I know actually likes it. Googlebucks delivering free service is the reason it's dominant. Easy to win a competition by burning cash.
Users would prefer a better product (I'm certain a much better one could even be delivered in the browser—Google's god-awful at writing efficient customer-facing software, especially on the Web) but GDocs wins due to subsidies and network effects. Its winning has little to do with whether customers would prefer native (or just somewhat better in-browser) software.
Native v. non-native, maybe they don't care, but good, yes, they care.
> I’d argue “users crave native experiences” is the engineer thinking. I have friends, family and hundreds of coworkers using Google Docs. No one cares.
They care. They just can't put in words that engineers understand.
"This is slow", "why can't I copy-paste?", "why is it laggy?", "why does my laptop het up?", "why do I have to wait X seconds for this to open"... All these are "users crave native experiences".
On top of that there are power users. Who may not be engineers, but who rely on certain things that exist in the system. From shortcuts (half of which are hijacked by the browser) to offline use to ...
On top of that a decade of moving everything to web tech has taught users to expect shittiness. Many don't even know that it shouldn't take 10+ seconds for an app containing nothing to open. And yet, here we are. Especially if it's an "app" on a spotty network connection.
When I say "no-one cares" I don't mean "they complain endlessly but accept it", I mean "they don't complain". They don't find Google Docs slow (nor for the record do I). They are happy with the solution in their hands.
Copy and paste on the other hand is a great example of the circular logic at work here: it is an issue and when browsers propose an API to fix the issue everyone throws up their hands and says "clipboard access? in a browser?!?!?" just like they are in this thread with filesystem access. Same with offline access via service workers. So it becomes a self fulfilling prophecy: web apps are inferior because they don't have features native apps have... and they shouldn't be allowed to have those features because native apps are superior. So around and around we go with the same old debate, the only losers are the users that want to just get on with things.
> When I say "no-one cares" I don't mean "they complain endlessly but accept it", I mean "they don't complain". They don't find Google Docs slow (nor for the record do I).
Again: it's because no one ever asks the right questions or actually watches people work. Or watches these apps in general.
Last year Google Docs consumed 20% of CPU on an M1 to scroll a two-page empty document. "They are happy with the solution in their hands".
> Copy and paste on the other hand is a great example of the circular logic at work here: it is an issue and when browsers propose an API to fix the issue everyone throws up their hands and says "clipboard access? in a browser?!?!?"
Nope. It's not "circular logic". If you look at iOS which actually has app sandboxing that you want on desktop (and that people keep complaining about), you are now notified when an app accesses clipboard. Why? Precisely because of the numerous issues with apps accessing clipboard data.
Again, it's funny how in the name of privacy you're literally arguing for giving web sites all the same access as the desktop apps that you complain are security nightmares.
> Again: it's because no one ever asks the right questions or actually watches people work.
This thread is getting nowhere but I'll leave it with this: the attitude you've outlined here is really patronizing. That these users can't possibly have valid opinions about the tools they use, if they dare to be happy with them they are wrong because you know better than they do. How dare they not care about 20% CPU usage! How dare they!
> it's funny how in the name of privacy
at no point have I made an argument that has anything to do with privacy
> the desktop apps that you complain are security nightmares
nor have I ever claimed desktop apps are security nightmares.
Like I said, I think I'm comfortable wrapping up my contributions here. I don't think conversation beyond this point is productive.
> This thread is getting nowhere but I'll leave it with this: the attitude you've outlined here is really patronizing.
It's not.
> That these users can't possibly have valid opinions about the tools they use, if they dare to be happy with them they are wrong because you know better than they do. How dare they not care about 20% CPU usage! How dare they!
You're ascribing thoughts and words to me that I never said or thought.
> at no point have I made an argument that has anything to do with privacy
What argument did you then make? We're literally in the context of why these things are the way the are due to privacy concerns
> I don't think conversation beyond this point is productive.
I don't think it was ever meant to be productive with opening like "you're thinking like an engineer and can't ever imagine what a user thinks or does"
They absolutely care, you just don't listen because you are so self centered you think your opinion and needs are more important.
Users CONSTANTLY bitch about how slow the internet is, and people who grew up with microsoft office in school complain about how mediocre google docs is.
But this is mostly (?) a historically contingent result of Google heavily advertising for Chrome while Microsoft dragged its feet to have an easy to use package manager, sandboxing, maybe flawed (?) rights management for Windows (a Windows Store comes with it's own issues if controlled by Microsoft of course).
Ignore those comments. There is a very large group of people on hacker news who do not understand and will never understand how real world products work. In their mind, native is better than a web app and that's the only way things should work.
Are you really using Google Docs as an example of the best that can be done ? (Assuming it's even a morally acceptable example, we are on Hacker News, aren't we ?)
(Also, this isn't so much about the best that can be done, but about what your median developer is able to do and/or median user is going to have to deal with.)
At no point did I say Google Docs is the best that can be done. But the efficiency with which it matched Office and blew OpenOffice out of the water ought to be of note. People weren’t just okay with office software in their browser, they flocked to it.
I don’t really see what Hacker News has to do with it. Are we supposed to deny the popularity of things because we don’t think they’re technically impressive enough?
Are we still pretending that Figma and Google Docs are good examples of applications? I want the native application features that my OS provides, not the half-baked, lowest-common-denominator kludges found in web/Electron apps.
If you can give me some native APIs which solve distribution and sandboxing, across the three major desktop OSes and two major mobile OSes, as easily as the web, then I would be more than happy to go back to native dev :D
Come on, this is an absurd response. I'm sure most of us here would love to while away untold hours learning desktop APIs for Windows and Mac, then picking up mobile APIs for iOS and Android. But in the real world we have jobs that have deadlines that do not facilitate rewriting and redistributing at least four different versions of a product. When it comes to delivering a write once deploy anywhere solution the web has no peer.
I'm not particularly happy about that but it's the way the world works. Calling people who work on the web "lazy" is a ridiculous response. Maybe you should get to work on the one size fits all native framework that will rival the web?
Building 5 apps using totally separate APIs for 5 different kinds of sandboxes, and then jumping through the arcane and hostile hoops of 5 different app stores (or 50, if you want to support all the linux distros), does not exactly count as “solved across platforms as easily as the web”
I wish it wasn't a local filesystem. Google Docs was superior (for me) in that my files were available on every device. To achieve that here would require setting up Dropbox or similar and dealing with edge cases. If this API was more sophisticated with conflict resolution, Firefox could sync these files for me (maybe S3 compatible? I dunno) and then every app could have magical Dropbox/GDrive capabilities instead of a boring old tech folder that gets wiped out every so often.
My point isn’t about local file system access. OP said that if you’re making a complex app it should be native. I was pointing out that millions of people use complex webapps every day, adding file system access is a logical attempt to meet an audience where it is.
> the browser interface is going to get in the way
Glad I’m not the only one who get irritated with browser chrome and other “browserisms” like having to include a bespoke menu system that web apps uses instead of the macOS global menubar because browser menus already occupy it.
Google Docs for instance would be a lot more nice and clean without the clutter of the browser toolbar and redundant menu system eating up all that vertical space. It’s simple enough to hack together a WebKit/Electron wrapper to get you the first half, but you’re stuck with the redundant menubar no matter what.
Actually now that I’m thinking about it, it seems like a massive oversight that the PWA spec doesn’t seem to have anything for desktop menus.
> I'd much rather live in a world where I can briefly use a web app to do some task than be forced to install a myriad of native desktop apps that have unsandboxed and unpermissioned access to everything on my system.
I just use a vanilla install of chromium for this.
The link above is to a different section of the page, giving the mistaken impression that this is unfettered access to the local file system, which it isn't. Quoting the appropriate section further down the page:
The origin private file system (OPFS) is a storage endpoint private to the origin of the page, providing optional access to a special kind of file that is highly optimized for performance, for example, by offering in-place and exclusive write access to a file's content.
Storing data in the OPFS is similar to storing data in any other browser-provided storage mechanism that's private to the origin of the page (for example the IndexedDB API). This means that files in the OPFS differ from files selected using a picker in the following ways:
- Permission prompts are not required to access files in the OPFS.
- Clearing data for the site deletes the OPFS.
- The OPFS is subject to browser quota restrictions.
Cookies already don't prompt, so I'm not sure that's the best comparison. In addition, while cookies can be created by one origin and read by another origin (a.k.a. "third-party cookies", which Firefox has been trying to deprecate for a while now), this API is private to each origin, making it useless for cross-site tracking.
As for disabling this, I assume these are the appropriate pages in the docs:
So opening a directory picker and allowing access to user-selected files is fine, however opening a serial port picker and allowing access to user-selected serial ports is not[0].
My use-case is a web-based system which includes, among other things, a payment function. I'm building an interface based on WebSerial to initiate transactions on a USB-connected Pin Pad[1]. This works beautifully in some Chromium-based browsers, but nowhere else[2].
This bothers me because it represents a dependency on Chromium and they could pull the rug out on WebSerial support any time. If other browsers supported it at least I'd have a fallback plan.
[1] For reference, the USB connection only exposes a control channel. You can initiate transactions and monitor their status, but the Pin Pad has an ethernet connection for actual communication to the payment processor. There is an option to use REST services provided by the payment processor to do the same thing, however that is significantly more development effort in our application.
This is great news. I think at least all the desktop browsers support it now so it should hopefully finally be possible to start using disk-persisted sqlite in webapps with decent performance.
> So it is a sandboxed, abstract filesystem, not rw access to my actual filesystem?
It's sandboxed storage which lives in your filesystem but is only available via the browser and is sandboxed on a per-HTTP-origin basis. That makes it impossible[^1], e.g., for x.y.com to sideload data into, or exfiltrate from, y.z.com. How the files are actually stored on your filesystem is not defined by the in-progress standards doc, but they are not stored as-is because doing so would open them up to security issues from out-of-browser sources, as well as potential file-locking problems from out-of-browser apps.
[^1]: Edit: as a responder points out: "impossible" for a given value of "impossible"
> It's sandboxed storage which lives in your filesystem
It actually barely does. Spec does not require the OPFS to be browsable in the OS's filesystem. I believe all three browsers implement OPFS as a single opaque blob on disk per origin, kind of like a zip archive.
> While browsers typically implement this by persisting the contents of the OPFS to disk somewhere, it is not intended that the contents be easily user-accessible. While the browser might make it seem that there are files, they might be stored in a database or any other data structure. You cannot expect to find the created files matched one-to-one somewhere on the hard disk.
I would guess this makes it much harder to escape the sandbox filesystem if you're not actually in the filesystem in the first place.
It would be nice if browser offer per-origin encryption of files so that if an exploit at a future date allows x.y.com to access the files of y.z.com they would only be getting encrypted blobs (unless the encryption/decryption API is also exploited, but now we're talking about multiple exploits rather than just one).
> lives in your filesystem but is only available via the browser
Strange implementation if that's the case. While I don't want my browser to give a page arbitrary access to my files, a use-case I can see is sharing files between apps and websites. Say, obsidian for organizing, vim for editing and some cloud for backup.
You must have confused the part of it only being available to the browser, I don't see how that's even technically possible.
> You must have confused the part of it only being available to the browser, I don't see how that's even technically possible.
It's uses a virtual filesystem, not available _as-is_ in the filesystem to any application other than the browser or applications which implement identical access APIs. Obviously, the virtual filesystem lives in the containing filesystem.
So any sufficiently motivated/funded malicious actor who can register a whole bundle of domains can use up 50% of the entire free space on my disk? Am I getting this right?
Is the only defense against this the requirement for per-origin permission to be granted?
OPFS doesn't really change this concern that much. IndexedDB already allows for relatively arbitary blobs of data to be stored per site (subject to existing quotas)
IndexedDB should also be disabled by default. Adding more and more storage options instead of restricting the existing ones that are already being abused is madness.
I run desktop (not mobile) Firefox with an in-memory cache only. My opinion is that on-disk cache with several days (or weeks) old content is almost entirely useless, and that the most beneficial cache use is what you fetch/reuse through a single day of running browser.
Here's how you can "make the switch":
First of all, clear your disk cache entirely. Then, head into "about:config" and change accordingly:
The number 512000 is in kilobytes. Adjust to preference. Firefox will still do some caching to disk, but these settings stop the most pressing disk writes. You may confirm the change by visiting "about:cache".
Nowadays "several gigabytes" can also be read as "almost a percent" for a 1TB disk, which for an app so central is not outrageous to me. Well maybe it could be less for smaller 256G disks.
Right now, today, Apple will sell you a brand new phone with only 64GB of storage. And that's for users whose budget stretches to a brand new iphone - plenty of people spend less.
The modern web isn't just for people browsing from high-spec workstations and gaming PCs.
Would this file system access API finally allow use to use TiddlyWiki in the browser without add-ons or external tools finally? It's one of the sticking points for me for using it.
I got tired of waiting for this and all the constraints that come with it. So I wrote my own localhost solution with Node, web sockets, and DOM traversal that ended up being faster than the equivalent GUI functionality provided by the OS.
Origin private file system access seems cool, albeit a half measure. Seems like a better alternative than putting blobs into IndexedDB.