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.
