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/CAL5BFfVnx%3DFCsEtoizD-62d2HhE3KZTSo_fPGagm7nw-1mRp0Q%40mail.gmail.com.
