To which extent do we have control over network requests and cookies of WebViews and Progressive Web Apps?

[SebastianZimmeck]

We are following the approach of having different opt out mechanisms for different types of apps.

1. Non-browser apps

For non-browser apps (at least to the extent they are not using cookies), opting out via the AdID should be sufficient. Thus, simply surfacing the OS setting in our app to the user may be sufficient as well.

2. Browser apps (and WebViews)

For browser apps (and WebViews), to which extent can we access cookies and modify web requests? Is our problem easier now since we do not have to intercept all web traffic but only that of a browser?

If it does not get easier, are there browser-level controls that would prevent tracking? So, for example, a simple solution could be that our app simply surfaces a browser-level settings page for turning of third party cookies.

[kasnder]

Q: Can WebViews share information across apps?

[kasnder]

There are actually three types: https://developer.android.com/develop/ui/views/layout/webapps

We've been missing "Custom Tabs".

[SebastianZimmeck]

As we just discussed, from the developer agreement it seems that developers would not be allowed to use cookies if a user opted out from tracking (i.e., having their AdID used). Technically, though, there may still be various web technologies that a developer could leverage to perform cross-app tracking without an AdID.

@wesley-tan and @n-aggarwal, please look into the following and determine to which extent that is possible (according to documentation, building such app, etc.).

• WebViews per @kasnder reference above
• Progressive web apps, which are essentially websites appearing as apps (i.e., apps using web technologies, such as JavaScript, that look like native Java/Kotlin apps

This should not not too extensive, but just to get a handle on which tracking is possible on WebViews and PWAs beyond using the AdID.

[wesley-tan]

I believe that a PWA works pretty much like any website, in that to collect cookies in a PWA, you can use JavaScript's document.cookie property, as mentioned in a previous response. However, the cookies you can collect are limited to those created by the web application's domain itself. You cannot access cookies created by other domains or websites. I actually tried making my own Webview on Android Studio (for PWAs, they work quite similarly to websites.

• PWAs can access cookies created by their own domain using JavaScript's document.cookie property. However, they cannot access cookies created by other domains or websites. In this context, PWAs have the same access to cookies as any other web application running in a web browser.
• As such, the AdID (also known as Advertising ID or AAID) is a unique identifier used for advertising purposes on Android devices. AdID is not directly accessible through a PWA running in a web browser context, as it requires native Android code and the Google Play Services Ads SDK.I read somewhere about a possible way to "bridge" the PWA to the Android-native features, through something like this:

`public class AdIdInterface { Context mContext;

AdIdInterface(Context c) {
    mContext = c;
}

@JavascriptInterface
public String getAdId() {
    // Fetch the AdID and return it
}

}

WebView webView = findViewById(R.id.webView); webView.addJavascriptInterface(new AdIdInterface(this), "AndroidAdId"); ` but I don't think its effective.

So, as far as I know PWA has access to cookies (similar to websites), at least until further development (e.g. Chrome getting rid of cookies in 2024)

[wesley-tan]

For WebView, as previously covered, it can access both cookies and AdID. For AdID, as the WebView is typically connected to an app, it can gain access to the AdID through the getAdId() function.

For cookies, WebView can access cookies just like a regular web browser. They can access cookies created by their own domain, but not cookies created by other domains or websites. You can read, create, and modify cookies using JavaScript's document.cookie property within the web content loaded in the WebView. For AdID, WebView, by default, does not have direct access to native features like AdID. However, you can access the AdID in the native portion of your app and expose it to the WebView using a JavaScript interface.

function getAdId() { if (window.AndroidAdId && typeof window.AndroidAdId.getAdId === 'function') { const adId = window.AndroidAdId.getAdId(); console.log('AdID:', adId); // Use the AdID for your purposes } }

Interestingly, by default, Safe Browsing is disabled for Webview. To enable it, you can add the below-mentioned metadata in the application tag of Android Manifest: I don't know how important this is to enable or inform users about but this is a pretty interesting point.

<meta-data android:name="android.webkit.WebView.EnableSafeBrowsing" android:value="true" />

Additionally, data from browsing via the Webview can be stored in the local cache. Devs can access the local cache programmatically in your app by using the WebView.getCacheDir() method to get the path to the cache directory, and then using standard file I/O operations to read or modify the files in the cache. For example, you can use the following code to get the path to the cache directory:

[wesley-tan]

I believe Custom Tabs don't work differently vs surfing the browser itself. Think on the whole, Chrome Custom Tabs runs with Chrome multi-process architecture (https://www.chromium.org/developers/design-documents/multi-process-architecture). Chrome processes are separate from the app processes. Hence, there is much stronger protection from 3rd party content with Chrome Custom Tabs than with WebView, app security is improved. Also, yes, WebViews can "communicate" with other apps given that it can use intents. While WebView cannot use intents directly, you can combine WebView with intents in your Android application to achieve the desired functionality. For example, if you want to open a link within your WebView in an external browser or another app, you can intercept the URL loading request, create an intent, and use it to launch the appropriate app. webView.setWebViewClient(new WebViewClient() { @Override public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) { String url = request.getUrl().toString(); if (url.startsWith("myapp://")) { Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url)); startActivity(intent); return true; } else { return super.shouldOverrideUrlLoading(view, request); } } });

I will continue playing around with WebViews and inform about the result.

[wesley-tan]

Temporarily halt conversation on webview, but keep it at the back of our minds.