Comment by notaplumber | Hacker News Reader

Comment by notaplumber | Hacker News Reader

Browsers having unfettered access to users files is something which should be mitigated against on all platforms, not fleshed out into an ill-conceived feature, it goes in complete contrary to browser sandboxing efforts in Chrome itself for different process types (renderer/gpu/utility), but also work like OpenBSD has done with pledge(2)/unveil(2).

On OpenBSD, all processes of chromium, including the main browser process are tightly pledged and unveiled by default, write access to the users home directory is limited to only a few paths (~/Downloads), and a few config directories. As a consequence, users are rather forcibly taught safer usage pattern of copying files into the unveiled paths when uploading, which as Bob Beck alludes to in his slides below, is a reasonable compromise to every website having access to your ssh keys.

https://www.openbsd.org/papers/bsdcan2019-unveil/mgp00022.ht...

https://github.com/openbsd/ports/tree/master/www/chromium/fi...

The histrionics here are astounding considering they're about a _Save As_ dialog.

It appears I could use this to ask a victim to "select your downloads folder" to save files to and then steal or overwrite any file in it.

If the permissions system in place is clear and potent enough, I don't see the problem.

You can also ask people to simply download and install an app that can do whatever it wants.

It's 2020 and we still can't build web apps that can read and write to local files. Browsers are no longer useful just for reading text.

The permissions system seems to be granular with respect to whatever was selected - if you select a directory you have full access to everything in it. Theoretically the permission system requires explicit approval, but if you see the security system with the user I think it presents more risk to users than before.

Previously if you wanted filesystem control you had to trick a user into downloading something. With this API, it seems like it would be easier to con unsuspecting users into granting permissions they aren't aware they're granting.

> If the permissions system in place is clear and potent enough, I don't see the problem.

Maybe, but the odds of the permission system being clear and potent enough that non-technical users understand what's happening is basically zero.

> You can also ask people to simply download and install an app that can do whatever it wants.

And after 20 years we've managed to train many people that that's a red flag that crosses a security boundry, unlike this shiny new way to invite malware into your machine by accident.

> It's 2020 and we still can't build web apps that can read and write to local files. Browsers are no longer useful just for reading text.

That is... not a bug. Web apps are safer precisely because it's so hard for them to touch your "real" local system. Take that away and you erode the security model that made web apps so great in the first place.

This folder specifically is blocked by the API.

Reply on news.ycombinator.com