<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi,</p>
<p>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?</p>
<p>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?</p>
<p>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.</p>
<p>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?</p>
<p>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.</p>
<p>Cheers,<br>
-Slava<br>
<br>
</p>
<br>
<blockquote
cite="mid:CAMx7nHtcCTsioLqcFYN1OUM_5LzUAqyPWQ0CENV2r7WieC4pQA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">Slava,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep 7, 2016 at 11:23 AM, Slava
Monich <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:slava.monich@jolla.com" target="_blank">slava.monich@jolla.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I feel a
bit sceptical.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
-Slava<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>