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?
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_%3DQEHpPB0jSrWCtkMGG2b6VTvpsRFzSAoeWq1hjVgEUw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
