ubuntu-phone team mailing list archive

[Stefano Verzegnassi <stefano92.100@xxxxxxxxx>]

Below I'll talk about "default apps". It's just a way to say
"core-apps + system-app that can access to the home folder.

2016-04-12 15:20 GMT+02:00 Bill Filler <bill.filler@xxxxxxxxxxxxx>:
> Sorry, it's not an admission of a problem. Sounds like it's a sign that
> there is some confusion about the security and content sharing model on the
> platform which I can try to clear up.
>
> The default concept is that apps are silo'd and own their data in a location
> only they can access. No other apps can access another apps data in these
> cases. That is where the content-hub comes in. The content-hub's main
> purpose is to provide a secure mechanism for apps to transfer (i.e. copy)
> their data to another app, such that the other app gets a copy of the data
> and can store (or not) in it's own silo'd area. content-hub is not a
> "viewing" api by design, it's a data transfer api.

Ok, that makes sense now, since this mechanism should work in synergy
with url-dispatcher, as explained below.

> However, there are some exceptions to the rule which complicates things.
> There are system level directories on the platform that are able to be
> accessed by the certain allowed apps (via app armor rules) and system level
> components, and the apps use these directories to access/store their data.
> Specifically
>
> ~/Pictures -> Gallery, MediaPlayer, Scopes
> ~/Videos -> Gallery, MediaPlayer, Scopes
> ~/Music -> Music Player, Scopes
> ~/SD-Card -> Gallery, MediaPlayer, Scopes, Camera
> ~/Documents -> Document Viewer (I believe?)

Docviewer-app and music-app are also able to access the SD card, but
their access to /media/*/* is not the same.
Music-app can read the content of the whole SD card, docviewer-app has
also write permissions but the security team has authorized the app to
access only /media/*/*/Documents.

Just a bit off-topic here but, since it seems that Ubuntu will
(ideally) have one app for each user's folder (Documents, Music,
Downloads, Video, Pictures), does it make sense to provide a link in
the applications scope for the downloads page in browser-app?
Also, that downloads page should also be registered in content-hub,
since browser-app is able to save downloaded files in ~/Downloads: I'm
thinking at a scenario where the user downloads a file but there's no
app that can handle that content yet.

> url-dispatcher is different from content-hub, in that it's purpose is to
> request an app on the system to open a given url, with the assumption being
> the destination app has permission to access the specified url/resource, in
> order to "view" or open it in place.

That's not documented at:
https://developer.ubuntu.com/en/phone/platform/guides/url-dispatcher-guide/

I believe this is also a reason why url-dispatcher has never been
considered as a solution for this problem.

> So backing up yet again, the phone was designed without having a File
> Manager at all, as it's really in conflict to the notion of apps owning
> their own data. The app is not installed on the device by default for this
> reason. Having a single app, file-manager, which is allowed to access all of
> the data on the disk, is only granted with a special security permissions
> and the user has to enter their password. So file-manager is really a
> special case.

That makes sense.

> That said, the file-manager needs to be aware of the above rules and use the
> appropriate api's depending on the case. It's unfortunately not one size
> fits all with our current model. Using the content-hub for everything which
> the file-manager currently does, by definition will perform a copy of the
> data. It works but is not optimal for data which lives in the special
> directories as it makes a copy.

Ok, to sum up what you've explained, we have two types of content:

- Content owned by an app, which is the case of the silo'd apps.
- Content without any "ownership", which is the case of files stored
in user's folders.

Core/System apps are a sort of bridge between the latter type and
third party apps, and should provide two methods (via content-hub or
url-dispatcher) for accessing that content.

