On Wed, Jul 17, 2024 at 3:13 PM 'Dylan Cutler' via blink-dev < blink-dev@chromium.org> wrote:
> 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. > That makes sense. It does increase the risk of this removal, but I can't think of any other approach. As someone pointed out: "having no cookies is better than having corrupted cookies", and apps/sites should be able to deal gracefully with cookies being deleted. LGTM1 > Also, could you start the various reviews on the chromestatus entry? > > Done! > > Dylan > > On Wed, Jul 17, 2024 at 2:03 PM Vladimir Levin <vmp...@chromium.org> > wrote: > >> Thank you for all of the context. >> >> 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? >> >> Also, could you start the various reviews on the chromestatus entry? >> [image: chipsna.png] >> >> Thanks, >> Vlad >> >> On Thu, Jul 11, 2024 at 1:17 PM Torne (Richard Coles) <to...@chromium.org> >> wrote: >> >>> >>> >>> On Tue, 9 Jul 2024 at 10:20, Vladimir Levin <vmp...@chromium.org> wrote: >>> >>>> >>>> >>>> On Fri, Jun 28, 2024, 16:28 'Dylan Cutler' via blink-dev < >>>> blink-dev@chromium.org> wrote: >>>> >>>>> 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. >>>>> >>>> >>>> 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. >>>> >>> >>> Right, it won't be distributed evenly because apps load different sites, >>> and whether partitioned cookies are used is primarily down to the site. >>> It's not entirely straightforward to figure out how this is distributed >>> across apps. >>> >>> >>>> 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? >>>> >>> >>> Yes, though for many apps the breakage would be nothing - lots of apps >>> use WebView in a way where there is *no* meaningful data stored via web >>> mechanisms. >>> >>> >>>> 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 >>>> >>> >>> This is not the only issue; there's a bigger problem with apps that >>> intercept network requests from WebView - because the interception happens >>> extremely early in the request lifecycle, the request information that gets >>> passed to the app does not include any cookie headers at all (regardless of >>> partitioning), and if the app does choose to intercept the request and >>> return a response, any Set-Cookie headers in the response are *also* not >>> processed. This means that when apps are doing this kind of interception >>> they need to use the CookieManager APIs to get the cookies for the request >>> and attach them themselves, and likewise need to set cookies manually using >>> CookieManager for responses. >>> >>> It's impossible for apps to do this correctly for partitioned cookies, >>> and extending the CookieManager APIs to allow getting/setting partitioned >>> cookies is not sufficient to fix it: the request interception API doesn't >>> provide any 1P/3P context information and so the app has no way to know >>> which partition key to pass to the API to get/set the cookies correctly. >>> This also means that any future changes to cookie behavior are likely to >>> cause similar problems. >>> >>> bewise@ is working on changes to the request interception behavior to >>> handle the cookie headers automatically to fix this (e.g. >>> https://chromium-review.googlesource.com/c/chromium/src/+/5616051) but >>> this is significantly more difficult than just extending the CookieManager >>> API, as this requires changing the behavior of existing APIs in a >>> backward-incompatible way. >>> >>> >>>> Also, what's the timeline for shipping the cookie manager fix that >>>> would be able to deal with partitioned cookies properly? >>>> >>> >>> I'm not sure what the current plan to ship the changes here is, but it >>> may take some time due to the changes being more involved and a bigger >>> compat risk than initially thought. >>> >>> >>>> >>>> Thanks, >>>> Vlad >>>> >>>>> >>>>> 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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQObcMXRVrxrq%3DhHSWV8L9uxDpWhrSJ3xQDNb53RH6DVA%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/CADsXd2P-k%2B6fnpYDP8G0T%3DhQFfETKV7DedYb%3DohYpTKNMiOSzQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P-k%2B6fnpYDP8G0T%3DhQFfETKV7DedYb%3DohYpTKNMiOSzQ%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/CAEV-rjeO4FDkD8g%3D0hKbmUCd_%2BAfDBpAq3ydB98Tm8eDJfSBug%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEV-rjeO4FDkD8g%3D0hKbmUCd_%2BAfDBpAq3ydB98Tm8eDJfSBug%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/CADsXd2N1H7XfZdmSWednDD8u0607ZE275HJf1-7ouJpOiLsMwg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2N1H7XfZdmSWednDD8u0607ZE275HJf1-7ouJpOiLsMwg%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/CAMCNMFRwF4AjE6foyriSasv83dSQ6Gq_H%2BjKgoad1Dh2iNiEgw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFRwF4AjE6foyriSasv83dSQ6Gq_H%2BjKgoad1Dh2iNiEgw%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/CADsXd2Ne3Y5G%2BjYTFDwFEnkTwZfuwM%2BCZW4TWYJacNj1UA0oXg%40mail.gmail.com.
