Re: RFC - file chooser dialog API for sandboxed apps

[Matthias Clasen <matthias clasen gmail com>]

Hi Steve,

thanks for working on sandboxing - it is a topic that is on the mind
of a lot of people, and we're long overdue to make progress on it.
You've clearly invested a lot of effort into this, and deserve a
serious response.

> From your API proposal, one could get the impression that you are
simply approaching this as a 'we need a remote file chooser'
perspective. And you address many of the problems that need solving
when the goal is to remote the file chooser. I'm not entirely
convinced that a remote file chooser is the best way forward, though.

I would start by looking at concrete use cases. What are the
applications that we are talking about ? Will they need to open
abstract 'files' ? Or are they better served with a more concrete api
that lets them ask for the kind of objects they are dealing with:
documents, notes, photos, or whatever it may be ? You blog post gives
some hints about the use cases you have in mind: 'process your
documents', 'cooperative apps', 'multi-tasking' - it would be great to
know more about the problems you are trying to solve.

Next, I would look at the user experience, and sketch out how the
interaction would look for the user of a sandboxed application in your
use cases. To give some examples, our design team has recently started
to work on this for sharing [1][2][3]. Sharing may or may not be
related to your problem ('sharing documents between applications').
One user experience I could imagine is a 'shelf' or 'clipboard', where
you could drop documents temporarily to make them quickly accessible
from all applications while you are working on them.

Last, I don't think you can really solve sandboxing without talking
about 'the other side' - how is the system going to provide this
service to the sandboxed application, and how is the application going
to request it. I didn't see much about that in my quick review of your
material - maybe I missed it.

Lets take a step back: Why is the file chooser a problem in sandboxed
applications ? The file chooser that the toolkit provides is all about
access to the file system, which we obviously need to limit for
sandboxed applications. But how much ? This is a question about the
design of the sandboxing infrastructure, and the answer will greatly
influence how the 'working on a document with multiple applications'
use case can be solved.

What are the options ?
- unlimited access
- restricted access
- no file system access at all

The first option sounds like a non-starter, although one could discuss
options like running each app under their own uid, and use traditional
access control to limit the applications view of $HOME, just like we
currently limit its view of /etc.

The last option is the simplest, but will also require applications to
change quite a bit.

The middle option seems to be what most people that I have talked to
about sandboxing have in mind: Each application gets its own area on
the file system where it can save state. This is relatively easy to
implement, because we are already reasonably close to this, with music
applications mostly caring about ~/Music, photo managers looking in
~/Photos, and so on.

A problem with the 'restricted access' approach for your use case of
'working with multiple apps on the same document' is that each app
will be able to access only its own filesystem area. A lo-tech
solution to this might be a simple as adding a 'shared space' to the
restricted access, where multiple apps can read and write files.


Lots of food for thought. Again, thanks for bringing this up for
discussion, and for working on an proposed solution!


Matthias



[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/photos/wires-sharing.png
[2] 
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/shell/access-dialogs/wire-access-dialogs.png
[3] 
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/privacy/privacy-panel.png