Web Writable Files API: Simplifying Local File Access • Hacker News Board

Re: Web Writable Files API: Simplifying Local File Access

#111

Post by jmull » Tue, Nov 13, 2018, 5:23 PM UTC

asaph wrote: post #15

jcoffland wrote: post #10

Earlier quoted context omitted.

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

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

Re: Web Writable Files API: Simplifying Local File Access

#112

Post by jcoffland » Tue, Nov 13, 2018, 7:08 PM UTC

euroclydon wrote: post #22

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 use the Native Messaging API. Password Managers used to use a localhost listener, but it's less safe than Native Messaging. But if you stick with the HTTP listener, as someone else mentioned, while you're installing your app, you can edit the user's host file to add a domain name to the loopback adapter, and then you can also create a one-off SSL cert for the computer.

Thanks, I did not know about Native Messaging API. Unfortunately it appears to be only supported by Chrome.

Re: Web Writable Files API: Simplifying Local File Access

#113

Post by watersb » Wed, Nov 14, 2018, 5:45 AM UTC

AnIdiotOnTheNet wrote: post #89

rkagerer wrote: post #70

Earlier quoted context omitted.

Am I the only crusty old fart who thinks this a lousy trend? I worry the next talented generation of developers is being alienated from the desktop, and as a result my computing experience will degrade as Chrome's piecemeal attempts to reinvent the OS leave me with an inferior selection of browser-based toys that are awkward and clunky compared to their native counterparts. I grant the browser fixes a couple things m…

You're not alone. In another 20 years, you'll get to laugh tragically as a new generation of naive young techs invent yet another layer of abstraction on top of the browsers and gush about how this time it will finally be a universal platform. And your old 2TB of ram, 50 core cpu laptop might even still be able to run a text editor with only a few seconds of latency. And it goes without saying that, for your own safe…

20 years? Is that a typo? Actually sincere question -- because it feels like the time horizon for adding another layer is closer to 2 years, not 20.

Re: Web Writable Files API: Simplifying Local File Access

#114

Post by amaccuish » Thu, Nov 15, 2018, 7:57 PM UTC

jcoffland wrote: post #112

euroclydon wrote: post #22

Earlier quoted context omitted.

You can use the Native Messaging API. Password Managers used to use a localhost listener, but it's less safe than Native Messaging. But if you stick with the HTTP listener, as someone else mentioned, while you're installing your app, you can edit the user's host file to add a domain name to the loopback adapter, and then you can also create a one-off SSL cert for the computer.

Thanks, I did not know about Native Messaging API. Unfortunately it appears to be only supported by Chrome.

Hi there. Sorry I'm a bit late, but Firefox definitely supports native messaging with their new WebExtensions architecture; the extension I use with my Estonian ID card uses native message to talk to a native component, which in turn talks to my card.

Re: Web Writable Files API: Simplifying Local File Access

#115

Post by amaccuish » Thu, Nov 15, 2018, 7:57 PM UTC

bmm6o wrote: post #18

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.

Not on my network, since I ban dns rebinding