-
Notifications
You must be signed in to change notification settings - Fork 522
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
Comments
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. |
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 |
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. |
So what happens in WebKit, where the demo logs "showing" first? |
@annevk can you comment on what WebKit does here? |
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
The text was updated successfully, but these errors were encountered: