This would be easier to assess if it were clearer what would be made accessible and how that access were managed. For instance, if it were possible to access arbitrary directories or files, that would be very bad. It is also possibly bad if access were granted to spaces that are shared between origins or shared with native applications. Of course, the main reason you might want to allow access to files is to enable passing of information between the web and other applications, so systems for managing access are crucial.

Working out what is safe, building systems to constrain use to fit within those bounds, and establishing norms around use are all problems that likely require significant research. We don't have any established wisdom on these topics, so I expect that will take time. The proposed spec is completely silent on this, which indicates to me that this is still very much exploratory work.

Like the other proposal, I would suggest defer until more information is available.

Yeah, defer seems reasonable to me as well given that reasoning. I intend to open one issue on the repo about something else I noticed, though.

Closed by #156, but it would make sense to reopen this or file a new issue if you believe there's more to evaluate.

We've been working hard over the last year and a half to get the spec (and chrome implementation) in a better shape. As such we would appreciate if you could take another look at this. Hopefully it is a lot clearer now what access this will give, and how we're thinking about doing this safely. As such would it make sense to re-open this?

Happy to reopen this if you think that it is done. The README on the repo suggests that the spec is "very early" though. But my initial assessment is that the protections described in the spec are inadequate and I am of the opinion that this should be marked harmful.

From my original comment:

For instance, if it were possible to access arbitrary directories or files, that would be very bad. It is also possibly bad if access were granted to spaces that are shared between origins or shared with native applications.

The first is only partially curtailed by allowing user agents to block access to /etc and similar, with additional discussion about ~/Downloads. The second seems not to have been addressed at all. The spec does note that this could be used for tracking, which doesn't really cover the full extent of granting multiple origins access to the same file(s).

That is relatively minor in relation to the other concern:

Working out what is safe, building systems to constrain use to fit within those bounds, and establishing norms around use are all problems that likely require significant research. We don't have any established wisdom on these topics, so I expect that will take time.

There is more substance to the current proposal, which is good, but it still falls short in this regard. I recognize the difficulty posed by trying to bootstrap this process, but - at least for me - I would like to see a lot more before I would be comfortable with this being shipped.

These concerns do not apply to getOriginPrivateDirectory, which avoids many of these issues. Though there are some minor UX concerns even there (is this folder from example.com or example.com as framed by foo.example? and how do you even communicate that distinction) getOriginPrivateDirectory is far less problematic overall.

