13 ms·

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

153 points by ausjke 6y ago

randtrain34 6y ago
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.
- ausjke 6y 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.
  - cromwellian 6y ago
    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.
    - anaganisk 6y ago
      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.
      - cromwellian 6y ago
        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.
        yjftsjthsd-h 6y ago
        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.
- pjmlp 6y ago
  With WebApps, it is enough to exploit sandbox contents itself.
chromedev 6y ago
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.
- nirui 6y ago
  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.
  - searchableguy 6y ago
    The main selling point would be if it works on my mobile. Vscode in its current form with plugins doesn't.
    - kjaftaedi 6y ago
      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.
      - searchableguy 6y ago
        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. I started using this: https://foambubble.github.io/foam/ https://foambubble.github.io/foam/
        6y ago
0xy 6y ago
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.
- strombofulous 6y ago
  That sounds like a lot of fun. Do you have a good file to start with? Does Google deliver a payload to fingerprint browsers on page they serve ads to?
  - 0xy 6y ago
    Google routinely allows third parties to run egregious malicious fingerprinting scripts without consequence, most notably on StackOverflow. [1] [1] https://meta.stackexchange.com/questions/331960/why-is-stack-overflow-trying-to-start-audio https://meta.stackexchange.com/questions/331960/why-is-stack...
  - simcop2387 6y ago
    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.
    - searchableguy 6y ago
      They need to ask for permission after the person has closed the tab again.
- sayhello 6y ago
  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.
jaredcwhite 6y ago
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."
- nuker 6y ago
  It won't work on iPhones, which means no one will use it, I hope.
  - deleted 6y ago
    [deleted]
  - kyriakos 6y ago
    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.
  - pjmlp 6y ago
    In plenty of countries iPhone has 0% market share, the local companies don't care about iPhone support.
    - imwillofficial 6y ago
      Name one.
      - pjmlp 6y ago
        iOS global market share is around 22%, plenty of countries to chose from. https://leftronic.com/android-vs-ios-market-share/ https://leftronic.com/android-vs-ios-market-share/ Here a device atlas (2019) with plenty of countries for you to play with, https://deviceatlas.com/sites/deviceatlas.com/files/images/map-world-os-q1-2019-lrg.png https://deviceatlas.com/sites/deviceatlas.com/files/images/m...
maple3142 6y ago
It seems like I can replace an Electron app which only needs (a part) of File System access to browser.
- searchableguy 6y ago
  Which app is it?
  - maple3142 6y ago
    It is a simple music player specifically made for playing music from osu! (https://osu.ppy.sh/ https://osu.ppy.sh/).
- sayhello 6y ago
  Precisely. You'll also gain the ability to update your apps cheaply (via the web) and bonus security points by not being beholden to Electron updates.
  - anhner 6y ago
    more like "you won't have a choice but to always use the newest version of the app"
    - anhner 6y ago
      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
      - diggernet 6y ago
        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."
dragonwriter 6y ago
> Chrome 86 Enables the Native File System API by Default 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-highlighting.html?m=1 https://blog.chromium.org/2020/09/chrome-86-improved-focus-h...
- jjcm 6y ago
  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.
  - dboreham 6y ago
    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.
  - gvjddbnvdrbv 6y ago
    s/worth supporting in the browser/something Google wants you using/
- dang 6y ago
  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".
notaplumber 6y ago
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.html https://www.openbsd.org/papers/bsdcan2019-unveil/mgp00022.ht... https://github.com/openbsd/ports/tree/master/www/chromium/files#:~:text=unveil.main https://github.com/openbsd/ports/tree/master/www/chromium/fi...
- anoncareer0212 6y ago
  The histrionics here are astounding considering they're about a _Save As_ dialog.
  - rainforest 6y ago
    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.
    - bad_user 6y ago
      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.
      - rainforest 6y ago
davidbanham 6y ago
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 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.
- akerro 6y ago
  Do you remember first few proposals of WebUSB where security section was just "mmeeeeeeh, nothing bad can happen"
- tomayac 6y ago
  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.
  - davidbanham 6y ago
    Ah, yes that makes sense. Thanks for clearing it up.
pskinner 6y ago
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?
CGamesPlay 6y ago
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. Am I missing some extra consideration here?
akerro 6y ago
Ok, so first, tell me how to block it. Running firefox in a container?
- yjftsjthsd-h 6y ago
  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 https://news.ycombinator.com/item?id=24421622
t0astbread 6y ago
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".
- tgv 6y ago
  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.
  - AnIdiotOnTheNet 6y ago
    > Making the interface simple and predictable Please tell me who, in the entire computing industry, is actually working on that? Because I have seen no evidence of it.
    - tgv 6y ago
      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.
  - t0astbread 6y ago
    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.
wdb 6y ago
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.
- mmebane 6y ago
  Absolutely. It feels like we're finally almost back to the level of functionality browsers had in 2010 with Flash/Java Applets.
eecc 6y ago
I’d feel safer if all applications could only access files tagged with an unique ID for the application. But then applications will start asking access for all of $HOME and we’re back to square one
- vbezhenar 6y ago
  Create separate user for every application and run it under that user.
octoberfranklin 6y ago
Just when you thought nothing could be dumber than WebUSB....
AshleysBrain 6y ago
We've been trialling the Native File System API in our PWA Construct 3 (a browser based game editor - https://www.construct.net 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.
- dwild 6y ago
  > 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".
shrubble 6y ago
Were there users that were asking for this feature?
nuker 6y ago
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] [0] https://github.com/mozilla/standards-positions/issues/154#issuecomment-668923566 https://github.com/mozilla/standards-positions/issues/154#is... [1] Specification Positions https://mozilla.github.io/standards-positions/#native-file-system https://mozilla.github.io/standards-positions/#native-file-s...
- tomayac 6y ago
  The points brought up by @cromwellian in https://news.ycombinator.com/item?id=24416738 https://news.ycombinator.com/item?id=24416738 are important in the context of the present comment, too.
  - nuker 6y ago
    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. [0] https://en.wikipedia.org/wiki/Chilling_effect https://en.wikipedia.org/wiki/Chilling_effect
    - rewq4321 6y ago
      > 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.
