Open-In data loss prevention policy details

The following provides details about the Open-In feature:

Open In behavior in wrapped apps versus SDK apps

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

  • MobileIron Cloud: on the AppConnect Device configuration.

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

By default, Open In is allowed to all apps.

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

 

Open In Not allowed

Open In is allowed to all apps or only to apps in the 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?
All apps or apps in the whitelist are displayed as possible target apps.

Wrapped apps running iOS 11 through the most recently released version as supported by MobileIron

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.5 for iOS through the most recently released version as supported by MobileIron

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 through the most recently released version as supported by MobileIron, 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:

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 for iOS through the most recently released version as supported by MobileIron, 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 2. Open In policy and iOS native email

Device user action

Open In Not Allowed

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 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 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 launched.

For apps built or wrapped with AppConnect 4.1 through the most recently released version supported by MobileIron, 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
IMPORTANT: 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 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.

App extension use and the Open In DLP policy

For apps using AppConnect 4.0 for iOS through the most recently released version as supported by MobileIron, 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.
   

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 Device configuration . 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

You specify the Open In behavior for an AppConnect app in the AppConnect Device configuration.

To override the Open In setting specified in the AppConnect Device configuration for a specific app, 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 from the app to all apps.

NOTE: Disabling Open In behavior, has the potential impact of leaking secure data.