touch-packages team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

I've tweaked the design to solve a problem with video+microphone access.
<https://wiki.ubuntu.com/AccountPrivileges?action=diff&rev2=20&rev1=19>

I was trying to solve the problem that an app trying to record video and
nothing else (Vine, for example) shouldn't result in two prompts in
quick succession, one for camera access and one for microphone access.

The way I originally solved it was to say that if an app tries to access
anything while the the permission prompt for something is up, the two
prompts should be combined. But that was over-broad: it could have
resulted in riders, for example an app that really needed your location
trying to access your contacts at the same time, resulting in a single
prompt for both. This would be exactly the all-or-nothing choice that
the prompt model aims to prevent.

Instead I've special-cased video recording: if you give an app
permission to record video, it should automatically have access to the
microphone when -- and only when -- it is recording video. If you just
give the app access to your camera for still photos, then accessing your
microphone should require a separate prompt.

** Description changed:

  Currently Ubuntu Touch is using the android camera-service and that is
  the plan for 13.10.
  
  Going forward in 14.04, the android camera-service will no longer be
  used and camera access is going to move to the Ubuntu side. There was
  discussion of either using HAL directly (direct access to devices) or
  using a camera-service type thing in Ubuntu.
  
  Using devices directly causes at least a few problems:
   * can't prevent more than one user from accessing the device at a time
   * enumerating camera devices for apparmor policy is extra maintenance for porters
   * can't provide a contextual runtime prompt for access (like we (will) do with online accounts, location, microphone). This is particularly important for application confinement.
  
  Instead of direct hardware access, an out of process helper (in relation
  to the app) can be used to address all of these problems, similar to
  what pulseaudio does for audio. This service can ensure only one user
  can access the device at a time and since the service accesses the the
  device files on the app's behalf, we don't need to enumerate devices in
  /dev in policy. Furthermore, when an app accesses the service (ideally
  over DBus), the service can contact trust-store, the trust-store will
  prompt the user ("Foo wants to access the camera. Is this ok? Yes|No"),
  then optionally cache the result and return the result to the service.
  In this manner the user is given a contextual prompt at the time of
  access by the app. By using caching this decision can be remembered the
  next time. If caching is used, there should be a method to change the
  decision in system settings.
  
  If direct hardware access is needed for performance reasons, it is
  possible to use fd delegation in AppArmor and have the service open the
  device and pass the fd to the app without having to enumerate the /dev
  devices. Please talk to jjohansen if pursuing this option.
  
  Lastly, bug #1230391 discusses providing a visual cue during background
  recording for audio. We will need to do the same for video recording.
  Feel free to add a task to bug #1230391 if there is work to integrate
  this new service with that visual cuing.
  
  This should be implemented in time for shippable devices to address the
  application confinement concern.
+ 
+ <https://wiki.ubuntu.com/AccountPrivileges#permission-prompt>: "On the
+ phone, if an app tries to access your ... camera ... or video recording,
+ this should be subject to permission..."

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

Title:
  Please provide Ubuntu camera service that integrates with trust-store

Status in qtubuntu-camera package in Ubuntu:
  Triaged

Bug description:
  Currently Ubuntu Touch is using the android camera-service and that is
  the plan for 13.10.

  Going forward in 14.04, the android camera-service will no longer be
  used and camera access is going to move to the Ubuntu side. There was
  discussion of either using HAL directly (direct access to devices) or
  using a camera-service type thing in Ubuntu.

  Using devices directly causes at least a few problems:
   * can't prevent more than one user from accessing the device at a time
   * enumerating camera devices for apparmor policy is extra maintenance for porters
   * can't provide a contextual runtime prompt for access (like we (will) do with online accounts, location, microphone). This is particularly important for application confinement.

  Instead of direct hardware access, an out of process helper (in
  relation to the app) can be used to address all of these problems,
  similar to what pulseaudio does for audio. This service can ensure
  only one user can access the device at a time and since the service
  accesses the the device files on the app's behalf, we don't need to
  enumerate devices in /dev in policy. Furthermore, when an app accesses
  the service (ideally over DBus), the service can contact trust-store,
  the trust-store will prompt the user ("Foo wants to access the camera.
  Is this ok? Yes|No"), then optionally cache the result and return the
  result to the service. In this manner the user is given a contextual
  prompt at the time of access by the app. By using caching this
  decision can be remembered the next time. If caching is used, there
  should be a method to change the decision in system settings.

  If direct hardware access is needed for performance reasons, it is
  possible to use fd delegation in AppArmor and have the service open
  the device and pass the fd to the app without having to enumerate the
  /dev devices. Please talk to jjohansen if pursuing this option.

  Lastly, bug #1230391 discusses providing a visual cue during
  background recording for audio. We will need to do the same for video
  recording. Feel free to add a task to bug #1230391 if there is work to
  integrate this new service with that visual cuing.

  This should be implemented in time for shippable devices to address
  the application confinement concern.

  <https://wiki.ubuntu.com/AccountPrivileges#permission-prompt>: "On the
  phone, if an app tries to access your ... camera ... or video
  recording, this should be subject to permission..."

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtubuntu-camera/+bug/1230366/+subscriptions