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 <https://github.com/fedidcg/FedCM/blob/main/proposals/webdriver.md> > 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 > <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/SYA56RETDGc/m/yicXrX3qAAAJ> > (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. 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 >>>> <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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMgTO8-OStci%3DDgu-xeNZJKgOnf17i15wkXintg2wod2Ag%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/CAK7rkMiXRs97mKph1BayrWAknP-1dfdCOTPHq%2B7xRBnSN%2BxU9g%40mail.gmail.com.
