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

Seems there are about 18 APIs that require explicit user permission: https://developer.mozilla.org/en-US/docs/Web/API/Permissions...

7 of those are actually available in Firefox at all.

It's definitely more complex than that because many of those APIs have additional areas that may or may not be covered by permissions.

For example, Firefox implemented permissions for enumerating MIDI devices, and Chrome didn't, with predictable results: https://twitter.com/denschub/status/1582730985778556931?s=20

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.

It becomes effectively "random" (arbitrary) when no or very little concern for second order effects goes into the proposal. We saw this with ActiveX controls. It becomes a game of chicken that eventually leads to an imbalance where website operators always win.

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

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.

"Good sites". Like the "good" apps on Android that ask for a hundred permissions at once. Like that good Android flashlight that ended up settling with FTC: https://www.ftc.gov/news-events/news/press-releases/2013/12/...

Edit:

> there are already so many ways to scam these people that we need better solutions.

We're literally in a discussion about one such solution: reduce the chance of scamming by sandboxing.

And the question isn't just scamming. It's also things like fingerprinting: https://twitter.com/denschub/status/1582730985778556931?s=20

The linked article is a bit different

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

> The linked article is a bit different

We could go for a different one: https://cybernews.com/privacy/android-apps-are-asking-for-to...

There's bo 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 an 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.

[1] https://www.construct.net

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 frontend 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 is supported by all major browsers nowadays—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, allowing them to veto (or rename) the written file at a fine-grained level—which will be difficult or impossible to do if the Chrome team's proposed API because standard.

Overall, the File System Access proposal is a bad one that favors authors over users, 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 support for yet another experimental API of theirs will be sunset in some future release.

This is not access to the filesystem.

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

While Google's new API definitely is.

* * *

What's wrong with <input type="file" /> and the $HOME/Downloads folder?

Why is arbitrary access to a whole folder needed? Cool, yes. Dangerous? Very.

That's how you end up with "March 2023 Report (Final) (Edited) (3).docx".

Making users repeatedly upload and download the same file to work with it is clunky.

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

> So it's also what real people actually want to use in browsers.

I am a real person and I don't want this.

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

It is unclear why the views of 65% should be also pushed onto me.

You’re free to not use it?

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.

Jesus Christ. 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. You put a feature in front of people and see how many use it. How many the 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 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?

Yes.

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.

> desktop web apps

....what?! ... World Wide Web Desktop? World Wide Web on my desktop? My desktop on the World Wide Web? There must be some confusion here. : )

If an app becomes desktop app why the heck using a browser?

Because the web solved app distribution and sandboxing before desktop operating systems did.

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:

https://developer.mozilla.org/en-US/docs/Web/API/File_System...

Perhaps your sample is biased?

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

> If your app is complex enough to need something like this, you probably should make it native anyway

Are we really still making this argument in an era where Figma and Google Docs exist?

Don't they save the files on the cloud? I think this is about having access to local file system.

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.

I'm not blaming Mozilla here (at least I don't think I should..? Not sure that the «enabler of bad behaviour» argument can really apply here ??)

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.

Yes and Google Docs is not nearly as good as Office or even Apple’s iWork suite.

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.

Figma literally said they had to build a browser inside the browser: https://www.figma.com/blog/building-a-professional-design-to...

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.

No. What users want is using complex apps that are smooth, fast, support native behaviors (anything from screen readers to system shortcuts) etc.

They couldn't care less about the tech behind those apps.

Thinking that users "want to use complex apps on the web" is literally what engineers are thinking.

And especially in the actual context of the thread my original point still stands.

We can argue until the end of time about what we think users want and it’ll never get anywhere.

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.

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

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

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.

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.

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?

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

"Waaah waah I get paid six figures to npm install and don't want to actually do any work but still want to be called an engineer"

Seriously it's pathetic. Stop making my computing environment worse just because you are too lazy to learn some desktop APIs

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?

I mean, Mac/iOS App Store apps are already sandboxed and easily distributable.

Windows, Android, and Linux all have stores/package managers and I assume/hope some level of sandboxing.

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”

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

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.

/rant

If we're calling C++/Rust to WASM in the browser "native", then Javascript is native also.

> 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

I use FitNotes[0] which seems to do most of what the Strong app does and I don't think it needs "online" except for the optional cloud export.

[0] http://www.fitnotesapp.com/

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

In Chrome the wording is "cookies and other site data".

Saving a file is easily implementable without a Filesystem access API. See https://draw.io/ as an example.

Draw.io's local file saving is clunky as hell and I'm sure even that was an absolute pain for them to get working.

I actually implemented it recently in one of my open-source apps. It's 6 lines of Javascript: Create an <a> element, set the data in its href with:

element.setAttribute("href","data:text/plain;charset=utf-8," +encodeURIComponent(content))

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.

Those users probably didn't need their RAM anyways

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

Unfortunely it harldy matters anymore if they implement something or not.

On all our projects it is already downgraded to "nice to have" status, if it matters at all.

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.

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.

> but I’ve not seen it elsewhere in desktop OSes aside from macOS.

Flatpack-ed applications on Linux do have similar sandbox.

Windows does as well. But like Flatpak, I think they're handled at install time, not at-access time.

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.