Re: Initial ideas on portals for file access

[Allan Day <allanpday gmail com>]

Alexander Larsson <alexl redhat com> wrote:
...
> I've been thinking a bit about file access in sandboxed apps.
...
> There are a few ways such documents could be used by sandboxed
> applications:
>
> * Application silos
...
> * Allow app access to parts of $HOME
...
> * Allow application access to files after interactive operation
...
> * Implicit permission grants from interactive operations
...
> So, what do we want to do here? I don't think the application silo
> model is a good fit
...
> We could allow partial HOME access
> to some very trusted apps, but that doesn't really strikes me as a
> proper sandbox solution.

We need to keep cloud storage in mind here. I can imagine a future
where each content application (such as your photo manager or music
app) can be backed by an online account rather than defaulting to
local-only storage. That online account could be filesystem-like [1],
in which case other apps could access the same files (assuming they
are given permission), but it might be a more specific service [2].

I can also imagine some deployments where the system is preconfigured
to only allow certain online storage providers, and local-only file
storage is either limited or disabled altogether.

We will also need to be able to have open, save and share dialogs that
can span each of these types of file storage, so you can attach a
photo to an email, irrespective of whether you use Flickr, OneDrive,
or just the local disk in order to store it.

A slightly different point - while content apps require comprehensive
access to a storage location (since they need to be able to see every
content item, and might want to change any of them),  I don't think
that this is necessary for most apps. This could create issues with
apps asking for unnecessary access - how is a user supposed to know
that the access isn't necessary?

Allan

[1] Such as Google Drive or OneDrive accessed through GVFS.
[2] Like Google Photos, Google Music, or Flickr.