Focus control in privacy test steps

[wangw-1991]

Let’s consider a special case. As shown in the picture, Main frame A embedded iframe B, iframe B embedded iframe C, iframe C embedded iframe D. Main frame A and iframe C are same -origin, iframe B and iframe D are same-origin, but Main frame A and iframe B are cross-origin. According to the spec, If we focus on iframe B, observer in Iframe D can receive PressureRecord, right? Because top-level browsing context has system (system focus is actually per window, so if the iframe has focus, the top-level browsing context will have system focus) and the document (iframe D) is same-origin with focused document (iframe B).

[wangw-1991]

@kenchris @anssiko @rakuco @arskama Hi, all. PTAL, thanks.

[wangw-1991]

I checked this in GenericSensor, current focused frame and frames that are same-origin with the current focused frame can get sensor readings.

[arskama]

As far as I understand the specs, you are correct and I don't see any issue with this. The question I would ask is: Should them the main frame, be always updated by its own observer even if the embedded iframe as a different origin. I would say yes, but that is not specified so. (as I understood the specs... :) ) @kenchris @anssiko

[kenchris]

I think this is going to be limiting. We want to allow people to embed SDKs like Zoom or Whereby, and we already force them to explicitly set a security polity to allow them to have access. I would say that if they or any parent have focus they should be allowed to have access to the readings

in pseudo code:

initialFrame = frame;

// all parents must allow the policy.
do {
  if (! frame->policyAllowsComputePressure) return false;
} while (frame = frame->parent)

// One parent must have focus
frame = initialFrame;
do {
  if (frame->hasfocus) return true;
 } while (frame = frame->parent)

return false

[wangw-1991]

So an iframe can access to the readings only when any parent has focus and it is same-origin with the focused parent frame, right?

[kenchris]

@anssiko what do you think about this approach?

[anssiko]

This, as any other new API, should align with the established practice. I'm hearing the use case at hand is an SDK embedded in an iframe. You can look at how we did that in the Battery Status API for the YT embed.

For novel approaches, I recommend you seek explicit feedback from the relevant horizontal group(s). You can find the in-flight review requests from https://github.com/w3c/compute-pressure/issues/177 and you can augment them with this design consideration. The requests are GH issues filed against each horizontal group's repo.

[kenchris]

Let’s consider a special case. As shown in the picture, Main frame A embedded iframe B, iframe B embedded iframe C, iframe C embedded iframe D. Main frame A and iframe C are same -origin, iframe B and iframe D are same-origin, but Main frame A and iframe B are cross-origin. According to the spec, If we focus on iframe B, observer in Iframe D can receive PressureRecord, right? Because top-level browsing context has system (system focus is actually per window, so if the iframe has focus, the top-level browsing context will have system focus) and the document (iframe D) is same-origin with focused document (iframe B).

According to the spec (as it is written right now), only the focused frame (and anyone same origin with it's origin) can receive events. The frame also has to have all its parents having granted permission policy (auto granted for top level frame)

[kenchris]

Let focusedDocument be the topLevelBC's currently focused area's node document.

// calls this algo: https://html.spec.whatwg.org/multipage/interaction.html#currently-focused-area-of-a-top-level-browsing-context

The currently focused area of a top-level traversable traversable is the focusable area-or-null returned by this algorithm:

If traversable does not have system focus, then return null. // Our spec also has that check for top frame, so we could remove that

Let candidate be traversable's active document.

While candidate's focused area is a navigable container with a non-null content navigable: set candidate to the active document of that navigable container's content navigable.

// navigable container == main frame and iframes (and maybe portals in the future) so it iterates to the inner most focused frame

If candidate's focused area is non-null, set candidate to candidate's focused area.

Return candidate.

[kenchris]

Looking over the spec, I think it works as intended. But I think we could discuss whether we should open it up more.

Like currently we try to make sure that only one origin get's data at one time, but maybe it is OK that more do if explicitly allowed by setting security policy

[wangw-1991]

Let’s consider a special case. As shown in the picture, Main frame A embedded iframe B, iframe B embedded iframe C, iframe C embedded iframe D. Main frame A and iframe C are same -origin, iframe B and iframe D are same-origin, but Main frame A and iframe B are cross-origin. According to the spec, If we focus on iframe B, observer in Iframe D can receive PressureRecord, right? Because top-level browsing context has system (system focus is actually per window, so if the iframe has focus, the top-level browsing context will have system focus) and the document (iframe D) is same-origin with focused document (iframe B).

According to the spec (as it is written right now), only the focused frame (and anyone same origin with it's origin) can receive events. The frame also has to have all its parents having granted permission policy (auto granted for top level frame)

Yes, permission policy has already been considered. If an iframe is not allowed by permission policy, observer in the frame can't call observe() successfully (see code). There are two issues to be determined：

1. Is cross-origin frame allowed to receive events if permission policy granted? (Is iframe C allowed to receive events if we focus on iframe B?) This is not allowed in GenericSensor.
2. Do we need to consider the relationship between focused_frame and this_frame? (Is iframe B allowed to receive events if we focus on iframe D? Or is iframe D allowed to receive events if we focus on iframe B?) This is not considered in GenericSensor.

[kenchris]

Is cross-origin frame allowed to receive events if permission policy granted? (Is iframe C allowed to receive events if we focus on iframe B?) This is not allowed in GenericSensor.

Only frame C will get access as well as any other document sharing same-origin

[kenchris]

Do we need to consider the relationship between focused_frame and this_frame? (Is iframe B allowed to receive events if we focus on iframe D? Or is iframe D allowed to receive events if we focus on iframe B?) This is not considered in GenericSensor.

Same as above, only the focused frame (which has allowed policy) and same origin origins can get events

[arskama]

@wangw-1991 If you consider this as fixed, please close. Thanks

[wangw-1991]

@wangw-1991 If you consider this as fixed, please close. Thanks

Thanks for reminding.