search

mozilla / standards-positions

https://mozilla.github.io/standards-positions/
Mozilla Public License 2.0
650 stars 72 forks source link

File System Access API #154

Closed mconca closed 3 years ago

mconca commented 5 years ago

Request for Mozilla Position on an Emerging Web Specification

Other information

Based on activity in this Chromium bug, Google seems to be actively working towards implementing this draft spec.

This spec is a follow-on to the Writable Files proposal, which Mozilla initially classified as defer, but the last comment in the position issue suggested a new issue be opened if there is "new information such that reassessment is warranted".

martinthomson commented 5 years ago

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.

dbaron commented 5 years ago

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.

dbaron commented 5 years ago

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

mkruisselbrink commented 4 years ago

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?

martinthomson commented 4 years ago

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.

annevk commented 4 years ago

(Filed https://github.com/WICG/native-file-system/issues/211 on the name of that method. It does seem to use the new underlying primitive which will eventually enable proper partitioning.)

mkruisselbrink commented 4 years ago

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.

josephrocca commented 4 years ago

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:

image

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.

kaizhu256 commented 4 years ago

would it be reasonable to add an append() api, e.g. (await fileHandle.createWritable()).append(content) for logging and journaling scenarios?

tomayac commented 4 years ago

would it be reasonable to add an append() api, e.g. (await fileHandle.createWritable()).append(content) for logging and journaling scenarios?

@kaizhu256 filed this again as https://github.com/WICG/file-system-access/issues/234. Please ignore the comment here.

james-cnz commented 3 years ago

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.

dwelle commented 3 years ago

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.

fonsp commented 3 years ago

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.

feross commented 3 years ago

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.

tomayac commented 3 years ago

(Meta: Could an admin rename this issue to reflect the new name, File System Access API, please?)

mkruisselbrink commented 3 years ago

FYI, in https://github.com/WICG/file-system-access/pull/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.

operutka commented 3 years ago

I have one more insight from perspective of a web developer.

Our company provides a service where you can record your IP cameras to the cloud and, among other features, we offer our customers an option to download sections of their recordings as video clips. These clips can be quite large depending on their length and bitrate of the video. A few GB clips are not an exception.

Currently, we are very limited in terms of media containers that can be used. We construct these clips "on the fly" from infinite record streams. It means that encoded video data (e.g. h264) are being muxed into the target media container and the resulting chunks of data are being sent to the client immediately as they become available. We don't want to construct the whole clip on a server and send it to the client once it's constructed. This solution would be bad from several reasons but mostly because of poor UX and scalability.

Now the interesting part - if you want to create a media file, you'll most likely need a seekable IO. Pretty much all of the most common media containers have this requirement. There is a few formats that don't have this requirement (e.g. fragmented MP4 or MPEG-TS) but they have quite significant drawbacks. These formats are intended for streaming (i.e. not for file storage) and they are not that common, so some applications (especially those for video editing) might not even support them and those that do support these formats usually don't allow seeking in the video. I guess you can see here why we get customer complaints from time to time :smile:

TL;DR

The File System Access API would be like a miracle for us. We would be no longer limited to use only a few media formats that don't require seekable IO. We could easily construct a remote seekable IO by forwarding seek commands from our server to the client application. Because of this, we could let our customers pick the media container that fits their needs.

I understand all the concerns regarding security. In general, giving websites unlimited access to client's file system definitely isn't a good idea. But who says the access should be unlimited? There certainly are subsets of the File System Access API that can hardly cause any harm. For example saving a single file using window.showSaveFilePicker() which will display the file saving dialog. Therefore, the user is fully aware which file the website will be accessing.

In my opinion, there are parts of the API that are safe and they would be extremely helpful for web developers. Even if the remaining parts won't get accepted due to security concerns, it would be still a big step forward.

PS: Sorry for the long comment. I had a need to explain our position :)

FunctionDJ commented 3 years ago

As a web dev who likes to create tools for game modification and translation this API is absolutely amazing because it solves the issue of providing tools that use copyright protected game files. Using this API you don't need to create a desktop app to avoid hosting copyright protected files on your web server, and instead you can just make the user choose the game's directory and the web app can load all the files it needs into browser memory.

I would love to have this in Firefox, because then i don't need to tell users that they need to use Chrome or Edge to use a tool.

kepta commented 3 years ago

I wanted to say that this really hinders the ability for indie web developers like me to provide powerful and compelling alternatives to modern day electron wrappers.

Talking particularly about my use case, I am developing a local only note taking app https://bangle.io . I do not want to or have the time to invest working on an electron wrapper and this API is golden for me and my audience. If Firefox decides to not go forward with this API, what alternative do you have for use cases like these ? I love Firefox and hate to ask my users to go and download Chrome.

annevk commented 3 years ago

