There is no way this isn't going to open up massive security holes. Even if the browser puts up alert after alert, people are just going to randomly click buttons and then all of a sudden wonder why some random web app is deleting all their files and adding malware. And the spec docs aren't exactly reassuring. This is an exact quote! "This API could be used by websites to try to store and/or execute malware on the users system."
This is just a variation on <input type=file> as far as read-access is concerned.
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.
> It is not downloading malware that is the issue, it's executing it.
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-...)
It's important not to forget about drive-by DLL injection when making the "execution is the problem" argument.
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.
Ugh, my Win32 security knowledge is non-existent, but this sounds horrible. Seems to me that nothing marked 'from web' and non-executable should be loadable into a memory segment which can be executed, and nothing in the system partition should be overridable like this. This sounds like a flaw in the OS design.
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.
> Seems to me that nothing marked 'from web' and non-executable should be loadable into a memory segment which can be executed,
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.
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.
A decent number of linux filesystems do support extended attributes, which is how I assume you'd do this (actually, looking at https://en.wikipedia.org/wiki/Extended_file_attributes a lot of OSs support xattrs), but I'm not aware of any browsers using them to mark downloads.
> How would you "mark something 'from web'"? This is a file after all.
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.
> This means that if you can save a malicious DLL next to that executable you can make a perfectly legitimate executable run malicious code.
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.
If you look at the way most scammers work, it's even simpler than that. They simply phish people by sending them a link and telling them to run it for some reason (it'll fix their computer, it's a required security update, etc) or they tell them to install something like TeamViewer so they can help them eliminate security flaws, and call center scammers then pillage their box.
I'm amazed the the number of people still forwarding chain letters to me in Facebook, so who knows how many people fall for the "pass this Javascript into your browser console" trick.
It’s funny you say this, because I did exactly this yesterday. I downloaded chromium and forgot I had not yet dragged it to my applications folder and I was running it for a few hours out of my downloads folder.
Google Chrome ships in a DMG, doesn’t it? This means that if it is running out if your downloads folder, it’s not subject to the things that would mess it up because you dragged it there.
The article says there is a possibility to grant access to a directory. For a non technical user who clicks “ok, whatever” on 200 cookies consent and newsletter nagging popups a day, there is a high probability they will click ok without reading it. This is absolutely not like the file input. Once you have access to a folder, you can write a decent cryptolocker.
BTW, for anyone who has children who are doing distance learning during COVID, the vast majority of school districts are using the Web, not native apps on desktop or iOS for the kids to do collaborative learning and submit work.
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.
I think adding a virtual file system to the local storage API's might be fine. One which cannot be mounted easily by non-technical users but has a viewer which allows dragging files into and out of it.
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.
I worked on this. The quote is true, in all honesty. Same as downloading and running applications from the web.
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.
Edit:
I forgot to say that "sensitive" directories are not allowed.
Think C:\Windows, etc.
I'm sure you worked hard and thought a lot about the security of this, but you have to be really arrogant to think that this will be fine because you thought about everything. I'm pretty sure this will open up a lot more possibilities for malware, viruses, harmful web pages than the convenience it will provide.
Yeah, they sure thought about everything thats why ad networks abuse the hell out of every API they implemented to fingerprint people, like AudioContext Api, battery API and what not.
The alternatives arent that people just dont use it, the alternative is are that people download some random executable that has much larger security vector, ie some electron app that has unlimited file system access.
I have no idea why you were down-voted here. Non-technical people are downloading executable files on their systems by the millions every day.
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.
Which paths are "sensitive" depends on which other programs the user has installed. Would Chrome recognize ~/.mozilla as a sensitive path? How about adding arbitrary content to ~/.ssh/authorized_keys?
Push notifications don't work on iPhones and yet a lot of sites use them, some in a spammy way but some I actually allowed on my phone and are quite useful.
Seems like it can be disabled in flags for now, which I just went in and did. That flag is bound to disappear at some point though… might become necessary to wrap browsers in an isolating sandbox or VM just to be sure they can't touch things they're not supposed to.
> might become necessary to wrap browsers in an isolating sandbox or VM just to be sure they can't touch things they're not supposed to.
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?
For filesystem access they are beholden to their enterprise users as well and Chromium still has a lot of open source developers that aren't simply looking out for Google's best interests. If they became overly hostile, then I'm sure we'd see a fork at some point. I'm not saying they are perfect, but a lot of Chromium hate is unfounded and exaggerated.
Do we need to just create a dummy proof OS for people that are oblivious and click yes to everything? Otherwise, why not give people choice? I mean you could create a pop up asking people for their passwords today on any browser, so how is adding a feature that requires permission any different?
Not dummy proof, just normal human proof. It’s very easy to condition someone to click a yes button when it stands between them and whatever task they’re actually trying to accomplish.
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.
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.
There is a comment on this by Martin Thomson, Mozilla Distinguished Engineer, member of Internet Architecture Board:
"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." [0]
cromwellian > "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."
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 [0].
A side note, DNS over HTTP (DoH) bothers me too, spec is silent about setting cookies, DoT is cleaner in this regard.
> When I reset my browser (and IP address), I expect a clean slate, and with this API I won't get it.
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.
I'm gonna throw an unpopular opinion out there: The real issue is not that phones or browsers have too much capabilities but rather that people fundamentally don't understand how to use computers. Locking things down and removing features doesn't really solve the problem just like wrapping your child in bubble wrap before crossing the street instead of teaching it to look both ways for cars doesn't solve the problem. Digitalization is being sold as a land of opportunities but no one ever tells people what the software they're using is actually capable of and how to control it. And that's why people vote for digital elections and accept all permissions and cookies and shrug mass surveillance off with "they know everything about me anyways".
But then the solution becomes: stop using computers, because the kind of sophistication required is out of reach for a very large part of the population. So, computers will stay part of everyday life. Making the interface simple and predictable, and locking features that can be abused may be fighting the symptom, but it's better than nothing.
Well yeah, I agree but even in the most locked down system people will still (involuntarily) find ways to get screwed or otherwise not be able to discern what's good and what's bad for them.
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.
Tablets and phones are computers, IMO. They're still general purpose machines. For many tasks, their interfaces are less confusing than a desktop's interface, which is progress, but when it comes to web apps, there's no difference, and especially phones can be really clumsy.
Not using computers would be falling back to paper forms and mail.
First macOS, then iOS, and then Android, have made some inroads. My mother is very clumsy around computers, but a iPad she can manage. It's not perfect, but much better than 10 or 20 years ago.
nowadays' security is that you have to manually grant permission, which for most people, esp non-technical people, they will normally just press Y, so yeah, the default sandbox protection will be gone for most people.
Sure why not, let me just create a blog post, with exact steps on how to make your windows more colorfull, and make users inject my DLLs into filesystem.
The user will do exactly if i give him exact copy paste paths and commands. And voila.
You can do the same exact thing without this API, so what’s your point? How do you think most call center scams work? By asking the user to download an executable that owns their system and run it.
It's possible for this to reduce steps / make the exploit process easier, and to do so without the "download this file and run it" step that should trigger a red flag to people.
We've been trialling the Native File System API in our PWA Construct 3 (a browser based game editor - https://www.construct.net).
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.
> Also as noted elsewhere, existing web features already allowed reading files and even entire directories;
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 get that you dislike electron, but that doesn't take away from the truth: don't like the latest version of an app? too bad, you just have to get used to it or stop using it
What a ridiculously user-hostile attitude.
It's not about Electron, it's about the loss of control. It's one of the big problems with any sort of forced-update software delivery: Web apps, SaaS, snaps, etc.
The new version drops a feature I need? "Too bad."
The new version doesn't work right on my computer? "Too bad."
The new version has a bug that is blocking my work? "Too bad."
Reminds me of the old ActiveX days - I wrote a whole WYSIWYG website editor using the ActiveX component that let you read/write files.
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?
Might not be appreciated opinion here but Personally, I think, the web starts to get feature parity in some way with Adobe Flash. Flash could do most of this back in the day and now the web is getting it too.
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.
The old File System API interface will not grant you access to the users filesystem. Instead you will have a "virtual drive" within the browser sandbox. The Native File System API gives you access to the actual file system.
Sounds like there's a flag in Chrome for the moment. After that, yeah some sort of container or sandbox seems like a good idea (TBH I'd argue that it's a good idea regardless of this change). I named some options at https://news.ycombinator.com/item?id=24421622
Serious question. Since this is going to be enabled by default by Chrome 86, is there any way to block Javascript from using the API? Or force it to ask for permissions? Because it seems like anything that uses the API by default has full access to my filesystem (at least based on the demo on that page). That seems insane. I don't even want anything JS-based to see my filesystem. That's a huge breach of privacy.
Not exactly what you're asking, but some thoughts:
* 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.
There's also Luminous[1], which can allow blocking individual JS events (eventAddListener and handleEvent calls). Something like that could also be extended to allow blocking of other API calls.
I read over the document and the security considerations don't seem super clear. If I find an XSS on Cloud 9 or some other web-based IDE that users are likely to grant directory permissions to, I can ransomware every file in that directory without requiring extra permissions?
In other words, granting this permission is effectively the same level of severity as downloading and running an app.
There's some things in 86 that are even more interesting imo, mainly FTP support is finally being removed. Crazy that something so integral to the early web is now not even worth supporting in the browser.
Hmm. I used ftp in the browser yesterday. We have a large forest fire here which led me to look at detailed maps the incident team produce showing burn boundaries etc. These are published via ftp.
Thanks. I've changed the title to the article's subtitle (shortened to fit HN's 80 char limit), since the subtitle is a bit more factual than "simplifying access to local files".
All they have to do with this API now is just save their own fingerprints to somewhere the user can write to and they can find later. Evercookies that can survive browser reinstalls, and anything short of a meticulous search through everything in your home directory.
We made sure that the activation of the API is gated by:
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.
From personal experience in my job, I've seen ad networks abusing the following APIs for privacy invasive fingerprinting:
- 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.
I feel dev's at Google, just turn blind eye, once a PM pitches an Idea, literally every API they build is abused by ad networks, and now they want us to believe native file system access is safe, and good enough to be allowed by default. I just want this to blow up and see how the same googlers defending this feature, come and answer again.
> We put a lot of thought in Privacy and Security, as we do for all APIs.
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?
> o 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?
Yeah so there are few dozens of ways people are getting spammed, why not lets add more ways. Here's an Idea let me write a blog post on how to make windows look cooler and ask my 12YO user to point me to their windows directory and let me use my API to inject my DLLs, none of the defenders of this API are not estimating the level of social engineering, and how dumb users can be, and also the reason why Android failed in terms of privacy.
You forgot to read the part where they will block certain directories, and your 12 year old could easily install malware or give out his password, and Android did't fail in terms of privacy. Apple has failed by locking you into a closed-source ecosystem. Android is open source and has a lot of options, and a lot of open source apps you can review yourself and pick the best cryptography algorithms for password management, etc.
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.
Finally, we can have a local markdown editor with live preview. I just hope it can read files and folders in a particular directory as well, with permission of course.
Not sure why you would say that. Maybe try some vscode extensions such as "Markdown Preview Enhanced" or "Markdown All In One"? Those works both offline and local.
"Don't use a web app that has an extremely constrained permissions model and only has access to the files you explicitly grant it using the file picker, use a native app that has unconstrained access to everything!"
I don't but I use vscode for note taking. Chrome is cross platform and widely used so it would be easy for me to develop a standalone web app that works on most of my devices. I can sync the directory containing my data with self hosted next cloud.
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.
VS Code sucks and if I were to go the route of a different app there are lot better options out there for markdown editing. This feature has a lot of amazing potential, but some people like the Apple-model so much that they'd prefer only being told what they are allowed to do.
Lots of potential for abuse, especially. Any API introduced into an industry-controlling browser granting too many local privileges seems absolutely wild given that the Internet's full of people trying new and creative ways to scam, hack, or otherwise inconvenience end users.
As someone with professional experience in web security, this API is like a nightmare come true.
This is "Open File" and "Save File" taken API form. Right now web apps can already read and save files with uploads and downloads. This just allows the user to pass a file descriptor to the app rather than a copy of the file's contents.
As a counter opinion I would posit that VS Code is probably the most well written piece of widely-used software written in the last decade.
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.
Native apps are really poor at collaboration and composition. School districts around the world are effortlessly doing distance learning by giving parents and kids URLs, which open Web based editors, science experiments, music and art 'web apps', etc all at one click, without worry about whether the kids own iPhones or Android, or desktops, and whether or not they can install it, or have it installed.
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"
