ubuntu-phone team mailing list archive

[John Johansen <john.johansen@xxxxxxxxxxxxx>]

On 09/21/2015 08:10 PM, Mitchell Reese wrote:
> 
> 
> On Tuesday, 22 September 2015 3:17:28 AM AEST, John Johansen wrote:
>> On 09/21/2015 09:25 AM, Oliver Grawert wrote:
>>> hi,
>>> Am Montag, den 21.09.2015, 17:42 +0200 schrieb Krzysztof Tataradziński:
>>>> So for clarification:
>>>> app XYZ can access by content-hub other app's (YYY) file (abc.odf)
>>>> located in .local/share/YYY/abc.odf read and edit it, yes?
>>>> But could XYZ use content-hub to read/write in example in ~/Documents
>>>> or ~/Music?
>>>
>>> i could imagine you could have a "reverse-content-hub" so you move the
>>> file back to the shared folder after editing it (something like a
>>> checkbox in the save dialog that says "make available to other apps"
>>> which would overwrite the file in ~/Documents or some such)
>>>
>> It is also possible that the file can stay in place and never has to
>> be copied into the directory, or copied back out.
>>
>> The important part for security is that the user uses the content-hub
>> to associate access of the file to the application.
>>
>>
> That might make sense for a phone, where file browsers these days seem optional, but that will kill usability on a desktop system.
> 
> I.e. - I regularly create folders for various projects. In these folders are images, text documents, open document formats, gimp files, ms word documents, pdf's, etc. In short, multiple formats that need different programs to open them. If I want to see them at once easily, it's not feasible to have all these files stored within each application that created/opens them.
> 
> Security is great, but it needs to be balanced with ease of use or we will loose people. The content hub could be a great solution, providing it can also be used to write files to user accessible folders. It needs to be quick, easy, and light - a couple touches and the file is saved, without the user seeing much of the back-end.
> 
Think of content-hub for desktop being the system file access dialogues and even the file browser. Instead of running the file access dialogue in the app it is run as an external processes and the app transparently communicates with it. The dialogue or file browser can hand the app permission to access the file file in place, but the application is still prevented from accessing files it hasn't been granted rights to.

Again the important part security wise is the user interaction to choose a file happens in a trusted context, this is the content-hub, file browser, system load/save dialogue, etc. And this trusted code then gives the application access to the data. The current system of copying files into the apps dir is just a first pass and is not a required part of the security model. Improvements to the current implementation will come, the goal is a full converged system.