touch-packages team mailing list archive

[John McAleely <john.mcaleely@xxxxxxxxxxxxx>]

certainly. is there actually any way to *do* background recording, in the
current app lifecycle?

On 14 August 2015 at 19:23, Jamie Strandboge <jamie@xxxxxxxxxx> wrote:

> Should bug #1230391 be revisited now that this is landing (show a visual
> cue if background recording)?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1224756
>
> Title:
>   Pulseaudio should integrate with trust-store
>
> Status in Canonical System Image:
>   In Progress
> Status in pulseaudio package in Ubuntu:
>   In Progress
>
> Bug description:
>   Currently the 'audio' policy group allows access to pulseaudio which
>   allows apps to use the microphone and eavesdrop on the user.
>   Pulseaudio needs to be modified to use trust-store, like location-
>   service does. Integrating with trust-store means that when an app
>   tries use the microphone via pulseaudio, pulseaudio will contact
>   trust-store, the trust-store will prompt the user ("Foo wants to use
>   the microphone. Is this ok? Yes|No"), optionally cache the result and
>   return the result to pulseaudio. In this manner the user is given a
>   contextual prompt at the time of access by the app. Using caching this
>   decision can be remembered the next time. If caching is used, there
>   should be a method to change the decision in settings.
>
>   Targeting to T-Series for now, since the trust-store is not in a
>   reusable form yet.
>
>   Original description:
>   David and the security team (inspired by an observation from Rick)
> discussed that when recording, pulseaudio should somehow unobtrusively show
> the user that it is recording. The easiest thing to do would be for
> pulseaudio to alert indicator-sound which would then turn its icon red
> (similar to indicator-message turning blue with new messages). Marking
> 'high' because apps with access to pulseaudio can currently eavedrop on
> users. If the app is allowed to do networking (the default for apps), then
> it can ship that information off to a server somewhere.
>
>   Note 1, the alert to indicator-sound must happen via the out of
>   process pulseaudio server and not the confined app itself to be
>   effective.
>
>   Note 2, we should consider how to enforce this for foreground apps
>   only. Application lifecycle should probably handle this for 13.10
>   (apps are suspended if not in foreground or if the screensaver is on),
>   but we don't want an app on the converged device to record in the
>   background when the user isn't paying attention. Example eavesdropping
>   attack: start recording only when the screensaver is on (perhaps
>   inhibiting the screensaver during recording would be enough).
>
>   <https://wiki.ubuntu.com/AccountPrivileges#Phone>: "On the phone, if
>   an app tries to access your ... microphone ... or video recording,
>   this should be subject to permission. “Video recording” should be
>   separate from “Camera” so that an app does not need two permissions
>   when recording video, one for the camera and one for the microphone.
>   If an app has permission to record video, it should have access to the
>   microphone whenever it is recording video..."
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1224756/+subscriptions
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1224756

Title:
  Pulseaudio should integrate with trust-store

Status in Canonical System Image:
  In Progress
Status in pulseaudio package in Ubuntu:
  In Progress

Bug description:
  Currently the 'audio' policy group allows access to pulseaudio which
  allows apps to use the microphone and eavesdrop on the user.
  Pulseaudio needs to be modified to use trust-store, like location-
  service does. Integrating with trust-store means that when an app
  tries use the microphone via pulseaudio, pulseaudio will contact
  trust-store, the trust-store will prompt the user ("Foo wants to use
  the microphone. Is this ok? Yes|No"), optionally cache the result and
  return the result to pulseaudio. In this manner the user is given a
  contextual prompt at the time of access by the app. Using caching this
  decision can be remembered the next time. If caching is used, there
  should be a method to change the decision in settings.

  Targeting to T-Series for now, since the trust-store is not in a
  reusable form yet.

  Original description:
  David and the security team (inspired by an observation from Rick) discussed that when recording, pulseaudio should somehow unobtrusively show the user that it is recording. The easiest thing to do would be for pulseaudio to alert indicator-sound which would then turn its icon red (similar to indicator-message turning blue with new messages). Marking 'high' because apps with access to pulseaudio can currently eavedrop on users. If the app is allowed to do networking (the default for apps), then it can ship that information off to a server somewhere.

  Note 1, the alert to indicator-sound must happen via the out of
  process pulseaudio server and not the confined app itself to be
  effective.

  Note 2, we should consider how to enforce this for foreground apps
  only. Application lifecycle should probably handle this for 13.10
  (apps are suspended if not in foreground or if the screensaver is on),
  but we don't want an app on the converged device to record in the
  background when the user isn't paying attention. Example eavesdropping
  attack: start recording only when the screensaver is on (perhaps
  inhibiting the screensaver during recording would be enough).

  <https://wiki.ubuntu.com/AccountPrivileges#Phone>: "On the phone, if
  an app tries to access your ... microphone ... or video recording,
  this should be subject to permission. “Video recording” should be
  separate from “Camera” so that an app does not need two permissions
  when recording video, one for the camera and one for the microphone.
  If an app has permission to record video, it should have access to the
  microphone whenever it is recording video..."

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1224756/+subscriptions