I tend to agree with @martinthomson that overall this is still harmful as we don't have a good way of informing the user about the risks.

I think there are two exceptions to this:

It's unfortunate that all these capabilities are bundled together as it's not clear if we could support only some of them in Firefox at this point or if applications expect all-or-nothing.

Jaifroid commented 3 years ago

Our use case: we have a lightweight archive reader (Kiwix JS) written as an offline-first PWA, that reads very large archives (up to 90GB currently) stored on a user's Storage. These archives mostly consist of Wikipedia articles, but also Gutenberg books, TED talks videos, PhET experiments, Wiktionary.... These can be used by anyone who has intermittent Internet access, connectivity issues, in places where Wikipedia is censored, in rural schools, in prisons, in refugee camps, when travelling without Internet access, etc.

In Chrome and Edge (and other Chromiums) we can now provide one-click access to these archives (once the user has picked the directory that contains their archives), persisting permissions between app launches, using the File System Access API. The user can switch seamlessly between archives in a session, and only needs to click once on the permission prompt on launching a new session. However, in Firefox, the user must use the File Picker every time they wish to open a new archive, and again in every new session, which is very clumsy UX.

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. Since the user must pick the file or directory in the first place, where is the harm in persisting permissions for content that the user has already given permission to access? If the contents of the picked directory changes, the user must pick it again. Mozillans, please take a step back and ask yourself if you're opposing this API on ideological grounds, instead of doing so after carefully considering its value to your users, and after studying the security model that the developers of the API have put in place. If you have valid security concerns, might it not be better to contributie to the spec to help plug them?

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.

annevk commented 3 years ago

When evaluating an API we have to consider how it can be abused. And if we cannot make the API safe by default and have to involve the end user, whether we can adequately convey the risks of the API to them. That's the problem here.

For your particular use case, Firefox does offer persistent storage, which allows a website to essentially take up "unlimited storage". This results in some storage duplication if users do not exclusively use your app for these archives, but would result in less UI on subsequent visits.

Jaifroid commented 3 years ago

Thanks for the suggestion @annevk. Unfortunately, copying multi-gigabyte files into IndexedDB or localStorage or a sandboxed FS, or even worse, asking the user to download these large files into a closed-wall storage, is not a realistic option for us. Our users will often swap files on USB sticks, or store on microSD cards where internal storage is limited, or one person downloads an update using a torrent and then shares the file (full English-language Gutenberg is 66GB for example, but offers a huge free library for schools).

Firefox not offering this API is not a blocker for us: users can still pick the file and access their content, but it is inferior and clunky UX compared to what Kiwix JS PWA can now offer (on desktop) for Chromium-based browsers (and frameworks based on them). I don't see anthying in the discussion above that explains why it's safe for a user to pick a file and access their own content, but why it is not safe to allow the same user to persist access to their very own content or non-root location that they have explicitly picked and allowed access to. Having an extra step in the user's way (it's not as if the standard File Picker comes with any "scary warnings") does not change the security of the scenario.

The problem is that if users (or, indeed, developers) can't see the safety rationale for the degraded UX (in comparison to the alternatives), they will end up using those alternatives. Engaging with this draft API needn't imply capitulation: instead, Mozilla could feed into the proposed spec, influence it, and find ways to address legitimate security concerns. IMHO, this would better for Firefox (and Firefox users) in the long run. But I understand this is just one dev's perspecitve.

annevk commented 3 years ago

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.

Jaifroid commented 3 years ago

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

josephrocca commented 3 years ago

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:

image

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

Jaifroid commented 3 years ago

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.

NotizMe commented 3 years ago

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:

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.

fabricedesre commented 3 years ago

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.

Jaifroid commented 3 years ago

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.

fabricedesre commented 3 years ago

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.

Jaifroid commented 3 years ago

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.

fabricedesre commented 3 years ago

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.

Jaifroid commented 3 years ago

@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 commented 3 years ago

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

NotizMe commented 3 years ago

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.

Jaifroid commented 3 years ago

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.

feross commented 3 years ago

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.

fabricedesre commented 3 years ago

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.

fabricedesre commented 3 years ago

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.

Jaifroid commented 3 years ago

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:

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

fabricedesre commented 3 years ago

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!

feross commented 3 years ago

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:

fabricedesre commented 3 years ago

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.

Jaifroid commented 3 years ago

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.

NotizMe commented 3 years ago

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.

Jaifroid commented 3 years ago

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.

pschiffmann commented 3 years ago

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.

tantek commented 3 years ago

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

torshind commented 3 years ago

From the perspective of a user who remains your loyal follower solely because he understands that we can't leave the monopoly of web technologies to a few players, this decision is disappointing because it puts Firefox even further on the periphery. Right now, anyone who wants to upload a photo to Instagram will uninstall Firefox in favor of Chrome (or use Edge, which you can't remove from Windows), and that's a fact.