LGTM2 for a low percentage finch experiment in M128-M130 (inclusive)
/Daniel
On 2024-07-03 22:02, Chris Harrelson wrote:
LGTM1
(probably 3 needed because this is a non-standard experiment)
On Wed, Jul 3, 2024 at 12:28 PM Kyra Seevers
<kyraseev...@chromium.org> wrote:
One point of clarification: we are intending to experiment for one
milestone (M128), but would like to request 3 milestones (M128 -
M130) in case of any delays.
Thanks so much!
On Wed, Jul 3, 2024 at 2:16 PM Kyra Seevers
<kyraseev...@chromium.org> wrote:
Update: I wanted to update the thread that WebKit left
positive indications of support for this proposal in the
request for position recently:
https://github.com/WebKit/standards-positions/issues/363.
Daniel: Thanks for the question! We will be using a
traditional Finch experiment rollout starting with Canary/Dev
in M128. I will update this thread with any changes to the
experiment that occur.
As for why we chose our keying structure: top-level site
allows us to prevent cross-site leaks and frame origin allows
us to adhere to the same-origin policy and avoid cross-frame
leaks. For example, if I have an iframe c.com <http://c.com>
embedded in both a.com <http://a.com> and b.com
<http://b.com>, keying by top-level site removes the
opportunity for cross-site tracking to occur between these two
iframes. For a visual example of this, please see the
explainer (especially Key Scenarios #2 and #3):
https://github.com/kyraseevers/Partitioning-visited-links-history?tab=readme-ov-file#key-scenarios.
Thanks all,
Kyra
On Wed, Jul 3, 2024 at 10:48 AM Daniel Bratell
<bratel...@gmail.com> wrote:
What milestones do you plan to run the experiment in?
(Also, why isn't it enough to key on frame origin? I'm
sure there is a good reason but it's not obvious.)
/Daniel
On 2024-07-02 22:42, Kyra Seevers wrote:
Intent to Experiment: Partitioning :visited links
historyPhase 2 (User-facing partitioning for
:visited links)
Contact emails
kyraseev...@chromium.org
Explainer
https://github.com/kyraseevers/Partitioning-visited-links-history
<https://github.com/kyraseevers/Partitioning-visited-links-history>
Specification
We plan to specify our solution before shipping. This
work currently falls under the wording in CSS Selectors
Level 4 <https://www.w3.org/TR/selectors-4/#link>: “UAs
may treat all links as unvisited links or implement other
measures to preserve the user’s privacy while rendering
visited and unvisited links differently.”
Summary
To eliminate user browsing history leaks, anchor elements
will be styled as :visited if and only if they have been
clicked from this top-level site and frame origin before.
On the browser-side, this means that the VisitedLinks
hashtable will now be partitioned via "triple-keying", or
by storing the following for each visited link: <link
URL, top-level site, frame origin>. By only styling links
that have been clicked on this site and frame before, the
many side-channel attacks that have been developed to
obtain :visited links styling information are now
obsolete, as they no longer provide sites with new
information about users.
Blink component
Blink>History>VisitedLinks
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHistory%3EVisitedLinks>
Search tags
visited links
<https://chromestatus.com/features#tags:visited%20links>,
:visited selector
<https://chromestatus.com/features#tags::visited%20selector>,
partitioning history
<https://chromestatus.com/features#tags:partitioning%20history>
TAG review
https://github.com/w3ctag/design-reviews/issues/896
<https://github.com/w3ctag/design-reviews/issues/896>
TAG review status
Issues addressed
Risks
Interoperability and Compatibility
Gecko: Positive
(https://github.com/mozilla/standards-positions/issues/1040
<https://github.com/mozilla/standards-positions/issues/1040>)
WebKit: Under Review
(https://github.com/WebKit/standards-positions/issues/363
<https://github.com/WebKit/standards-positions/issues/363>)
Web developers: No signals
Other signals:
*
Positive initial signals from presentation at
WebAppSec from both Apple and Firefox
<https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-06-21-minutes.md>
*
At the XS Leaks Summit, Firefox stated exploration of
:visited links partitioning in their privacy goals
for the upcoming year at the XS-Leaks Summit
*
Positive or neutral initial signals from security and
privacy researchers at the XS-Leaks summit. No
security concerns about this design. Interest in
understanding user behavior around this new model of
what constitutes a :visited link.
*
Feedback from UX that CSS extensibility is in-demand
from developers right now, and this work would pave
the way for less restricted CSS on anchor elements.
In addition, support from various developers who
believe that taking care of this long-standing
privacy leak will allow their own security and
privacy solutions to advance once history sniffing is
no longer an issue.
Ergonomics
This design is asynchronous and not used in tandem with
other APIs.
Activation
Since this is a Finch roll-out, there are no additional
activation risks.
Security
For this design we worked with the Chrome Security
Architecture team to ensure reasonable precautions were
taken against leaks of the :visited links hashtable via
renderer compromise.
WebView application risks
This experiment will not run on WebView. This feature
deals with platform-specific code and the WebView
implementation of :visited links does not integrate with
the History Database.
Goals for experimentation
Our intent is to run a Finch experiment. This user-facing
experiment will use the traditional Finch roll-out
schedule. We will utilize newly added UMA to determine
the percentage of links styled as :visited under
partitioning, as well as observe the size, efficiency,
and impact of the newly partitioned infrastructure in
comparison to the unpartitioned (original) codepaths.
Experiment Risks
As this is a Finch experiment, it is per-client rather
than per-site. The biggest potential risk to clients is a
visible change to which links are styled as :visited once
they enter the experiment. However, based on
pre-experimental metrics analysis, we believe that most
links the user sees will remain unchanged. In the event
of an issue during the experiment, we will flip our kill
switch via Finch.
Ongoing technical constraints
None
Debuggability
No DevTools support is required.
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, ChromeOS,
Android, and Android WebView)?
No
This feature is not currently supported on iOS or Android
Webview. For iOS, this feature requires WebKit to alter
its CSS parsing to support triple-key partitioning.
Android Webview relies on an entirely different system to
populate history, so it will require a separate design.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No
This feature is not tested by Web Platform Tests because
the :visited selector cannot be queried via JavaScript
(https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector
<https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector>).
As a result, we can only test :visited-ness via manual
tests which rely on users visually confirming the correct
links are :visited, or unit and integration tests
internal to Chrome.
Flag name on chrome://flags
N/a
Finch feature name
PartitionVisitedLinkDatabase
Requires code in //chrome?
True
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1448609
Launch bug
https://launch.corp.google.com/launch/4330864
<https://launch.corp.google.com/launch/4330864>
Estimated milestones
Shipping on desktop
128
Shipping on Android
128
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5101991698628608?gate=4821248529137664
<https://chromestatus.com/feature/5101991698628608?gate=4821248529137664>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXbbLWwmRYH5SWx0%2BMWkfB2UY2miOAq4r0MZc34i_sWqBw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXbbLWwmRYH5SWx0%2BMWkfB2UY2miOAq4r0MZc34i_sWqBw%40mail.gmail.com>
Intent to Experiment (Phase 1):
https://groups.google.com/a/chromium.org/g/blink-dev/c/U5AX0OXaxM8/m/tIGr4bJJBgAJ?utm_medium=email&utm_source=footer
<https://groups.google.com/a/chromium.org/g/blink-dev/c/U5AX0OXaxM8/m/tIGr4bJJBgAJ?utm_medium=email&utm_source=footer>
This intent message was generated by Chrome Platform
Status <https://chromestatus.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/CA%2BmmbXYy4CSMuPLY0HJuTbZt0qPz5ZUsGUToFJuCE%2BTfC86umA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXYy4CSMuPLY0HJuTbZt0qPz5ZUsGUToFJuCE%2BTfC86umA%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/CA%2BmmbXbJX%2BW5m9351o8qZV56SAnsmEfDbSwTr6YHPrpQUx%3DG2Q%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXbJX%2BW5m9351o8qZV56SAnsmEfDbSwTr6YHPrpQUx%3DG2Q%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/c88842b3-894d-49c6-be1a-d83f7fdae7ea%40gmail.com.
