Add Scroll Margin to Intersection Observer #511

tcaptan-cr · 2023-08-30T00:33:13Z

Closes #431

The following tasks have been completed:

Modified Web platform tests (link to pull request)

Implementation commitment:

Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=1469500)

Preview | Diff

tcaptan-cr · 2023-08-31T00:51:58Z

PTAL @emilio @zcorpan @smfr

marcoscaceres · 2023-09-01T22:38:54Z

Thanks @tcaptan-cr... just to make this even easier to review, would you mind splitting out the Makefile into its own PR (and possibly even the xref bikeshed fixes if it's not a huge pain?)

marcoscaceres · 2023-09-01T22:40:31Z

Also, @tcaptan-cr, you are committing to becoming co-Editor? That's ok... but just making sure you are 100% ok with taking on co-ownership. I'll need to announce that to the working group.

tcaptan-cr · 2023-09-02T00:25:57Z

Thanks @tcaptan-cr... just to make this even easier to review, would you mind splitting out the Makefile into its own PR (and possibly even the xref bikeshed fixes if it's not a huge pain?)

I split the makefile into this PR, and the bikeshed fixes into this PR

szager-chromium · 2023-09-07T19:57:28Z

FYI, this change was reviewed in tcaptan's mirror:

tcaptan-cr#1

szager-chromium

lgtm

tcaptan-cr · 2023-09-08T23:03:45Z

Also, @tcaptan-cr, you are committing to becoming co-Editor? That's ok... but just making sure you are 100% ok with taking on co-ownership. I'll need to announce that to the working group.

Yes, I am 100% OK with taking on co-ownership.

emilio

Looks good to me, with that bit clarified. Thanks for doing this!

emilio · 2023-09-08T23:30:48Z

index.bs

@@ -630,9 +673,11 @@ run these steps:
 		of the {{document}}, and update |container| to be
 		the <a>browsing context container</a> of |container|.
 	2. Map |intersectionRect| to the coordinate space of |container|.
-	3. If |container| has a <a>content clip</a> or a css <a>clip-path</a> property,
+	3. If |container| is scrollable, apply the {{IntersectionObserver}}’s


Would be great to have a more precise definition of scrollable, or a link to the relevant CSS spec. Otherwise whether this applies to overflow: hidden or not is a bit questionable, right?

Good point. How about using CSS scroll-container?

Sounds good, let's make sure that we test overflow: hidden then, and confirm that it does apply.

Thanks Emilio!
The tests I added in my PR for the wpt tests use overflow: hidden. For example the scroll-margin.html test.
I confirmed these pass with my prototype.

emilio

Let's fix the link. Pretty sure there's a better way of doing this.

Same for the margin property link, which I hadn't noticed.

Also, can you rebase to remove the merge commit?

index.bs

tcaptan-cr · 2023-09-11T19:29:06Z

Let's fix the link. Pretty sure there's a better way of doing this.

Same for the margin property link, which I hadn't noticed.

Also, can you rebase to remove the merge commit?

Done.

… section

…er section

tcaptan-cr · 2023-09-14T01:09:03Z

lgtm

Thanks Stefan!

tcaptan-cr · 2023-09-14T01:09:26Z

Looks good to me, with that bit clarified. Thanks for doing this!

Thanks Emilio!

SHA: f22fbf4 Reason: push, by tcaptan-cr Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

letitz · 2023-09-19T15:10:10Z

Hi there,

Chromium web platform security reviewer here. I've been looking at the I2P for this change and have a few questions, mostly to clarify my understanding:

Why does this rely on same-origin-domain-ness of elements? I see the spec mentions that this only matters for implicit intersection observers, but I don't have context on why this matters (or why origin-domain was chosen over origin, the usual security boundary).
I've given this some thought through the lens of xs-leaks, and I believe this makes no material difference to that kind of attack, mostly because scrollMargin does not apply to iframes. This means that even if the intersection rectangle has been expanded by scrollMargin, it will be clipped to the iframe's viewport on the way up the tree, so a malicious iframe will not be able to determine more than "am I visible" (modulo rootMargin, but it only applies for same-origin-domain elements). Does this match your understanding?
I guess the iframe could be contained in a scroll container itself, and scrollMargin would affect that? This seems related to my next question:
In Ability to have automatic rootMargin for all nested scroll containers #431 (comment) it was mentioned that scrollMargin should stop at cross-origin iframe boundaries. What was meant by that, and is that specified in this PR? I cannot find a reference.
I cannot find in the spec algorithms where it is specified that scrollMargin only applies to same-origin-domain elements. Is the plain english paragraph normative here?

szager-chromium · 2023-09-20T18:51:06Z

This feature is modelled after the existing rootMargin feature, and it has basically the same set of security/privacy concerns...

Only implicit-root observers are subject to these restrictions, because only implicit-root observers communicate geometry information that crosses iframe boundaries. Quoting from the spec:

"Any target of an explicit root observer is also a same-origin-domain target, since the target must be in the same document as the intersection root."

scrollMargin does indeed apply to the top-level scrolling viewport of the iframe! No distinction is made between the document-level scrolling viewport and a scrollable element. That is why scrollMargin is restricted to explicit-root observers and same-origin-domain implicit-root observers.
The comment in that spec issue is simply stating the requirement that scrollMargin cannot probe the geometry of the embedding page, in the same way that rootMargin cannot. This is commensurate with the above explanations.
Beginning at line 291 in index.bs, this PR adds:

"These offsets are only applied when handling same-origin-domain targets;
for cross-origin-domain targets they are ignored."

letitz · 2023-09-22T10:50:32Z

Thanks for the answers!

This feature is modelled after the existing rootMargin feature, and it has basically the same set of security/privacy concerns...

Right, and I don't have context on those concerns, hence my questions :)

Only implicit-root observers are subject to these restrictions, because only implicit-root observers communicate geometry information that crosses iframe boundaries. Quoting from the spec:

"Any target of an explicit root observer is also a same-origin-domain target, since the target must be in the same document as the intersection root."

I see, and this is actually specified by step 2.2.2 of the Run the Update Intersection Observations Steps algorithm.

I'm still left with my questions:

Why does this matter (for explicit root observers)?
Why choose same-origin-domain instead of same-origin? The latter is the web's usual security boundary.

scrollMargin does indeed apply to the top-level scrolling viewport of the iframe! No distinction is made between the document-level scrolling viewport and a scrollable element. That is why scrollMargin is restricted to explicit-root observers and same-origin-domain implicit-root observers.

Oh, I see. I was looking at step 3.1 of the compute the intersection algorithm, but step 3.3 also applies because an iframe is a scroll container?

The comment in that spec issue is simply stating the requirement that scrollMargin cannot probe the geometry of the embedding page, in the same way that rootMargin cannot. This is commensurate with the above explanations.

I see, this is what is mentioned in the Privacy and Security section. Can you help me understand the attack here? How would the embeddee learn about its embedder's geometry using rootMargin or scrollMargin?

That section mentions that IntersectionObserver does not allow new methods of detecting intersection, only making existing hacks more usable. Is this "compatibility goal" what led to the choice of same-origin-domain instead of same-origin?

Beginning at line 291 in index.bs, this PR adds:

"These offsets are only applied when handling same-origin-domain targets; for cross-origin-domain targets they are ignored."

Right, this was what I referred to as "the plain english paragraph". IIUC this does not correspond to any step in the compute the intersection algorithm? I was expecting to find something there.

szager-chromium · 2023-09-26T21:18:43Z

Only implicit-root observers are subject to these restrictions, because only implicit-root observers communicate geometry information that crosses iframe boundaries. Quoting from the spec:

"Any target of an explicit root observer is also a same-origin-domain target, since the target must be in the same document as the intersection root."

I see, and this is actually specified by step 2.2.2 of the Run the Update Intersection Observations Steps algorithm.

I'm still left with my questions:

Why does this matter (for explicit root observers)?

Sorry, I don't understand your question. Why does what matter for explicit root observers? Explicit root observers can use scrollMargin without restriction; implicit root observers can use scrollMargin conditionally.

Why choose same-origin-domain instead of same-origin? The latter is the web's usual security boundary.

Here's the previous discussion.

scrollMargin does indeed apply to the top-level scrolling viewport of the iframe! No distinction is made between the document-level scrolling viewport and a scrollable element. That is why scrollMargin is restricted to explicit-root observers and same-origin-domain implicit-root observers.

Oh, I see. I was looking at step 3.1 of the compute the intersection algorithm, but step 3.3 also applies because an iframe is a scroll container?

Yes, that's right.

The comment in that spec issue is simply stating the requirement that scrollMargin cannot probe the geometry of the embedding page, in the same way that rootMargin cannot. This is commensurate with the above explanations.

I see, this is what is mentioned in the Privacy and Security section. Can you help me understand the attack here? How would the embeddee learn about its embedder's geometry using rootMargin or scrollMargin?

The general idea is that the attacker would create a bunch of IntersectionObservers, each with slightly different rootMargin and perhaps a range of thresholds; and that by analyzing the received notifications, it would be possible to deduce the size of the containing viewport. I unfortunately can't find a concrete exploit, but this came up during the early days of developing the API.

Beginning at line 291 in index.bs, this PR adds:

"These offsets are only applied when handling same-origin-domain targets; for cross-origin-domain targets they are ignored."

Right, this was what I referred to as "the plain english paragraph". IIUC this does not correspond to any step in the compute the intersection algorithm? I was expecting to find something there.

Ah, that's a good point. There is an explanation of the same-origin-domain restriction on rootMargin which is reachable from the algorithm description; but the equivalent explanation for scrollMargin is not directly reachable from the algorithm description. I think this content, which is currently intermingled with the definition of root intersection rect, should be moved to the definition of scrollMargin:

When calculating a scrollport intersection rectangle for a same-origin-domain target, the rectangle is expanded according to the offsets in the IntersectionObserver’s [[scrollMargin]] slot in a manner similar to CSS’s margin property, with the four values indicating the amount the top, right, bottom, and left edges, respectively, are offset by, with positive lengths indicating an outward offset. Percentages are resolved relative to the width of the undilated rectangle.

NOTE: scrollMargin affects the clipping of target by all scrollable ancestors up to and including the intersection root. Both the scrollMargin and the rootMargin are applied to a scrollable intersection root’s rectangle.

zcorpan · 2023-09-27T16:58:15Z

On same-origin-domain vs same-origin, it only matters when using document.domain (which is going away). If the pages involved have used document.domain so they're same-origin-domain, they can access each other's DOM.

letitz · 2023-09-28T10:22:52Z

Thanks for the answers and pointers, this is super helpful.

Using same-origin-domain makes sense for this, though it would always be better to avoid introducing a new dependency on document.domain. If y'all would be happy with same-origin, I think it would be a nicer fit for today's web platform.

+1 to amending the spec to extend the same-origin-domain restriction from rootMargin to scrollMargin more explicitly.

I have one remaining clarification question: the intent of the same-origin-domain restriction is to prevent scrollMargin from applying to scroll containers (including iframe documents) that are cross-origin-domain with the observer, right? That is, if A embeds B embeds A, the grandchild A cannot learn about the geometry of B by using scrollMargin, even though it is same-origin with the top-level document. Is that correct?

progers · 2023-10-10T23:36:55Z

I don't think there is any new information being exposed that is not already in rootMargin. Do you think there may be something?

the intent of the same-origin-domain restriction is to prevent scrollMargin from applying to scroll containers (including iframe documents) that are cross-origin-domain with the observer, right?

Yes, this is my understanding.

letitz · 2023-10-12T15:48:06Z

I don't think there is any new information being exposed that is not already in rootMargin. Do you think there may be something?

I think I'm now convinced there isn't. Since scrollMargin applies to many more elements than rootMargin, I was worried there could be.

the intent of the same-origin-domain restriction is to prevent scrollMargin from applying to scroll containers (including iframe documents) that are cross-origin-domain with the observer, right?

Yes, this is my understanding.

Thanks for confirming.

zcorpan · 2023-10-19T11:32:34Z

There were no bugs filed for Gecko or WebKit. Please keep that in the issue template in the future.

I've now filed:

This was referenced Sep 2, 2023

Add Makefile for Intersection Observer #512

Merged

Fix bikeshed errors #513

Merged

tcaptan-cr force-pushed the tcaptan/scroll-margin branch from 7a20e51 to 3560926 Compare September 2, 2023 00:21

szager-chromium approved these changes Sep 7, 2023

View reviewed changes

emilio approved these changes Sep 8, 2023

View reviewed changes

emilio requested changes Sep 11, 2023

View reviewed changes

index.bs Outdated Show resolved Hide resolved

tcaptan-cr force-pushed the tcaptan/scroll-margin branch from 5985bf2 to ddbd4ad Compare September 11, 2023 19:27

tcaptan-cr requested a review from emilio September 12, 2023 20:11

tcaptan-cr added 15 commits September 12, 2023 15:03

Added name to editors.

45f1fe2

Added ScrollMargin definitions to IntersectionObserver interface section

b091baa

Added ScrollMargin definitions to IntersectionObserverInit dictionary…

c707550

… section

Added ScrollMargin definitions to Initialize a new IntersectionObserv…

1c15e45

…er section

Added ScrollMargin definitions to IntersectionObserver section

5601bb1

Add ScrollMargin to Intersection Computation section

84bb858

Add ScrollMargin to Privacy and Security section

7db7140

Change scrollable intersection rectangles to scrollport

926b684

Link 'margin' to css-box-3/#margins

e31b8a2

Clarified application of both scroll and root margin to root rect

7b0ce86

Update scrollMargin to match rootMargin

b238f1a

Fixed grammar and missed matching to rootMargin

f4d956e

Changed 'boxes' to 'clip rects' in scroll margin def

05bfe16

Clarified scrollable container

c535f7e

Simplified margin and scroll container links

41baa1f

tcaptan-cr force-pushed the tcaptan/scroll-margin branch from 72b81b1 to 41baa1f Compare September 12, 2023 22:07

emilio approved these changes Sep 13, 2023

View reviewed changes

tcaptan-cr merged commit f22fbf4 into w3c:main Sep 14, 2023
2 checks passed

github-actions bot added a commit that referenced this pull request Sep 14, 2023

Add Scroll Margin to Intersection Observer (#511)

97db3ba

SHA: f22fbf4 Reason: push, by tcaptan-cr Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

tcaptan-cr mentioned this pull request Sep 28, 2023

Clarify scrollMargin details #515

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Scroll Margin to Intersection Observer #511

Add Scroll Margin to Intersection Observer #511

tcaptan-cr commented Aug 30, 2023 •

edited

Loading

tcaptan-cr commented Aug 31, 2023

marcoscaceres commented Sep 1, 2023

marcoscaceres commented Sep 1, 2023 •

edited

Loading

tcaptan-cr commented Sep 2, 2023

szager-chromium commented Sep 7, 2023

szager-chromium left a comment

tcaptan-cr commented Sep 8, 2023

emilio left a comment

emilio Sep 8, 2023

tcaptan-cr Sep 11, 2023

emilio Sep 11, 2023

tcaptan-cr Sep 11, 2023

emilio left a comment

tcaptan-cr commented Sep 11, 2023

tcaptan-cr commented Sep 14, 2023

tcaptan-cr commented Sep 14, 2023

letitz commented Sep 19, 2023

szager-chromium commented Sep 20, 2023 •

edited

Loading

letitz commented Sep 22, 2023

szager-chromium commented Sep 26, 2023

zcorpan commented Sep 27, 2023

letitz commented Sep 28, 2023

progers commented Oct 10, 2023

letitz commented Oct 12, 2023

zcorpan commented Oct 19, 2023

Add Scroll Margin to Intersection Observer #511

Add Scroll Margin to Intersection Observer #511

Conversation

tcaptan-cr commented Aug 30, 2023 • edited Loading

tcaptan-cr commented Aug 31, 2023

marcoscaceres commented Sep 1, 2023

marcoscaceres commented Sep 1, 2023 • edited Loading

tcaptan-cr commented Sep 2, 2023

szager-chromium commented Sep 7, 2023

szager-chromium left a comment

Choose a reason for hiding this comment

tcaptan-cr commented Sep 8, 2023

emilio left a comment

Choose a reason for hiding this comment

emilio Sep 8, 2023

Choose a reason for hiding this comment

tcaptan-cr Sep 11, 2023

Choose a reason for hiding this comment

emilio Sep 11, 2023

Choose a reason for hiding this comment

tcaptan-cr Sep 11, 2023

Choose a reason for hiding this comment

emilio left a comment

Choose a reason for hiding this comment

tcaptan-cr commented Sep 11, 2023

tcaptan-cr commented Sep 14, 2023

tcaptan-cr commented Sep 14, 2023

letitz commented Sep 19, 2023

szager-chromium commented Sep 20, 2023 • edited Loading

letitz commented Sep 22, 2023

szager-chromium commented Sep 26, 2023

zcorpan commented Sep 27, 2023

letitz commented Sep 28, 2023

progers commented Oct 10, 2023

letitz commented Oct 12, 2023

zcorpan commented Oct 19, 2023

tcaptan-cr commented Aug 30, 2023 •

edited

Loading

marcoscaceres commented Sep 1, 2023 •

edited

Loading

szager-chromium commented Sep 20, 2023 •

edited

Loading