For write access, it certainly could be used to store malware on a user's system, but so can "Save As" or clicking a link with HTTP headers that triggers a download. Basically, the "Save As" dialog from browsers have the same issues.
It is not downloading malware that is the issue, it's executing it. So unless you can trick the user into navigating to an existing binary that is normally executing on the system, and have the rights to replace it, executing is not any different that triggering the user to put something in his ~/Download directory and asking him to paste a shell command.
The API doesn't not provide a way to mark something executable, and it should block you from obtaining write access to any file already marked executable just like many mobile OSs don't let you simultaneously mark a page in memory as writable and executable.
The last one looks like a flaw, I couldn't find anything in the spec that says "thou shalt not let the user open a file marked executable for write access", although it does suggest banning access to stuff like C:/Windows, /usr, /Applications, etc.
But what really bothers me is people making uninformed comments. Rather than knee jerk trigger anytime any browser API is changed without fully reading the spec and then actually pointing out any weaknesses, we get the same low signal commentaries.
So again, browsers already allow unaware users to be tricked with bog standard fileupload form elements and Save As dialogs. This just breaks a hardcoded high level UI into smaller reusable parts, and it actually adds more concerns over security than the original 1997 spec for file upload and save.
That line is very thin. Local DLLs, application configs setting path to executables, even desktop.ini (https://threat.tevora.com/usb-drives-desktop-ini-and-ntlm-ha...) and that's before we get into NTFS alternative streams and other really out there ideas.
If you can choose which path you download to, the user has lost. Even if they never actively execute the file.
Same on *nix. If you can add something to bashrc, or drop a new file in desktop autostart, who cares about the executable bit.
And sometimes you can point out bad ideas without reading the spec. WebUSB was that kind of bad idea even before someone figured out exactly how they can read one time codes from security dongles that way. (https://www.yubico.com/support/security-advisories/ysa-2018-...)
Lots of executables on Windows link to DLLs that are not protected by the "KnownDLLs" protection. This means that if you can save a malicious DLL next to that executable you can make a perfectly legitimate executable run malicious code.
I haven't read into the API yet to determine how it protects against this, but it's definitely more nuanced than the argument you're making.
The real irony of the comments on HN that "it's dead on mobile because Apple won't support it", is iOS is one of the few operating systems where this kind of API is trust worth. I would not expect iOS to give Safari privileges to see any files other data files the Safari process itself created by user interaction, or something on say, a Permission-protected directory (e.g. Photos). Ditto for OSX.
If anything, the API really a selling point for OSX/iOS security architecture, in that it can be made safe.
Welcome to modern macOS and Safari. It’s a good idea, but puts up a block to third part or open source software. For now you can right-click and override (who knows for how long before Apple wants 30% of the price of all your desktop software too). I’d be more okay with the Mac version if you could add custom chains of trust.
How would you "mark something 'from web'"? This is a file after all.
There are ways to sign files (executable or not) but there is no 'from web' flag as far as I know.
File Quarantine on OSX:
Alternate data stream on Windows:
I wouldn't be surprised if Linux had it but I haven't used desktop Linux in a long time so I don't know what to search for, but generally having browsers annotate their file streams isn't an uncommon thing to support for filesystems & browsers.
Windows File System is very advanced and has metadata streams.
Files can have metadata, and most modern filesystems provide some kind of file attribute facility. On macOS browsers do exactly what described, setting a file attribute on downloaded files. The user will then be warned when trying to execute the file.
Some people install browsers onto a USB drive -- or even run a browser directly from their Downloads directory. Such people are easy targets for this type of thing.
From what I've seen, they're basically creating APIs like this that set on top of GDrive, DropBox, and File Upload / Server-directed File-Save. So in essence, all this new API is mostly buying you is offline mode.
There's been, for a long time, local storage APIs.
This is filesystem access, which is very different.
> BrowserFS is an in-browser file system that emulates the Node JS file system API and supports storing and retrieving files from various backends.
It supports storage backends such as: in memory, LocalStorage, IndexDB, HTTP, or the FileSystem API.
Filesystem access is going to have nefarious consequences.
I get that from your comment you agree that this is enough to mitigate the risk they themselves bring up:
>Another risk factor is that of ransomware attacks. The limitations described above regarding blocking access to certain sensitive directories helps limit the damage such an attack can do. Additionally user agents can grant write access to files at whatever granularity they deem appropriate.
We do our best to make sure the scenario listed doesn't happen. For instance, on Windows, after a writer is closed, we apply the Mark-of-the-Web, apply SafeBrowsing checks and finally call a system API which may trigger an anti-virus check.
On the Mac, we apply the equivalent of Mark-of-the-Web. You may have noticed that when you open the file, sometimes it asks you to ensure the provenance of the file?
Basically, it's a similar procedure as for file downloads.
I forgot to say that "sensitive" directories are not allowed.
Think C:\Windows, etc.
People can argue about how scary the warning messages should be on this new API, but they can't argue that this is not the way forward to a more secure world.
With this new API in place we'll be one step closer to the goal of having all consumer applications running inside a progressively-permissioned sandbox. It's a dream come true and will allow the culture and OSes to even more strongly stigmatise the opening of executables which immediately gain full system access - something that's completely absurd, but was a necessary evil.
Here a device atlas (2019) with plenty of countries for you to play with,
Honestly I view this as a good idea regardless (it also helps contain exploits, in addition to official APIs). On Linux firejail is amazing for this (but also consider bubblewrap and others), and AFAIK sandboxie is a good choice on NT. No idea what sandboxing options are on Darwin - looks like it has something built in?
I already had it disabled before LOL
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.
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.
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.
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.
"But my initial assessment is that the protections described in the spec are inadequate and I am of the opinion that this should be marked harmful." 
 Specification Positions https://mozilla.github.io/standards-positions/#native-file-s...
This may sound dumb too, but I expect my browser just show me web. When I reset my browser (and IP address), I expect a clean slate, and with this API I won't get it. When I install apps, I use very different due diligence. Without clean slate after resetting my browser, I'd have to change my browsing habits radically .
A side note, DNS over HTTP (DoH) bothers me too, spec is silent about setting cookies, DoT is cleaner in this regard.
Browsers don't currently give you that, and never have. You can download files, and these files remain on your system even if you re-install your browser.
> This may sound dumb too, but I expect my browser just show me web.
Browsers are just a sandbox for running applications that are downloaded over the network. Some applications need web cam access, some need access to files on your system, some need geolocation, and so on. Browsers let you choose what permissions to give applications. Because of this, you're completely free to let your browser just "show you the web" in whatever sense you like.
It sounds a bit nuts and I'm being slightly hyperbolic on purpose but I think the way to go is to slow digitalization in the public (i.e. our everyday lives) down a bit and properly educate at least decision makers, children (or young adults) and teachers about how this sorta stuff really works and how their rights are being undermined in the digital world.
Alas, the pandemic has been a big blow to that as well.
I don't think this is a guarantee. Already most people's primary computing device is their phone; there are households where everyone has a phone and a couple iPads and no PC; and iPads or Android tablets seem to be fairly common as POS terminals and kiosk devices.
PCs will definitely always be around for serious content creation and heavy work; but the group "very large part of the population" is also the group that is less and less likely to own a PC or use one other than at work or for school.
Not using computers would be falling back to paper forms and mail.
Please tell me who, in the entire computing industry, is actually working on that? Because I have seen no evidence of it.
I think it's absolutely fantastic, and users love it too - it gives them exactly what they expect from IDE-style software in the browser, such as "Save as" to any location on disk, and the ability to use folder-based projects (that are spread across multiple files).
The security concerns are obviously important but I'm pretty confident it's largely mitigated through the permissions model (which is similar to one Windows Store apps use). Also as noted elsewhere, existing web features already allowed reading files and even entire directories; the writing files part is new, and you cannot choose system directories, or ask for too much (e.g. root of the user directory).
So in short I think this is great news for the web and a big step towards allowing web apps to reach parity with desktop/native apps, while managing to do it in a reasonably safe way.
None of theses access are persistent though.
> the writing files part is new, and you cannot choose system directories, or ask for too much
If only that was enough.. there's plenty of important file outside of what will be defined as "system directories" by whoever define them.
I love particularly this part of the documentation:
> Another risk factor is that of ransomware attacks. The limitations described above regarding blocking access to certain sensitive directories helps limit the damage such an attack can do. Additionally user agents can grant write access to files at whatever granularity they deem appropriate.
They are perfectly aware of the risk, yet completely ignore it. At least it won't be whatever the browser define as "sensitive directories".
I mean that was fun for a young budding developer, but I can see the major security issues with this. I really hope this has been thought through.
I can imagine this being another one of those popups that constantly appear on websites - are certain files protected like your hosts file or does it rely upon the access level of the user running the browser?
Is Google proposing this as a replacement? As a supplement?
I made heavy use of the FileSystem API in a cross platform educational application a few years ago, tripping over a really hairy memory leak bug in Webkit along the way. By the end of that project the API had been deprecated, but apparently now it isn't any more and instead it's experimental? I have no idea what that means.
Running firefox in a container?
* There is, for the moment, a flag to disable it, right?
* You could probably just have noscript/umatrix block JS outright (yes, I know this is overkill)
* Sibling comment is probably right in that Firefox is likely to not implement this immediately, if at all.
* You could also do it from the outside by sandboxing the whole browser; this is a somewhat poor mitigation (ex. leaves your Downloads directory wide open), but it could help.
In other words, granting this permission is effectively the same level of severity as downloading and running an app.
Am I missing some extra consideration here?
But then applications will start asking access for all of $HOME and we’re back to square one
Not only is this not the source title, but this information nowhere in the linked article.
It's true, but the linked article only very indirectly suggests the possibility in that the most recent origin trial ends in Chrome 85.
The Chromium blog post on 86 does indicate this directly: https://blog.chromium.org/2020/09/chrome-86-improved-focus-h...
If you're bored one day you should consider reverse engineering some ad network code. You'll be stunned at the insidious practices used.
1) User Activation checks
2) When access to the file system is requested, a File Picker is necessary
3) When the API is in use, there are plenty of indication that it's being used
We put a lot of thought in Privacy and Security, as we do for all APIs.
- AudioContext API (introduced as recently as last year)
- Performance API
- Widevine DRM
- Speech Synthesis API
If you put a lot of thought into privacy and security, we certainly wouldn't be seeing this level of widespread abuse by ad networks.
Let's deep dive on AudioContext for a second.
Chrome's AudioContext API allows ad networks to pilfer latency information about the user's audio hardware (which is used in the wild for fingerprinting today) with zero user interaction, zero indication and zero approval. A web page that never plays audio (!!!) has access to this silently and without approval.
but somehow, data is heavily harvested thru browsers(chrome), apps(android). Do you even test your APIs with a sample audience, like real tech ignorant people and see how they are blind to all those and just click yes, and don't care?
I am sure that's part of the feature.
I've been saying for 10+ years that browsers will integrate more and more into the OS until they become another layer that users aren't even aware of. Sort of like Electron. Imagine web apps that can render native widgets and show up in the taskbar separately.
This is just another inevitable step towards that. The only concern is how secure this will be, and from the sounds of it, the answer is not very. Still, it's inevitable that some form of this will become popular.
I set up my phone to code recently and the first thing I did was set up my editor to connect to a remote server.
Editing local files seems counter productive since you would think you would be doing most of your development not on a phone.
There are other one time use cases where I don't want to install a native app. Sqooshy app is one. Maybe I want to make data extraction easier for someone with directory of old clunky pdf files. They don't need to download an app for that. Also Linux is a bit broken with sandboxing right now compared to browser.
I started using this: https://foambubble.github.io/foam/
This feature has a lot of amazing potential
As someone with professional experience in web security, this API is like a nightmare come true.
If you don't like the editing options, you've either not tried all the various plugins options available or you are too lazy or not interested enough to make your own.
You're entitled to your opinions, but I think your judgement is skewed.
VS Code is solid. I still prefer TextMate on a Mac, but on windows 10, VS Code is by far the best.
Any solution that requires you to write a multipage doc for parents and kids, to go follow two different sets of rules depending on devices and install 2 dozen apps, just so they can take class at home, is a non-starter for school districts.
A link is all you need with the Web for most things. No install. No uninstall. No worry about OS.
Ever since the fanboyism between mobile platforms started, people have started worshipping at the church of the native app, which is say, before the Web once broke us away finally from Windows, and now we're back asking people to install heavyweight native apps for things like "Order a Burger" or "Pay a Parking Meter"
Modern native apps support links, by the way, they just need to be explicitly enabled.