Intent to Deprecate and Relaunch: CHIPS on WebView

Hello Blink API Owners,

We’re seeking approval to unship and relaunch CHIPS (a.k.a. partitioned cookies) in Android WebView only.

Rationale

The WebViewClient supports a method, shouldInterceptRequest, which allows developers to intercept network activity and modify HTTP headers, etc. This API does not have access to the Cookie header and relies on the Android CookieManager API in order to query what cookies are available for a particular request URL. This is because the request is intercepted before it is sent to the network service, where the Cookie header is added. However, partitioned cookies are double-keyed on the top-level site and the site of the URL using the cookies.

Currently, the CookieManager API provides no way for developers to query partitioned cookies correctly, and this will cause a mismatch between what the Java API returns and what frames in WebView will actually be in their Cookie header. In hindsight, this seems risky and prone to bugs, and not something the CHIPS team had considered while designing the API.

After discussing this with the WebView team, we believe that the option that will minimize potential app breakage is to disable CHIPS on WebView until we are able to ship support for the Cookie header to shouldInterceptRequest. We will release the changes to shouldInterceptRequest in the next target SDK version (API level 36).

We will reconsider our decision to unlaunch CHIPS in WebView if we get feedback from the community that this would cause significant disruption.

Behavior after deprecation:

Cookies set with the Partitioned attribute on WebView will have the attribute ignored, and the cookie will be treated as unpartitioned. Any existing partitioned cookies created in WebView will be deleted to avoid conflicts across different partitions and the unpartitioned cookie jar.

All other platforms besides WebView will still have the Partitioned attribute enabled.

Timeline:

We plan to turn down CHIPS on WebView in M127.

We will relaunch CHIPS along with Android W, which will include changes to the Android CookieManager API, in 2025.

Thanks,

Dylan Cutler

On Fri, Jun 28, 2024, 16:28 'Dylan Cutler' via blink-dev <[email protected]> wrote:

Hey Vlad,

Thanks for your response. I have completed the analysis and have some results to report. I also have created the Chromestatus entry as requested.

Here are some stats that give a picture of CHIPS usage on WebView

• Global percentage of requests from WebView clients that contain partitioned cookies:  33%
• Global percentage of requests from WebView that contain a single partitioned cookie: 29%

• Average percentage of requests from a single WebView app that contain partitioned cookies: 10%
• Average percentage of requests from a single WebView app that contain a single partitioned cookie: 7%

• Global percentage of CHIPS we estimate to be the receive-cookie-deprecation opt-in cookie: 54%
• Average percentage of CHIPS that each app has stored that we estimate to be the receive-cookie-deprecation opt-in cookie: 55%

• The percentage of apps using CHIPS: 73%
• The percentage of apps using the receive-cookie-deprecation opt in cookie: 66%

The majority of usage of CHIPS is for the 3PCD facilitated testing opt-in cookie, which will not be impacted by this change since this cookie merely serves to opt into browser behavior that is not available on WebView regardless.

That being said, we do see usage of CHIPS is significant on WebView, so we have to weigh our options. Is it more disruptive to delete the cookies, silently change their behavior to unpartitioned, or to do nothing until shouldInterceptRequest supports the Cookie header. I am also curious to hear your take.

Thank you for the analysis. Can you help me understand what percentage of webview apps do you expect would experience a breakage if delete the cookies? My understanding is that it's around 33% assuming that global requests are distributed evenly across apps? Although that doesn't seem to be a valid assumption to make.

It does sound like it's not going to be a small number. I'm also assuming that a single cookie case is interesting because these are the cases that can be moved to be unpartitioned with no collisions, is that right? If so the remainder of breakages seems large as well.

The type of breakage would be temporary but noticeable, like a need to sign in again. However, it can also be as bad as losing arbitrary data that would have been stored in that cookie. Is that correct?

You noted that the current behavior is a mismatch between what webview sees and what the cookie manager can access in java. Do we know how frequently cookie manager is used in these cases? I'm trying to estimate actual inconsistent behavior that this is trying to fix and if that worth the risk of breakage for all partitioned cookies

Also, what's the timeline for shipping the cookie manager fix that would be able to deal with partitioned cookies properly?

Hey Vlad,

I agree that deleting the affected cookies seems to be the least risky behavior here. Is this plan to roll out via Finch and monitor for bad breakages?

Unfortunately it is not possible to roll out network feature changes via Finch to WebView, since WebView may sometimes use the cookie store before the feature list has been fully initialized. We have implemented this change as a command line switch for the process running the network service.