Live data from Hacker News

The Native File System API allows web apps to save directly to files

web.dev

51–60 of 155 posts

Re: The Native File System API allows web apps to save directly to files

#51
post #5

Every time Chrome adds a new API it is nearly always abused by ad networks and tracking companies to fingerprint users. If you're bored one day you should consider reverse engineering some ad network code. You'll be stunned at the insidious practices used.

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.

Re: The Native File System API allows web apps to save directly to files

#52

Earlier quoted context omitted.

This is just a variation on 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…

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 thi…

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

Re: The Native File System API allows web apps to save directly to files

#53
post #50

Earlier quoted context omitted.

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.

> 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?

I am sure that's part of the feature.

Re: The Native File System API allows web apps to save directly to files

#54

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 pro…

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

Re: The Native File System API allows web apps to save directly to files

#55

Earlier quoted context omitted.

This is just a variation on 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…

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 thi…

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.

Re: The Native File System API allows web apps to save directly to files

#56

Earlier quoted context omitted.

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 thi…

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

Re: The Native File System API allows web apps to save directly to files

#57
post #3

As much as they try to add security to this feature it inherently breaks out of the "sandbox" concept of the browser and scares me.

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.

You have to do more than just hit 'Y', you have to navigate in a file chooser and pick the file to save, or write.

Re: The Native File System API allows web apps to save directly to files

#58
post #42

Earlier quoted context omitted.

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 buyin…

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

Which has policies that can be enabled to block it if necessary

Re: The Native File System API allows web apps to save directly to files

#59

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 us…

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.

It has a policy as well and will always allow you to disable it. No need for hyperbole.

Re: The Native File System API allows web apps to save directly to files

#60
It's not clear to me how the Native File System API relates to the existing File System API.

https://developer.mozilla.org/en-US/docs/Web/API/FileSystem

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.

Post reply on HN