Live data from Hacker News

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

web.dev

71–80 of 155 posts

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

#71

Earlier quoted context omitted.

Why would you want to edit code on your mobile locally? 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.

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

I use markor for android markdown note taking. Apache license, simple, works on files, also useful for todo.txt

https://gsantner.net/project/markor.html?source=inapp_more_h...

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

#72

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…

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

[deleted]

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

#73
post #50

Earlier quoted context omitted.

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

Data is easily harvested in Firefox and Safari too

Exactly, the focus must be on trying to mitigate it, not make it more easier.

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

#74
post #51

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.

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

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.

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

#75

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…

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…

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.

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

#77

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

Do you remember first few proposals of WebUSB where security section was just "mmeeeeeeh, nothing bad can happen"

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

#78

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…

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

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.

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

#79

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.

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.

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

#80

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…

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

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

Post reply on HN