Intent to Prototype: Partitioning :visited links history
Kyra Seevers
Contact emails
Explainer
https://github.com/kyraseevers/Partitioning-visited-links-history
Specification
TBD
Summary
To eliminate user browsing history leaks, anchor elements will be styled as :visited if and only if they have been visited from the same 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 visited from this site and frame before, the many side-channel attacks that have been developed to obtain :visited links styling information will be obsolete, as they no longer provide sites with new information about users.
Blink component
Motivation
Since 2010, the number of side-channel attacks to leak the user’s browsing history by abusing :visited links styling has grown, including user interaction attacks, timing attacks, pixel color attacks, and process-level attacks. While these attack vectors are slowed down by the 2010 mitigations, they are not eliminated; browsers are still actively leaking user browsing history today.
Triple-keyed history partitioning only styles links have been visited from the same top-level site and frame origin before. As a result, the many side-channel attacks that have been developed to obtain the global :visited links state will now be obsolete, as they will no longer provide sites with new information about users.
This feature will improve user privacy and security. The resulting implementation will be relevant to users who will see slight changes to which links appear styled on their screens, and to bad actors who will no longer be able to use side-channel attacks to reveal user browsing history.
Initial public proposal
https://github.com/WICG/proposals/issues/100
Search tags
visited links, :visited selector, partitioning history
TAG review
TBD
TAG review status
Not Started
Risks
Interoperability and Compatibility
Gecko: Positive initial signals from presentation at WebAppSec
WebKit: Positive initial signals from presentation at WebAppSec
Web developers: 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.
Other signals: N/a
WebView application risks
No - this feature deals with platform-specific code, and Android WebView does style :visited links based on user browsing history, but we do not expect significant challenges for WebView users.
Debuggability
Is this feature fully tested by web-platform-tests?
No
Flag name
(Tentatively) base::features::PartitionVisitedLinks
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1448609
Launch bug
https://launch.corp.google.com/launch/4259382
Estimated milestones
No milestones specified yet
Link to entry on the Chrome Platform Status
Yoav Weiss
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXbbLWwmRYH5SWx0%2BMWkfB2UY2miOAq4r0MZc34i_sWqBw%40mail.gmail.com.
Dave Tapuska
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUc0KFyXgQ0LMWQnj3AT363td0k1LJSgsZp8pXvCxPZ7A%40mail.gmail.com.
