When it comes to marketing, we've recently seen both Apple and Google work to create a more privacy-conscious ecosystem. It began with Apple's introduction of a button to disable applications from monitoring you, and it has continued with Google's Android Privacy Sandbox programme. While information was scant at the launch, further details about the "SDK Runtime," which is part of Google's answer to advertising and privacy, have surfaced.
The Android Privacy Sandbox is made up of two key components: the SDK Runtime and Privacy-Preserving APIs, which will be provided as Modular System Components, also known as Project Mainline. Google has recently released developer documentation for the SDK Runtime and how it would improve user privacy. According to the firm, the SDK Runtime will allow third-party SDKs to operate in a dedicated runtime environment separate from an app's code in Android 13.
Each programme on Android operates in its own sandbox, with its own permissions and changing access to the system based on the level of access allowed. According to Google, "if programme A attempts to do something dangerous, such as read application B's data or dial the phone without authorization, it is stopped from doing so because it lacks the required default user rights." The SDK Runtime extends that sandbox by allowing third-party SDKs to be executed in a separate runtime environment, separate from any specific app.
Why the SDK Runtime exists
Google intends to prevent advertising SDKs from gathering data that they shouldn't have access to maliciously (or even mistakenly) by sharing the host app's sandbox. When an advertisement SDK is performed within an app, it has access to everything that the programme does, and an app developer may be unaware of how much access they have. By separating the advertising code and running it in its own runtime, it can only access the data that the developer has expressly shared with it.
As a result, Google claims that the SDK Runtime offers the following enhanced precautions and assurances in terms of user data collection and sharing:
- A new execution environment
- SDK permissions and data access rights must be clearly established.
The first version of the SDK Runtime focuses solely on advertising-related SDKs, such as SDKs for ad serving, ad measurement, ad fraud detection, and abuse detection.
How the SDK Runtime works
Currently, in the absence of the SDK runtime, an app process will call an SDK, and that SDK will execute within the same sandbox as the rest of the app's code. Google prefers that developers provide an interface for an SDK that operates in the foreground process of an app, and that interface may then connect to and communicate particular data back and forth with the SDK that's being used.
BEFORE
AFTER
The "before" diagram (first) demonstrates that the SDK-calling code, as well as the SDKs that receive calls from this code, are all located within the app's process. This implies that the SDK has access to the same data that the app does. The "after" figure (second) depicts how the SDK calling code talks with SDK interfaces during the app's foreground activity. These interfaces then cross a process boundary into the SDK Runtime process to invoke the SDKs. This implies that the SDK can't just access whatever it wants; it can only get information from the app that it's running alongside.
New trusted distribution model for SDKs
Currently, when you download an app that includes third-party SDKs, the developer includes them in the app that is submitted and distributed on the Google Play Store. Google prefers that when you install an app on your phone that needs certain SDKs, they are downloaded separately from the app. That implies SDK developers might make non-breaking modifications to their SDKs (no changes to APIs or their semantics) and distribute them to devices without involving app developers.
As a result, non-breaking SDK modifications may be delivered or rolled back without having to wait for app developers to rebuild their apps with the new SDKs or for end users to update their apps. Breaking changes that change APIs and their semantics would still require app developers to update their apps, but SDK developers could get their latest non-breaking changes and fixes out to more people at once, more quickly and uniformly, without relying on an app dev
eloper to update their app and package in the new SDK.
eloper to update their app and package in the new SDK.
BEFORE
AFTER
The "before" graphic depicts how apps are currently deployed with SDKs. They are combined into an app, which is then uploaded to the Google Play Store. SDK developers would no longer embed SDKs directly inside apps in the "after" diagram; instead, SDK developers would upload an SDK and publish it to the Google Play Store. The Google Play Store would then manage the delivery of programmes to end-user devices, as well as any SDK requirements. Google also used the word "app store" on purpose in its graphics, as it is an open and universal solution that can operate across various shops.
Changes to how SDKs and apps are built, run, and distributed
The original SDK Runtime proposal calls for a number of modifications in five major areas:
- Access
- Execution
- Communications
- Development
- Distribution
Google would like to establish the following permissions for the SDK Runtime:
- INTERNET: The ability to connect to the internet in order to communicate with an online service.
- ACCESS NETWORK STATE: Get network information.
- Permissions to use privacy-preserving APIs that give essential advertising features without requiring access to cross-app identifiers. The titles of the permissions have not been decided, but access to these APIs would be limited by the app's access to these rights.
- AD ID: The ability to obtain the advertising ID. The app's access to this permission would likewise be a barrier.
- BIND GET INSTALL REFERRER SERVICE: The ability to attribute the source of an app's installation via the Google Play Install Referrer API.
In terms of how SDKs will operate, they will have a somewhat lower priority than the app itself. That is, if a circumstance developed in which an app required to be shutdown by the system, it is quite probable that it would be ended immediately after an SDK Runtime was stopped. If it is not terminated at the same time, or for another reason, the proposal provides app developers with associated lifecycle callback methods to handle this error and re-initialize the SDK Runtime. At any moment, runtime SDKs will be unable to use the notifications APIs to provide user notifications.
Finally, Google emphasises that this is a broad concept that is not specific to any one app store. While it's likely to be integrated into the Google Play Store, there's no reason why other app shops couldn't follow suit. According to Google, the following advantages are obvious:
- Ensure the SDKs' quality and uniformity.
- Streamline SDK developer publication.
- Accelerate the distribution of SDK minor version upgrades to installed applications. Android Privacy Sandbox looks promising
Android Privacy Sandbox looks promising
According to Google, the initial design suggestions, design comments, and revisions will take place in Q1 of 2022. Developer previews will be released later this year, followed by a beta towards the end of the year. Finally, scaled testing will begin in 2023. These previews and betas will not be affected by the Android 13 release schedule. When the settings app is released, it will also have user-facing controls.
The Android Privacy Sandbox is promising in my perspective, but we'll have to wait and see how the business executes it. It's very conceivable that developers may dislike it, or that it will create more difficulties than it solves. Developers are urged to study the documentation provided by Google in order to have a better understanding of what is to come in the future of Android privacy.
This is presently only a suggestion, not a guarantee of what will happen in a future Android version, although it's likely to come close. We'll keep an eye out for any further developments!
