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!).
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 <mailto:wanderv...@chromium.org>,
b...@chromium.org <mailto:b...@chromium.org>,
rtarp...@chromium.org <mailto:rtarp...@chromium.org>,
j...@chromium.org <mailto:j...@chromium.org>
Explainer
https://github.com/privacycg/nav-tracking-mitigations/blob/main/bounce-tracking-explainer.md
<https://github.com/privacycg/nav-tracking-mitigations/blob/main/bounce-tracking-explainer.md>
Specification
https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations
<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
<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
<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/
<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
<https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations>
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5705149616488448
<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/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
<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/dab86fa7-8036-4f0f-95a9-d5a3a440e4d8%40chromium.org.
