Intent to Ship: Bounce Tracking Mitigations

[Ben Kelly]

Contact emails

wande...@chromium.org, b...@chromium.org, rtar...@chromium.org, j...@chromium.org

Explainer

https://github.com/privacycg/nav-tracking-mitigations/blob/main/bounce-tracking-explainer.md

Specification

https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations

Summary

This feature mitigates bounce tracking on the web.  It works by deleting state from sites that access storage during a redirect that the user has never directly interacted with.  See the specification for more details.

Blink component

Privacy>NavTracking

TAG review

https://github.com/w3ctag/design-reviews/issues/862

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

The main risk is that we will incorrectly delete state for a site that the user needs to continue functioning.  Our approach attempts to address this with a number of signals:

• If a user has interacted with the site within the last 45 days, we will not delete its state.

• We are adding successful webauthn key assertions as another "interaction" source in M117 to address SSO use cases that only require security taps to stay logged in.

• We only delete state if the potential tracking site is not permitted as a 3P cookie.  This allows users and enterprises to grant permission to maintain state on these sites through existing mechanisms.

We have documented some known use cases at-risk.

In particular, since 3P cookies are default allowed today, this feature will only have an immediate impact on users that have opted into 3P cookie blocking or incognito where 3P cookies are blocked by default.

Ergonomics

Minimal ergonomic risk.  There are no direct APIs to call here.  We are deleting state for sites behind the scenes.  We do not delete state for sites that are currently open.  We have devtools enhancements to help developers understand the process.

Activation

No activation risk.  There is nothing to polyfill.

Security

This feature does incrementally worsen existing XS-Leaks in the browser by exposing an additional bit of information.  Attackers can learn if a user has interacted with a site within the last 45 days if they are able to trigger a stateful bounce on the target site and execute a XS-Leak attack to detect the existence of cookies or state on the site.  Since bounce tracking mitigations are only enforced when 3P cookies are blocked, however, the XS-Leak must use navigations and not subresource attacks.

We feel the best solution to this problem is to invest in fixing navigation-based XS-Leaks.  The additional bit of interaction information leaked in the meantime is not ideal, but it has limited utility if an attacker can already tell if there is state on the target site.  We are interested in collaborating with the security team to help address the underlying XS-Leak.

WebView application risks

We are purposely excluding WebView from this launch so we can evaluate impact to that platform separately.

Debuggability

We issue devtool "issues" when a site may potentially be deleted as a bounce tracking.  In addition, we have a devtools application panel to force the bounce tracking algorithm to run immediately.  See the screenshots in this blog post.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All except WebView.  We would like to evaluate the impact to WebView in a separate launch.

Is this feature fully tested by web-platform-tests?

No, unfortunately.  Since this feature runs off of a long duration timer we cannot construct a WPT test case.  We need wpt#17489 to be fixed in order to correct this.

Flag name

DIPS

Requires code in //chrome?

Yes.  We must integrate with features like the chrome sign-in manager, TabHelper, etc.  We are, however, actively working to move other code into the content// layer.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1360489

Measurement

We are measuring UKM for sites that have state deleted by bounce tracking mitigations.

Availability expectation

Our initial MVP implementation is launching to all platforms with the exception of WebView.  In addition, bounce tracking mitigations are only enforced in situations where the tracking domain is not permitted as a 3P cookie.

Adoption expectation

There is no specific API to adopt for this effort, but we only enforce the bounce tracking mitigations when 3P cookies are blocked.  Therefore we expect it to have a greater impact as 3P cookie blocking becomes more common in the future.

Adoption plan

N/A

Non-OSS dependencies

None

Sample links

https://bounce-tracking-demo.glitch.me/

Estimated milestones

Gradual rollout during M116.  Webauthn interaction support will take effect in M117.

Anticipated spec changes

We have written a monkey-patch spec here:

https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5705149616488448

Links to previous Intent discussions

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMi_7z0-yeTbBiE43V5SD1ri4jSVxrkR8Gs%3DD0NRoRKivA%40mail.gmail.com

https://groups.google.com/a/chromium.org/g/blink-dev/c/vyXWn1W1daA/m/tL3f1_WbAwAJ

[Ben Kelly]

Sorry, it seems I left off the signals section of the template:

