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/CAOMQ%2Bw-ekOHO4g7AtAhg645VR56qDP1oMaBF6kNZUUOpoWSyDw%40mail.gmail.com.
