Hey Vlad,

Thanks for your response. I have completed the analysis and have some
results to report. I also have created the Chromestatus
<https://chromestatus.com/feature/5279664766713856> 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
   
<https://developers.google.com/privacy-sandbox/relevance/setup/web/chrome-facilitated-testing>
   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.

Best,
Dylan
On Wed, Jun 5, 2024 at 11:55 AM Vladimir Levin <vmp...@chromium.org> wrote:

> Hey,
>
> The first item looks like a good starting point. We can discuss possible
> solutions when we know how much usage there is.
>
> For visibility, can you please file a chromestatus entry for this intent?
>
> Thanks,
> Vlad
>
> On Wed, Jun 5, 2024 at 10:36 AM 'Dylan Cutler' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hey Vlad,
>>
>> Thanks for your response and interest in the intent. I can see two paths
>> going forward.
>>
>>
>>    1. We query UMA to determine just what percentage of WebView apps
>>    embed content using CHIPS (and in how many partitions). We can also use
>>    these metrics to identify the top apps who embed users of CHIPS and make
>>    sure this change would not lead to disruptions. If that proves to be 
>> enough
>>    so that you are no longer concerned about breakage then we could move
>>    forward. Otherwise, we move on to approach (2).
>>    2. We refactor our code so that if CHIPS is disabled in WebView,
>>    rather than deleting partitioned cookies we could convert them to
>>    unpartitioned. If the user has an unpartitioned cookie with the same
>>    name/domain/path, then we would delete the partitioned cookie in favor of
>>    the unpartitioned one. If multiple cookies exist in different partitions
>>    and no such unpartitioned cookie exists, we would fall back on the most
>>    recently used cookie. It is worth noting, this technique is complex and
>>    could have its own risks, so we'd like to leave it as a last resort.
>>
>> Let me know what you think, and if this sounds acceptable, I can get that
>> data from UMA to start to inform if we want to pursue the algorithm in (2).
>>
>> Thanks,
>> Dylan
>>
>> On Fri, May 31, 2024 at 5:11 AM Vladimir Levin <vmp...@chromium.org>
>> wrote:
>>
>>> On Wed, May 29, 2024 at 5:02 PM 'Dylan Cutler' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> 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
>>>> <https://developer.android.com/reference/android/webkit/WebViewClient#shouldInterceptRequest(android.webkit.WebView,%20android.webkit.WebResourceRequest)>,
>>>> 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
>>>> <https://developer.android.com/reference/android/webkit/CookieManager>
>>>> 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
>>>> <https://source.chromium.org/chromium/chromium/src/+/main:android_webview/browser/aw_contents_io_thread_client.cc;l=316;drc=59ac8227c5dd59754331b3f7f9f85e1a947f1242>,
>>>> 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.
>>>>
>>>
>>> This sounds like a pretty noticeable breakage. Are there any estimates
>>> on how many apps/users/developers would be impacted by this change?
>>>
>>> Also, as a point of process, I think this may require an intent to
>>> deprecate and remove in the chromestatus, although because this is only for
>>> WebView, I'm not entirely sure if there's a precedent.
>>>
>>> Thanks!
>>> Vlad
>>>
>>>
>>>>
>>>> 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
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "blink-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to blink-dev+unsubscr...@chromium.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQOPkYjRxrs68q%2BHxebt-JWCopZ6Rq9r0O80dQF8PWwRg%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQOPkYjRxrs68q%2BHxebt-JWCopZ6Rq9r0O80dQF8PWwRg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQ0N4hu_TF%2BBVC4MgRJgYoqmodqP%3Dg7L1dmE_GYqb1v3w%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQ0N4hu_TF%2BBVC4MgRJgYoqmodqP%3Dg7L1dmE_GYqb1v3w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQObcMXRVrxrq%3DhHSWV8L9uxDpWhrSJ3xQDNb53RH6DVA%40mail.gmail.com.

Reply via email to