mParticle / mparticle-apple-sdk

mParticle Apple SDK
Apache License 2.0
46 stars 66 forks source link

Add the option to fully disable collecting the Advertising ID #112

Closed tiwoc closed 4 years ago

tiwoc commented 4 years ago

This is a long one, so lets start with a summary:

Summary

Apple only allows to use the Advertising ID (IDFA) for ad targeting and attribution. We don't have a use for the identifier and don't want to jump through the hoops that Apple recently put up (see below). We therefore can't use the AdSupport framework, but there's no way to disable it when using the mParticle SDK without forking the SDK and removing the related code. We propose to add a couple of #if defineds to make sure the code accessing the IDFA doesn't make it into our app.

Background

When submitting an iOS app to Apple's app review team to get it into the app store, developers have to explain their use of the Identifier for Advertising (IDFA). The prompt in App Store Connect looks like this if you state that you collect the ID:

Full questionnaire when selecting Yes in App Store Connect (click to expand)

(See also section 3.3.12 of the current version of the Apple Developer Program License Agreement, need to be signed in with a developer Apple ID to access this file.)

Since we don't use the IDFA at all, and since mParticle also collects the Identifier for Vendor (IDFV) which is more reliable for generating user IDs within a single app (users can't reset or disable it), we'd like to disable the code in the mParticle SDK that collects the IDFA so that we can answer No the the question about the IDFA.

Current status

We're using both the mParticle SDK and the Braze/AppBoy integration with mParticle. Both use the IDFA.

mParticle SDK

There's a preprocessor flag for disabling the import of the AdSupport framework here: https://github.com/mParticle/mparticle-apple-sdk/blob/c3ed1ac6eab6305e9c1f4d968f5be36ebe99741d/mParticle-Apple-SDK/Utils/MPDevice.m#L18-L20 This doesn't have any effect, though, because the actual client code doesn't reference the imported symbols at all but uses the Objective-C runtime to dynamically call into AdSupport: https://github.com/mParticle/mparticle-apple-sdk/blob/c3ed1ac6eab6305e9c1f4d968f5be36ebe99741d/mParticle-Apple-SDK/Utils/MPDevice.m#L120-L149

This code is called for every Identify request and seems to be sent to mParticle servers.

Suggested change to the mParticle SDK

We'd like to have the body of -[MPDevice advertiserId] surrounded with something like

#if defined(MP_NO_IDFA)
    return nil;
#else
    ... (original body)
#endif

We can then use the post_install step in our Podfile to add MP_NO_IDFA to the set of compiler definitions for compiling pods.

At least the CocoaPods install will still link to AdSupport, but linking to but not using the framework should be fine (from personal experience), so I guess we don't need a change here. https://github.com/mParticle/mparticle-apple-sdk/blob/c3ed1ac6eab6305e9c1f4d968f5be36ebe99741d/mParticle-Apple-SDK.podspec#L52

Braze/AppBoy integration with mParticle

In the mparticle-apple-integration-appboy repo, there are two methods that access the IDFA in a similar way to the main SDK: MPKitAppboy.m#L186-L229 (sorry, inline diffs across repos or orgs don't seem to work in GitHub).

At first look, it seems like setting collectIDFA to false would disable IDFA collection, but that isn't the case: The Braze/AppBoy SDK doesn't check isAdvertisingTrackingEnabled before accessing advertisingIdentifierString, where collectIDFA isn't checked. Also, this would still leave the "forbidden" code in the app.

Suggested change to the Braze/AppBoy integration with mParticle

Similar to the change to the base SDK, we'd like to guard the bodies of these two methods with #if defined(MP_NO_IDFA) and return false / nil if MP_NO_IDFA is defined.

peterjenkins commented 4 years ago

@tiwoc Thanks for the detailed report! We will take a look.

samdozor commented 4 years ago

hey @tiwoc ! We've just released SDK 8.0.0-beta1 which fully removes IDFA collection, in favor of an opt-in approach whereby you pass the IDFA to the SDK (if desired). Please see the migration guide here for details.

tiwoc commented 4 years ago

Looks great, thank you!