Same origin navigations

[jonathanKingston]

Thanks for the session at TPAC yesterday, we discussed this in the meeting but I wanted to highlight the discussion here a little.

In the triple keying approach outlined in the explainer, same origin links wouldn't be considered visited if they came from a different origin.

The example was something like:

• User is visiting example.com which links to https://en.wikipedia.org/wiki/history_of_seville and they click.
• User is visits example2.com which links to https://en.wikipedia.org/wiki/history_of_spain and they click.
• The history of spain page links to https://en.wikipedia.org/wiki/history_of_seville

In the above case the link wouldn't be considered visited.

If we wish to support this case, we should be careful to:

• Store this data separately to the originator visited link store.
  • A third party to the site shouldn't be able to impact the visited state of the first party as this would violate SOP.
• This should continue to be triple keyed to prevent it being used as a 3p storage device.
  • This is most likely to only apply in the main frame case but also could happen with frame navigations too.

[yoavweiss]

Naively, I would think that if we're keying on top-level origin (A), frame origin (B) and link URL (C/foobar), we could add 2 entries to the cache for each link click: (A, B, C/foobar) and (C, C, C/foobar)

That way, same-origin links would Just Work™ (without exposing any extra information to origin C, as it can already store that information relative to the user's credentials).