BraveSnoo1028 6y ago
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.
- RL_Quine 6y ago
  The simple answer is to not use Chrome.
- yjftsjthsd-h 6y ago
  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.
  - SAI_Peregrinus 6y ago
    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. [1]https://gbaptista.github.io/luminous/doc/en-US/ https://gbaptista.github.io/luminous/doc/en-US/
RandoHolmes 6y ago
Inevitable. 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.

153 points by ausjke 6y ago

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.

ausjke 6y 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.
- cromwellian 6y ago
  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.
  - anaganisk 6y ago
    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.
    - cromwellian 6y ago
      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.
      - yjftsjthsd-h 6y ago
        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.
pjmlp 6y ago
With WebApps, it is enough to exploit sandbox contents itself.

chromedev 6y ago

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.

nirui 6y ago
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.
- searchableguy 6y ago
  The main selling point would be if it works on my mobile. Vscode in its current form with plugins doesn't.
  - kjaftaedi 6y ago
    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.
    - searchableguy 6y ago
      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. I started using this: https://foambubble.github.io/foam/ https://foambubble.github.io/foam/
      - 6y ago

0xy 6y ago

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.

strombofulous 6y ago
That sounds like a lot of fun. Do you have a good file to start with? Does Google deliver a payload to fingerprint browsers on page they serve ads to?
- 0xy 6y ago
  Google routinely allows third parties to run egregious malicious fingerprinting scripts without consequence, most notably on StackOverflow. [1] [1] https://meta.stackexchange.com/questions/331960/why-is-stack-overflow-trying-to-start-audio https://meta.stackexchange.com/questions/331960/why-is-stack...
- simcop2387 6y ago
  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.
  - searchableguy 6y ago
    They need to ask for permission after the person has closed the tab again.
sayhello 6y ago
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.

jaredcwhite 6y ago

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

nuker 6y ago
It won't work on iPhones, which means no one will use it, I hope.
- deleted 6y ago
  [deleted]
- kyriakos 6y ago
  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.
- pjmlp 6y ago
  In plenty of countries iPhone has 0% market share, the local companies don't care about iPhone support.
  - imwillofficial 6y ago
    Name one.
    - pjmlp 6y ago
      iOS global market share is around 22%, plenty of countries to chose from. https://leftronic.com/android-vs-ios-market-share/ https://leftronic.com/android-vs-ios-market-share/ Here a device atlas (2019) with plenty of countries for you to play with, https://deviceatlas.com/sites/deviceatlas.com/files/images/map-world-os-q1-2019-lrg.png https://deviceatlas.com/sites/deviceatlas.com/files/images/m...

