ubuntu-phone team mailing list archive

[Olivier Tilloy <olivier.tilloy@xxxxxxxxxxxxx>]

On Wed, Apr 13, 2016 at 4:25 PM, Stefano Verzegnassi
<stefano92.100@xxxxxxxxx> wrote:
> 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.

webbrowser-app is already registered as a content source, if that’s
what you mean. So you can for example download a file to ~/Downloads,
and later request opening that file from another app (e.g. telegram to
attach it to a message).


>> 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/
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp