iFrame support

[kenchris]

Use-case from @fideltian: The Zoom SDK is commonly used in iframes so we need to investigate if/how we can support the feature in iframes and what it means for privacy

@anssiko

[anssiko]

One possible solution is to use the allow attribute of the iframe element.

This would require 3rd party developers integrating Zoom SDK via an iframe to update their HTML slightly and add the allow attribute to make use of the Compute Pressure API. I believe this is the most architecturally clean way to solve this issue.

<iframe src="https://example.org/app" allow="foobar"></iframe>

If the allow attribute is not defined, all the things would work except the Compute Pressure API would not be enabled.

@fideltian your thoughts?

[kenchris]

@anssiko do you know of any spec that does this that I can refer to for spec text?

[kenchris]

OK I assume this is what I need: https://www.w3.org/TR/screen-wake-lock/#policy-control

Plus this:

If document is not [allowed to use] the [policy-controlled feature] named "screen-wake-lock", return [a promise rejected with] a "[NotAllowedError]" [DOMException].

Would need to make that work with workers as well

[anssiko]

@anssiko do you know of any spec that does this that I can refer to for spec text?

The list of Policy Controlled Features is probably the best resource.

[kenchris]

I have run into some challenges while trying to support this.

First of all, the permission policy doesn't support workers yet and it shouldn't be inherited from the creator document of the worker according to discussions: w3c/webappsec-permissions-policy#207

Secondly, we say that top level docs should be focused (focusable area) and workers should have a focused document in their ownet set. This is much harder to spec

[kenchris]

Iframes should work now, thought we probably need a policy for the workers but that is not yet supported so filed #110