I'm fine with changing the way that `:visited` works in order to make it less likely that we leak data about user behavior. I worry a bit about the amount of data we'd need to store locally in order to support a directed `:visited`, and the impact that would have on things like clearing browsing data for a given origin, but I'm sure we could work those out. There were other crazy ideas in the doc that are probably worth exploring, so publicizing it would be excellent.

Skimming it again, the things I was most skeptical about were related to the "removing our existing `:visited` mitigations" bits you're carving out of this change. I think that's a harder problem in general, but also well worth discussing.

+battre@, msramek@: FYI.

Adding Objective label for Blink>CSS tracking.

Making :visited a directed thing sounds great to me if it is technically feasible.

This SGTM as well.

Apart from giving a perfect privacy guarantee that no information crosses the origin boundary, I think this also makes a lot of sense from user's perspective. If a website contains a long list of links, I certainly want to know which ones I already clicked. But it is rarely useful to know that I already visited a link in the past from somewhere else.

This would require us to view local browsing history as a directed graph. We have discussed this in the past in the context of different features. It might be reusable for a nicer history page, smarter history deletion, or any feature that needs to consume history for personalization. Therefore I agree that the logic should live in //c/b/history and/or //components/history and be passed down to Blink from there.

History as a feature is owned by the Privacy team, so we can own this work. But I think we should have a few more use cases in mind to justify the added complexity.

> If we were to decide to prioritize trying something here, what team would own it?
> Perhaps all the work is really in the history system with only tiny hooks in the 
> style system?

I don't think we need to change anything in the style system. A pure same-origin check could be implemented in LinkHashForElement, returning 0 if the origin-check fails:

  https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/VisitedLinkState.cpp?l=51

FTR: I don't have access to go/rethink-visited/

Removing Blink>CSS component based on #9

We used to have an implementation of double-keying, however, the webkit changed how :visited worked, and the patch wasn't landed.

The major complained with double-keying was that it would break the use case where you go to some aggregator site and want to see what URLs you already visited (even if not from this aggregator side).

ericwilligers: If not Blink>CSS, this bug should still be SOME Blink bug.  How about Blink/DOM since 'VisitedLinkState.cpp' is in the DOM directory?

jochen: Yep, that's the main downside.  My argument is that there are so many recurring costs (privacy risks shipped, important features delayed/prevented, etc.) that we should seriously consider just accepting that downside even though it'll upset some users.

Blink>DOM might be okay, but we are thinking that we should move VisitedLinkStte.cpp to other directory out of core/dom. :)

See https://docs.google.com/a/google.com/spreadsheets/d/1OydPU6r8CTj8HC4D9_gVkriJETu1Egcw2RlajYcw3FM/edit?usp=drive_web

previous patch is here: https://bugs.webkit.org/show_bug.cgi?id=37443