LGTM2 On Thu, Jul 18, 2024 at 6:49 AM Vladimir Levin <vmp...@chromium.org> wrote:
> > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Ne3Y5G%2BjYTFDwFEnkTwZfuwM%2BCZW4TWYJacNj1UA0oXg%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/CAOMQ%2Bw_%3DQEHpPB0jSrWCtkMGG2b6VTvpsRFzSAoeWq1hjVgEUw%40mail.gmail.com.
