ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 03/10/2014 04:34 AM, Thomas Voß wrote:
> On Mon, Mar 10, 2014 at 10:27 AM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx> wrote:
> Jamie Strandboge wrote on 07/03/14 16:09:
>>>> ...
>>>>
>>>> This reminded me about how we are going to deal with an application
>>>> recording audio and video. (I don't want to get into a situation
>>>> where an app can be uploaded to the store to eavesdrop or spy on
>>>> users via the mic or camera).
>>>>
>>>> There are open bugs on this[1][2] and there is a nice summary in
>>>> comment #14 of LP: #1224756[3]. I don't think this ever made it to
>>>> the list, so I figured I'd both put the information out there and
>>>> ask a couple followup questions here.
>>>>
...
>> As we do not allow applications running in the background (at least on
>> the phone/tablet), this applies to (trusted) helpers and their
>> operation. My understanding is that the indicators are responsible for
>> providing this sort of feedback to users.
> 
Indicators are fine and were discussed in the bug[1] as the implementation, but
they doesn't work well in all cases, particularly when the app is full screen.

>> With that: We do not have trusted helpers for recording of audio or
>> video. For that, a recording application is either in the foreground
>> and thus visible to the user, or in the background and stopped or
>> killed. The same applies for the lock screen: Only operations provided
>> by (trusted) helpers continue while the phone is locked. All regular
>> applications are stopped or killed when enetering the locked state.
> 
>> Matthew/Jamie: Does that correspond to your understanding?
> 

So, I may have not been clear. Well-behaved apps are, well, well-behaved and the
whole application lifecycle point you made applies to them.

I am talking about something like a torch app that is a essentially a trojan in
that when the app is running (foreground or background is irrelevant), it is
recording audio and/or video and shipping it off over the network even though
the user is just trying to illuminate the pages of her book. Right now, this is
possible because pulseaudio is not a trusted helper and we don't have a camera
service yet (so it obviously isn't a trusted helper yet). We felt that
restricting access to the audio and camera apparmor policy groups was too
onerous at this stage of our app developer story, so all apps have access to
them (and pulseaudio isn't written in such a way that apparmor can differentiate
between recording and playback). This is why I filed bugs[1][2] and why I
brought this conversation up here-- to make sure we address this for when we
ship devices.

If we rely solely on indicators, malicious apps will just always be full screen.
In my mind, we need to treat recording just like how we treat the location
service: pulseaudio and the camera service become trusted helpers such that when
the app tries to *record* audio and video (respectively, with no prompting for
simple playback), the user is prompted that the app wants this access, and the
result can be cached via the trust store. After that, how we present that an app
is recording is a matter of design/usability and no longer strictly a security
issue (though, it would be nice if we did it really well so people can notice
being recorded).

[1]https://bugs.launchpad.net/ubuntu/trusty/+source/pulseaudio/+bug/1224756
[2]https://bugs.launchpad.net/touch-preview-images/+bug/1230366

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

Attachment: signature.asc
Description: OpenPGP digital signature