1398414 - Key :visited per origin (first-party-isolation / partitioning for :visited).

Status: NEW

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Thorin [:thorin]]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

Not sure if this should be tied to privacy.resistFingerprinting (RFP), it's more tracking than FP'ing, but certainly falls in the realm of Tor Uplift. There is already a solution - See [1] for details and [2] for the bugzilla and `layout.css.visited_links_enabled` (notably https://bugzilla.mozilla.org/show_bug.cgi?id=147777#c106 ). 

Note in the Mozilla docs [3] that this has never been fully resolved, it says "will lie to web applications under certain circumstances".

Suggest overriding css visited links (disable it) when RFP = true, and check "all circumstances" are covered, or check/patch/close the original ticket


Actual results:

PoC: http://lcamtuf.coredump.cx/yahh/

Note: it's not very clear what to do in this old PoC. You will need layout.css.visited_links_enabled set as true. You will also need a normal window (not a Private Browsing one). The PoC only covers a handful of sites, and many of those will not "leak" as the code is checking HTTP and most of the sites have moved to HTTPS - For best results:
- Open a normal window in a vanilla Firefox
- Clear everything (Ctrl-Shift-Del)
- Go to http://www.cnn.com/ and http://www.foxnews.com/
- Go to the test page and play a game (takes 30 seconds or so)



Expected results:

[1] https://dbaron.org/mozilla/visited-privacy
[2] Bug 147777
[3] https://developer.mozilla.org/docs/Web/CSS/Privacy_and_the_:visited_selector

Comment 1

[Emilio Cobos Álvarez (:emilio)]

This one is easy, I can just take it...

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1398414: Simplify some ResistFingerprinting callers in nsMediaFeatures.

The docshell version just redirects to the document one, so no need to
ping-pong.

Review commit: https://reviewboard.mozilla.org/r/213998/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/213998/

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1398414: disable :visited when resisting fingerprinting.

Review commit: https://reviewboard.mozilla.org/r/214000/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/214000/

Comment 4

[Tom Ritter [:tjr]]

LGTM - thanks!

Comment 5

[Arthur Edelstein [:arthur]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #2)
> Created attachment 8943616 [details]
> Bug 1398414: Simplify some ResistFingerprinting callers in nsMediaFeatures.
> 
> The docshell version just redirects to the document one, so no need to
> ping-pong.
> 
> Review commit: https://reviewboard.mozilla.org/r/213998/diff/#index_header
> See other reviews: https://reviewboard.mozilla.org/r/213998/

Hi, Emilio -- thank you for working on this. I wonder if we could apply first-party isolation (privacy.firstparty.isolate) instead of patching fingerprinting resistance. That would allow visited link styling to continue to work, but would still prevent tracking across first party or container.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

(In reply to Arthur Edelstein (Tor Browser dev) [:arthuredelstein] from comment #5)
> (In reply to Emilio Cobos Álvarez [:emilio] from comment #2)
> > Created attachment 8943616 [details]
> > Bug 1398414: Simplify some ResistFingerprinting callers in nsMediaFeatures.
> > 
> > The docshell version just redirects to the document one, so no need to
> > ping-pong.
> > 
> > Review commit: https://reviewboard.mozilla.org/r/213998/diff/#index_header
> > See other reviews: https://reviewboard.mozilla.org/r/213998/
> 
> Hi, Emilio -- thank you for working on this. I wonder if we could apply
> first-party isolation (privacy.firstparty.isolate) instead of patching
> fingerprinting resistance. That would allow visited link styling to continue
> to work, but would still prevent tracking across first party or container.

As of right now the style system effectively has just a per-document toggle of whether :visited is enabled.

How would that work? Would that need to be per-link? I'm not sure how first-party isolation works, so please bear with me :)

Comment 7

[Arthur Edelstein [:arthur]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #6)

> How would that work? Would that need to be per-link? I'm not sure how
> first-party isolation works, so please bear with me :)

When privacy.firstparty.isolate is enabled, the status of links (visited or not) should be keyed by first-party domain (the URL bar domain) as well as the link URL:

So for example, if the page at https://www.mozilla.org/en-US/ were to contain a link to https://en.wikipedia.org/wiki/Mozilla, then when privacy.firstparty.isolate = true, we would store (in pseudocode):

VisitedLinks["https://mozilla.org"]["https://en.wikipedia.org/wiki/Mozilla"] = true;

Where the first index represents the first party domain, and the second index represents the link itself.

mFirstPartyDomain can be found in a document's OriginAttributes. If we isolate by OriginAttributes, then that takes care of isolating :visited status by both first-party and containers.

Comment 8

[Arthur Edelstein [:arthur]]

Here's a list of examples of first-party isolation patches:
https://wiki.mozilla.org/Security/FirstPartyIsolation#First_Party_Isolation_-_FIXED

Comment 9

[Emilio Cobos Álvarez (:emilio)]

(In reply to Arthur Edelstein (Tor Browser dev) [:arthuredelstein] from comment #8)
> Here's a list of examples of first-party isolation patches:
> https://wiki.mozilla.org/Security/FirstPartyIsolation#First_Party_Isolation_-
> _FIXED

That is a much more invasive change than this one though.

Keying :visited by origin has been discussed earlier, as it allows basically removing the :visited privacy restrictions, but as I said it is also a bigger change than what I have time to work on right now :).

See

Comment 10

[Emilio Cobos Álvarez (:emilio)]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #9)
> (In reply to Arthur Edelstein (Tor Browser dev) [:arthuredelstein] from
> comment #8)
> > Here's a list of examples of first-party isolation patches:
> > https://wiki.mozilla.org/Security/FirstPartyIsolation#First_Party_Isolation_-
> > _FIXED
> 
> That is a much more invasive change than this one though.
> 
> Keying :visited by origin has been discussed earlier, as it allows basically
> removing the :visited privacy restrictions, but as I said it is also a
> bigger change than what I have time to work on right now :).

Err, I was going to paste the link here too. Anyway, would you think it'd make sense to restrict this bug to privacy.resistFingerprinting, and file another one (in DOM, I'd think, since I think that's where the database that tracks :visited state lives) for FPI? The patches would look completely different.

Comment 11

[Arthur Edelstein [:arthur]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #10)

> > Keying :visited by origin has been discussed earlier, as it allows basically
> > removing the :visited privacy restrictions, but as I said it is also a
> > bigger change than what I have time to work on right now :).

Makes sense! I appreciate your looking into this. Sorry for making it more complicated! :)

> Err, I was going to paste the link here too. Anyway, would you think it'd
> make sense to restrict this bug to privacy.resistFingerprinting, and file
> another one (in DOM, I'd think, since I think that's where the database that
> tracks :visited state lives) for FPI? The patches would look completely
> different.

As Simon mentioned in comment 0, the information leak via :visited links is not really a form of fingerprinting. Rather it is a type of super-cookie that I think is best addressed by FPI. So I would propose not binding it to privacy.resistFingerprinting at all, in which case we can use this bug for FPI.

Comment 12

[Xidorn Quan [:xidorn] UTC+10]

Comment on attachment 8943616 [details]
Bug 1398414: Simplify some ResistFingerprinting callers in nsMediaFeatures.

https://reviewboard.mozilla.org/r/213998/#review222244

Comment 13

[Xidorn Quan [:xidorn] UTC+10]

Comment on attachment 8943617 [details]
Bug 1398414: disable :visited when resisting fingerprinting.

https://reviewboard.mozilla.org/r/214000/#review222246

I agree with Arthur that this doesn't sound like really a fingerprinting factor. And given that we already have a separate pref `layout.css.visited_links_enabled` to control it, people concerned can just unset that (which itself may create a fingerprint, though).

The first patch is probably still worth landing, which can happen in a separate bug. I guess we can leave this bug for FPI as suggested (although that may not happen very soonish).

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Yeah, I agree, will land it on another bug.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 8943616 [details]
Bug 1398414: Simplify some ResistFingerprinting callers in nsMediaFeatures.

Landed in bug 1434215.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 8943617 [details]
Bug 1398414: disable :visited when resisting fingerprinting.

Per comments this is not worth landing :)

Comment 17

[Thorin [:thorin]]

new paper [1] with new (and old) techniques: CSS Paint API, Bytecode cache which are currently chrome only. CSS 3D, SVG, Pixel Perfect attacks. FF60, with and without visited, is still vulnerable to those last three. Their proposed solution (Part 6, Conclusion) is a same-origin-style policy.

Keying :visited: with OA's would only work effectively for FPI. container or PB mode OA's are not restrictive enough. I would be in favor of dropping this ticket for a "same-origin-style policy"

[1] https://www.usenix.org/system/files/conference/woot18/woot18-paper-smith.pdf

Comment 18

[Thorin [:thorin]]

also see Bug 1283320

Comment 19

[Emilio Cobos Álvarez (:emilio)]

(In reply to Simon Mainey from comment #17)
> [1]: https://www.usenix.org/system/files/conference/woot18/woot18-paper-smith.pdf

I'm confused, how is their proposed fix different from the proposal here?

It'd only allow to style links either from the same origin, or visited from a given origin, which is what this bug roughly proposes, unless I'm misunderstanding.

Comment 20

[Thorin [:thorin]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #19)
> I'm confused, how is their proposed fix different from the proposal here?

Maybe I'm mistaking the intent of this proposal: I thought it would apply OA's: i.e FPI (^firstPartyDomain=), Containers (^userContextId=), PB Mode (privateBrowsingId=), and any combinations. And that only those with FPI cover "same origin", whereas containers and PB mode on their own only compartmentalize.

IMO, keying :visited: with FPI is the same proposal as the paper, but, I am assuming, it would require privacy.firstparty.isolate=true. This would not help non-FPI users, so my comment was poorly written: I was angling that we should make this totally independent of that (eg privacy.firstparty.isolate.visited), so everyone can be protected. I still think we should key the other two OAs as well (eg cases of same domain in different containers).

Comment 21

[Emilio Cobos Álvarez (:emilio)]

(In reply to Simon Mainey from comment #20)
> (In reply to Emilio Cobos Álvarez (:emilio) from comment #19)
> I was angling that we
> should make this totally independent of that (eg
> privacy.firstparty.isolate.visited), so everyone can be protected.

Yeah, I agree, though before doing that it may be worth prototyping it under the FPI pref, so at least we have a way to test its compat impact.

> I still
> think we should key the other two OAs as well (eg cases of same domain in
> different containers).

I don't know how those interact and how easy to do that'd be, but that sounds reasonable off-hand.

Comment 22

[Thorin [:thorin]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #21)
> I don't know how those interact and how easy to do that'd be, but that sounds reasonable off-hand.

FPI&Containers, FPI&PBMode already exist: e.g: ^userContextId=1&firstPartyDomain=example.com .Note, containers cannot be used in PB Mode.

Comment 23

[Thorin [:thorin]]

Wouldn't this approach be obsolete with Bug 1506842 and Bug 1591717 ?

Comment 24

[Emilio Cobos Álvarez (:emilio)]

(In reply to Simon Mainey from comment #23)

Wouldn't this approach be obsolete with Bug 1506842 and Bug 1591717 ?

No, this would still be interesting for a variety of reasons:

• FPI is more provably correct than our current setup (our current setup relies on always doing the same amount of work for visited and unvisited links, which is not great).

• FPI would allow us to avoid the restrictions we impose on :visited right now (https://github.com/w3c/csswg-drafts/issues/3012), and simplify a lot our style engine.

But it could be a usability regression: if I visit this page from my urlbar and two sites link to it, with FPI those two links would appear unvisited, which some users might dislike.

I do think this is worth trying out. If we could do FPI I think it's a more robust solution than our current privacy mitigations.

Comment 25

[Masatoshi Kimura [:emk]]

But it could be a usability regression: if I visit this page from my urlbar and two sites link to it, with FPI those two links would appear unvisited, which some users might dislike.

I dislike that. We could just turn off layout.css.visited_links_enabled instead of introducing such complex and hard-to-understand feature.

Comment 26

[Thorin [:thorin]]

(In reply to Masatoshi Kimura [:emk] from comment #25)

I dislike that. We could just turn off layout.css.visited_links_enabled instead of introducing such complex and hard-to-understand feature.

layout.css.visited_links_enabled is purely cosmetic since bug 1632765 landed since all links are now restyled

• FF77+: layout.css.always-repaint-on-unvisited + layout.css.notify-of-unvisited default true

See bugs 557579, 773338, 884270, 1131288, 1632765

Bug 1632765 does slow down timing attacks but does not fully mitigate it (Emilio has info on this PoC). RFP likewise makes this difficult, but timing bypasses are still possible (see Fantastic Timers and Where to Find Them)

As Emilio said in comment 24, FPI/dFPI is a more robust solution

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 6 See Also bugs.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 28

[Emilio Cobos Álvarez (:emilio)]

No, S3 seems fair.

Comment 30

[Simon Pieters [:zcorpan]]

Chromium is currently implementing partitioned :visited per https://github.com/w3c/csswg-drafts/issues/3012#issuecomment-2034797550

Comment 31

[Daniel Holbert [:dholbert]]

For the record, there was a csswg resolution today in https://github.com/w3c/csswg-drafts/issues/11151#issuecomment-2607888849 that was related to this -- the resolution requires browsers to mitigate :visited privacy leakage in some way (which we already do by removing all ways we've found that web developers could use to observe the visitedness of a link).

As part of that resolution, the spec is going to gain an appendix that'll discuss Chromium's experimental approach (which is along the lines of what's proposed in our bug here, I think) as one possible mitigation.