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.

Reply via email to