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

isIntersecting leaks information cross-origin #508

Open
zcorpan opened this issue May 12, 2023 · 5 comments
Open

isIntersecting leaks information cross-origin #508

zcorpan opened this issue May 12, 2023 · 5 comments

Comments

@zcorpan
Copy link
Member

zcorpan commented May 12, 2023

See WICG/scroll-to-text-fragment#79

Even without Text Fragments, IntersectionObserver (and therefore also lazy-loading images) leaks scrolling position in the parent to cross-origin iframes (e.g. ads). The iframe can use IntersectionObserver on itself and detect when the iframe comes into view in the parent.

That might be useful for e.g. ad visibility measurement and other things, but is it OK to leak the user's scroll position from a privacy perspective? Leaking text content in the parent seems not OK (issue #79), but making sites opt out of text fragment scrolling as the only measure doesn't seem ideal since most sites won't know this is an issue and won't opt out. The opt out also disables regular fragment scrolling which may not be desirable.

A more thorough measure could be to make IntersectionObserver in cross-origin iframes act as if the iframe is always visible in the parent. The parent can still communicate iframe visibility to the iframe via postMessage and we could maybe add an opt-in to the current behavior with <iframe allow="...">.

I'm not sure if there are other APIs that are similarly problematic.

cc @emilio @bokand @rniwa

@emilio
Copy link
Collaborator

emilio commented May 12, 2023

You can detect scroll position / visibility of the parent as well in other ways fwiw, I think. For example we'll throttle iframes that aren't visible (I believe this is common across engines), so you can infer if you're visible by measuring the time requestAnimationFrame takes to get called.

@zcorpan
Copy link
Member Author

zcorpan commented May 12, 2023

OK. I assume changing that is not acceptable from a performance perspective?

Demo: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/11660

Works in Firefox, Chrome, Safari. But note that in Safari the first state is showing, suggesting it's not rate-limited until the iframe is first scrolled out of view, right?

@khushalsagar
Copy link
Member

OK. I assume changing that is not acceptable from a performance perspective?

Intuitively yes. We could try to measure but it seems like it would be common for a page to have below the fold iframes which are never brought onscreen because the user leaves before scrolling to them.

@zcorpan
Copy link
Member Author

zcorpan commented May 16, 2024

So what happens in WebKit, where the demo logs "showing" first?

@zcorpan
Copy link
Member Author

zcorpan commented Jun 3, 2024

@annevk can you comment on what WebKit does here?

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

3 participants