maple3142 6y ago

It seems like I can replace an Electron app which only needs (a part) of File System access to browser.

searchableguy 6y ago
Which app is it?
- maple3142 6y ago
  It is a simple music player specifically made for playing music from osu! (https://osu.ppy.sh/ https://osu.ppy.sh/).
sayhello 6y ago
Precisely. You'll also gain the ability to update your apps cheaply (via the web) and bonus security points by not being beholden to Electron updates.
- anhner 6y ago
  more like "you won't have a choice but to always use the newest version of the app"
  - anhner 6y ago
    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
    - diggernet 6y ago
      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."

dragonwriter 6y ago

> Chrome 86 Enables the Native File System API by Default 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-highlighting.html?m=1 https://blog.chromium.org/2020/09/chrome-86-improved-focus-h...

jjcm 6y ago
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.
- dboreham 6y ago
  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.
- gvjddbnvdrbv 6y ago
  s/worth supporting in the browser/something Google wants you using/
dang 6y ago
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".

notaplumber 6y ago

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.html https://www.openbsd.org/papers/bsdcan2019-unveil/mgp00022.ht... https://github.com/openbsd/ports/tree/master/www/chromium/files#:~:text=unveil.main https://github.com/openbsd/ports/tree/master/www/chromium/fi...

anoncareer0212 6y ago
The histrionics here are astounding considering they're about a _Save As_ dialog.
- rainforest 6y ago
  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.
  - bad_user 6y ago
    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.
    - rainforest 6y ago

davidbanham 6y ago

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

akerro 6y ago
Do you remember first few proposals of WebUSB where security section was just "mmeeeeeeh, nothing bad can happen"
tomayac 6y ago
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.
- davidbanham 6y ago
  Ah, yes that makes sense. Thanks for clearing it up.

pskinner 6y ago

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?

CGamesPlay 6y ago

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. Am I missing some extra consideration here?

akerro 6y ago

Ok, so first, tell me how to block it. Running firefox in a container?

yjftsjthsd-h 6y ago
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 https://news.ycombinator.com/item?id=24421622

t0astbread 6y ago

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

tgv 6y ago
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.
- AnIdiotOnTheNet 6y ago
  > Making the interface simple and predictable Please tell me who, in the entire computing industry, is actually working on that? Because I have seen no evidence of it.
  - tgv 6y ago
    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.
- t0astbread 6y ago
  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.

wdb 6y ago

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.

mmebane 6y ago
Absolutely. It feels like we're finally almost back to the level of functionality browsers had in 2010 with Flash/Java Applets.

eecc 6y ago

I’d feel safer if all applications could only access files tagged with an unique ID for the application. But then applications will start asking access for all of $HOME and we’re back to square one

vbezhenar 6y ago
Create separate user for every application and run it under that user.

octoberfranklin 6y ago

Just when you thought nothing could be dumber than WebUSB....

AshleysBrain 6y ago

We've been trialling the Native File System API in our PWA Construct 3 (a browser based game editor - https://www.construct.net 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.

dwild 6y ago
> 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".

shrubble 6y ago

Were there users that were asking for this feature?

nuker 6y ago

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] [0] https://github.com/mozilla/standards-positions/issues/154#issuecomment-668923566 https://github.com/mozilla/standards-positions/issues/154#is... [1] Specification Positions https://mozilla.github.io/standards-positions/#native-file-system https://mozilla.github.io/standards-positions/#native-file-s...

tomayac 6y ago
The points brought up by @cromwellian in https://news.ycombinator.com/item?id=24416738 https://news.ycombinator.com/item?id=24416738 are important in the context of the present comment, too.
- nuker 6y ago
  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. [0] https://en.wikipedia.org/wiki/Chilling_effect https://en.wikipedia.org/wiki/Chilling_effect
  - rewq4321 6y ago
    > 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.

BraveSnoo1028 6y ago

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.

RL_Quine 6y ago
The simple answer is to not use Chrome.
yjftsjthsd-h 6y ago
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.
- SAI_Peregrinus 6y ago
  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. [1]https://gbaptista.github.io/luminous/doc/en-US/ https://gbaptista.github.io/luminous/doc/en-US/

RandoHolmes 6y ago

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