Export (0) Print
Expand All

Privacy, permissions and security for mail apps in Outlook

apps for Office

Learn how the security model for mail apps can promote transparency and a sense of privacy for end-users and administrators. Follow resource usage guidelines to help prevent denial of service and provide satisfactory app performance.

Last modified: November 06, 2014

Applies to: Exchange Online | Exchange Server 2013 | Exchange Server 2013 SP1 | Outlook 2013 | Outlook 2013 RT | Outlook 2013 SP1 | Outlook for Mac for Office 365 | Outlook Web App

   Office.js: v1.0, v1.1

   Apps for Office manifests schema: v1.0, v1.1

Note Note

In this article, "Outlook" refers to Outlook for Windows, Outlook for Mac, Outlook RT, OWA for Devices (OWA for Android phones, OWA for iPad, OWA for iPhone), and Outlook Web App. "Outlook rich clients" refers to Outlook for Windows, Outlook for Mac and Outlook RT. At this point, Outlook for Mac supports JavaScript API for Office in only Outlook read mode, and can activate mail apps that reference office.js version 1.0 or 1.1 and use apps for Office schema version 1.0.

In this article
Permissions model
Office Store: app integrity
End users: privacy and performance concerns
Developers: permission choices and resource usage limits
Administrators: privileges
In this section
Additional resources

This topic first describes the possible permissions that mail apps can request, and examines the security model from the following perspectives:

  • Office Store—app integrity.

  • End-users—privacy and performance concerns.

  • Developers—permissions choices and resource usage limits.

  • Administrators—privileges to install high-trust apps and set performance thresholds.

Because customers' perception of app security can affect app adoption, mail app security relies on a tiered permissions model. A mail app would disclose the level of permissions it needs, identifying the possible access and actions that the app can make on the customer's mailbox data.

Starting in apps for Office manifest schema version 1.1, there are four levels of permissions. Table 1 shows the four levels of permissions that developers can request for a mail app through the manifest, starting with the most fundamental permission, restricted.

Table 1. App permission levels

Permission level

Value in mail app manifest

Restricted

Restricted

Read item

ReadItem

Read/write item

ReadWriteItem

Read/write mailbox

ReadWriteMailbox

The four levels of permissions are cumulative: the read/write mailbox permission includes the permissions of read/write item, read item and restricted, read/write item includes read item and restricted, and the read item permission includes restricted. Figure 1 shows the four levels of permissions and describes the capabilities offered to the end user, developer, and administrator by each tier. End users and administrators can install low-trust mail apps that require restricted, read item, or read/write item permission. Only administrators can install high-trust mail apps that require read/write mailbox permission. For more information about these permissions, see End users: privacy and performance concerns, Developers: permission choices and resource usage limits, and Specify permissions for mail app access to the user's mailbox.

Figure 1. Relating the four-tier permission model to the end user, developer, and administrator

4-tier permissions model for mail apps schema v1.1
Note Note

The permissions model of mail apps that use apps for Office manifest schema v1.0 includes only three tiers: read/write mailbox, read item and restricted, as shown in Figure 2. If you are creating a new mail app, you should use at least schema v1.1. For more information in the features available in each version and choosing a version of the apps for Office platform for a new mail app, see Choosing a version of the platform for your mail app for Outlook.

Figure 2. The three-tier permissions model for manifest schema v1.0

3-tier permission model for user, developer, admin

The Office Store hosts low-trust and high-trust mail apps which can be installed by end users and administrators depending on the requested permissions. The Office Store enforces the following measures to maintain the integrity of these mail apps:

  • Requires the host server of an app to always use Secure Socket Layer (SSL) to communicate.

  • Requires a developer to provide proof of identity, a contractual agreement, and a compliant privacy policy to submit apps.

  • Archives apps in read-only mode.

  • Supports a user-review system for available apps to promote a self-policing community.

The security model addresses security, privacy, and performance concerns of end users in the following ways:

  • End user’s messages that are protected by Outlook’s Information Rights Management (IRM) do not interact with mail apps.

  • Before installing an app from the Office Store, end users can see the access and actions that the app can make on their data and must explicitly confirm to proceed, as shown in figure 3. No mail app is automatically pushed onto a client computer without manual validation by the user or administrator.

    Figure 3. Dialog displaying the possible access and actions that a mail app can make on the user's mailbox data

    Confirmation dialog before installing a mail app
  • Granting the restricted permission allows the mail app to have limited access on only the current item. Granting the read item permission allows the mail app to access personal identifiable information, such as sender and recipient names and email addresses, on only the current item,.

  • End users can install a low-trust mail app for only himself or herself. Mail apps that affect an organization are installed by an administrator.

  • End users can install low-trust mail apps that enable context-sensitive scenarios that are compelling to users while minimizing the users’ security risks.

  • Manifest files of installed mail apps are secured in the user’s email account.

  • Data communicated with servers hosting apps for Office is always encrypted according to the Secure Socket Layer (SSL) protocol.

  • Applicable to only the Outlook rich clients: The Outlook rich clients monitor the performance of installed mail apps, exercise governance control, and disable those mail apps that exceed limits in the following areas:

    • Response time to activate.

    • Number of failures to activate or reactivate.

    • Memory usage.

    • CPU usage.

    Governance deters denial-of-service attacks and maintains app performance at a reasonable level. The Business Bar alerts end users those mail apps that the Outlook rich client has disabled based on such governance control.

  • At any time, end users can verify the permissions requested by installed mail apps, disable or subsequently enable any low-trust or high-trust mail app in the Exchange Admin Center.

The security model provides developers granular levels of permissions to choose from, and strict performance guidelines to observe.

Tiered permissions increases transparency

Developers should follow the tiered permissions model to provide transparency and alleviate users’ concern about what apps can do to their data and mailbox, indirectly promoting app adoption:

  • Developers request an appropriate level of permission for a mail app, based on how the mail app should be activated, and its need to read or write certain properties of an item, or to create and send an item.

  • Developers request permission by using the Permissions element in the manifest of the mail app, by assigning a value of Restricted, ReadItem, ReadWriteItem or ReadWriteMailbox, as appropriate.

    Note Note

    Note that the ReadWriteItem permission is available starting in manifest schema v1.1.

    The following example requests the read item permission.

    <Permissions>ReadItem</Permissions>
    
  • Developers can request the restricted permission if the mail app activates on a specific type of Outlook items (appointment or message), or on specific extracted entities (phone number, address, URL) being present in the item’s subject or body. For example, the following rule activates the mail app if one or more of three entities - phone number, postal address, or URL - are found in the subject or body of the current message.

    <Permissions>Restricted</Permissions>
        <Rule xsi:type="RuleCollection" Mode="And">
        <Rule xsi:type="ItemIs" FormType="Read" ItemType="Message" />
        <Rule xsi:type="RuleCollection" Mode="Or">
            <Rule xsi:type="ItemHasKnownEntity" EntityType="PhoneNumber" />
            <Rule xsi:type="ItemHasKnownEntity" EntityType="Address" />
            <Rule xsi:type="ItemHasKnownEntity" EntityType="Url" />
        </Rule>
    </Rule>
    
  • Developers should request the read item permission if the mail app needs to read properties of the current item other than the default extracted entities, or write custom properties set by the app on the current item, but does not require reading or writing to other items, or creating or sending a message in the user’s mailbox. For example, a developer should request read item permission if a mail app needs to look for an entity like a meeting suggestion, task suggestion, email address, or contact name in the item’s subject or body, or uses a regular expression to activate.

  • Developers should request the read/write item permission if the mail app needs to write to properties of the composed item, such as recipient names, email addresses, body, and subject, or needs to add or remove item attachments.

  • Developers request the read/write mailbox permission only if the mail app needs to do one or more of the following actions by using the makeEWSRequestAsync method of the Mailbox object (JavaScript API for Office v1.1) object:

    • Read or write to properties of items in the mailbox.

    • Create, read, write, or send items in the mailbox.

    • Create, read, or write to folders in the mailbox.

    Only administrators can install mail apps that require this permission. For more information about permissions, see Specify permissions for mail app access to the user's mailbox.

Resource usage tuning

Developers should be aware of resource usage limits for activation, incorporate performance tuning in their development workflow, so as to reduce the chance of a poorly performing app denying service of the host. Developers should follow the guidelines in designing activation rules as described in Limits for activation and JavaScript API for mail apps in Outlook. If a mail app is intended to run on an Outlook rich client, then developers should verify that the app performs within the resource usage limits, as described in Following resource usage rules in apps for Office.

Other measures to promote user security

Developers should be aware of and plan for the following as well:

  • Developers cannot use ActiveX controls in apps because they are not supported.

  • Developers should do the following when submitting a mail app to the Office Store:

    • Produce an Extended Validation (EV) SSL certificate as a proof of identity.

    • Host the app they are submitting on a web server that supports SSL.

    • Produce a compliant privacy policy.

    • Be ready to sign a contractual agreement upon submitting the app.

The security model provides the following rights and responsibilities to administrators:

  • Can install low-trust and high-trust mail apps, including those that require read/write mailbox permission and provide richer access to mailboxes.

  • Granting the read/write mailbox permission allows a mail app to access personal identifiable information on all items in the user’s mailbox, and read or modify any item in the mailbox.

  • Can prevent end users from installing any mail app, including apps on the Office Store.

  • Can disable or enable any mail app on the Exchange Admin Center.

  • Applicable to only Outlook for Windows: Can override performance threshold settings by GPO registry settings. For more information, see Overriding resource usage settings for performance of apps for Office.

Show:
© 2014 Microsoft