
The Native File System API allows web apps to save directly to files - ausjke
https://web.dev/native-file-system/
======
jaredcwhite
There is no way this isn't going to open up massive security holes. Even if
the browser puts up alert after alert, people are just going to randomly click
buttons and then all of a sudden wonder why some random web app is deleting
all their files and adding malware. And the spec docs aren't exactly
reassuring. This is an exact quote! "This API could be used by websites to try
to store and/or execute malware on the users system."

~~~
cromwellian
This is just a variation on <input type=file> as far as read-access is
concerned.

For write access, it certainly could be used to store malware on a user's
system, but so can "Save As" or clicking a link with HTTP headers that
triggers a download. Basically, the "Save As" dialog from browsers have the
same issues.

It is not downloading malware that is the issue, it's executing it. So unless
you can trick the user into navigating to an existing binary that is normally
executing on the system, and have the rights to replace it, executing is not
any different that triggering the user to put something in his ~/Download
directory and asking him to paste a shell command.

The API doesn't not provide a way to mark something executable, and it should
block you from obtaining write access to any file already marked executable
just like many mobile OSs don't let you simultaneously mark a page in memory
as writable and executable.

The last one looks like a flaw, I couldn't find anything in the spec that says
"thou shalt not let the user open a file marked executable for write access",
although it does suggest banning access to stuff like C:/Windows, /usr,
/Applications, etc.

But what really bothers me is people making uninformed comments. Rather than
knee jerk trigger anytime any browser API is changed without fully reading the
spec and then actually pointing out any weaknesses, we get the same low signal
commentaries.

So again, browsers already allow unaware users to be tricked with bog standard
fileupload form elements and Save As dialogs. This just breaks a hardcoded
high level UI into smaller reusable parts, and it actually adds more concerns
over security than the original 1997 spec for file upload and save.

~~~
armada651
It's important not to forget about drive-by DLL injection when making the
"execution is the problem" argument.

Lots of executables on Windows link to DLLs that are not protected by the
"KnownDLLs" protection. This means that if you can save a malicious DLL next
to that executable you can make a perfectly legitimate executable run
malicious code.

I haven't read into the API yet to determine how it protects against this, but
it's definitely more nuanced than the argument you're making.

~~~
inetknght
> _This means that if you can save a malicious DLL next to that executable you
> can make a perfectly legitimate executable run malicious code._

Some people install browsers onto a USB drive -- or even run a browser
directly from their Downloads directory. Such people are easy targets for this
type of thing.

~~~
saagarjha
Running a browser from the downloads directory is unlikely to work correctly
on macOS.

~~~
imwillofficial
It’s funny you say this, because I did exactly this yesterday. I downloaded
chromium and forgot I had not yet dragged it to my applications folder and I
was running it for a few hours out of my downloads folder.

~~~
saagarjha
Google Chrome ships in a DMG, doesn’t it? This means that if it is running out
if your downloads folder, it’s not subject to the things that would mess it up
because you dragged it there.

~~~
merlinscholz
I think Chromium does get shipped as a normal executable, it's only Chrome
which gets released as DMG.

------
notaplumber
Browsers having unfettered access to users files is something which should be
mitigated against on all platforms, not fleshed out into an ill-conceived
feature, it goes in complete contrary to browser sandboxing efforts in Chrome
itself for different process types (renderer/gpu/utility), but also work like
OpenBSD has done with pledge(2)/unveil(2).

On OpenBSD, all processes of chromium, including the main browser process are
tightly pledged and unveiled by default, write access to the users home
directory is limited to only a few paths (~/Downloads), and a few config
directories. As a consequence, users are rather forcibly taught safer usage
pattern of copying files into the unveiled paths when uploading, which as Bob
Beck alludes to in his slides below, is a reasonable compromise to every
website having access to your ssh keys.

[https://www.openbsd.org/papers/bsdcan2019-unveil/mgp00022.ht...](https://www.openbsd.org/papers/bsdcan2019-unveil/mgp00022.html)

[https://github.com/openbsd/ports/tree/master/www/chromium/fi...](https://github.com/openbsd/ports/tree/master/www/chromium/files#:~:text=unveil.main)

~~~
anoncareer0212
The histrionics here are astounding considering they're about a _Save As_
dialog.

~~~
rainforest
It appears I could use this to ask a victim to "select your downloads folder"
to save files to and then steal or overwrite any file in it.

~~~
bad_user
If the permissions system in place is clear and potent enough, I don't see the
problem.

You can also ask people to simply download and install an app that can do
whatever it wants.

It's 2020 and we still can't build web apps that can read and write to local
files. Browsers are no longer useful just for reading text.

~~~
rainforest
The permissions system seems to be granular with respect to whatever was
selected - if you select a directory you have full access to everything in it.
Theoretically the permission system requires explicit approval, but if you see
the security system with the user I think it presents more risk to users than
before.

Previously if you wanted filesystem control you had to trick a user into
downloading something. With this API, it seems like it would be easier to con
unsuspecting users into granting permissions they aren't aware they're
granting.

------
nuker
There is a comment on this by Martin Thomson, Mozilla Distinguished Engineer,
member of Internet Architecture Board:

"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._ " [0]

[0] [https://github.com/mozilla/standards-
positions/issues/154#is...](https://github.com/mozilla/standards-
positions/issues/154#issuecomment-668923566)

[1] Specification Positions [https://mozilla.github.io/standards-
positions/#native-file-s...](https://mozilla.github.io/standards-
positions/#native-file-system)

~~~
tomayac
The points brought up by @cromwellian in
[https://news.ycombinator.com/item?id=24416738](https://news.ycombinator.com/item?id=24416738)
are important in the context of the present comment, too.

~~~
nuker
cromwellian > "But what really bothers me is people making uninformed
comments. Rather than knee jerk trigger anytime any browser API is changed
without fully reading the spec and then actually pointing out any weaknesses,
we get the same low signal commentaries."

This may sound dumb too, but I expect my browser just show me web. When I
reset my browser (and IP address), I expect a clean slate, and with this API I
won't get it. When I install apps, I use very different due diligence. Without
clean slate after resetting my browser, I'd have to change my browsing habits
radically [0].

A side note, DNS over HTTP (DoH) bothers me too, spec is silent about setting
cookies, DoT is cleaner in this regard.

[0]
[https://en.wikipedia.org/wiki/Chilling_effect](https://en.wikipedia.org/wiki/Chilling_effect)

~~~
rewq4321
> When I reset my browser (and IP address), I expect a clean slate, and with
> this API I won't get it.

Browsers don't currently give you that, and never have. You can download
files, and these files remain on your system even if you re-install your
browser.

> This may sound dumb too, but I expect my browser just show me web.

Browsers are just a sandbox for running applications that are downloaded over
the network. Some applications need web cam access, some need access to files
on your system, some need geolocation, and so on. Browsers let you choose what
permissions to give applications. Because of this, you're completely free to
let your browser just "show you the web" in whatever sense you like.

------
t0astbread
I'm gonna throw an unpopular opinion out there: The real issue is not that
phones or browsers have too much capabilities but rather that people
fundamentally don't understand how to use computers. Locking things down and
removing features doesn't really solve the problem just like wrapping your
child in bubble wrap before crossing the street instead of teaching it to look
both ways for cars doesn't solve the problem. Digitalization is being sold as
a land of opportunities but no one ever tells people what the software they're
using is actually capable of and how to control it. And that's why people vote
for digital elections and accept all permissions and cookies and shrug mass
surveillance off with "they know everything about me anyways".

~~~
tgv
But then the solution becomes: stop using computers, because the kind of
sophistication required is out of reach for a very large part of the
population. So, computers will stay part of everyday life. Making the
interface simple and predictable, and locking features that can be abused may
be fighting the symptom, but it's better than nothing.

~~~
tenebrisalietum
> So, computers will stay part of everyday life

I don't think this is a guarantee. Already most people's primary computing
device is their phone; there are households where everyone has a phone and a
couple iPads and no PC; and iPads or Android tablets seem to be fairly common
as POS terminals and kiosk devices.

PCs will definitely always be around for serious content creation and heavy
work; but the group "very large part of the population" is also the group that
is less and less likely to own a PC or use one other than at work or for
school.

~~~
tgv
Tablets and phones are computers, IMO. They're still general purpose machines.
For many tasks, their interfaces are less confusing than a desktop's
interface, which is progress, but when it comes to web apps, there's no
difference, and especially phones can be really clumsy.

Not using computers would be falling back to paper forms and mail.

------
randtrain34
As much as they try to add security to this feature it inherently breaks out
of the "sandbox" concept of the browser and scares me.

~~~
ausjke
nowadays' security is that you have to manually grant permission, which for
most people, esp non-technical people, they will normally just press Y, so
yeah, the default sandbox protection will be gone for most people.

~~~
cromwellian
You have to do more than just hit 'Y', you have to navigate in a file chooser
and pick the file to save, or write.

~~~
anaganisk
Sure why not, let me just create a blog post, with exact steps on how to make
your windows more colorfull, and make users inject my DLLs into filesystem.
The user will do exactly if i give him exact copy paste paths and commands.
And voila.

~~~
cromwellian
You can do the same exact thing without this API, so what’s your point? How do
you think most call center scams work? By asking the user to download an
executable that owns their system and run it.

~~~
yjftsjthsd-h
It's possible for this to reduce steps / make the exploit process easier, and
to do so without the "download this file and run it" step that should trigger
a red flag to people.

------
AshleysBrain
We've been trialling the Native File System API in our PWA Construct 3 (a
browser based game editor -
[https://www.construct.net](https://www.construct.net)).

I think it's absolutely fantastic, and users love it too - it gives them
exactly what they expect from IDE-style software in the browser, such as "Save
as" to any location on disk, and the ability to use folder-based projects
(that are spread across multiple files).

The security concerns are obviously important but I'm pretty confident it's
largely mitigated through the permissions model (which is similar to one
Windows Store apps use). Also as noted elsewhere, existing web features
already allowed reading files and even entire directories; the writing files
part is new, and you cannot choose system directories, or ask for too much
(e.g. root of the user directory).

So in short I think this is great news for the web and a big step towards
allowing web apps to reach parity with desktop/native apps, while managing to
do it in a reasonably safe way.

~~~
dwild
> Also as noted elsewhere, existing web features already allowed reading files
> and even entire directories;

None of theses access are persistent though.

> the writing files part is new, and you cannot choose system directories, or
> ask for too much

If only that was enough.. there's plenty of important file outside of what
will be defined as "system directories" by whoever define them.

I love particularly this part of the documentation:

> Another risk factor is that of ransomware attacks. The limitations described
> above regarding blocking access to certain sensitive directories helps limit
> the damage such an attack can do. Additionally user agents can grant write
> access to files at whatever granularity they deem appropriate.

They are perfectly aware of the risk, yet completely ignore it. At least it
won't be whatever the browser define as "sensitive directories".

------
maple3142
It seems like I can replace an Electron app which only needs (a part) of File
System access to browser.

~~~
sayhello
Precisely. You'll also gain the ability to update your apps cheaply (via the
web) and bonus security points by not being beholden to Electron updates.

~~~
anhner
more like "you won't have a choice but to always use the newest version of the
app"

~~~
anhner
I get that you dislike electron, but that doesn't take away from the truth:
don't like the latest version of an app? too bad, you just have to get used to
it or stop using it

~~~
diggernet
What a ridiculously user-hostile attitude. It's not about Electron, it's about
the loss of control. It's one of the big problems with any sort of forced-
update software delivery: Web apps, SaaS, snaps, etc. The new version drops a
feature I need? "Too bad." The new version doesn't work right on my computer?
"Too bad." The new version has a bug that is blocking my work? "Too bad."

------
pskinner
Reminds me of the old ActiveX days - I wrote a whole WYSIWYG website editor
using the ActiveX component that let you read/write files.

I mean that was fun for a young budding developer, but I can see the major
security issues with this. I really hope this has been thought through.

I can imagine this being another one of those popups that constantly appear on
websites - are certain files protected like your hosts file or does it rely
upon the access level of the user running the browser?

------
wdb
Might not be appreciated opinion here but Personally, I think, the web starts
to get feature parity in some way with Adobe Flash. Flash could do most of
this back in the day and now the web is getting it too.

~~~
mmebane
Absolutely. It feels like we're finally almost back to the level of
functionality browsers had in 2010 with Flash/Java Applets.

------
davidbanham
It's not clear to me how the Native File System API relates to the existing
File System API.

[https://developer.mozilla.org/en-
US/docs/Web/API/FileSystem](https://developer.mozilla.org/en-
US/docs/Web/API/FileSystem)

Is Google proposing this as a replacement? As a supplement?

I made heavy use of the FileSystem API in a cross platform educational
application a few years ago, tripping over a really hairy memory leak bug in
Webkit along the way. By the end of that project the API had been deprecated,
but apparently now it isn't any more and instead it's experimental? I have no
idea what that means.

~~~
tomayac
The old File System API interface will not grant you access to the users
filesystem. Instead you will have a "virtual drive" within the browser
sandbox. The Native File System API gives you access to the actual file
system.

~~~
davidbanham
Ah, yes that makes sense. Thanks for clearing it up.

------
akerro
Ok, so first, tell me how to block it.

Running firefox in a container?

~~~
yjftsjthsd-h
Sounds like there's a flag in Chrome for the moment. After that, yeah some
sort of container or sandbox seems like a good idea (TBH I'd argue that it's a
good idea regardless of this change). I named some options at
[https://news.ycombinator.com/item?id=24421622](https://news.ycombinator.com/item?id=24421622)

------
BraveSnoo1028
Serious question. Since this is going to be enabled by default by Chrome 86,
is there any way to block Javascript from using the API? Or force it to ask
for permissions? Because it seems like anything that uses the API by default
has full access to my filesystem (at least based on the demo on that page).
That seems insane. I don't even want anything JS-based to _see_ my filesystem.
That's a huge breach of privacy.

~~~
yjftsjthsd-h
Not exactly what you're asking, but some thoughts:

* There is, for the moment, a flag to disable it, right?

* You could probably just have noscript/umatrix block JS outright (yes, I know this is overkill)

* Sibling comment is probably right in that Firefox is likely to not implement this immediately, if at all.

* You could also do it from the outside by sandboxing the whole browser; this is a somewhat poor mitigation (ex. leaves your Downloads directory wide open), but it could help.

~~~
SAI_Peregrinus
There's also Luminous[1], which can allow blocking individual JS events
(eventAddListener and handleEvent calls). Something like that could also be
extended to allow blocking of other API calls.

[1][https://gbaptista.github.io/luminous/doc/en-
US/](https://gbaptista.github.io/luminous/doc/en-US/)

------
CGamesPlay
I read over the document and the security considerations don't seem super
clear. If I find an XSS on Cloud 9 or some other web-based IDE that users are
likely to grant directory permissions to, I can ransomware every file in that
directory without requiring extra permissions?

In other words, granting this permission is effectively the same level of
severity as downloading and running an app.

Am I missing some extra consideration here?

------
shrubble
Were there users that were asking for this feature?

------
eecc
I’d feel safer if all applications could only access files tagged with an
unique ID for the application.

But then applications will start asking access for all of $HOME and we’re back
to square one

~~~
vbezhenar
Create separate user for every application and run it under that user.

------
dragonwriter
> Chrome 86 Enables the Native File System API by Default

Not only is this not the source title, but this information nowhere in the
linked article.

It's _true_ , but the linked article only very indirectly suggests the
possibility in that the most recent origin trial ends in Chrome 85.

The Chromium blog post on 86 does indicate this directly:
[https://blog.chromium.org/2020/09/chrome-86-improved-
focus-h...](https://blog.chromium.org/2020/09/chrome-86-improved-focus-
highlighting.html?m=1)

~~~
jjcm
There's some things in 86 that are even more interesting imo, mainly FTP
support is finally being removed. Crazy that something so integral to the
early web is now not even worth supporting in the browser.

~~~
dboreham
Hmm. I used ftp in the browser yesterday. We have a large forest fire here
which led me to look at detailed maps the incident team produce showing burn
boundaries etc. These are published via ftp.

------
0xy
Every time Chrome adds a new API it is nearly always abused by ad networks and
tracking companies to fingerprint users.

If you're bored one day you should consider reverse engineering some ad
network code. You'll be stunned at the insidious practices used.

~~~
sayhello
We made sure that the activation of the API is gated by:

1) User Activation checks 2) When access to the file system is requested, a
File Picker is necessary 3) When the API is in use, there are plenty of
indication that it's being used

We put a lot of thought in Privacy and Security, as we do for all APIs.

~~~
or-gate
> We put a lot of thought in Privacy and Security, as we do for all APIs.

but somehow, data is heavily harvested thru browsers(chrome), apps(android).
Do you even test your APIs with a sample audience, like real tech ignorant
people and see how they are blind to all those and just click yes, and don't
care?

~~~
chromedev
Data is easily harvested in Firefox and Safari too

~~~
anaganisk
Exactly, the focus must be on trying to mitigate it, not make it more easier.

~~~
chromedev
Should they block online email providers too because someone might send a
phishing email?

~~~
anaganisk
Yeah so there are few dozens of ways people are getting spammed, why not lets
add more ways. Here's an Idea let me write a blog post on how to make windows
look cooler and ask my 12YO user to point me to their windows directory and
let me use my API to inject my DLLs, none of the defenders of this API are not
estimating the level of social engineering, and how dumb users can be, and
also the reason why Android failed in terms of privacy.

~~~
chromedev
You forgot to read the part where they will block certain directories, and
your 12 year old could easily install malware or give out his password, and
Android did't fail in terms of privacy. Apple has failed by locking you into a
closed-source ecosystem. Android is open source and has a lot of options, and
a lot of open source apps you can review yourself and pick the best
cryptography algorithms for password management, etc.

------
RandoHolmes
Inevitable.

I've been saying for 10+ years that browsers will integrate more and more into
the OS until they become another layer that users aren't even aware of. Sort
of like Electron. Imagine web apps that can render native widgets and show up
in the taskbar separately.

This is just another inevitable step towards that. The only concern is how
secure this will be, and from the sounds of it, the answer is not very. Still,
it's inevitable that some form of this will become popular.

------
octoberfranklin
Just when you thought nothing could be dumber than WebUSB....

------
chromedev
Finally, we can have a local markdown editor with live preview. I just hope it
can read files and folders in a particular directory as well, with permission
of course.

~~~
nirui
Not sure why you would say that. Maybe try some vscode extensions such as
"Markdown Preview Enhanced" or "Markdown All In One"? Those works both offline
and local.

~~~
chromedev
VS Code sucks and if I were to go the route of a different app there are lot
better options out there for markdown editing. This feature has a lot of
amazing potential, but some people like the Apple-model so much that they'd
prefer only being told what they are allowed to do.

~~~
verandaguy

        This feature has a lot of amazing potential
    

Lots of potential for abuse, especially. Any API introduced into an industry-
controlling browser granting too many local privileges seems absolutely wild
given that the Internet's full of people trying new and creative ways to scam,
hack, or otherwise inconvenience end users.

As someone with professional experience in web security, this API is like a
nightmare come true.

~~~
Spivak
This is "Open File" and "Save File" taken API form. Right now web apps can
already read and save files with uploads and downloads. This just allows the
user to pass a file descriptor to the app rather than a copy of the file's
contents.

