File System Access API #154
Comments
|
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
added
the
venue: W3C CG
|
Yeah, |
…Native File System (mozilla#154).
|
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:
The first is only partially curtailed by allowing user agents to block access to That is relatively minor in relation to the other concern:
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 |
|
(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.) |
Oops, sorry about that. I forgot to update the README.
(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. |
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 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. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
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. |
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. |
|
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. |
This comment has been minimized.
This comment has been minimized.
|
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. |
@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... 😕 |
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.
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.
Indeed! |
Nothing guarantees that an executable file won't erase your files, but Firefox still lets you download them. What about
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 No one is seriously suggesting that Firefox block the user from downloading executable files or block 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, The questions must be:
|
Actually Firefox will block downloads that are identified as malware through safe browsing.
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. |
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. |
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:
https://github.com/mozilla/standards-positions/issues/154#issuecomment-874878839
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!
https://github.com/mozilla/standards-positions/issues/154#issuecomment-865654275
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:
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. 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/) |
|
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. |
|
The purpose of this repository is to discuss Mozilla's position on the value of specifications, not for whether Firefox will implement this or any other specification. If you want to discuss that, the place to do so is Bugzilla. |
|
Isn't Mozilla's position roughly equivalent to whether Firefox will implement it though? |
|
The comments by disappointed developers and users here are on topic and respectful. This topic was a request for Mozilla to take a position on an emerging/draft specification. The position Mozilla has taken is one that effectively blocks the File System Access API from reaching standards track, given that we now have a duopoly. This does have quite wide implications, and I believe it should be useful for those who take these decisions to be able to gauge developer and user sentiment. |
To be honest, anyone arguing about "you need to implement that" on Bugzilla will likely be shutdown with "bugzilla is the place to discuss how we implement, not if we should implement". Overall, what's missing is alternatives from Mozilla when the a valid end user need can't be fulfilled by a rejected proposal. Mozilla is doing quite poorly on that front. |
|
The inability to use vscode.dev is another consequence of not supporting this API; like the Instagram use-case mentioned above, it will force more users off of Firefox. |
So what's now, Google creates APIs on their own? Google is a standards body now? |
|
Firefox doesn't provide an equivalent API to access your file system so running vscode.dev is not possible... |
|
As i read it there are security concerns. I also believe that Mozilla should propose more drafts for standartization in general. |
|
@mystiquewolf My comment is about market share, not about standards. Yes, I understand that implementing non-standard Chrome features effectively turns Chrome into the standards. But that has to be weighed against the reality that the more features Chrome supports that Firefox doesn't, the less market share Firefox will have; without market share, Mozilla's stance on standardization will be effectively irrelevant. |
|
@BatmanAoD So basically what you're saying is judge from your comment then Mozilla's stance is already irrelevant? They are required to implement *as it is* -> they have *no choice*? |
|
@mystiquewolf No. If I had meant that, I would have said so. I've edited |
|
@BatmanAoD Not trying to be rude, but i don't really see a difference between:
Either is is a standard and it is required or it is not a standard and is not required. That's the proper way, anything else is monopol, which should be dealt in court IMO. |
|
I think everyone here understands that it will not be good for the browser ecosystem if Chromium effectively becomes the new Internet Explorer (of the 1990s), marching ahead with non-standard APIs. The frustration is that Mozilla devs seem to be so entrenched in the box of "any file access is a security breach" that genuinely useful and well implemented draft APIs are getting almost summarily dismissed. This is a real problem, and it's actually contributing to reinforcing the monopoly. We realize it looks like a double-bind, or Catch 22, for Mozilla. However, many of us think there is another way. We desperately want to see Mozilla help to make these APIs into good standards (and then we're desperate to be able to use them, or an appropriately hardened version, in Firefox, precisely because we don't want to be driven into the "arms" of a monopoly). |
|
Locking this conversation. We asked folks a week ago (#154 (comment)) to keep it on topic and subsequent comments for the most part have not, nor have they added any new technical information (advocacy, "implications", "consequences", SDO processes, and market dynamics are not; there are other venues for those things, and if you’re not sure where, start with your own blog). (Originally published at: https://tantek.com/2021/301/t1/) |
Closes mozilla#154 (again).
This CL moves the base::Feature from content_features.h to a generated feature from runtime_enabled_features.json5. This means that the base::Feature can be default-enabled while the web API is controlled by the RuntimeFeature, which will still be default-disabled. An origin trial can enable the RuntimeFeature, which will allow full access to the API, provided the base::Feature is also enabled (see change to origin_trial_context.cc). Meanwhile, the base::Feature can be disabled through Finch as a kill-switch for the whole feature, and prevent origin trials from turning the feature on. Tests have been added to WebView test, as it allowed for easy spoofing of responses on a known origin. Bug: 1439945 Change-Id: Ifa0f5d4f5e0a0bf882dd1b0207698dddd6f71420 Fixed: b/278701736 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4681552 Reviewed-by: Rayan Kanso <rayankans@chromium.org> Commit-Queue: Peter Pakkenberg <pbirk@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Richard Coles <torne@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Cr-Commit-Position: refs/heads/main@{#1173344}
and others
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".
The text was updated successfully, but these errors were encountered: