Open-In data loss prevention policy details

• Open In behavior in wrapped apps versus SDK apps
• iOS native email use and the Open In DLP policy
• AirDrop use and the Open In DLP policy
• App extension use and the Open In DLP policy
• Whitelisting services integrated into iOS in the Open In DLP policy
• Overriding the Open In policy for an app

Related topics 

• Configuring the AppConnect global policy
• Configuring AppConnect container policies

Open In behavior in wrapped apps versus SDK apps

You select an app’s Open In data loss prevention policy:

• MobileIron Core: on the AppConnect global policy or the AppConnect container policy.

When Open In is allowed, an AppConnect app’s Open In behavior is the same as the behavior of a regular, non-AppConnect app. However, if Open In is not allowed to some or all apps, the AppConnect app’s behavior depends on the following:

• whether the AppConnect app requesting Open In is a wrapped app or an SDK app
• the iOS version on which a wrapped app is running
• the AppConnect for iOS SDK version of an SDK app

Table 31.   Open In behavior in wrapped apps versus SDK apps

	Open In Not allowed	Open In is allowed only to AppConnect apps or Open In only to apps on whitelist
Wrapped apps
Wrapped apps running on iOS versions prior to iOS 11	Open In policy enforced by: AppConnect wrapper in the app. What if the app initiates Open In? No target apps are displayed.	Open In policy enforced by: AppConnect wrapper in the app. What if the app initiates Open In? Only AppConnect apps or apps in the whitelist are displayed as possible target apps.
Wrapped apps running iOS 11 and supported newer versions	Open In policy enforced by: AppConnect wrapper in the app. What if the app initiates Open In? iOS displays all apps that support the document type as possible target apps. Because of the AppConnect library’s enforcement, if the user taps on any of the apps, nothing happens.	Open In policy enforced by: AppConnect wrapper in the app. What if the app initiates Open In? iOS displays all apps that support the document type as possible target apps. Because of the AppConnect library’s enforcement, if the user taps on an app that is not allowed, nothing happens
SDK apps
Apps built with AppConnect 3.0 for iOS and earlier	Open In policy enforced by: The app. App behavior can vary depending on the app’s implementation.	Open In policy enforced by: The app. App behavior can vary depending on the app’s implementation.
Apps built with AppConnect 3.1 through 3.1.3 for iOS	Open In policy enforced by: The AppConnect library, contained in the AppConnect app. App is responsible for: Disabling user interfaces, such a menu items, that provide the Open In capability. What if the app initiates Open In anyway? iOS displays all apps that support the document type as possible target apps. Because of the AppConnect library’s enforcement, if the user taps on any of the apps, that target app cannot open the file. Target app error handling varies. For example, some apps display an error pop-up.	Open In policy enforced by: The AppConnect library, contained in the AppConnect app. App is responsible for: Enabling user interfaces, such as menu items, that provide the Open In capability. What happens when the app initiates Open In? iOS displays all apps that support the document type, including the apps that are not allowed by the Open In policy. Because of the AppConnect library’s enforcement, if the user taps on an app that is not allowed, that target app cannot open the file. Target app error handling varies. For example, some apps display an error pop-up.
Apps built with AppConnect 3.5 for iOS and supported newer versions	Open In policy enforced by: The AppConnect library, contained in the AppConnect app. App is responsible for: Disabling user interfaces, such a menu items, that provide the Open In capability. What if the app initiates Open In anyway? iOS displays all apps that support the document type as possible target apps. Because of the AppConnect library’s enforcement, if the user taps on any of the apps, that target app cannot open the file. In this case: •Target app error handling varies. For example, some target apps display an error pop-up. •Error handling also varies for the SDK app that initiated the Open In. Some apps display an error message.	Open In policy enforced by: The AppConnect library, contained in the AppConnect app. App is responsible for: Enabling user interfaces, such as menu items, that provide the Open In capability. What happens when the app initiates Open In? iOS displays all apps that support the document type, including the apps that are not allowed by the Open In policy. Because of the AppConnect library’s enforcement, if the user taps on an app that is not allowed, that target app cannot open the file. In this case: •Target app error handling varies. For example, some target apps display an error pop-up. •Error handling also varies for the SDK app that initiated the Open In. Some apps display an error message. Special case for iOS native email app: For apps using AppConnect 4.0 for iOS and supported newer versions, if the user taps to launch the native email app, but it is not in the whitelist, Email+ for iOS is launched if it is installed on the device.

iOS native email use and the Open In DLP policy

Apps have various ways to launch the iOS native email app, including:

• using the iOS Open In menu in which the native email app is an option
• specifically launching the iOS native email app
• displaying a standard native email interface inside the app
• requesting to launch any app that handles email

The first way, using the iOS Open In menu, is part of the handling described in Open In behavior in wrapped apps versus SDK apps.

The other ways of invoking the iOS native email app are also impacted by the Open In Data Loss Prevention (DLP) policy. The impact depends on whether the AppConnect app uses:

• Open In and native email with an AppConnect version prior to AppConnect 4.0 for iOS
• Open In and native email with AppConnect 4.0 for iOS through most recently released version

If you want to include iOS native email in the Open In whitelist, seePutting iOS native email into the Open In Whitelist .

Open In and native email with an AppConnect version prior to AppConnect 4.0 for iOS

For apps using AppConnect versions prior to AppConnect 4.0 for iOS, the Open In DLP policy does not impact launching the iOS native email app from an AppConnect app. That is, launching the iOS native email app is always allowed. However, one exception exists to this rule. Launching the native email app is not allowed when:

• the Open In policy specifies a whitelist, and
• the iOS native email app is not in the whitelist

Therefore, even when you set the Open In policy to, for example, not allowed, launching the iOS native email app is allowed when the device user taps the app to:

• specifically launch the iOS native email app
• display a standard native email interface inside the app
• launch any app that handles email

Open In and native email with AppConnect 4.0 for iOS through most recently released version

For apps using AppConnect 4.0 and supported newer versions, the Open In DLP policy impacts launching the iOS native email app from an AppConnect app. If Open In is allowed for all apps, then iOS native email can be launched. However, the behavior for the other Open In policy settings is described in the following table:

Table 32.   Open In policy and iOS native email

Device user action	Open In Not Allowed	Open In is allowed only to AppConnect apps	Open In is allowed only to whitelisted apps, and iOS native email is NOT in the whitelist	Open In is allowed only to whitelisted apps, and iOS native email is in the whitelist
Taps to specifically launch the iOS native email app	iOS native email is not launched.	iOS native email is not launched.	iOS native email is not launched.	iOS native email is launched.
Taps to display a standard native email interface inside the app	iOS native email is not launched.	iOS native email is not launched.	iOS native email is not launched.	iOS native email is launched.
Taps to launch any app that handles email	iOS native email is not launched.	iOS native email is not launched. Email+ for iOS is launched if it is installed on the device.	iOS native email is not launched. Email+ for iOS is launched if it is installed on the device.	iOS native email is launched.

For apps built or wrapped with AppConnect 4.1 and supported newer versions, you can override the behavior for the scenario when the user taps to launch any app that handles email. Specifically, if the Open In policy blocks launching the iOS native email app in this scenario, you can allow iOS native email to launch. To allow iOS native email to launch, add the key MI_AC_DISABLE_SCHEME_BLOCKING with the value true to the app’s AppConnect app configuration.

AppConnect apps can also override the Open In policy for this scenario, allowing the iOS native email app to launch. Contact the application vendor or developer to find out if the app overrides the policy.

Putting iOS native email into the Open In Whitelist

To put the native iOS mail app is in the whitelist, put both of these bundle IDs in the whitelist:

• com.apple.UIKit.activity.Mail
• com.apple.mobilemail

However, include iOS native email in a whitelist for an AppConnect app only if you understand the potential impact of leaking secure data.

AirDrop use and the Open In DLP policy

The Open In DLP policy impacts the use of AirDrop as follows:

• A wrapped AppConnect app’s use of AirDrop is behaves according to the Open In DLP policy.
• An AppConnect app built with the AppConnect 3.1 for iOS SDK through the most recently supported version behaves according to the Open In policy.
• An AppConnect app built with AppConnect 3.0 for iOS SDK or earlier is not impacted by the Open In policy. Regardless of how you set the policy, AirDrop is allowed.

App extension use and the Open In DLP policy

For apps using AppConnect 4.0 for iOS and supported newer versions, the Open in data loss protection policy includes restricting access to the iOS extensions that apps provide. Specifically:

Open In DLP for host app (the app using the extension)	Extension behavior
All apps allowed	The host app can use any app’s extension for Open In.
Only AppConnect apps allowed	The host app can use only extensions provided by AppConnect apps for Open In.
Whitelist	The host app can use only extensions of apps in the whitelist for Open In.

Whitelisting services integrated into iOS in the Open In DLP policy

When you whitelist apps for the Open In DLP setting, you provide the bundle ID of each whitelisted app in the AppConnect global policy or AppConnect container policy. Although the bundle ID of apps in the Apple App Store or your own in-house apps are readily available, the bundle IDs for services integrated into iOS are not well known.

The following list gives the bundle IDs of some common services integrated into iOS. However, include them in a whitelist for an AppConnect app only if you understand the potential impact of leaking secure data.

• com.apple.UIKit.activity.PostToFacebook
• com.apple.UIKit.activity.PostToTwitter
• com.apple.UIKit.activity.PostToWeibo
• com.apple.UIKit.activity.AssignToContact
• com.apple.UIKit.activity.AddToReadingList
• com.apple.UIKit.activity.Quicklook
• com.apple.UIKit.activity.Message

Overriding the Open In policy for an app

In the AppConnect global policy, you can specify that you want to authorize AppConnect apps that do not have an AppConnect container policy. When an app does not have an AppConnect container policy, the data loss prevention (DLP) settings in the AppConnect global policy, including the Open In setting are applied to the app.

If you do not want the app to have the same Open In setting as the AppConnect global policy, you have two choices to override the setting:

• Create an AppConnect container policy for the app and label it appropriately. In it, specify the Open In and other DLP settings that you want for the app. These DLP settings override the settings in the AppConnect global policy.
• Create or modify an AppConnect app configuration for the app, and add this key-value pair to its App-specific Configurations section:
  Key: MI_AC_DISABLE_OPEN_IN_ENFORCEMENT
  Value: YES
  This key-value pair disables Open In enforcement in the AppConnect library of an AppConnect app, which means that Open In is allowed to all apps.

In both cases, make sure you understand the potential impact of leaking secure data. This leak can happen:

• directly by an app for which you have configured one of the override choices.
• indirectly by an app that shares a document with an app for which you have configured one of the override choices.

For the indirect case, consider this scenario:

• The AppConnect global policy authorizes AppConnect apps that do not have an AppConnect container policy.
• The AppConnect global policy specifies Open In only to AppConnect apps.
• AppConnect App 1 and AppConnect App 2 do not have AppConnect container policies.
• You add the key MI_AC_DISABLE_OPEN_IN_ENFORCEMENT with the value YES to the AppConnect app configuration of App 2.

In this case, App 1 can share a document with App 2, and App 2 can share the document with non-AppConnect apps. Therefore, App 1 can indirectly share secure data with unsecured apps.