Live data from Hacker News

Web Writable Files API: Simplifying Local File Access

developers.google.com

31–40 of 115 posts

Re: Web Writable Files API: Simplifying Local File Access

#31

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?

Re: Web Writable Files API: Simplifying Local File Access

#32
"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.

Re: Web Writable Files API: Simplifying Local File Access

#33
post #24
post #18

Earlier quoted context omitted.

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

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

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

Re: Web Writable Files API: Simplifying Local File Access

#34

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

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

Re: Web Writable Files API: Simplifying Local File Access

#35
post #30

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…

As you surely noticed, for last 10 years the browser is actively trying to replace your desktop OS, so that the browser would become the platform, instead of Windows / macOS / Linux / anything else. Imagine the desktop becoming ChromeOS on any computer, not just Chromebooks. For this, the browser must make all the traditional OS interfaces available. It has interfaces for accelerated 2D and 3D graphics, audio, USB, p…

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.

Re: Web Writable Files API: Simplifying Local File Access

#36

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

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.

By that line of thinking relying on OS APIs will be trouble as Microsoft or Apple could remove features at any time.

Re: Web Writable Files API: Simplifying Local File Access

#39
post #31

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?

Like session cookies, or SSL certificates?

Re: Web Writable Files API: Simplifying Local File Access

#40
post #30

Earlier quoted context omitted.

As you surely noticed, for last 10 years the browser is actively trying to replace your desktop OS, so that the browser would become the platform, instead of Windows / macOS / Linux / anything else. Imagine the desktop becoming ChromeOS on any computer, not just Chromebooks. For this, the browser must make all the traditional OS interfaces available. It has interfaces for accelerated 2D and 3D graphics, audio, USB, p…

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.
Post reply on HN