Bugzilla

(In reply to Johann Hofmann [:johannh] from comment #8)
> > We should open a bug if we don't have one to fix our permissions like I explain in w3c/permissions#185 which appears to be how Chrome works now.
> 
> That GitHub thread seems to conflict with how we want to build our permission model alongside feature policy. With our update, no third party origin will request permission anymore, any permission request will always come from the first party, which then may decide to choose how to distribute the permission. 

How? What "update" are you referring to? On nightly, where I believe feature policy is already enabled, I still see *"Will you share cam & mic with meet.jit.si"* in comment 4. 

I believe the [github thread](https://github.com/w3c/permissions/issues/185) is describing the same goal you describe: that end-users see all requests as coming from the top-level site only. If that's what you mean by *"no third party origin will request permission anymore"*, then I agree. But as an implementation comment, I'm not following who's code will need to deal with comment 4. There's no MediaManager patch coming to have a top-level document ask for gum permissions on behalf of an iframe.

Clearly third parties will still request *camera and microphone* through `getUserMedia`. In the specs—which is what the github thread concerns—[getUserMedia](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevices-getusermedia) calls [request permission to use](https://w3c.github.io/permissions/#requesting-more-permission) in step 5. This means that the latter algorithm's *"realm and other realms with the same origin."* is referring to the document, realm and origin of the *iframe*, not the top-level document. That's where it finds the [policy controlled feature](https://wicg.github.io/feature-policy/#policy-controlled-feature) in [permission state](https://w3c.github.io/permissions/#permission-state). I would similarly expect our permission code to handle this. That's why I reopened the github issue to allow persisting to the granting origin.

>Thus, there will not be two doorhangers or anything, if the first party has access any embeddee may have access if the first party deems it acceptable. Otherwise their permission requests will be blocked outright.

Agreed.

> With feature policy, what you describe in comment 4 isn't our problem anymore. If the user decides to give trust to the first party then there's hardly anything we can do to prevent said part to share the user's camera data with third parties anyway. The site could just stream the keyframes via postMessage or simply send the data directly to the server of the third party.

Agreed once we fix our permission prompt to name the top-level domain, and persist permission to the top-level domain instead of the iframe's. 

Please let me know if this matches your understanding, or if I'm off track.

(In reply to Johann Hofmann [:johannh] from comment #8)
> > We should open a bug if we don't have one to fix our permissions like I explain in w3c/permissions#185 which appears to be how Chrome works now.
> 
> That GitHub thread seems to conflict with how we want to build our permission model alongside feature policy. With our update, no third party origin will request permission anymore, any permission request will always come from the first party, which then may decide to choose how to distribute the permission. 

How? What "update" are you referring to? On nightly, where I believe feature policy is already enabled, I still see *"Will you share cam & mic with meet.jit.si"* in comment 4. 

I believe the [github thread](https://github.com/w3c/permissions/issues/185) is describing the same goal you describe: that end-users see all requests as coming from the top-level site only. If that's what you mean by *"no third party origin will request permission anymore"*, then I agree. But as an implementation comment, I'm not following who's code will need to deal with comment 4. There's no MediaManager patch coming to have a top-level document ask for gum permissions on behalf of an iframe.

Clearly third parties will still request *camera and microphone* through `getUserMedia`. In the specs—which is what the github thread concerns—[getUserMedia](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevices-getusermedia) calls [request permission to use](https://w3c.github.io/permissions/#requesting-more-permission) in step 6.3.5. This means that the latter algorithm's *"realm and other realms with the same origin."* is referring to the document, realm and origin of the *iframe*, not the top-level document. That's where it finds the [policy controlled feature](https://wicg.github.io/feature-policy/#policy-controlled-feature) in [permission state](https://w3c.github.io/permissions/#permission-state). I would similarly expect our permission code to handle this. That's why I reopened the github issue to allow persisting to the granting origin.

>Thus, there will not be two doorhangers or anything, if the first party has access any embeddee may have access if the first party deems it acceptable. Otherwise their permission requests will be blocked outright.

Agreed.

> With feature policy, what you describe in comment 4 isn't our problem anymore. If the user decides to give trust to the first party then there's hardly anything we can do to prevent said part to share the user's camera data with third parties anyway. The site could just stream the keyframes via postMessage or simply send the data directly to the server of the third party.

Agreed once we fix our permission prompt to name the top-level domain, and persist permission to the top-level domain instead of the iframe's. 

Please let me know if this matches your understanding, or if I'm off track.