[CTA] audio record works for call audio

I believe this behaviour is not device specific (users report this on other devices too), and that it is a regression during one of the OTAs since the phone launched.

Status changed to 'Confirmed' because the bug affects multiple users.

Bringing the conversation from email:

On 27 June 2016 at 23:18, Tyler Hicks <email address hidden> wrote:

I've pulled in Jamie Strandboge, who may have some insights about how
the audio recording policy should work. I'm not aware of the intended
functionality in the situation described in the bug.

I don't personally see capturing the audio output in the recording as a
security vulnerability as the user is still in control of audio recording.

On 28 June 2016 at 16:02, Jamie Strandboge <email address hidden> wrote:

> "On Thu, 2016-06-09 at 09:05 -0400, Pat McGowan wrote:
> Seems Rex understood the plumbing, maybe there is a pulse setting to
> disable it.
>

I would very much prefer this since this is a very sensitive area and IMHO, we
should only enable voicecall recording if there is a clear customer requirement,
and even then only with proper design.

The oem bug #1569213 references the voicecall-record[1] profile as being newly enabled.
Can we simply not disable that profile? Or is Ondrej saying that because of how
we do routing, you might be able to still record without the voicecall-record
profile (I'm guessing this means it would show up in pulse as a different,
recordable profile?)? If that's the case, let's fix the routing. :)

In other words:

 * the microphone is currently mediated by pulseaudio and trust-store

 * call recording recently was added somewhere and doesn't seem to be mediated
   by trust-store on all platforms (someone should confirm)

 * if pulseaudio and trust-store properly mediated call recording then this is
   probably technically enough to satisfy mediation requirements

 * (this bug) indicates it is surprising
   that call audio is lumped in with microphone recording. I agree this is
   surprising and strongly feel we should disable call audio recording until
   there is a clear customer requirement. call audio recording was never a
   consideration by our implementation because it didn't exist at the time--
   if it is something we want, it should be properly designed (likely a 2nd
   trust-store prompt)

[1]https://github.com/mer-hybris/pulseaudio-modules-droid/blob/master/README#L114

@tvoss could you comment on the trust-store aspects in #5

So, as the o/p I would add: jdstrand's note in #5 that we should only do this on a customer requirement is fine by me. We have a clear anti-requirement in some regulatory regions.

Specifically that we should either treat call recording as a special trust domain, and prompt/warn the user about the behaviour, or simply disable the functionality.

At the moment, I think this bug has three subtasks:

 - trust-store should have a clear notion of 'call recording' as a separate permission required of apps.

 - Pulse Audio should use this permission for the voicecall-record plugin.

If we agree, then there is a third task

 - Review our existing devices and confirm that voicecall-record is the only way the routing can set this behaviour up.

Alternatively, I think Trust Store can take the view that it does not want to support call-recording, and in that case we should arrange all devices to disable this feature.

On the trust-store aspect of this: pulseaudio should use the "feature" field when asking trust-store to verify requests, and use different enumeration values to distinguish ordinary microphone recording from voicecall recording. The respective functionality is available from trust-store today.

Taking the bigger picture into account, I would vote in favor of keeping the voicecall recording feature enabled under the assumption that the different recording types are clearly surfaced to the user.

re-opening, and moving this bug to clarify status. The general solution proposed here is the one we wish to use in the future, but we assume that we can simply disable this feature at lower levels in devices launched before this bug is fixed.

OEM bug #1597028 covers this.

Ubuntu Touch is no longer supported.