Containing software without annoying users

>And there's the problem. Not everybody has the same notion of a "normal" app. I just don't see how you would do it without either losing tons of flexibility or writing tons of complicated policy.

Just because it can't work transparently for every possible program doesn't mean that it's not a good model to start from, a target to aim for, or that it won't work for the vast majority of desktop software.

>> If the application opens a file using the standard (and trusted) file open dialog, the application gets rights to that file.
> Let's leave aside the fact that there's nothing like a standard file open dialog on my system

Well, that's kind of your problem, you can't always take advantage of the work and standards that others make if you march to the beat of your own drummer, that goes for the app developers too.

> This magic file picker needs to be appropriate for all apps that are going to run inside that session. I just don't see this happen.

The vast majority of apps use a toolkit which provides a comprehensive, flexible, file picker widget. What you really need is negotiation and agreement from the top two or three toolkit developers to add support for file pickers over IPC with a standard policy hook, if this doesn't already exist.

Of course that won't cover all programs but you can hopefully cover the most exposed targets and provide guidance for the rest to come along on their own time. I think you still get significant benefit if you can containerize the top 80 out of 100 of the most used desktop applications, even if there are 10,000 other apps which aren't covered.

> It might work on Android

Yes, you see a bunch of work on this on more modern platforms. The new-type systems like Android , iOS and ChromeOS may replace traditional desktop systems like Windows, MacOS and Linux anyway except maybe for certain kinds of content creation and software development work.

> How would you contain something like Emacs without severely neutering its usefulness?

To contain an app like that there would be constraints which you might consider neutering because while you would be able to do the things you want to do you probably won't be able to negotiate on the _way_ you do them. An example of a constrained file access model might have ~/Documents/Emacs "owned" by emacs and this (along with ~/.config/Emacs and ~/.local/Emacs, maybe a few other settings files) are the only places where it can do unconstrained read/write, every other file access is either read-only or uses an IPC service which validates the request. That would would be a constraint on where you put your source code projects, mail spool, etc. that you expect to be editing, probably necessitating remote source control to get files in and out of the container. You might also make your app require its own private repository of tools rather than having shared tools as part of your OS, so it gets its own /usr with docs and compilers and whatever.

> > But even if there aren't any intentional holes, if your application has one little buffer overflow and parses one slightly odd attachment then suddenly your friendly F/OSS software becomes rather hostile.

> Yes, of course. That's a problem, I agree. I just think the solution is going to be a little harder.

Anyway this kind of containerization is very possible but there are tradeoffs. Concentrating on the programs which are most likely to be exposed, like web browsers, anything that might be spawned as a dependency of viewing an attachment, anything that talks directly over the network, is going to provide the most bang for the buck.

Also comprehensive political and legal reform on how the internet is regulated to try and reduce the base level of hostility in the environment would be a good parallel project to technical security measures. 8-)