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

Re: Web Writable Files API: Simplifying Local File Access

#51

Post by coverband » Mon, Nov 12, 2018, 9:32 PM UTC

nine_k wrote: post #40

Individualist wrote: post #35

Earlier quoted context omitted.

I would argue that you could use a combination of local storage and global state in these web apps to approximate a file system already. Not to mention lazy loading and web workers to cache larger files needed to run a web app. As well as parrelism and currency already offered by web workers.

Approximation is not what it's about. It's about integration. Write that google doc and store it as a local .docx or .odc. Edit that 20 MB raw picture in a browser app and store it back to the disk, instantly, then feed it to a traditional desktop editor. Write that Python script in a Web IDE, store locally, and upload it to an Arduino.

All those use cases and more can be accomplished if the Write API is limited to a sandboxed local storage with a configurable size limit per domain. I would hate to see all the gains made by sandboxing the browser fly away by allowing it to access any file on the user's system.

Re: Web Writable Files API: Simplifying Local File Access

#52

Post by Ajedi32 » Mon, Nov 12, 2018, 9:35 PM UTC

fouc wrote: post #31

joshfraser wrote: post #19

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…

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?

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

This isn't just unrestricted filesystem access. The site would need to request file system permission first, _and_ get the user to select the file in a file picker.

In short, that's not a serious concern.

Re: Web Writable Files API: Simplifying Local File Access

#53

Post by burtonator » Mon, Nov 12, 2018, 9:36 PM UTC

I just finished banging out a new Electron app (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.

Re: Web Writable Files API: Simplifying Local File Access

#54

Post by nusq » Mon, Nov 12, 2018, 9:37 PM UTC

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

Re: Web Writable Files API: Simplifying Local File Access

#55

Post by Ajedi32 » Mon, Nov 12, 2018, 9:37 PM UTC

eastendguy wrote: post #20

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

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

Re: Web Writable Files API: Simplifying Local File Access

#56

Post by dreamcompiler » Mon, Nov 12, 2018, 9:41 PM UTC

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.

Re: Web Writable Files API: Simplifying Local File Access

#57

Post by z3t4 » Mon, Nov 12, 2018, 9:41 PM UTC

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.

Re: Web Writable Files API: Simplifying Local File Access

#58

Post by EGreg » Mon, Nov 12, 2018, 9:41 PM UTC

zawerf wrote: post #26

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…

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

Re: Web Writable Files API: Simplifying Local File Access

#59

Post by EGreg » Mon, Nov 12, 2018, 9:45 PM UTC

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!

Re: Web Writable Files API: Simplifying Local File Access

#60

Post by the8472 » Mon, Nov 12, 2018, 9:47 PM UTC

joshfraser wrote: post #19

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…

You could set the whole directory tree to no-execute via ACLs.

Anyway, more interoperability with the native environment is a good thing. Right now browsers are an alien implant in every operating system that can't communicate with anything else.