4 ms·

> No filesystem access This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access)

by throwaway2016a 8y ago

> No filesystem access This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing. There are some use cases that are hard to support (like being able to open all the files in a folder). But people are working on a solution.[1] > No IPC WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC. And there is nothing stopping a process running in a different browser (or even no browser at all) to connect to a webapp using WebRTC locally. Additionally, if a new window is opened by Javascript and both pages are in the same domain + port (or subdomains of the same domain and you have access to the parent domain) you can communicate between the windows with simple Javascript function calls. And since browsers are moving towards a 1 process per window setup this is essentially IPC. > That means browsers are building on top of operating systems while not interoperating with them. While I can't argue with that. So is X Window. The abstraction between app and OS is a thick gray line not a thin black one. [1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystemDirectoryEntry https://developer.mozilla.org/en-US/docs/Web/API/FileSystemD...

TeMPOraL 8y ago
> This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing. Most apps being limited to their little part of the filesystem is not a problem. The problem is, now as a user, I can't access those files. I can't view them in a form that suits me, I can't use other applications to operate on them. The true form of the data is forever hidden from me, a secret of the application that "owns" it.
- Klathmon 8y ago
  IMO that's a fairly easily solved problem. Browsers can add "localstorage browsers", you might even be able to do it in a browser extension. I'd also love it if they gave that ability.
  - Eequei3i 8y ago
    But that's the wrong direction. Instead it should map to a file tree that you can explore with your native file explorer and text editor. The browser becomes a silo for your data, inaccessible by every other application.
- aeorgnoieang 8y ago
  > The true form of the data is forever hidden from me, a secret of the application that "owns" it. But that's been true for almost all users, and not just webapp users, forever.
  - TeMPOraL 8y ago
    Not necessarily. In the world of desktop software, most users know what a file is, and know that all the data of what they've been working at the moment on is contained within such a file. They know they can move this file around and possibly send to whomever they want. They also know that a file can be opened by multiple applications. SaaS and web kill that.
    - aeorgnoieang 8y ago
      I was thinking of all of the files in proprietary, and particularly binary, formats. Maybe some users know that even those files can be opened by multiple applications, when that's even true, but I suspect even more users don't even realize that almost all of their data is stored in a file somewhere, let alone where that file is in the filesystem and in what format it's stored. Given the ubiquity of Word document and Powerpoint presentation files and the like, most users I'll grant you are aware of the files themselves, and the fact that they can be attached to an email. I'll even grant that a large fraction of those same users could answer 'yes' to the question 'Could these files be opened by another application?'. But almost none would be capable of doing anything with those files without an application that handles everything for them. I don't dispute tho that an awareness of, let alone existence of, files in a filesystem is a significant benefit and not having access to them is a (relatively) significant loss.
Eequei3i 8y ago
> The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. Your are neglecting the option of exposing a limited subview of the filesystem like containers do. > But people are working on a solution.[1] The big red box on top says it's not on standards-track. > WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC. Can I send open file descriptors like I can with unix domain sockets? Can I share memory for low-latency atomics? Futexes? > So is X Window. Maybe if you're remoting X, few people do that these days. In practice X applications have access to the same machine that they are drawing on.
- throwaway2016a 8y ago
  > Your are neglecting the option of exposing a limited subview of the filesystem like containers do. No I'm not. I said the limitation is a step forward. I didn't intend to imply it is perfect. It is not at all perfect. > The big red box on top says it's not on standards-track. Correct, but most standards started as experiments by the browsers. I think it qualifies as "people are working on it" but means it is probably far from being standardized. > Can I send open file descriptors like I can with unix domain sockets? Can I share memory for low-latency atomics? Futexes? No. But you already knew that. But it does allow for data communication which in my opinion solves the 80% use case for IPC. From my experience (YMMV) the features you described while useful are not needed for most consumer apps. Don't let perfect be the enemy of good.
  - TeMPOraL 8y ago
    > Don't let perfect be the enemy of good. The problem isn't perfectionism, but that at least some of us believe that things are moving in the wrong direction - towards making vendors own everything, and end-users in control of nothing.

TeMPOraL 8y ago

> This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing. Most apps being limited to their little part of the filesystem is not a problem. The problem is, now as a user, I can't access those files. I can't view them in a form that suits me, I can't use other applications to operate on them. The true form of the data is forever hidden from me, a secret of the application that "owns" it.

Klathmon 8y ago
IMO that's a fairly easily solved problem. Browsers can add "localstorage browsers", you might even be able to do it in a browser extension. I'd also love it if they gave that ability.
- Eequei3i 8y ago
  But that's the wrong direction. Instead it should map to a file tree that you can explore with your native file explorer and text editor. The browser becomes a silo for your data, inaccessible by every other application.
aeorgnoieang 8y ago
> The true form of the data is forever hidden from me, a secret of the application that "owns" it. But that's been true for almost all users, and not just webapp users, forever.
- TeMPOraL 8y ago
  Not necessarily. In the world of desktop software, most users know what a file is, and know that all the data of what they've been working at the moment on is contained within such a file. They know they can move this file around and possibly send to whomever they want. They also know that a file can be opened by multiple applications. SaaS and web kill that.
  - aeorgnoieang 8y ago
    I was thinking of all of the files in proprietary, and particularly binary, formats. Maybe some users know that even those files can be opened by multiple applications, when that's even true, but I suspect even more users don't even realize that almost all of their data is stored in a file somewhere, let alone where that file is in the filesystem and in what format it's stored. Given the ubiquity of Word document and Powerpoint presentation files and the like, most users I'll grant you are aware of the files themselves, and the fact that they can be attached to an email. I'll even grant that a large fraction of those same users could answer 'yes' to the question 'Could these files be opened by another application?'. But almost none would be capable of doing anything with those files without an application that handles everything for them. I don't dispute tho that an awareness of, let alone existence of, files in a filesystem is a significant benefit and not having access to them is a (relatively) significant loss.

Eequei3i 8y ago

> The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. Your are neglecting the option of exposing a limited subview of the filesystem like containers do. > But people are working on a solution.[1] The big red box on top says it's not on standards-track. > WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC. Can I send open file descriptors like I can with unix domain sockets? Can I share memory for low-latency atomics? Futexes? > So is X Window. Maybe if you're remoting X, few people do that these days. In practice X applications have access to the same machine that they are drawing on.

throwaway2016a 8y ago
> Your are neglecting the option of exposing a limited subview of the filesystem like containers do. No I'm not. I said the limitation is a step forward. I didn't intend to imply it is perfect. It is not at all perfect. > The big red box on top says it's not on standards-track. Correct, but most standards started as experiments by the browsers. I think it qualifies as "people are working on it" but means it is probably far from being standardized. > Can I send open file descriptors like I can with unix domain sockets? Can I share memory for low-latency atomics? Futexes? No. But you already knew that. But it does allow for data communication which in my opinion solves the 80% use case for IPC. From my experience (YMMV) the features you described while useful are not needed for most consumer apps. Don't let perfect be the enemy of good.
- TeMPOraL 8y ago
  > Don't let perfect be the enemy of good. The problem isn't perfectionism, but that at least some of us believe that things are moving in the wrong direction - towards making vendors own everything, and end-users in control of nothing.