On Wed, Apr 13, 2016 at 4:25 PM, Stefano Verzegnassi <[email protected]> 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 <[email protected]>: >> 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 : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