(Filed WICG/file-system-access#211 on the name of that method. It does seem to use the new underlying primitive which will eventually enable proper partitioning.)

The README on the repo suggests that the spec is "very early" though.

Oops, sorry about that. I forgot to update the README.

It is also possibly bad if access were granted to spaces that are shared between origins or shared with native applications.

(I assume you're talking about write access specifically, since browsers already grant read access to spaces like that) Given that that is literally the exact use case we want to enable with this API, yeah, if you consider that bad you probably won't like the API. We think that the UI affordances (permission prompts, etc) we have implemented sufficiently help the user understand what is going on, and give them enough control for this to be safe.

establishing norms around use are all problems that likely require significant research

Going off this demo on Chrome 86, it seems to fairly intuitively extend the normal file-picker behavior with just an extra prompt asking for the ability to save changes to the file:

This doesn't feel like something that's too far away from established norms. In one sense, it's like a "Save As..." dialogue which has a persistent save ability until the tab is closed.

I could be overlooking something, but it seems that the only real additional risk here is ransomware-type attacks, and although I think Chrome's modal is quite clear, Firefox of course has the ability to add warnings that are more "scary" to make these sorts of attacks very hard to pull off.

Since the safety/danger of this feature can be decided by the browser vendor via the scariness of the warnings, it seems like the question for Firefox (and other browser vendors) is: Is there enough expected utility in this feature given the amount of usage they predict, given the scariness-level that they've chosen (since usage will decrease with increased scariness). It's not really a question of safety.

To zoom out a bit, though: Users want to edit their files (videos, images, games, 3D models, etc). If they can't do it on the web, they will download a native application. That native application will have access to their files, including sensitive directories, and will most often have access to many more sensitive features without any warnings to the user.

So, given that the scariness can be controlled by the browser vendor to match the scariness of the "The file you just downloaded can harm your computer" warning (after downloading executable files like exe and deb), it seems like this feature is a net win for user safety. If this feature is implemented, users suddenly gain the ability to limit the permissions of their editing applications to only read/write on the relevant files. If this feature is considered harmful (again, given the browser-vendor's control over the scariness of the warning/permission dialogue), then that would seem to imply that downloads of executable files should be deprecated in Firefox, or that the ability to download these types of files is only regretful backwards-compatibility.

I'll caveat all of that by saying that I haven't actually read through the spec, so I'm not commenting on the lower-level details here. These are just (potentially naive) thoughts from a user and developer perspective, looking only at the high-level features.

I can understand not wanting this available for websites generally, but would it be possible to make it available for installed web apps?

Currently, as josephrocca says, if users want to edit files, they can download and install software, which has more security issues. They could also install from an app store or other curated repository, which may provide some confidence in security (depending on how thoroughly the curator checks this), but creates a gatekeeper between the app creator and user. Alternatively, they could edit files "in the cloud", which gives the host full control over their files. Web apps with this API would be better than any of these options, I think.

but would it be possible to make it available for installed web apps?

If by installed web apps you mean PWAs, then Firefox is dropping support for them, so...

That said, I think Native FS should work everywhere.

Browser-based scientific IDEs like Jupyter, Pluto.jl, iodide, and more would benefit enormously from this feature. Currently we need to implement our own (confusing) clone of the file browser, which is yet another hurdle for new programmers.

This API would be enormously useful for a file transfer web service that I'm currently building. Please consider adding support to Firefox!

I'm also the lead maintainer of the WebTorrent project which runs https://instant.io which could use this API to make downloading all the files in a torrent much simpler.

FYI, in WICG/file-system-access#287 (explainer at https://github.com/WICG/file-system-access/blob/main/SuggestedNameAndDir.md) we're adding some extra options to the file picker API part of the File System Access API.

The basic problem with persistent read access (let alone write) is that the implications are unclear to users. And you cannot solve that by changing the API. And this has been discussed in prior comments as well as directly with Google, e.g., in the W3C TPAC meeting where this was first suggested. It's simply not true that we do not directly engage.

OK, thanks for the clarification, and sorry that I misunderstood the level of prior engagement.

we don't have a good way of informing the user about the risks

@annevk @martinthomson @tantek I'm not sure if there's any room for discussion/reversal here, but in case there is: I don't understand why it would be hard for Firefox to communicate the implications here? Is it not true that, as I mentioned in my comment you can make the warnings as detailed/multi-step/scary as you like? You could have several confirmation steps like "are you sure? [explain again in a different way to ensure they get the message]". It seems to be less a matter of "is the feature secure", and more "would the feature be used enough given how scary we're going to make the warning". Would you be able to comment on this point?

Also, as mentioned in that previous comment, Firefox allows downloading executable files (which is often required in part due to a lack of a standard browser API like File System Access), which can give access to every permission on the users system, and although I couldn't get any warning to show on my system when downloading and executing a .deb, apparently Firefox's warning for Windows users looks something like this:

Since running an executable file is significantly more dangerous than allowing File System Access, and the above warning message is deemed adequate for executable files, wouldn't that imply that Mozilla would deem File System Access safe even with a relatively simple warning like the one above? Obviously it could be made scarier than that, but my point is that it seems that the user safety bar is actually fairly low? Could you please also comment on this point?

The basic problem with persistent read access (let alone write) is that the implications are unclear to users

Note that in Chrome the access is revoked once the user has closed the tab. I find it hard to understand why the implications would be unclear if it were simply explained it with a sentence or two, and with an additional confirmation/warning. Chrome's "This website will be able to edit thefile.txt until you close all tabs for this site" (after the user has picked the file/directory) seems quite clear, but again, Firefox can choose to make this a much scarier multi-step process - seems like more of a UI decision rather than a security/safety problem that's inherent to the File System Access API.

One side note that I'd add is that there's a precedent for this pattern/flow in Android's permission system (I'm not an iOS user, so I can't comment on that). Apps can request access to a user-selected "root folder" and retain access to it until the app is uninstalled or has the permission manually revoked. Apps are different to websites, so I don't want to be misunderstood here - I'm just saying that many users will likely be comfortable with this "give the application access to a folder" UX pattern already. Again though, this is just a minor/side point - it doesn't really interact with my previous points.

Given the value of this feature to developers (as evidenced by the comments in this issue), it seems well worth the time to explore UX approaches which can make this feature clear/safe, rather than to mark the API as inherently harmful. I think it would be a bold claim to say that no UX design can make this feature meet Firefox's safety standards! :)

It seems the Mozilla people have dug their heels in on this one. It makes me sad for Firefox, because with Google and MS going full steam ahead on this, and now running origin trials for the draft File Handling API (which actually depends on the File System Access API), Firefox is going to find itself at a significant disadvantage when it comes to the experience of running enhanced web apps. I had to smile ironically when this API was marked as "harmful". It is indeed harmful... to Firefox's market share.

From reading all this, my feeling is that there is two options:

1. The Firefox team is saying "we should prevent our users from hurting themselves, because they are dumb"
2. The Firefox team didn't read the API draft, because it proposes:
   • to limit what users can give access to
   • to communicate what is happening to the user

Dumb users will just download malware that executes outside of the Firefox sandbox. You can't prevent them from doing that either. Please make software for people who aren't dumb.

I feel like this could be done quite safeish (nothing is 100% safe) with a few design decisions:

• Limit the API to be used within the user's home folder, (excluding folders like "Roaming" on Windows), or be even more specific and only allow to give access to folders like Documents, Pictures, Downloads ...
• Prevent the API from creating executable files

As pointed out, Chrome doesn't give you access that persists over sessions. Once you close all tabs, access is lost. You can persist the handles, but you will have to ask permission again in a new session.

Persisting handles for accessing directories read-only is my interest, by the way. We would like to make uploading large groups of big files smoother and resumeable. It wouldn't be a problem to ask the user permission to a folder each session. But we don't want to require the user to find the correct path every time.

Overall, I feel like this API is a very decent draft. Please have an open minded discussion and be more specific of what the problems with this API would be.

It's very deceiving to see proponents of this api turn the argument into a "dumb" vs. "not dumb" users, because this is unlikely to get you to where you want, and it ignores the reality that most users have no idea what a file system is. This is for good reasons, since that's a low level abstraction that should not be exposed to users. We're in 2021, users deserve better abstractions to manage their resources.

The reality is that giving write access to any app needs a very auditable trust model. What happens when app-i-trusted.com gets hacked and starts storing illegal material on your device? YOLO! We would at least need something close to a history that can be rolled back provided by the user agent. But should that be "left to the implementation", or actually mandated by the spec?

I also feel that some of the disconnect here is to consider that what Chrome implements is the spec, while the spec is not that precise yet. That can be fine as a draft, but that also means that the Chrome implementation can change in ways that lessen security while still being compliant to the draft.

What happens when app-i-trusted.com gets hacked and starts storing illegal material on your device?

As some of us keep trying to explain, you must give permission for each new session for a file to be written to your device. Modern file systems back up user files, this is not something the browser could or should provide. Please remember that Firefox already fully supports downloading files -- even executables -- to the file system via file pickers. This API is specifically designed to block executables, and won't let you grant permission to a folder that contains system files. It's actually more secure than currently supported APIs in Firefox that allow users to store randomly downloaded files anywhere in their filesystem with no permission prompts.

most users have no idea what a file system is. This is for good reasons, since that's a low level abstraction that should not be exposed to users

I couldn't disagree more. The one thing everyone understands about a computer is that it contains their files / documents / photos / mp3s / mp4s. Users understand files. They swap them, share them, put them on USB sticks. My sister and my mum understand files. They certainly don't understand blobs stored in IndexedDB that they have no idea how to share, attach to emails, etc.

As some of us keep trying to explain, you must give permission for each new session for a file to be written to your device.

And because you had no problem 100 times, you keep giving permission and get in trouble at the 101th. Users can't tell what changed on the remote side (that's why not breaking the sandbox model of the web is so important), so the per-session revocation only prevents drive-by changes. This is useful but not sufficient.

Modern file systems back up user files, this is not something the browser could or should provide.

Most don't, not in a way that let users recover overwritten files, etc.

Please remember that Firefox already fully supports downloading files -- even executables -- to the file system via file pickers. This API is specifically designed to block executables, and won't let you grant permission to a folder that contains system files. It's actually more secure than currently supported APIs in Firefox that allow users to store randomly downloaded files anywhere in their filesystem with no permission prompts.

Yes, old APIs have issues, and they should be deprecated. That doesn't magically make new ones good enough.

I couldn't disagree more. The one thing everyone understands about a computer is that it contains their files / documents / photos / mp3s / mp4s. Users understand files. They swap them, share them, put them on USB sticks. My sister and my mum understand files. They certainly don't understand blobs stored in IndexedDB that they have no idea how to share, attach to emails, etc.

Yes they know about documents, that you can call "files". Certainly not about filesystems, mount points etc. The web can be superior than old native stacks, but not so much if the only goal is to "bridge the gap" instead of trailing a better path. Exposing a good api for document management, that you can implement on top of a local fs, and/or backing up remotely etc. would be vastly better.

Exposing a good api for document management, that you can implement on top of a local fs, and/or backing up remotely etc. would be vastly better.

While it sounds good, unfortunately this would be completely useless for my use case.

Exposing a good api for document management, that you can implement on top of a local fs, and/or backing up remotely etc. would be vastly better.

While it sounds good, unfortunately this would be completely useless for my use case.

Not sure why, since this api doesn't exist.

@fabricedesre Because anything abstracted and locked down using current technologies like IndexedDB or Cache API or sandboxed filesystem is not going to allow me to store a 66GB file in it. And why would a user want to lock such an archive up in a domain-restricted sandbox that does not let them exercise their free right to access open-source data, put the data on a USB stick, share them with other users, etc.? I'm a strong advocate for keeping things simple, open and accessible to users with smart security models.

@fabricedesre Because anything abstracted and locked down using current technologies like IndexedDB or Cache API or sandboxed filesystem is not going to allow me to store a 66GB file in it. And why would a user want to lock such an archive up in a domain-restricted sandbox that does not let them exercise their free right to access open-source data, put the data on a USB stick, share them with other users, etc.? I'm a strong advocate for keeping things simple, open and accessible to users with smart security models.

We're getting very off-topic but I never implied that this "content management" api should use IndexedDB or the Cache API. It can be backed by a file system, but should not expose it directly.

I'm sorry about the "dumb" "non dumb" comment. I was trying to communicate my feelings on this and might not have done it in the best way.

You're saying we need an auditable trust model. But would you agree that, in the end, it is the user's choice to trust a web app or not trust it? I think that is a reality we have to live with.

I do get that you don't want the users to give permission out of habit. We could have a system that checks the checksum of the executing code and warns the user when things have changed. But even then, there are very few users capable of assessing whether a change is harmful, let alone spend their time on checking this.

We could build a trust relationship between Firefox and certain apps, but I feel like this would put to much burden on the Firefox development.

If you could give a reference to the kind of trust model you would be looking for I would like that. An example, or an article describing how this could look like. I have a hard time wrapping my head around how you would do this.

Looks like we're heading for a repeat of what happened with the File and Directory Entries API, aka FileSystem API. Firefox didn't support that one either, though ended up having to implement a subset of the API. Seems there is a fundamental and irreconcilable difference of philosophy here. It's a real shame IMHO.

I find it hard to believe that this API can be so dangerous and confusing that Firefox can't safely ship it, but Chrome and Edge have been safely shipping it since as early as October 2020 without issue.

Users who can use a file picker to select files to use with a website can reasonably be expected to understand the statement "This website will be able to edit example.txt until you close all tabs for this site".

It's my belief that if Firefox doesn't ship this API, developers will:

1. recommend users switch to Chrome/Edge for a better experience; or
2. ask Firefox users to download an Electron app that has unrestricted user-level filesystem access

Both of these options make me sad.

You're saying we need an auditable trust model. But would you agree that, in the end, it is the user's choice to trust a web app or not trust it? I think that is a reality we have to live with.

In the current web model, users don't have to trust the web app, they only have to trust their browser because its sandboxed execution model offer strong guarantees. Some aspects of this api are breaking away from this model unfortunately. That people want to accept that, especially browser vendors, is frightening: in the name of bridging the gap with native, they actually kill one of the web strongest differentiator.

I do get that you don't want the users to give permission out of habit. We could have a system that checks the checksum of the executing code and warns the user when things have changed. But even then, there are very few users capable of assessing whether a change is harmful, let alone spend their time on checking this.

You're right, we should not ask the user this kind of question because most (if not all) can't make an informed decision.

We could build a trust relationship between Firefox and certain apps, but I feel like this would put to much burden on the Firefox development.

I agree - that's what we did in FirefoxOS, with signed packages that get access to potentially dangerous apis. This is not very webby: scaling woes, not a level-playing field. Users then delegate trust to the store operator.

If you could give a reference to the kind of trust model you would be looking for I would like that. An example, or an article describing how this could look like. I have a hard time wrapping my head around how you would do this.

I don't know of a better alternative than signed code, or defining high level apis. The second option is what WebShare and Contact Picker APIs are doing. The drawback is that you end up with many specialized APIs, hence letting only browser vendors innovate. A more generic delegation system (like the WebActivity used in FxOS) is a better fit since it allows signed code to expose various high level APIs without needing browser runtime changes.

I find it hard to believe that this API can be so dangerous and confusing that Firefox can't safely ship it, but Chrome and Edge have been safely shipping it since as early as October 2020 without issue.

Do you seriously believe that such a short time frame is meaningful to declare that there are no issues with this API?

Users who can use a file picker to select files to use with a website can reasonably be expected to understand the statement "This website will be able to edit example.txt until you close all tabs for this site".

That's not the problem. The problem is that nothing guarantees to the user that a malicious version of the site won't erase their files, fill them with garbage, ask for a ransom, etc.

It's my belief that if Firefox doesn't ship this API, developers will:

1. recommend users switch to Chrome/Edge for a better experience; or
2. ask Firefox users to download an Electron app that has unrestricted user-level filesystem access

Both of these options make me sad.

Yes, this is sad. It's also very sad that the market leader is harming the web by not looking for solutions that don't change a fundamental security property of the web platform.

The problem is that nothing guarantees to the user that a malicious version of the site won't erase their files, fill them with garbage, ask for a ransom, etc.

@fabricedesre I'm sure you're familiar with https://wicg.github.io/file-system-access/#security-considerations. This kind of issue can be mitigated by the User Agent within this API:

• this API does not provide any way to mark files as executable
• user agents are encouraged to apply things like Mark-of-the-Web to files created or modified by this API
• user agents are encouraged to verify the contents of files modified by this API via malware scans and safe browsing checks, unless some kind of external strong trust relation already exists
• user agents can grant write access to files at whatever granularity they deem appropriate.

In other words, Firefox could support this API while creating an extremely strong security model within the existing spec. The API itself does not require the User Agent to leave the stable door unlocked, as you imply.

The Mozilla focus on security is commendable, but it seems to block consideration of the ways in which this API can be a real benefit to users and open-source developers while taking security seriously.

But I guess we're going in circles now, and it's no use flogging a dead horse any further... 😕

In other words, Firefox could support this API while creating an extremely strong security model within the existing spec. The API itself does not require the User Agent to leave the stable door unlocked, as you imply.

I don't think any of the cited protections are enough to prevent data loss or corruption, but I guess this is a matter of how much risk you're fine with.

The Mozilla focus on security is commendable, but it seems to block consideration of the ways in which this API can be a real benefit to users and open-source developers while taking security seriously.

Not sure why "open-source" is relevant here, but Mozilla is the one that actually shows more concern about users. Threats like server compromise are almost never considered by chrome, and that's quite incredible.

But I guess we're going in circles now, and it's no use flogging a dead horse any further... confused

Indeed!

The problem is that nothing guarantees to the user that a malicious version of the site won't erase their files, fill them with garbage, ask for a ransom, etc.

Nothing guarantees that an executable file won't erase your files, but Firefox still lets you download them.

What about <input type='file'>? Nothing guarantees that a website won't take your files and threaten to release them publicly unless you pay a ransom. Have you considered why Firefox allows this feature, despite this obvious risk?

In the current web model, users don't have to trust the web app

This is only partially true. You can rely on the browser to prevent the site from accessing system resources by default. But the browser also allows sites to pierce the sandbox with user consent. Camera, microphone, location, and even <input type='file'>, as I mentioned earlier.

No one is seriously suggesting that Firefox block the user from downloading executable files or block <input type='file'> because it "breaks away from the web model".

The world has risk, but we must find a way to live in it and get things done. The bar can't be "we can only ship this API if you can guarantee that a bad actor won't try to pull a fast one on a user". Camera, microphone, location, <input type='file'>, all have similar risks to the user if the website is bad.

The questions must be:

• Does the potential benefit outweigh the potential harm?
• Is it possible to clearly explain the permission request to the user so they can make an informed decision?

No one is seriously suggesting that Firefox block the user from downloading executable files or block <input type='file'> because it "breaks away from the web model".

Actually Firefox will block downloads that are identified as malware through safe browsing.

* Is it possible to clearly explain the permission request to the user so they can make an informed decision?

It's clear that a user can understand the consequences of sharing camera and microphone access. Much less when we talk about letting a website manipulate files. That's exactly the criteria used in FirefoxOS to decide if an api could be exposed to the web at large or only to signed code.

Not sure why "open-source" is relevant here

As I put in my original use case above: "Our users tend to be Open Source devotees and privacy conscious, hence Firefox is the natural browser for many of them. Frankly, we can't understand Mozilla's stance on this API... This API, amongst others that are trying to bridge the gap between native apps and web apps, has the potential to liberate users from dependency on gatekeepers (vendor Stores) for their apps, and to enable a new era of lightwieght, distributed open-source applications for which Firefox could and should be the platform of choice."

We're having this discussion at all because developers of PWAs actually care about Firefox. The commercial developers are neither interested in PWAs nor in Firefox, sadly.

The commercial developers are neither interested in PWAs nor in Firefox, sadly.

Don't underestimate us commercial developers. We're very interested in both Firefox and PWAs. We have feelings too 😄

And indeed it would pain me to have to tell users "works best on Chrome and Edge" or something like that. But if this API or an alternative API is not coming to Firefox, it will probably happen.

For our Firefox users, we will probably end up creating a desktop application for uploading, which our users will download and use, because they trust us. Which would be kind of similar to trusting us with file access permissions. Only as a desktop app, we would have access to all the user files by default.

Security-wise Firefox granting access to a specific file or folder, with a lot more checks and boundaries, seems like the better option.

I do get that you're trying to defend the sandbox model, but I wonder how sustainable it is.

Technologies like WebAssembly and WebGPU would give us the possibility to offer users web apps capable of doing significant local data processing in the near future. But without the File System Access API or something similar a lot of user friendliness will be lost.

Sorry, @NotizMe, I was answering a specific point about why open-source devs often champion Firefox, and I completely overlooked that there are commercial services provided via webapps. The main point is that it ought to be in Mozilla's long-term interests to help enable an ungated, anti-monopolistic app framework based on open standards. I'd love to be able to recommend Firefox as the platform of choice for my PWA, but I can't do that ATM, because Mozilla devs have taken this apparently hostile/purist stance towards PWAs. I too am forced to offer an Electron app as an alternative for those who don't have a Chromium browser installed.

After reading through this thread, I'm a bit confused. The second half of the discussion focuses on the security threat that a trusted web app gets compromised and does bad things with your data:

What happens when app-i-trusted.com gets hacked and starts storing illegal material on your device?

https://github.com/mozilla/standards-positions/issues/154#issuecomment-874878839

The problem is that nothing guarantees to the user that a malicious version of the site won't erase their files, fill them with garbage, ask for a ransom, etc.

https://github.com/mozilla/standards-positions/issues/154#issuecomment-876021444

Sure, that's a risk we have here. But this risk is not exclusive to storing data on my local file system!
For some use cases of the FS API you responded by suggesting alternative APIs:

For your particular use case, Firefox does offer persistent storage, which allows a website to essentially take up "unlimited storage".

https://github.com/mozilla/standards-positions/issues/154#issuecomment-865654275

Exposing a good api for document management, that you can implement on top of a local fs, and/or backing up remotely etc. would be vastly better.

https://github.com/mozilla/standards-positions/issues/154#issuecomment-874914613

How do these storage locations offer any better protection against a compromised web app than the FS API would? On the contrary, look at these scenarios for, let's say, a photo editing software:

1. Your photos are persisted as files in an open file format so you can use them later, on any device in any compatible software. You store the files on a USB stick, then unplug the USB stick.
2. All your photos are backed up remotely "in the cloud", together with all your other documents. You give the photo editing web app full write access to your cloud storage.
3. The photos are stored as ArrayBuffers in IndexedDB. Only this one web app is able to open the photos.

If the compromised app steals your data and asks for ransom, you're in trouble either way. Sure, the compromised app can deal a lot of damage if you're "dumb" and give it access to more directories than it needs, but the same thing can happen with remotely stored files. And the FS API requires explicit user approval on every session, something that many cloud storages probably don't have.
If you really want to protect users from this kind of attack, they just can't be allowed to have persistent data.

What I'm arguing here is that there exists no single best choice for data storage, it always depends on the context of the app. And the person with the most knowledge about the context, who can make the most informed decision, is the app developer.

Reminder on comments on standards-position issues:

Please keep it on topic, and respectful, per https://github.com/mozilla/standards-positions/blob/main/CONTRIBUTING.md#discussing-mozillas-position-on-a-web-specification

Thanks,

Tantek

(Originally published at: https://tantek.com/2021/294/t1/)