Repository navigation
Remove support for native file system API #11407
Description
Chromium is shipping a native file system API. The privacy / security model is extemely not fleshed out, but its shipping enabled in chromium. We should disable
cc @jumde
Spec: https://github.com/WICG/native-file-system/blob/master/EXPLAINER.md
Activity
33 remaining items
okdistribute commentedon Apr 14, 2021
This is unfortunate as this causes many devs to tell their users to install Chrome which has even more privacy issues. We're planning a PWA now and I was hoping to be able to tell users to use Brave but it seems like we might have to encourage them to use Chrome instead for full functionality. A shame, really.
pes10k commentedon Apr 14, 2021
I understand your frustration but the ability to set permissions that allow for long lived disk access, even when revisiting a site is a serious privacy harm, and an enormous footgun we're not going to load and hand to our users.
I appreciate @tomayac point, that the spec is sufficiently vague in privacy protections that one could maybe implement it in such away that it was privacy protecting. But vagueness in privacy protections in a spec is not a feature, its a bug and a sign of a proposal that isn't solving the privacy risks it introduces.
I'll mention again what i said in #11407 (comment), that we're considering having these default off, and expert enable-able through flags, but we don't have any immediate plans to implement such a policy.
TL;DR; this is a spec with serious privacy risks, and protecting our users from those risks is higher priority right now than either 1) dedicating developer time to figure out how to implement this not-yet-standard in a privacy preserving way, or 2) supporting these use cases that we don't think are core to why folks want to use Brave.
As always, decision is subject to change at any point, but #11407 (comment) is the current position. If sites need to use privacy-risking features, thats (at least for now) what other browsers are for ;)
okdistribute commentedon Apr 14, 2021
OK! Well we are looking forward to the day we can have more full-featured local-first applications in Brave! I will be following this thread in case things change and we can start recommending brave instead of chrome for this work.
samueljim commentedon Apr 14, 2021
@pes10k
I was under the impression that the file system API only has access to the file system while the domain is open.
In Chrome, you need to give the site access to the file system every time you open the webapp. The file system access is also sandboxed to the folder that the user requests.
This might be different for PWA apps.
pes10k commentedon Apr 15, 2021
@samueljim, I think I explained my concerns poorly. On my initial read through the spec, I have two concerns:
that while the page has a FileSystemHandle, the page can continue watching and reading updates to that file; this seems to be an intended use for the API. This is not my main concern, but its a concern none the less, as this is a completely different way than how pages can deal with files currently (again, by design). Basically, right now there is a high level of intentionality in telling a page "please read or upload the contents of this file", every time. This changes that model significantly, in a way that i expect most non-expert users will not understand, and create two very similar ways of doing similar things with very different privacy implications in the browser. The risk for misuse and error is high to my mind.
More significantly, if I am reading the spec right, pages have access to the file handles they had the last time the page was open, and w/o having to re-request permission from the user (since the permission lives across page visits). This seems possible through the API either by serializing, storing, and then later unserializing the handle, and also possibly just by the general behavior of
getFile(its not 100% clear to me whether the spec intends the permission to be tied to the JS object, or to the underlying file. If the former, this is surprising to me, but would reduce some at least some of my concerns).And then, finally, I'm very nervous about APIs that are not (yet?) standards (and so may change out from underneath us at any time) that do very privacy sensitive things. Thats not a controlling concern, but its a reason we're extremely wary about enabling non-standard, under development features that are privacy risky.
tomayac commentedon Apr 15, 2021
Maybe @mkruisselbrink as the spec author can speak to this.
hkalbasi commentedon Apr 22, 2021
Valid concerns on non-standard api. I hope it will soon become standard with privacy/security issues solved. Until that day, I don't see anything wrong with flag. We shouldn't choose what is correct, people should. Concerns can be explained in flags page.
Dmitra commentedon Apr 24, 2021
I might be missing smth, but what flag can I use to enable this feature?
ndarilek commentedon May 14, 2021
Wondering if there's a flag as well? I remember this being supported previously, so was surprised when it didn't work. Tried enabling a few promising-looking flags, but none seemed to work.
Thanks.
kepta commentedon May 30, 2021
@pes10k this is incorrect, pages can store a file handle but if a page is closed (including all the tabs of that subdomain), browser prevents access to the handle and shows a user a prompt to regrant the permission.
Here is an example from my note taking app https://bangle.io , which shows explicitly the prompt message for the first time a user selects a directory:
And once you close the website and visit again, the browser shows this prompt:
This feature is not a dangerous feature and should not be dismissed just because the highlight of this feature is the ability to read users files. As I mentioned above there are proper safe guards in the spec which give the power to the user to decide whether they trust the website or not and also prevent accessing sensitive directories.
I kindly request you to rethink this, as it a monumental step in giving power to the web apps and enabling things that weren't possible before. With this said, I am curious to hear what your thought process is like for enabling this feature for brave users.
pes10k commentedon Jun 1, 2021
Thank you for the notes @kepta !
Folks can find more details for how we're considering dealing with non-standardized, privacy-risking, still changing Chrome features here: #9586 (comment).
But the TL;DR; here is:
ibsusu commentedon Jun 15, 2021
@pes10k, I'm just a nobody but I really think that while you and the rest of your team handle Brave's adoption of Chrome features amazingly well, disabling the file system access api is overly protective. The guards in place are enough and the power and consistency that it affords developers as a superior alternative to indexedDB and localStorage are easily worth it, even on the balance of 'millions of users'.
Your second point is really weak and the first and third are just the reasonable amount of bias I expect anyone to have with the Chrome team.
You can serialize a handle into storage but how is the 3rd party script going to read it? IndexedDB? LocalStorage? Neither are available cross origin. If you're really worried about other attack avenues just lock it down to one directory that you specify.
Please prioritize researching the api more thoroughly because right now it looks like your conclusion isn't well supported. I don't know what else you have on your plate but this one shouldn't take long.
kepta commentedon Jun 15, 2021
To be blatantly honest, it looks like a decision was made first and then you all decided to look for ways to support that decision.
The spec is pretty spec-d out, as far as reading and writing files is considered with millions of chrome devices out in the wild using it.
There is a fine line between thinking that you are protecting your users and actually protecting your users. Limiting the advancement of the web ecosystem on the pretense of security, "oh that poor user doesn't know what they are doing" and "oh this sounds privacy invasive and is coming from google, lets block it without proper research".
This API by design is 'opt in' --- the user has to take an action (clicking 'yes' on a prompt) to even make a malicious attack feasible in the first place.
I would really be interested in hearing how you think this is privacy risky.
pes10k commentedon Jun 16, 2021
I'm locking this conversation.
Brave issues are for keeping track of bugs and things Brave plans on implementing, not to debate Brave product decisions. I've already shared Brave's plans for features like this. As mentioned before, this plan does not currently have an implementation timeline, but when implemented would allow users to enable the feature through brave://flags.
Further, the conversation has drifted from the substance of the issue, to presuming motives or assuming ignorance, which is definitely not what these issues are for.
Ya'll, I appreciate we disagree. Thats okay and inevitable given the size of the Web. But, without any snark or sarcasm meant, it shouldn't be a surprise to anyone that Brave considers some things privacy risks that other browsers (including Chrome) don't consider privacy risks. A partial list of Brave's concerns (already discussed above) include:
Next, even though I expect they don't like or approve of the decision here, I'll just say again that I appreciate the testing and additional information provided by @kepta in #11407 (comment).
Finally, a correction:
I think there is a misunderstanding here. 3p scripts can read the storage of the frame they're executing in. If a 1p script writes something into storage (say… a file handle), nothing prevents a 3p script (or any other script), executing in the same frame, from reading that value out of storage.
The "cross origin" limitation mentioned above prevents a script (3p or otherwise) from accessing storage for a eTLD+1 other than the eTLD+1 of the frame the script is being executed in. With storage, as with most other parts of the Web platform, access is scoped to the eTLD+1 of the frame code is executing in, not the eTLD+1 that the code came from.