Comment by satyenr | Hacker News Reader

Comment by satyenr | Hacker News Reader

Parent Full thread

> What if I don't desire a gui application store or desire a different one or switch application stores or move a dir with executable files from one machine to another?

What does any of this have to do with a GUI? And for transporting, extract the data into a portable bundle, or take the entire store.

> Is the application store the only way to start at app? If I bind a global hotkey to start an app how is that handled?

Again, what does any of this have to do with how the applications are stored? Can you see the files that make up an iOS app? You can still start them, can’t you? A macOS app is a folder called Something.app, the actual binary lies somewhere inside. Do you typically need to poke inside the .app folder?

> How about I have an addon for firefox that allows me to bind keys to operations which can include javascript which can itself start applications which can then write to files.

As far as the computer is concerned, you are merely starting a process. Again, what does that have to do with how applications are stored. They can be triggered however and wherever they are stored.

> Do I have to access my photos via a a singular photo manager? I can imagine images accessed in 17 different contexts by 30 different apps does each of them need permission to access each dir which contains images or just generically to access images

This is already being handled on iOS and Android. Photos apps is merely the default interface for the PhotoStore. You can access your photos from any app.

> Does this mean that a singular permission would control both access to the browsers cached image of the ycombinator logo on this page and some ones nude selfies?

Namespaces inside individual stores, or separate stores.

1. At present I can take a text file even not on the PATH put a shebang on it, mark it executable, and execute it because the underlying medium is a user visible hierarchical data store that I interact with directly. It's not clear how the app store application would be associated with it or even know about it or how say a terminal would borrow the application that it didn't know about to run it.

2. An actual filesystem allows you to run things that aren't in an app store bundle

3. Which app owns the files when An app starts an addon which starts a process which runs an app which accesses a file. Does the last app in the chain own the file? This is challenging because plenty of apps could do things based on arguments passed in that involve modifying the filesystem.

4. The way ios and android handle 2 apps accessing the same file is only acceptable if someone has envisioned the way you want this to happen to some degree on both ends. A file picker works on any type of file and an OS that can't have a file picker seems to be objectively worse whereas adding an image picker would be an upgrade. I enjoy using calibre to manage how ebooks are stored and beets for music but neither is bounded by an underlying system designed by others and neither locks said files into said structure or limits access according to it. Its trivial to all out to calibre including via the cli get the full path to a book for example and do something with it.

It seems fairly clear to me that there several layers of filesystem access.

Applications that should never have access to your filesystem because they are malicious. Avoided by installing only from trusted sources to avoid malware in the first place the best possible line of defense. This also makes it possible to get a list of applications that ought to be revoked and communicate this to users.

Running code that should have no or very very controlled access to the filesystem ordinarilylike the Javascript on this page.

Apps that run as the user on their behalf that accesses the filesystem.

You appear to want to pile a layer on top of the last. This appears to only work for the simpler cases and I'm not even clear what the benefits are supposed to be.

> It's not clear how the app store application would be associated with it or even know about it or how say a terminal would borrow the application that it didn't know about to run it.

Where does the file come from? Suppose you create a file in your terminal application, then it lives inside the terminal and you can use your terminal to run it.

> 2. An actual filesystem allows you to run things that aren't in an app store bundle

Neither a global namespace (file system) nor an appstore are required to execute a program.

> Which app owns the files when An app starts an addon which starts a process which runs an app which accesses a file.

This should be at the discretion of the application developer. This is also the way browsers already work with sandboxed addons.

> This appears to only work for the simpler cases and I'm not even clear what the benefits are supposed to be.

If you don't put everything in the same global namespace, you get more security, cohesion and compatibility. That's why we use VMs, containers, sandboxes, and various user accounts instead of doing everything in a single filesystem using the root user.

I think constraining many apps access to the file system is a fine idea. I just think think that mapping files to applications very quickly becomes farcical as the abstraction just clearly doesn't match.

It not even optimally secure. Why for example would your image editor need access to all your image files instead of just the ones passed in via a secure system dialog?

In that instance the dialog would be the checkpoint not the some weird file system borrow checker.

Reply on news.ycombinator.com