Scroll as a User Gesture in RWS

[ASHISH932]

Context
The Related-Website-Set (RWS) comprises a network of websites belonging to the same organization. While ensuring stringent data privacy protocols, there is a need to provide organizations with more detailed insights about users within the limited ecosystem that FPS has restricted to.

The Case for Scroll as a User Gesture-

• Problem with Current Tracking: Currently FPS does not allow to capture navigation user activities, like reading an article or browsing through a page.
• Solution: Implementing scroll tracking can bridge this gap. It would allow us to understand how users interact with our content beyond just clicks and page views.

Proposed Implementation Strategy

Event-Driven Tracking: Implement scroll depth tracking to capture user engagement at various thresholds (25%, 50%, 75%, 100%).

[cfredric]

I don't think I understand the problem here. The scroll event already exists; can your pages use that to measure user engagement? If not, why not?

If you're trying to measure reach using a cross-site embed, and your use case doesn't fit into an RWS (e.g. because your embed needs to be embedded on more than 6 sites), then you could consider using other Privacy Sandbox proposals like Shared Storage to measure reach in a privacy-preserving way.

[ASHISH932]

Chris, I am just talking about embedding needs up to 5, but the requestStorageAccessFor method which grants permission to write third-party cookies in a related-site restricted domain needs a user gesture to be triggered which currently is restricted to 'keydown', 'mousedown', 'pointerdown', 'pointerup', 'touchend' events. There are some cases where a User of Site A visits Site B and just scrolls the content of that site and leaves without doing the above-mentioned gesture he would be left untracked or considered as another user by the system.

What I am suggesting is if a user visits some percentage of the page he visits, the requestStorageAccessFor method should be permitted to read and write third-party cookies

[cfredric]

I see, you're asking if RWS can treat scroll events as "user interaction", in addition to the event types that have traditionally counted as user interaction on the web platform (HTML specification), for the purposes of the document.requestStorageAccessFor(origin) (and presumably also document.requestStorageAccess()) APIs.

Unfortunately, I don't think that is a good option, for a few reasons:

• It's not a reliable signal of engagement.
  • Whether a user has to scroll depends on their device's screen size (and the location of the content they're interested in), so a user with a sufficiently large screen would never scroll, and would not be able to scroll. This makes it hard to build a reliable site that relies on scrolling.
  • Similarly, a user who is only interested in content that's above-the-fold would not need to scroll, so the site would not work properly if it relies on scrolling.
• It is unexpected for the user.
  • The web platform has aligned on requiring user activation (using the current definition in the HTML specification) for powerful capabilities. Sharing unpartitioned data will be considered a powerful capability in the near future, since it can be used for pervasive tracking; so it ought to require the same kind of "interactions" that are required for other powerful features in the web platform. However, I think it's extremely unlikely that we could succeed in changing the definition of "user interaction" in the HTML spec to include scrolling, since scroll events have historically not been considered a signal of user interaction, in general.
• It encourages sites to build worse experiences for users.
  • As noted above, a user only needs to scroll if the content they're interested in is currently off-screen. If browsers treated scroll events as user interactions, then sites would be incentivized to put interesting content below the fold, to force the user to scroll (and therefore unlock some powerful feature such as access to unpartitioned data, as described above). This is bad for the user because they had to do more work in order to get to the content they wanted.

There may be more issues that I haven't thought of, but these are enough to convince me that we should not consider scroll events for document.requestStorageAccessFor(origin).

[TheJKFever]

Why do you even need the user interaction at all for requestStorageAccessFor, if you're using RWS, isn't the grant automatic? The documentation reads:

When third-party cookies are blocked but Related Website Sets (RWS) is enabled, Chrome will automatically grant permission in intra-RWS contexts

Are you experiencing otherwise? Or did you not setup RWS and you're just using SAA without RWS?

[cfredric]

The requestStorageAccessFor spec requires a transient user interaction for a successful invocation of the API; please see step 13.7 of the specification.

The documentation reads:

When third-party cookies are blocked but Related Website Sets (RWS) is enabled, Chrome will automatically grant permission in intra-RWS contexts

It's tricky to document this in an unambiguous way, but the auto-granting behavior described here means that Chrome will accept the permission request on the user's behalf (without prompting the user), provided that all of the other requirements (e.g. that the caller is the top-level document, that the requestedOrigin is valid, etc.) are met.

Having a transient user activation is one of the baseline requirements that Chrome checks before deciding to accept or reject the request on the user's behalf.