kyraseevers / Partitioning-visited-links-history

A proposal to partition :visited link history by top-level site and frame origin.
12 stars 1 forks source link

Alternative: make :visited main-frame only #1

Open RByers opened 1 year ago

RByers commented 1 year ago

One variation not discussed is to make :visited apply only in main frames and to main frame history entries. I.e. double-key rather than triple-key.

Do you know of legitimate use cases for :visited in iframes? Any idea if anyone would notice if that stopped working? Would that save much in terms of complexity, RAM etc?

I suppose this could always be a potential future signification based on metrics of the cost / benefit tradeoff right?

NDevTK commented 1 year ago

Chat widgets are sometimes a cross-site iframe with links. Maybe add a permission policy like allow="visited-links"

Seems in its current state sandboxed pages and embeds would get there visited status removed after a reload.

arturjanc commented 1 year ago

Seems in its current state sandboxed pages and embeds would get there visited status removed after a reload.

I think removing state from sandboxed frames is more of a feature than a bug -- documents from opaque origins aren't supposed to maintain state (e.g. no cookies, localStorage, etc.). So it seems reasonable to uphold this for history as well and ignore visitedness from sandbox frames.

Re: limiting :visited to the main frame, I see how it could let us avoid some complexity. However, it would also reduce some of the utility of visitedness, e.g. in scenarios with same-origin iframes; I'm a little worried that it might limit functionality in a way we could avoid if we went with a triple-keyed design (but AFAIK we don't have any data to either support or disprove this).

Another benefit of triple-keying is that it aligns the partitioning design with what we've done for HTTP cache and network state, so there's some conceptual consistency in how we're separating various kinds of client-side state.

NDevTK commented 1 year ago

Yeah feature just wanted to ensure that frame origin stayed included. So no leaking visitedness without allow-same-origin

It seems unlikely visited links can just be disabled for all embeds.

kyraseevers commented 1 year ago

Do you know of legitimate use cases for :visited in iframes? Any idea if anyone would notice if that stopped working?

It seems unlikely visited links can just be disabled for all embeds.

These are great points - I'll add a section to the explainer! Based on the metrics we've collected so far, a non-zero amount of navigations are manual subframe navigations, meaning there are a good chunk of users who click on links in iframes causing them to navigate. And since we believe that styling :visited links is still useful on top-level sites, I think its reasonable to extend that usefulness to these iframes with links as well (i.e. I think these people would notice if they stopped working based on the data I have available).

Would that save much in terms of complexity, RAM etc?

While the number of subframe navigations is non-zero, it is not close to being the majority of navigations. Again, based on early rough metrics analysis, we estimate that many of the triple-keyed entries will be 1:1 with the previous unpartitioned entries (i.e. we don't expect users to click the same link in all N frames on a top-level site. Potential growth will most likely come from users clicking on the same link from multiple top-level sites, but again, we estimate this to be a small number of navigations.)

All this to say - early metrics analysis suggests that triple keying should not produce a significantly larger number of partition keys than double keying.

I suppose this could always be a potential future signification based on metrics of the cost / benefit tradeoff right?

Absolutely - it will be something we examine closely in future experiments!