Opting out: looking at SDKs and smart devices

Collection of individual's data for processing, analytics, advertising, and other purposes has become the norm today. There are numerous ways in which data is tracked and collected. Data collection via the cookies placed on websites is one of the most well-known methods of collection. However, data collection doesn't end with cookies on websites. Data is also collected via SDKs, which are implemented on mobile phones and smart devices like Amazon's Alexa and Roku.

SDKs: understanding how they work and the need for opt-out

Software Development Kits (SDKs) are platform-specific building tools usually provided in one installable package. These packages are provided by software companies, and app developers of other companies use them to integrate their apps with the SDK provider's services. These companies then embed the code provided by the SDK provider in their own app environment. SDKs generally include Compilers, debuggers, documentation, editors, drivers, code samples, network protocols, etc.

SDKs are generally needed when developing mobile and desktop applications. Utilizing SDKs enables the integration of important features like payment, location, analytics, User Login/Authentication, etc.

The use of SDKs can sometimes raise privacy concerns as they collect data from the environment in which they are placed; the data collected is then transmitted to the SDK provider. Sometimes, the collection of this data is transparent, while at times, it is not. This poses an issue as many users are unaware of SDKs or that their data is collected and accessible by third parties (SDK providers). Further, companies may not be able to track or control what kind of data is being collected by the SDK and subsequently transmitted back, which could also lead to excessive data being collected without any controls in place.

The existence of SDKs provides different complexities to cookies (as we described in How to effectively opt-out: practical solutions):

• Many users remain unaware of the existence of SDKs and the fact that their data is being collected and sent to third parties (SDK providers). This especially was the case until the Duck Duck Go App Tracker and the Apple App Tracker. Today, however, there is growing visibility surrounding the data that is collected by apps and sent to third-party providers.

• Tag management tools that trigger tags based on consent cannot be used as SDKs get deployed automatically.

Even though SDKs bring their own hurdles when it comes to respecting the privacy of users, certain steps can be taken by companies when using SDKs.

Big software players like Apple and Google now require developers to clearly disclose what kind of data is being collected by the SDKs integrated within the apps. They themselves provide users with the ability to provide their consent for the collection of their data. This consent needs to be honored by the app as well as the third-party SDK provider embedded within the application. Sometimes, third-party apps or SDK providers allow the app developer to pass a flag when consent is revoked by the end user. For example, Facebook has an LDU flag that can be turned on when a user is from certain states or when a user has revoked consent.

Similarly, analytics SDK providers, like Adobe Analytics and Mixpanel, provide the ability to allow users to stop the tracking of their data. When initializing the SDKs, the preference of the users needs to be collected, stored, and then transmitted back to the SDK provider as specified in their documentation. For example, Mixpanel allows for the user's opt-out preference to be stored as a browser cookie or local Storage. There is also a provision by which the SDKs can be configured to opt users out of tracking by default. Mobile App developers need to understand the privacy requirements and the options available to them to meet the privacy requirements. The responsibility falls on developers to ensure that any SDKs to be integrated are privacy compliant and to thoroughly study the documentation provided, as the specifications for maintaining compliance are generally included here.

Best practices while developing apps require that the environment is transparent and discloses to users what data is being collected (by the app itself and by any SDKs embedded within the app) so that they can then opt out should they choose to do so. Further, the preferences of the users should be stored so that they need not keep setting their preferences; instead, those preferences can be disclosed to the users whenever needed and remain applicable for a predetermined period of time.

Maintaining a privacy-compliant app environment is vital. Periodic auditing of SDKs is a best practice to keep track of SDKs as they might change their policies or update their policies on privacy and data collection, especially while upgrading.

Companies can build SDK Governance into their privacy program. This includes mapping, monitoring, and mitigation of risks related to SDKs. All SDKs should be tracked in your Data Map, and risks associated with each SDK should be evaluated based on the kind of data it collects, the frequency with which data is transmitted, any security measures in place, and so forth. It is important to keep track of the data present in the app environment that the SDKs can access. As discussed, many SDK providers offer platforms where certain configurations can be made to the SDKs and can, in some cases, restrict the transfer of data; these configurations should be made wherever applicable. However, in many cases, the code and configurations offered by the SDK do not limit the amount of data being transmitted as much as they might send a signal to the SDK provider to restrict the use of the data being sent. SDKs that are no longer in use should be promptly removed.

Further, it is the responsibility of companies to have controls and security measures in the app environments. Contracts with SDK providers should be reviewed thoroughly before implementing the SDKs.

With smart devices like Alexa, Ring, Roku, Firestick TV, etc., the privacy policies should clearly disclose the kind of data that gets collected, the purpose for collection, and most importantly, how users can submit requests to stop collection if applicable and for data deletion. Since consent banners and universal opt-out signals are not applicable to smart devices, clear, accurate privacy notices and efficient DSA request mechanisms are vital.

The matter increases in complexity when data collected is shared or sold to third parties. As with all opt-out mechanisms, no request is complete until the third parties involved also comply with the request. If the user sends in a Delete request via the DSAR portal, the third parties or service providers with whom their data has been shared will have to comply with the request and delete their data. Honoring the user's request does not end once the initial preference information is communicated; ensuring that third parties remain updated is a requirement.

Complex Ad tech environments, complex app environments, and the ever-evolving legal landscape make the designing and implementing of privacy programs and opt-out mechanisms difficult. However, in each case, there are always steps that we can take to bring our business processes closer to compliance. While it may not be possible today to completely stop the collection of data or the involvement of third parties, there are practices we can implement that respect the privacy of users and fall in line with compliance requirements.