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. > > 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 >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3ENavTracking> >>> >>> 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 >>> <https://github.com/privacycg/nav-tracking-mitigations/issues?q=is%3Aopen+is%3Aissue+label%3Abounce-tracking+label%3Aat-risk-use-case> >>> . >>> >>> 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 >>> <https://developer.chrome.com/blog/bounce-tracking-mitigations-dev-trial/> >>> . >>> >>> 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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? >>> >>> No, unfortunately. Since this feature runs off of a long duration timer >>> we cannot construct a WPT test case. We need wpt#17489 >>> <https://github.com/web-platform-tests/wpt/issues/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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMi2xOMKfZsV5q9jgBuaFvRC3b67fsw%3DYF%2BLNDRgp%2BjdrA%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/CAK7rkMgTO8-OStci%3DDgu-xeNZJKgOnf17i15wkXintg2wod2Ag%40mail.gmail.com.
