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/eed28bed-0972-4350-ab90-08e73d53d8a6%40gmail.com.
