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 <chris...@chromium.org> wrote: > LGTM3 > > On Tue, Sep 5, 2023 at 6:56 AM Ben Kelly <wanderv...@chromium.org> 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 <yoavwe...@chromium.org> >> wrote: >> >>> LGTM2 >>> >>> On Tue, Aug 29, 2023 at 5:44 PM Ben Kelly <wanderv...@chromium.org> >>> wrote: >>> >>>> On Tue, Aug 29, 2023 at 1:40 AM Yoav Weiss <yoavwe...@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 <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 <miketa...@chromium.org> >>>>> 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 <wanderv...@chromium.org> >>>>>> wrote: >>>>>> >> >>>>>> >> >>>>>> >> On Mon, Aug 21, 2023 at 11:38 AM Mike Taylor < >>>>>> miketa...@chromium.org> wrote: >>>>>> >>> On 8/21/23 11:09 AM, Ben Kelly wrote: >>>>>> >>> >>>>>> >>> On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss < >>>>>> yoavwe...@chromium.org> wrote: >>>>>> >>>> Thanks for working on this important problem! >>>>>> >>>> >>>>>> >>>> On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly < >>>>>> wanderv...@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 >>>>>> > >>>>>> >> 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 < >>>>>> wanderv...@chromium.org> wrote: >>>>>> >>>>>> Contact emails >>>>>> >>>>>> >>>>>> >>>>>> wanderv...@chromium.org, b...@chromium.org, >>>>>> rtarp...@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. >>>>>> >>>> >>>>>> >>>> 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 blink-dev+unsubscr...@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 >>>>>> . >>>>>> >>> -- >>>>>> >>> 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/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 blink-dev+unsubscr...@chromium.org. >>>>>> >> 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 blink-dev+unsubscr...@chromium.org. >> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMhY-GV6%3DgqgvvyTyDnf704URqn4VABkgH%2BrNX1URUh2gw%40mail.gmail.com.
