ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-10-25 08:20 AM, Michael Zanetti wrote:
> On Friday 25 October 2013 08:13:20 Marc Deslauriers wrote:
>> On 13-10-25 06:43 AM, Michael Zanetti wrote:
>> <snip>
>>
>>>> In short, your use case falls into the category of 'backup software' and
>>>> backup software is not supported by the appstore at this time.
>>>
>>> Just to add some more unsupported use cases:
>>>
>>> * A Music downloader
>>
>> That's supported with the "music_files" policy group.
>>
>>> * An alternative Camera app that allows making funny pictures like the
>>> google hangout toolbox
>>
>> That's supported with the "picture_files" policy group.
>>
>>> * An office suite
>>
>> Wouldn't an office suite store it's files in its own directory?
>>
>>> * An app like the Parrot AR.Drone controller wouldn't be able to store
>>> pictures taken with the drone's camera in a place where a user can ever
>>> find it again.
>>
>> That's supported with the "picture_files" policy group.
>>
>>> I personally think this should be considered higher priority than after
>>> 14.10. Also I don't really see why allowing access to arbitrary
>>> subfolders in $HOME (granted by policy ofc) is more problematic than
>>> allowing access to location, address book, microphone or camera.
>>
>> It's not more problematic, but it currently leads to a manual review process
>> because allowing an app to access all the user's files is
>> security-sensitive and defeats being able to install and trust arbitrary
>> applications from the store.
>>
>> In the future, I hope we'll be able to remove the manual review process step
>> by adding appropriate content providers for those items that will prompt
>> the user on first access.
>>
>>> A policy "write_pictures" that gives write access to $HOME/Pictures
>>> doesn't
>>> sound like the end of security to me.
>>
>> We have that already, it's called "picture_files".
>>
> 
> Oh, nice. What is the problem then why Robert's use cases don't work?
> 
> I understood Jamie's explanation as this is not supported (and won't be in the 
> foreseeable future).

The first message in this thread sounds like he wants to access arbitrary
directories in the user's home folder. His original post however seems to
indicate he wants his ebook reader to be able to read and write ebooks into
arbitrary locations in the user's home directory.

Our application security model has each application owning its own data, and
sharing it with other applications. In other words, the ebook reader should be
storing its files in its own directory, and offering them to other applications
via the content hub. This allows the user to authorize which files get
transferred between applications instead of allowing a malicious application
access to the totality of the user's data.

This design also remedies the usability issues inherent with file and folder
management.

Marc.