Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative: make :visited main-frame only #1

Open
RByers opened this issue May 25, 2023 · 4 comments
Open

Alternative: make :visited main-frame only #1

RByers opened this issue May 25, 2023 · 4 comments

Comments

@RByers
Copy link

RByers commented May 25, 2023

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
Copy link

NDevTK commented May 25, 2023

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
Copy link

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
Copy link

NDevTK commented Jun 4, 2023

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
Copy link
Owner

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants