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.
On Thu, Sep 7, 2023 at 12:29 PM Ben Kelly <[email protected]> wrote: > Thank you. > > FYI, bounce tracking mitigations are rolling out to stable 1% as of today. > > On Tue, Sep 5, 2023 at 12:09 PM Chris Harrelson <[email protected]> > wrote: > >> LGTM3 >> >> On Tue, Sep 5, 2023 at 6:56 AM Ben Kelly <[email protected]> wrote: >> >>> Ping for last LGTM or more feedback. We were hoping to be able to >>> collect some stable data before TPAC, if possible. >>> >>> On Wed, Aug 30, 2023 at 8:45 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> LGTM2 >>>> >>>> On Tue, Aug 29, 2023 at 5:44 PM Ben Kelly <[email protected]> >>>> wrote: >>>> >>>>> On Tue, Aug 29, 2023 at 1:40 AM Yoav Weiss <[email protected]> >>>>> 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 <https://github.com/privacycg/nav-tracking-mitigations/issues/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! >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> On Mon, Aug 28, 2023 at 11:08 PM Mike Taylor <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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.) >>>>>>> >>>>>>> On 8/21/23 3:44 PM, Christian Biesinger wrote: >>>>>>> > On Mon, Aug 21, 2023 at 3:25 PM Ben Kelly <[email protected]> >>>>>>> wrote: >>>>>>> >> >>>>>>> >> >>>>>>> >> On Mon, Aug 21, 2023 at 11:38 AM Mike Taylor < >>>>>>> [email protected]> wrote: >>>>>>> >>> On 8/21/23 11:09 AM, Ben Kelly wrote: >>>>>>> >>> >>>>>>> >>> On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss < >>>>>>> [email protected]> wrote: >>>>>>> >>>> Thanks for working on this important problem! >>>>>>> >>>> >>>>>>> >>>> On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly < >>>>>>> [email protected]> 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 >>>>>>> > >>>>>>> >> 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. >>>>>>> >> >>>>>>> >>> >>>>>>> >>>> >>>>>>> >>>>> Webkit: No signal ( >>>>>>> https://github.com/WebKit/standards-positions/issues/214) >>>>>>> >>>>> Web developers: No signals >>>>>>> >>>>> >>>>>>> >>>>> On Thu, Aug 17, 2023 at 10:22 AM Ben Kelly < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>> Contact emails >>>>>>> >>>>>> >>>>>>> >>>>>> [email protected], [email protected], >>>>>>> [email protected], [email protected] >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 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. >>>>>>> >>>> >>>>>>> >>>> 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? >>>>>>> >>> >>>>>>> >>> 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). >>>>>>> >>> >>>>>>> >>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 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 >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>> -- >>>>>>> >>>>> 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 [email protected]. >>>>>>> >>>>> 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 >>>>>>> . >>>>>>> >>> -- >>>>>>> >>> 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 [email protected]. >>>>>>> >>> 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 >>>>>>> . >>>>>>> >> -- >>>>>>> >> 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 [email protected]. >>>>>>> >> 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 >>>>>>> . >>>>>>> >>>>>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMh5YYoSgos29560-ZasdpiPQTZSPzAPcTL83XGeHvNy5Q%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMh5YYoSgos29560-ZasdpiPQTZSPzAPcTL83XGeHvNy5Q%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMheCrRfQaQSUy2FXNSObHA1xJ8A%2BJqcuiw4-BKfm1pZLw%40mail.gmail.com.