The two methods should work as follow:
- via content-hub: when an app requires the ownership on the content
or handle specific data. This could be the case of an app that needs
to access the details of a specific contact, or e.g. an "image editor"
app, which requires to read/write the original image pixel by pixel.
(i.e. data manipulation)
- via url-dispatcher: when an app needs to satisfy an user request
about viewing the content with the specific handler. (i.e. view some
data on user's request)

> For content that lives in the special directories listed above, there could
> be options in the file-manager to "view" the content based on mime-type
> using url-dispatcher. This would cause the content to be viewed in place by
> the destination app without copy. Yes it is extra work in the file-manager,
> but there is no support in content-hub for this type of operation.

At this point it sounds legit, however which standard file-manager
should follow is still unclear to me.

What do you mean by ""view" the content based on mime-type using
url-dispatcher"?

I had a look at how things work on the Ubuntu Touch platform and,
actually, it seems that apps do this thing at their own way.

First of all, no app is registered for the "file://" protocol in url-dispatcher.
So here's the first question: is Ubuntu Touch following its own
standard, or should it use the "file://" freedesktop.org standard[1]?

1) In the former case, I can easily think that we'll have some
protocol like "video://", "music://", "photo://", "document://" and so
on.
Each of the protocols I mentioned is already there, so nothing else is
required by each app's side. The extra work file-manager should do is
to get the proper protocol for the mimetype (should it have an
hard-coded database with the associations?).

- Is this usage of url-dispatcher meant to be used exclusively by file-manager?
If not, this extra work should be done at a platform level (UITK or
url-dispatcher itself), so that any third party app can open a file
with the proper app.
A use case that has been discussed in the past is CheckBox - there was
some interest in in opening the results via DocViewer.

- What happens if file-manager needs to open a file which is not
located in user's folders?
Currently no core-app can access to that part of the file system, and
gallery-app does not handle any file which is not located in one of
the watched paths. Should file-manager create a temporary copy of that
file, and load that copy instead?

2) Using the "file://" protocol.
As I wrote above, none of the apps available in the Ubuntu Store are
registered for this protocol in url-dispatcher. Also, the only app
that provides the supported mimetypes as per "Desktop Entry
specifications"[2] (i.e. gallery-app) explicitely refuses any protocol
which is different than "photo://".
In this case, anyway, url-dispatcher should take care of properly
resolving the mimetype and launch the right application through
ubuntu-app-launch.

> Perhaps in the future content-hub api can be extended to support opening in
> place if the source and destination directories are the same, but this
> doesn't exist today.

Ken answered about this. Good to know that it will gain an higher priority.

>> In the past, a similar request has been made by music-app developers:
>> if an user requires to open a file from ~/Music, file-manager should
>> use URL dispatcher instead of content-hub.
>
> Right, for same reason as stated above.

That's clear now.

>> This topic has been systematically raised every N months, by someone
>> complaining her/his unsatisfying experience with content-hub.
>> No answer has been given, so I'd like to know if there's some plan or
>> on-going work for those bugs that have been reported years ago, since
>> no progress has been made.
>
> We'll look at the possibility of extending content-hub for this type of
> support. Seems a big part of the unsatisfying user experience is coming from
> the way file-manager is currently implemented, and as pointed out there is
> another viable solution that has been proposed in the past, with bugs filed,
> so this should not be blocked.

I'm not going to talk about allowing third party apps to replace the
core/system apps as default providers (Android allows that, but it
isn't relevant now).

The biggest issues IIRC were about Beru, which is 3rd party ebook
reader but there's no default app that handles ebooks.
Perhaps we need to define these edge cases a bit further.

>>   https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1370687
>>   https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1425955
>
> These two bugs are not specifically related to the problem you are
> describing

Well, given that now we know that url-dispatcher is the solution to
many problems about not-silo'd content, they aren't related anymore.
In case content-hub was the solution instead, the second looks
desiderable and the access to the SD card surely useful.

Sorry for asking so many details, but this turned out to be a great
occasion for explaining how content sharing really works. Also, we're
just a few core app developers left, and it might be useful to have a
full reference available for whoever will resume the file-manager
development.

Thanks for your useful reply.

Stefano

====

[1] https://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.1.html
[2] http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/