In order to project user privacy and to make reproducibility guarantees feasible,
apps are by default heavily restricted in what data they can read and write.
Some apps, such as data management tools or apps that make use of external
online resources, may wish to request relaxation of these
By default, when an app is run, the following happens:
- Any input objects provided by the user to the job are cloned into the job's
- When running, the job has CONTRIBUTE (i.e. read and write) access to its
temporary workspace, and nothing else. The job cannot access the internet.
- When the job finishes, all of its outputs are cloned back into the job's
project context (the project from which the job was run).
That is, an app cannot read any objects except its input objects, it has no
other access to the "outside world", and it only has the power to create new
objects in the project context; it cannot modify or remove any existing objects in the
project context, nor can it create objects in any other project.
Apps may request the following permissions in order to relax the usual rules:
- Access to the Internet or to selected hosts on the Internet: the
Execution Environment permits the job to
connect to hosts on the internet, or to specific hosts (which may be
specified as hostnames, hostname wildcards, or network masks).
- Direct access to the project in which the app was launched: the job may directly manipulate its
project context. It may delete or modify existing objects or create objects
that are not explicitly enumerated among the job's outputs. The job may use any permission up to
whatever access level the user actually has on the project, or it may be
restricted to a lower access level (for example, only receiving CONTRIBUTE
access even if the user has ADMINISTER on the project).
- Direct access to all projects: the job may directly manipulate ANY project
that the user has access to. The job may use any permissions up to whatever
access level the user actually has on each project, or it may be restricted
to a lower access level (for example, only receiving CONTRIBUTE access to
each project even if the user has ADMINISTER on some projects).
- Developer permissions: the job may manipulate any app (e.g. creating,
updating, or publishing apps) that the user has permission to manipulate, or
create a new app on behalf of the user. (These permissions are broken out
separately because apps do not live in projects and therefore access to them
cannot be given by granting access to any project.)
Developers: for more information about how app developers can specify these permissions,
access field of the
/app/new method in the
Apps API documentation.