I agree that WPT infrastructure shouldn't be a blocker when we're following other browsers.
Have y'all tested the mitigation with commonly used authentication/payment flows, to make sure it doesn't break them? 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/CAL5BFfUN8zEqueKoOm0Jua79L%2BwP%2BncD9r%2BcDc9A%3DvDNk0YTqA%40mail.gmail.com.
