Application Access Control

This is a high-level overview of application sandboxing, with an emphasis on what it means for the user (and developer) experience.

Always Available

Examples of things that applications should be able to access without restriction:

• Sound (apps or system may be muted) [output]
• Notifications (it should be possible to disable notifications globally, or per app) [output]
• System search (it should be possible to disable search globally, or per app) [output]
• Region/language configuration [input]
• Time and time zone configuration [input]
• User’s name [input]
• System name [input]
• Hardware availability - Bluetooth, GPS, USB ports, printers, speakers, input devices (including keyboard model/layout), … [input]
• Network send/receive and connectivity status [input, output]
• Input sources configuration [input]
• Universal access configuration [input]

Access Control Points

These are the main points at which application access to resources will be controlled by the system (and the user). In all cases, it will be possible to review and revoke access through the Settings application.

1. Sharing [output]

Access is mediated by the sharing dialog. This is always per-access.

• Applications (apps must provide an integration point)
• Bluetooth send
• Copy (clipboard)
• Device send (probably through DLNA/UPnP)
• Wallpaper

2. Content selection [input]

Access is mediated by the content selection dialog. This is always per access.

• Files
• Documents
• Music
• Pictures
• Videos
• Third party applications?

3. Save As [output]

This is tentative and requires more thought. In principle, the Save As dialog would grant access to individual files that are outputted by the application. Whether all parts of the file system would be exposed is an open question.

4. Print

Printing could be presented as a share point. However, going through the share dialog isn't necessary in order to mediate access (since the user will always have to go through the system provided print dialog). Also, printing is traditionally not presented as sharing, so it could be confusing to move it there.

5. System authorisation

Used for granting access to services, content collections and devices. Each access request can be granted on a one-time basis, or authorisation can be granted for ongoing access. Access is mediated by dialogs that are provided by the system shell.

• Location (geoclue) [input] *
• Camera video [input] *
• Camera stills [input] *
• Microphone [input] *
• Modems (send/receive SMS, send/receive calls) [output]
• Content:
  • Documents [input, output]
  • Music [input, output]
  • Pictures [input, output]
  • Videos [input, output]
  • Contacts [input, output]
  • Calendar [input, output]

Other things we might want to control access to with this:

• Ability to run in the background
• Ability to run on startup
• Ability to access the network in the background

* System status area indicates when in use.

To Be Decided

Areas of functionality where the need for application access control isn't clear:

• Online accounts (will probably only be accessible by core applications - ie. not 3rd party apps)
• Input devices not handled by the compositor (joysticks, accelerometer, etc.)
• Access to remote or removable filesystems usually available via gvfs
• Access to optical media (raw device access, from DVD playback, to DVD/Blu-ray blanking and burning)

Key Design Elements

Key UX elements for sandboxed applications:

1. Sharing - the mechanism for applications to output content and data, either to other applications, system services, or online accounts. Major tasks here include the creation of the sharing framework itself, the reorganisation of system functionality that will become share points, and adding the ability for online accounts to send data.

2. Content selection - a system dialog that allows users to open content with their applications. A library for previewing content is a prerequisite for this.

3. Content and device access - system dialogs for authorising application access, along with status indicators to give feedback on when services, content and devices are being used.

4. Updated Privacy Settings.

5. Updated Sharing Settings.

6. Per-application search - currently, the core content applications share search configuration settings. In a sandboxed world, apps will have to have separate settings and separate collections of content that they manage.

Comments

• Might be good to support sandbox templates. See: http://lists.opensuse.org/opensuse-bugs/2007-09/msg02994.html

  • And: https://bugs.launchpad.net/ubuntu/+bug/156693 With this sort of system applications can also propose a custom sandbox they want to run in. If the app, sandbox etc are signed by trusted parties there may not have to be a prompt at all (depends on the PC config).

  • This isn't related to the Design of sandboxes, but to the implementation