Firefox: No signal (https://github.com/mozilla/standards-positions/issues/835)

Webkit: No signal (https://github.com/WebKit/standards-positions/issues/214)

Web developers: No signals

[Yoav Weiss]

Thanks for working on this important problem!

On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly <wande...@chromium.org> wrote:

Sorry, it seems I left off the signals section of the template:

Firefox: No signal (https://github.com/mozilla/standards-positions/issues/835)

Firefox folks seem tentatively supportive, but have WPT questions. Can you address them?

Does that mean that any exposed navigation bounce on a sensitive site becomes a history leak? Or do other conditions apply that would make this a rare occurrence?

If it's the former, how do other browsers' mitigation techniques deal with this?

   

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMi2xOMKfZsV5q9jgBuaFvRC3b67fsw%3DYF%2BLNDRgp%2BjdrA%40mail.gmail.com.

[Ben Kelly]

On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for working on this important problem!

On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly <wande...@chromium.org> wrote:

Sorry, it seems I left off the signals section of the template:

Firefox: No signal (https://github.com/mozilla/standards-positions/issues/835)

Firefox folks seem tentatively supportive, but have WPT questions. Can you address them?

I'm checking without our WPT folks to try to understand what mozilla is suggesting.  I'm not familiar with web-driver functions at all, so not quite sure yet how feasible this is.

I don't think it's equivalent to a full history leak on its own.  In order to get the extra leaked bit of "was interacted with in the last 45 days", the site must already have a XS-leak allowing an attacker to detect the existence of cookies or state on the site.  Typically cookies or state are already going to indicate some user activity (interaction).  So the additional bit, while strictly a worsening of the situation, is relatively minor compared to what is available from the prerequisite attack.

Again, we'd like to work on closing the underlying XS-leak that allows attackers to detect cookies/state in the future.  Fixing forward here is preferable since trying to fix just the interaction bit in bounce tracking mitigations itself would likely force the introduction of some kind of allow/block list which has larger negative impacts (as discussed in the explainer alternatives).

[Mike Taylor]

On 8/21/23 11:09 AM, Ben Kelly wrote:

On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for working on this important problem!

On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly <wande...@chromium.org> wrote:

Sorry, it seems I left off the signals section of the template:

Firefox: No signal (https://github.com/mozilla/standards-positions/issues/835)

Firefox folks seem tentatively supportive, but have WPT questions. Can you address them?

I'm checking without our WPT folks to try to understand what mozilla is suggesting.  I'm not familiar with web-driver functions at all, so not quite sure yet how feasible this is.

My read on bvandersloot's comment is that he's asking for a less generic version https://github.com/web-platform-tests/wpt/issues/17489 to make this testable (which you've already linked below). Exposing endpoints for advancing time seems to have more use cases than bounce tracking-specific webdriver endpoints, IMHO - but that's a discussion that should probably happen in the relevant WG.

See https://github.com/web-platform-tests/rfcs for the process to propose extending the testdriver.js API to expose... but I think you'll want to get the relevant concepts added to the webdriver spec first (seems possible, if Mozilla if supportive). The other option would be to something similar to FedCM by adding webdriver extension commands (see spec PR here: https://github.com/fedidcg/FedCM/pull/465/files).

I personally wouldn't recommend blocking on this work, but it seems useful for someone to pursue as good first bugs for folks interested in standards and WPT internals. Note that additions to WebDriver now require going through the Intent process (great news for folks interested in learning this process, presumably they exist!).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMgTO8-OStci%3DDgu-xeNZJKgOnf17i15wkXintg2wod2Ag%40mail.gmail.com.

[Ben Kelly]

On Mon, Aug 21, 2023 at 11:38 AM Mike Taylor <mike...@chromium.org> wrote:

On 8/21/23 11:09 AM, Ben Kelly wrote:

On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for working on this important problem!

On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly <wande...@chromium.org> wrote:

Sorry, it seems I left off the signals section of the template:

Firefox: No signal (https://github.com/mozilla/standards-positions/issues/835)

Firefox folks seem tentatively supportive, but have WPT questions. Can you address them?

I'm checking without our WPT folks to try to understand what mozilla is suggesting.  I'm not familiar with web-driver functions at all, so not quite sure yet how feasible this is.

My read on bvandersloot's comment is that he's asking for a less generic version https://github.com/web-platform-tests/wpt/issues/17489 to make this testable (which you've already linked below). Exposing endpoints for advancing time seems to have more use cases than bounce tracking-specific webdriver endpoints, IMHO - but that's a discussion that should probably happen in the relevant WG.

See https://github.com/web-platform-tests/rfcs for the process to propose extending the testdriver.js API to expose... but I think you'll want to get the relevant concepts added to the webdriver spec first (seems possible, if Mozilla if supportive). The other option would be to something similar to FedCM by adding webdriver extension commands (see spec PR here: https://github.com/fedidcg/FedCM/pull/465/files).

I personally wouldn't recommend blocking on this work, but it seems useful for someone to pursue as good first bugs for folks interested in standards and WPT internals. Note that additions to WebDriver now require going through the Intent process (great news for folks interested in learning this process, presumably they exist!).

Andrew Williams also helpfully pointed out a bunch of code source references to me for this.  I filed crbug.com/1474656 to do this work.

I think this is definitely something we will do, but it may take a milestone or two to get it done.  In particular, I'm unsure if there will be pushback to modifying the web-driver functions for a bounce tracking mitigations-specific feature.

I don't think we want to take on the general purpose clock modification change to web-driver, though.  That seems like a much larger scope.

[Christian Biesinger]

On Mon, Aug 21, 2023 at 3:25 PM Ben Kelly <wande...@chromium.org> wrote:
>
>
>
> On Mon, Aug 21, 2023 at 11:38 AM Mike Taylor <mike...@chromium.org> wrote:
>>
>> On 8/21/23 11:09 AM, Ben Kelly wrote:
>>
>> On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss <yoav...@chromium.org> wrote:
>>>
>>> Thanks for working on this important problem!
>>>
>>> On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly <wande...@chromium.org> wrote:
>>>>
>>>> Sorry, it seems I left off the signals section of the template:
>>>>
>>>> Firefox: No signal (https://github.com/mozilla/standards-positions/issues/835)
>>>
>>>
>>> Firefox folks seem tentatively supportive, but have WPT questions. Can you address them?
>>
>>
>> I'm checking without our WPT folks to try to understand what mozilla is suggesting. I'm not familiar with web-driver functions at all, so not quite sure yet how feasible this is.
>>
>> My read on bvandersloot's comment is that he's asking for a less generic version https://github.com/web-platform-tests/wpt/issues/17489 to make this testable (which you've already linked below). Exposing endpoints for advancing time seems to have more use cases than bounce tracking-specific webdriver endpoints, IMHO - but that's a discussion that should probably happen in the relevant WG.
>>
>> See https://github.com/web-platform-tests/rfcs for the process to propose extending the testdriver.js API to expose... but I think you'll want to get the relevant concepts added to the webdriver spec first (seems possible, if Mozilla if supportive). The other option would be to something similar to FedCM by adding webdriver extension commands (see spec PR here: https://github.com/fedidcg/FedCM/pull/465/files).
>>
>> I personally wouldn't recommend blocking on this work, but it seems useful for someone to pursue as good first bugs for folks interested in standards and WPT internals. Note that additions to WebDriver now require going through the Intent process (great news for folks interested in learning this process, presumably they exist!).
>
>
> Andrew Williams also helpfully pointed out a bunch of code source references to me for this. I filed crbug.com/1474656 to do this work.
>
> I think this is definitely something we will do, but it may take a milestone or two to get it done. In particular, I'm unsure if there will be pushback to modifying the web-driver functions for a bounce tracking mitigations-specific feature.

Lots of specs define webdriver extensions, that should not be a problem. E.g.:
https://fedidcg.github.io/FedCM/#automation
https://w3c.github.io/secure-payment-confirmation/#sctn-automation
https://w3c.github.io/webauthn/#sctn-automation-virtual-authenticators

Note that you have to implement the commands twice, once for Chrome's
bots and once for upstream wpt.fyi and general UA automation uses.
Chrome's impl does not really use webdriver, it usually just calls a
function on internals (e.g.
https://chromium-review.googlesource.com/c/chromium/src/+/4740672/6/third_party/blink/web_tests/resources/testdriver-vendor.js)

The second impl is in Chromedriver, likely using CDP, e.g.:
https://chromium-review.googlesource.com/c/chromium/src/+/4281897
plus
https://chromium-review.googlesource.com/c/chromium/src/+/4402971

Christian

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMiXRs97mKph1BayrWAknP-1dfdCOTPHq%2B7xRBnSN%2BxU9g%40mail.gmail.com.

[Mike Taylor]

LGTM1 to ship, as long as we fast follow with doing the work to define
and ship webdriver extensions in order to make this testable in WPT.

(I don't think your team should be blocked on shipping because other
browsers who already shipped the feature didn't do that work.)

[Yoav Weiss]

I agree that WPT infrastructure shouldn't be a blocker when we're following other browsers. 

Have y'all tested the mitigation with commonly used authentication/payment flows, to make sure it doesn't break them?

[Ben Kelly]

On Tue, Aug 29, 2023 at 1:40 AM Yoav Weiss <yoav...@chromium.org> wrote:

I agree that WPT infrastructure shouldn't be a blocker when we're following other browsers. 

Thank you. 

Have y'all tested the mitigation with commonly used authentication/payment flows, to make sure it doesn't break them?

We have been dogfooding and not run into any issues with auth/payment flows.  We are also collecting UKM metrics on sites deleted.  I've sent you a private email with that information.

The UKM is predominantly advertising, tracking, etc.  There are a smattering of auth/ecommerce/etc, but at lower volumes.  The auth issue we believe may be related to automatic login scenarios in enterprises (issue 36), which can be largely addressed with enterprise policies.  We also integrated webauthn security key taps as interactions in M117 to reduce authentication false positives.

Overall, however, we believe that since we only take action when 3P cookies are blocked, breakage should be limited.  The 3P cookie default has not changed yet, so most users will not be affected.  In addition, chromeguard, enterprise policies and other mechanisms can be used to add cookie exceptions which bounce tracking mitigations will honor. 

Ultimately, many sites will need to adapt to a new normal when the 3P cookie setting default changes.  That will need to include that bounce tracking is not an acceptable replacement.  We would like to ship bounce tracking mitigations gated on 3P cookie permissions so that when sites perform 3P cookie deprecation testing they see the new bounce tracking behavior as well.

[Yoav Weiss]

LGTM2

On Tue, Aug 29, 2023 at 5:44 PM Ben Kelly <wande...@chromium.org> wrote:

On Tue, Aug 29, 2023 at 1:40 AM Yoav Weiss <yoav...@chromium.org> wrote:

I agree that WPT infrastructure shouldn't be a blocker when we're following other browsers. 

Thank you. 

Have y'all tested the mitigation with commonly used authentication/payment flows, to make sure it doesn't break them?

We have been dogfooding and not run into any issues with auth/payment flows.  We are also collecting UKM metrics on sites deleted.  I've sent you a private email with that information.

The UKM is predominantly advertising, tracking, etc.  There are a smattering of auth/ecommerce/etc, but at lower volumes.  The auth issue we believe may be related to automatic login scenarios in enterprises (issue 36), which can be largely addressed with enterprise policies.  We also integrated webauthn security key taps as interactions in M117 to reduce authentication false positives.

Overall, however, we believe that since we only take action when 3P cookies are blocked, breakage should be limited.  The 3P cookie default has not changed yet, so most users will not be affected.  In addition, chromeguard, enterprise policies and other mechanisms can be used to add cookie exceptions which bounce tracking mitigations will honor. 

Ultimately, many sites will need to adapt to a new normal when the 3P cookie setting default changes.  That will need to include that bounce tracking is not an acceptable replacement.  We would like to ship bounce tracking mitigations gated on 3P cookie permissions so that when sites perform 3P cookie deprecation testing they see the new bounce tracking behavior as well.

Thanks for outlining your motivations! Going ahead with this change before the 3P cookie deprecation but 3P cookie blocking makes perfect sense!

[Ben Kelly]

Ping for last LGTM or more feedback.  We were hoping to be able to collect some stable data before TPAC, if possible.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMh5YYoSgos29560-ZasdpiPQTZSPzAPcTL83XGeHvNy5Q%40mail.gmail.com.

[Ben Kelly]

Thank you.

FYI, bounce tracking mitigations are rolling out to stable 1% as of today.

[Ben Kelly]

FYI, we are rolling out bounce tracking mitigations to stable 10% today.  (Again, this only impacts users who are blocking 3P cookies.)  This intermediate rollout step was added in order to investigate some regressions that showed up in the 1% stable data.

[Ben Kelly]

Bounce tracking mitigations are now rolling out to 100% stable starting today (in cases where 3P cookies are blocked).