Risk of re-identification attacks

[lavish]

I've been discussing the privacy implications of this proposal with Giorgio Maone during the xs-leaks summit in London last week.

The document lists Deprecating the 2010 CSS Mitigations as future work, assuming it's safe for a site to know what links the user has visited in a partitioned setting. Although a malicious site could not extract the user's global navigation history, it could still exploit the local :visited state to perform a re-identification attack.

Suppose a user is lured into visiting evil.example, with a unique token in the URL. The token can now be used to permanently identify subsequent visits of the same user to evil.exameple, e.g., by probing the :visited pseudo-class via window.getComputedStyle. The re-identification attack would work even if the user has cleared their cookies and local storage.

If the proposal is adopted, we recommend keeping the 2010 mitigations in place.

[NDevTK]

I don't think the 2010 migration provides a significant defense even for fingerprinting since detecting Visited Links via Redraw Timing does not require user interaction although does maybe slow an attack down.

Seems your concern is with fingerprinting and the fix for that would be delete visited link state same as localStorage or provide the option to opt-out of the visited links feature.

[lavish]

Agreed! The point was to avoid relaxing the existing mitigations since partitioning visited links by site does not solve all privacy issues. Re-identification via efficient visited link detection is undoubtedly valuable to an attacker.

[arturjanc]

@lavish Would clearing browsing history (or at least the visitedness status of links exposed to CSS) when the user decides to remove "Cookies and other site data" as mentioned by @NDevTK address your concern? IIUC this would ensure that history cannot persist as an alternative way to store state.

[NDevTK]

Seems this wont fix attacker controlled CSS injection so links clicked in one email will still be detectable in a different email.
I think the best way to fix this is with CSS sanitization or preload all external resources in the CSS.

[lavish]

@arturjanc, Clearing browsing history via "clear site data" sounds reasonable. At that point, I would probably expect to remove all visited entries having the top-level site or the frame origin keys same-site with the current origin. I also agree with @NDevTK that privacy-concerned users would appreciate a global switch to turn off the visited links feature completely.

[NDevTK]

This can be done by disabling browser history, or if on Firefox, by setting the option layout.css.visited_links_enabled to false in the about:config panel.

Chromium should also add a way to do it.

[jonathanKingston]

privacy-concerned users would appreciate a global switch to turn off the visited links feature completely.

We should probably note that equally leaks a bit of information to web pages that makes the user fingerprintable also. Privacy sensitive UAs probably would be better just expiring link history regularly.

• Alternatively the UA could choose to draw self links visited and anything in the referrer perhaps?

[NDevTK]

I dont think its equal for where this fix does not apply such as gmail its leaking what link you clicked not just that you have a feature disabled. Also the screenshare threat of having your browser history leaked is gone.