8 ms·

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 butto

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...
    - poizan42 6y ago
      In India iOS has 2-3% market share.
kitsunesoba 6y ago
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.
- _qulr 6y ago
  chrome://flags/#native-file-system-api I already had it disabled before LOL
- chromedev 6y ago
  It has a policy as well and will always allow you to disable it. No need for hyperbole.
  - giantrobot 6y ago
    "Will always" is a phrase Google does not know the meaning of.
    - chromedev 6y ago
      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.
      - imwillofficial 6y ago
        AMP waves “hello”
        chromedev 6y ago
        AMP isn't specific to Chromium
chromedev 6y ago
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?
- bigyikes 6y ago
  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.
- manjana 6y ago
  You don't always have to be a dummy to act stupid: https://en.m.wikipedia.org/wiki/Dark_pattern https://en.m.wikipedia.org/wiki/Dark_pattern
- ffpip 6y ago
  > why not give people choice ? https://news.ycombinator.com/item?id=24403392 https://news.ycombinator.com/item?id=24403392 https://news.ycombinator.com/item?id=20044430 https://news.ycombinator.com/item?id=20044430
deleted 6y ago
[deleted]
cromwellian 6y ago
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.
- cromwellian 6y ago
  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.
  - snvzz 6y ago
    >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.
sayhello 6y ago
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. https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/native_file_system/chrome_native_file_system_permission_context.cc;l=100;drc=41695565470611ba88f149ed16e54b9d5cb4f3ac https://source.chromium.org/chromium/chromium/src/+/master:c...
- deleted 6y ago
  [deleted]
- kissgyorgy 6y ago
  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.
  - daleharvey 6y ago
    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.
    - rewq4321 6y ago
      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.

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...
  - poizan42 6y ago
    In India iOS has 2-3% market share.

kitsunesoba 6y ago

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.

_qulr 6y ago
chrome://flags/#native-file-system-api I already had it disabled before LOL
chromedev 6y ago
It has a policy as well and will always allow you to disable it. No need for hyperbole.
- giantrobot 6y ago
  "Will always" is a phrase Google does not know the meaning of.
  - chromedev 6y ago
    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.
    - imwillofficial 6y ago
      AMP waves “hello”
      - chromedev 6y ago
        AMP isn't specific to Chromium

chromedev 6y ago

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?

bigyikes 6y ago
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.
manjana 6y ago
You don't always have to be a dummy to act stupid: https://en.m.wikipedia.org/wiki/Dark_pattern https://en.m.wikipedia.org/wiki/Dark_pattern
ffpip 6y ago
> why not give people choice ? https://news.ycombinator.com/item?id=24403392 https://news.ycombinator.com/item?id=24403392 https://news.ycombinator.com/item?id=20044430 https://news.ycombinator.com/item?id=20044430

deleted 6y ago

[deleted]

cromwellian 6y ago

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.

cromwellian 6y ago
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.
- snvzz 6y ago
  >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.

sayhello 6y ago

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. https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/native_file_system/chrome_native_file_system_permission_context.cc;l=100;drc=41695565470611ba88f149ed16e54b9d5cb4f3ac https://source.chromium.org/chromium/chromium/src/+/master:c...

deleted 6y ago
[deleted]
kissgyorgy 6y ago
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.
- daleharvey 6y ago
  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.
  - rewq4321 6y ago
    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.