ubuntu-phone team mailing list archive

[Bill Filler <bill.filler@xxxxxxxxxxxxx>]

On Tue, Apr 12, 2016 at 7:04 AM, Stefano Verzegnassi <
stefano92.100@xxxxxxxxx> wrote:

> Hi Bill,
>
> 2016-04-11 15:28 GMT+02:00 Bill Filler <bill.filler@xxxxxxxxxxxxx>:
> > Are you accessing the videos from File Manager and trying to open from
> > there? If so, that is the problem (actualy a bug in File Manager). When
> > clicking on the video from file manager it should request to open in
> > media-player not import via the content-hub.
>
> I understand the logic behind what you're saying, but that doesn't
> convince me.
> It sounds to me like an admission that there's something wrong with
> the content sharing concept in the Ubuntu platform, and that there's
> even no standard in a short term for that.
>

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.

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?)

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.


>
> Why should file-manager implement an exception for a single content type?
>

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 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.

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.

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.



>
> 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.


>
> What prevents Document Viewer (talking for myself here) to make a
> similar request, instead of being forced to rely on the file name and
> the size of the imported file[1][2], and finalize the transfer without
> copying the file if the app detects a similar file in ~/Documents? -
> This is the workaround that it has been suggested and I've been forced
> to implement for such scenario.
>

If we are talking about not copying the file that exists already, ideally
that should be done by content-hub and not the app, so I agree. Will add a
bug for this and see what is involved for adding it in the future.


>
> Being a not-preinstalled app, or a fully-confined one shouldn't be a
> reason why an app should be forced to provide a bad user experience,
> nor for being excluded from an app (file-manager) that it's the only
> way for an user to access the whole file system.
>
> I know there are security concerns about exposing the content of the
> device to third party apps. However, at least, there's no reason why
> content-hub should create a new copy of a file for an app that it has
> been already whitelisted (in the AppArmor profile) and authorized to
> the access that specific path.
>

Agreed


>
> 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.


> e.g.
>   https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1324985


This is in progress


>
>   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



>
>
>
> Cheers,
>
> Stefano
>
>
> [1]
> http://bazaar.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/lo-viewer/view/head:/src/plugin/file-qml-plugin/docviewerutils.cpp#L138
> [2]
> http://bazaar.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/lo-viewer/view/head:/src/app/qml/common/ContentHubProxy.qml
>