
Web Writable Files API: Simplifying Local File Access - feross
https://developers.google.com/web/updates/2018/11/writable-files
======
joshfraser
One of the great things about browsers is the way you can trust them to be
reasonably sandboxed from the rest of your machine. Features like this chip
away at that trust model and open up new attack vectors against unsuspecting
users. I get the usability benefits, but the security implications are scary.
How easy would it be to trick my mother into uploading her profile picture and
have the site change that file into a malicious executable without her
realizing? At a minimum, I'd hope you would be restricted from changing file
permissions or editing any executables.

~~~
fouc
And more than that, I honestly wonder about the motives of an advertising
driven company these days.

It feels like 5 years later this will come to bite us in the ass as another
way of exploiting access to our computer and data.

What if websites start requiring specific files to exist before allowing
access?

~~~
politician
> What if websites start requiring specific files to exist before allowing
> access?

This is certainly going to be immediately abused for encrypted storage of
persistent cookies and tracking identifiers.

\- If my site generates cat pics, I'll put identifiers in the metadata fields
of the image format.

\- If my site generates markdown, I'll put identifiers in an alternate data
stream (Windows) or encoded in the whitespace.

Since the files exist outside of the sandbox, they'll be outside of the scope
of privacy features like clearing the cache or cookies, and outside of the
reach of adblocker extensions.

~~~
icebraining
Nobody said the sites would have unfettered access to these files like they do
with their cookies. Putting an ID on a photo is useless if you then have to
ask the user to read it again the next time.

Also, why would they be outside the reach of adblockers? WebExtensions can
already intercept and manipulate the use of certain APIs by sites, the same
can easily apply here.

------
asaph
> The primary entry point for this API is a file picker, which ensures that
> the user is always in full control over what files and directories a website
> has access to. Every access to a user selected file (either reading or
> writing) is done through an asynchronous API, allowing the browser to
> potentially include additional prompting and/or permission checks.

I'm glad they are taking a security-focused approach from the beginning of the
design phase. I expect no less from Google. However, I worry that the approach
of putting the end user in charge of approving/denying access to resources
puts an unreasonably high burden on users. Many people simply click to dismiss
dialogs without even reading them, let alone thinking carefully about what
they are agreeing to. This is asking for trouble. I would rather see a sandbox
approach that restricts the locations and types of files that can be read and
written.

~~~
jcoffland
> I would rather see a sandbox approach that restricts the locations and types
> of files that can be read and written.

Which is exactly what is in the security proposal linked at the bottom of the
article.

~~~
asaph
Thanks for pointing that out. I missed these 2 items on first glance.

