ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 10/15/2013 09:24 AM, Florian Felgenhauer wrote:
> Hey *,
> 
> for all the paranoids (like me) out there, who guaranties me what Permy
> shows me is correct.
> 
Nothing really-- it happens to have a project page and the project is open
source so you have access to the source, but the source is built by the
developer so of course it could be replaced to conceal certain accesses, to
misreport or just have legitimate bugs. Because it is open source, you are in a
position to build it yourself and install it on your device. This is no
different than any other free software-- because you have a hackable device like
Ubuntu Touch and the source to this app, you can examine it and build/fork it
yourself. Or you can trust the developer.

> I like the idea of a server building the
> source. But again, what do we need to
> do to trust that server system. Can we
> build up a system where it is hard to
> "steal" or manipulate source code, and if you can manage this,
> it is at least known who did it.

The server is an interesting idea, and maybe it'll happen, but maybe not. If it
does, it doesn't actually solve the concern being expressed here because
non-opensource applications/binary blobs need to be supported by the appstore
otherwise certain types of non-free applications that many people would find
useful couldn't be added to the store. If there is a requirement that all apps
that come with source have to be built be a trusted server, the bad guy will
just ship a binary blob.

Apps run under application confinement[1] and application confinement has been
carefully designed to prevent stealing user data, running arbitrary code, etc.
An app can't steal another app's data (including system data). An app can't see
your facebook history or tweet as you. The trust model[2] is such that click
appstore apps are untrusted by the OS and that permission to access sensitive
data by AppStore apps is typically granted or denied at the time of access[3].
When a user installs an app, the user trusts the OS to make sure that the app is
confined and can't access anything outside of confinement, but the OS also
provides context for certain accesses. Eg, while some click game may have access
to the internet to post high scores, it is not allowed to steal your SSO
credential, to upload your music to a remote server or to sniff your keyboard.
Application confinement blocks *direct* access to things like that, but APIs
exist for access to some things so if an app wants to, for example, upload a
picture, it can do so-- but in using the API, the OS provides context for the
access so that the user discovers what the app is doing-- maybe via a
confirmation prompt, maybe via the gallery or a file picker (it all depends on
the API and what is appropriate in terms of usability, etc). So, if a game tries
to get a token to use twitter or obtain the pictures from your camera roll, then
the user sees a prompt and can act accordingly. The user can now explicitly
grant access to the sensitive data and therefore explicitly trusts the
application for this access. If it doesn't make sense for the app to have access
to twitter, then the user can deny the access and write a user review (eg, "1
star-- this app wants to access twitter for seemingly no good reason"). Of
course a malicious application can throw up a phishing page in a webview or
upload the picture to instagram while also uploading it to a remote server but
that is possible in any app store and that is where user reviews, terms of use
(for the developers) and app removals come into play. Policies are in place to
handle reported malicious apps and developers.

[1]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
[2]http://developer.ubuntu.com/publish/apps/security-policy-for-click-packages/
[3]due to https://launchpad.net/bugs/1230091, this is not fully implemented yet,
but will be soon

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature