Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Writable Files API: Simplifying Local File Access

developers.google.com

Post reply on HN
Print view View original

11–20 of 115 posts

Re: Web Writable Files API: Simplifying Local File Access

#11

Post by derefr »

asaph wrote: post #8

> 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 t…

In the main case, where the user is picking a file, the API as proposed in the examples[1] doesn't seem to suggest any ability to pre-select a file in the displayed file picker. Thus, this is a "dialog" where you literally cannot just press "OK"—you have to either select something to open first, or hit "Cancel"!

On the other hand, the last example (FileSystemDirectoryHandle.getSystemDirectory) might devolve into the sort of "user presses yes before even reading" permissions system that is so troublesome today. But I feel like the kinds of directories exposed through such a mechanism would likely be fairly innocent (the proposed example being the user's set of installed fonts.)

[1] https://github.com/WICG/writable-files/blob/master/EXPLAINER...

Re: Web Writable Files API: Simplifying Local File Access

#13

Post by 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.

Re: Web Writable Files API: Simplifying Local File Access

#14

Post by yjftsjthsd-h »

jcoffland wrote: post #13

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…

Isn't localhost exempt from http/s restrictions?

Re: Web Writable Files API: Simplifying Local File Access

#15

Post by asaph »

jcoffland wrote: post #10
asaph wrote: post #8

> 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 t…

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

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

Limiting write access to certain file types: https://github.com/WICG/writable-files/blob/master/EXPLAINER...

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.

Re: Web Writable Files API: Simplifying Local File Access

#16

Post by 0xCMP »

yjftsjthsd-h wrote: post #14
jcoffland wrote: post #13

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…

Isn't localhost exempt from http/s restrictions?

It's a special case, but HTTPS specific features don't always work. In this cause it's an HTTPS website talking to a local HTTP service which causes the cross-site errors.

Re: Web Writable Files API: Simplifying Local File Access

#17

Post by binarynate »

kevin_b_er wrote: post #7
[deleted] wrote: post #6

[deleted]

While I'm concerned the security implications greatly, one should not always assume network access always works or that it is effective at all times. In the United States, for example, bandwidth limitations and caps are rampant far and above what is needed just to saite the greed of our corporations. Given the current political control of the judiciary and executive branches, I don't expect this to change any time so…

I agree that offline access is important. Fortunately, the Service Worker browser APIs now allow enable web apps to work offline, too:

https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

Re: Web Writable Files API: Simplifying Local File Access

#18

Post by bmm6o »

jcoffland wrote: post #13

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…

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

Re: Web Writable Files API: Simplifying Local File Access

#19

Post by 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.

Re: Web Writable Files API: Simplifying Local File Access

#20

Post by 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

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.

Post reply on HN