[SailfishDevel] [Minutes] Sailfish OS Open Source Community Collaboration Meeting, 5th of September 2016

[Andrew Penkrat]

s/archives/achieves/g

On Wednesday, September 7, 2016 3:56:15 PM MSK, Andrew Penkrat 
<penkrat8 at gmail.com> wrote:
> Hi Slava,
> 
> On Wednesday, September 7, 2016 3:20:23 PM MSK, Slava Monich 
> <slava.monich at jolla.com> wrote:
>> Hi,
>> 
>> Access to contacts is actually quite a good example. It may or may not 
>> require access to the network, depending on how it's implemented at Qt 
>> plugin level. Should every app that needs contacts declare that it needs 
>> network access even if the app itself doesn't use the network?
>> 
>> Or it could require access to certain parts of the filesystem that by 
>> default is disallowed. How is application supposed to figure that out in 
>> order to request appropriate privileges?
>> 
>> To make matters worse, the plugin requirements may change over time, 
>> meaning that a system upgrade may break the app because the app didn't 
>> request access to some features required by the updated plugins.
> 
> Application shouldn't know/care about how does plugin work. Plugins are 
> parts of the system and shouldn't be sandboxed.
> 
> I don't know much about implementation, but Ubuntu Touch somehow archives 
> this with AppArmor.
> 
> Regards,
> Andrew
> 
>> 
>> The only sure way to protect the app against surprises like that is to 
>> request access  to pretty much everything. Which is the way it is now. 
>> So way bother?
>> 
>> Having full source code available (in merproject git repo) and making 
>> sure that the app is built from those sources in Mer OBS and signed (by 
>> Jolla?) would be a good start, in my opinion. Still it doesn't guarantee 
>> that the app has no rogue functionality built in, but the community may 
>> help to examine the source code. The more popular the platform is, the 
>> more apps we have, the more security conscious people are willing to 
>> check the sources - that sounds fairly scalable to me.
>> 
>> Cheers,
>> -Slava
>> 
>> 
>>> Slava,
>>>
>>> Apps would have to declare what they need to function, and then the 
>>> sandbox is in place to ensure that they can only use what they declare.
>>>
>>> This doesn't solve apps declaring they need full access to everything, 
>>> but at least there are some assurances to the user that if they expect 
>>> an app wont need access to the contacts list, that its not poking 
>>> around in there. Expecting everyone to check the source code (if 
>>> available) is not a very user friendly solution, and asking Jolla to 
>>> hand verify all apps in the store isn't very scalable either.
>>>
>>> On Wed, Sep 7, 2016 at 11:23 AM, Slava Monich <slava.monich at jolla.com 
>>> <mailto:slava.monich at jolla.com>> wrote:
>>>
>>>     I feel a bit sceptical.
>>>
>>>     If the system supports plugins, i.e. shared libraries discovered
>>>     at runtime and getting loaded into the process context without
>>>     executable knowing it in advance (like Qt does), then the
>>>     application doesn't even know what kind of resources it actually
>>>     needs at runtime to function properly.
>>>
>>>     The next thing you do after you introduce sandboxing, you start
>>>     adding ways to get around sandbox limitations, which in the end
>>>     defies the whole purpose. Or you severely limit the usefulness of
>>>     3rd party apps. Sounds like a lose-lose situation.
>>>
>>>     Any 3rd party app is a risk, especially the native ones,
>>>     especially those that come unsigned and without the source code.
>>>     If you don't want to take the risk, you don't install 3rd party
>>>     apps. That works better than any kind of sandboxing.
>>>
>>>     Cheers,
>>>     -Slava
>>>
>> 
>>
> 
> 



-- 
Sent using Dekko from my Ubuntu device