Limiting access to certain directories: [https://github.com/WICG/writable-
files/blob/master/EXPLAINER...](https://github.com/WICG/writable-
files/blob/master/EXPLAINER.md#limiting-access-to-certain-directories)

Limiting write access to certain file types:
[https://github.com/WICG/writable-
files/blob/master/EXPLAINER...](https://github.com/WICG/writable-
files/blob/master/EXPLAINER.md#limiting-write-access-to-certain-file-types)

FWIW: On the surface, this appears to contradict the following quote from tfa:

> ...ensures that the user is always in full control over what files and
> directories a website has access to.

A sandbox is _not_ full control.

~~~
jmull
> Not allowing websites to write to certain file types such as executables
> will limit the possible attack surface.

The problem with that is there is no hard distinction between a data file and
an executable. Essentially every kind of file, when opened, causes code to be
executed, usually significantly influenced by the content of the file.

This API is moving the security perimeter back, making it the responsibility
of every local app that may open a file touched by this API — essentially
every file it might open — to ensure unexpected/malicious content can’t do
anything bad. That’s not going to happen. Instead, users are going to have to
be “sure” not to open files via this API using sites they don’t trust. That’s
pretty weak compared to what we’re generally used to today (which doesn’t seem
strong enough already).

------
tinyvm
A couple months ago I started studying PWA.

I realized PWA's potential was on Desktop and not really on mobile.

I came to realize that PWA missed really two things to change Desktop for good
:

\- Sandboxed FileSystem API

\- Standard Operating System Support

Most apps like Slack, Discord or Twitch can barely justify their usage of
Electron... beside the possibility to have those apps in a separate OS Window
they don't make an extensive usage of Node.JS like VSCode which spawn
"child_process".

They just seat there , in a separate OS Window and they can launch at OS
startup too..but in order to have those two features you must completely give
up on security and give access to almost everything on your computer...

PWA really bring a new dimension to Desktop App, if Windows and MacOS brought
native support to PWA ( using Edge and Safari without the need for Chrome )
this would change the industry for ever.

~~~
devwastaken
Problem with PWA: Native access, Browser versioning and seperation of
processes.

1\. If when you ran a .net application all .net applications shared the same
parent process that'd be a significant problem.

2\. Many electron clients control their versions because there are bugs,
quirks, removal of features, or other changes in chromium versions. Discord
last time I checked is still on 56.

3\. PWA's do not have native access. Discord requires that to spawn IPC
communications with game overalys, which are another native process.

PWA's are meant more for mobile, but even there you are of course, limited.

Firefox and Safari would change the world if they actually cared about doing
that. They're about market share, not about the technology anymore. Firefox
was in a position of making it possible to simply ship the firefox binary, and
you could add your js and css changes, effectively having the full firefox
browser as your 'app'. Which means it could be triggered to auto-update like
normal firefox, but still have your UI and act as a browser.

Firefox abandoned that route and instead is focusing upon whatever Chrome
impliments, like Custom Components. Safari also doesn't care about anything
but linux and mac.

~~~
xd1936
Safari... cares about Linux?

~~~
saagarjha
Maybe they meant WebKit?

------
eastendguy
Is this API needed? I understand the benefits, but web apps or Chrome
extensions that _really_ need file access can already use the Native Messaging
API and ask the user to install a native app, like here:

[https://a9t9.com/kantu/x#fileaccess](https://a9t9.com/kantu/x#fileaccess)

The advantage of an explicit app installation is that users/companies that
want to avoid such file access (and the many other things that native apps can
do) can simply avoid/block app installations.

In the last two decades users have learned that "as long as it's inside the
web browser, it's safe". If web apps themselves become too powerful this
security approach breaks down.

~~~
Ajedi32
A native app would have full filesystem access. This API only grants access to
files/directories you open in the web app.

------
andrewstuart
This is a great idea and will mean that many Electron applications can just
run much more securely as plain web applications.

~~~
devwastaken
Relying upon browser features for native access will be trouble. Google could
revoke the feature from chromium at any time. And in any real application you
will need to interact with plenty of folders users cannot be expected to know,
like Appdata.

~~~
ballenf
> And in any real application you will need to interact with plenty of folders
> users cannot be expected to know, like Appdata.

I think a lot of what you'd store in Appdata in a "real" application will
remain in browser storage or pulled from the server. A single file or folder
with app settings, drafts, etc. should suffice. And even settings are probably
better stored server side for user convenience so they can easily switch
devices.

~~~
devwastaken
1\. Completely unnecessary given native access

2\. Native will be much faster

3\. Native will allow for features from the kernel that browsers do not
impliment.

4\. You cannot plan for how people will use such a wide feature as the
Filesystem. Saying 'X and Y _should_ fit' requires a significant amount of
honest research and testing, with a very good reason as to why the change is
necessary.

------
jcoffland
This could be a great way to allow Web apps to talk to native apps. At
Folding@home our client software uses a Web frontend. This frontend talks to
the native Folding@home app at localhost over a socket. The problem is that
browsers are starting to show security warnings for any non-https traffic and
it's not possible to securely give the native app a valid SSL certificate.
Reading and writing shared files would let the frontend talk to the back end
more securely. Allowing the Web app access to a directory, with disk space
restrictions, would be ideal.

~~~
bmm6o
You can't get a certificate for localhost, but you can get one for
foldinglocalhost.com and resolve that to 127.0.0.1.

~~~
unilynx
That requires you to also ship the private key to end users, and your
certificate will be revoked once the CA discovers it

~~~
euroclydon
No, you can just install a self-signed unique cert for each machine.

~~~
SahAssar
Asking users to install a CA or cert is not a good or scalable solution.

~~~
vertex-four
Since when does a desktop application need to ask the user anything to install
a cert programmatically? Enforced desktop sandboxing hasn't really taken off.

------
dreamcompiler
I hope this can be made to work securely. The main thing holding back web-
based IDEs is file system access. It wouldn't be horribly difficult to port
e.g. Emacs to Javascript (or more likely WebAssembly) if file access was
available. I know this sounds ridiculous, but it would be doable.

------
zawerf
This will be amazing for simple webapps!

In a lot of use cases, all you really want is a simple way to read and save a
small blob of data.

But to achieve this today you would have to do one of:

\- Save it in local storage, but lose their data if they clear it or use
another device.

\- Build out a REST API backend, but need to also build auth and account
management.

\- Use a backend as service such as firebase, but still costing you to store
the data.

\- Use a filepicker api to save to the user's cloud storage. For example
Google Drive has a file picker:
[https://developers.google.com/picker/](https://developers.google.com/picker/).
But not everyone use the same cloud drive (icloud, dropbox, onedrive, etc).

With local file access, it's more or less the same as the filepicker api
solution except they are free to save it to a non-syncing file location too if
they choose.

~~~
EGreg
Why not IndexedDB? Is that cleared also when you reinstall an app or something

~~~
zawerf
Yea it has the same problems as web storage.

Also it's too opaque so the typical user won't understand that clearing their
browser data means losing their work. They have already been trained by other
sites to believe that their data should be persisted to the site's servers and
that they should see their data even if they open the site on a different
device.

Forcing them to choose where to save the data should hopefully clear up where
their data lives. If they need multidevice they can sync their filesystem
folders with one of many third party cloud storage of their choosing (such as
dropbox).

I think it's a perfect fit for webapps like as photopea.com (photoshop clone
in the browser) that came up on HN the other day.

------
exabrial
Why are we reinventing 100% of the problems from Java and flash?

------
carlosdp
This is a great idea. One interesting consideration would be how it would
handle symlinks. Would it follow them? Could that be used as an attack vector
to exit the user-specified directory?

------
nusq
Has a huge fan of the tiddlywiki project this is a welcome feature .

------
Paul-ish
Hopefully the file picker API looks very different from the file upload API to
cue the user that something different is happening.

------
RandomBookmarks
"The primary entry point for this API is a file picker (i.e. a chooser)."

...so what would be difference to today, where a user can "upload" files to
the browser's local storage, and then the web app can work with the file(s)?

I get it that you avoid to have to "re-download" the file, but that seems to
be a small benefit for the risks we get.

~~~
euroclydon
The browser retains the permission for the app to write the file back later, I
believe.

------
burtonator
I just finished banging out a new Electron app
([https://getpolarized.io/](https://getpolarized.io/))

It's an offline-first app for managing and annotating PDF and web documents.

The idea was that with Electron I can have direct access to the filesystem and
be fully integrated into the browser as well.

For the most part it works. The users can easily browse the local filesystem
and also access some operating specific features.

But let me tell you -it's rather schizophrenic to use something like Electron.
It just doesn't know whether it's a browser or a web server and then there's
the issue of dealing with process communication within Electron. Chrome is its
own process and node the main process and you have to communicate via message
passing - not super fun.

Now we have PWAs and they're far from idea but it might be that an API like
this, along with PWAs, and maybe a bit more functionality could replace
Electron for building these types of hybrid apps.

------
z3t4
I like the idea of a File API, to make it easier to for example search files.
But I'm afraid we'll end up with the same problem as native apps, where apps
would ask for all permissions, even if they don't really need them.

------
euroclydon
If you could write an executable file, you could make a compiler in browser
JS.

~~~
pjmlp
You already can do that by compiling into a WASM module and reloading it
afterwards.

------
timwis
Particularly interesting in light of linux's "everything is a file"
principle...sockets, printers..

~~~
pjmlp
Actually that is an UNIX thing, and not everything is a file on UNIX.

On Plan 9 and Inferno everything is indeed a file.

------
slartibardfast0
This looks great! I hope a capability driven multi-monitor api gets some
attention in the near future too!

------
wild_preference
Safari 11 or 12 introduced a new extension system where Safari extensions ship
as a macOS app with a Safari extension component that can communicate with the
native app. And the macOS app has standard Mac Store sandboxing options (by
default, no FS access outside of its bundle).

I've written some extensions for personal use and so far it's been a great
trade-off.

------
EGreg
I’m wondering how useful it is to save files on the local filesystem in 2018.

I can understand syncing Google Drive and saving stuff there. Or Resilio Sync
or any number of other solutions such as Dat.

You Already have filepickers to open and read files. And you can save files as
I indicated - via syncing to a service, where you have control of what goes
where and it’s still there if you lose the device. And it can be encrypted
where the local devices have keys for syncing.

The only new use case I can think of that this enables is overwriting existing
files - which is dangerous!

~~~
icebraining
Even in 2018, not everyone is online all the time, or has a connection capable
of uploading large files (due to speed or caps). And frankly, it's just
wasteful to upload everything.

