Use the Feature Policy for provisioning access to VR from embedded content/frames

[foolip]

https://html.spec.whatwg.org/multipage/embedded-content.html#allowed-to-use

The language in https://w3c.github.io/webvr/#allowvr-attribute doesn't say to traverse all frames to the top-level frame, so it's easy to circumvent by just creating an iframe with the attribute on it.

As with w3c/mediacapture-main#268 (comment) I wonder if permission delegation might work here.

[toji]

Thanks! I intended to bring up the idea of using permission delegation (spec link for easy reference) with the other implementors today. Seems like a more forward looking path than the allowvr attribute.

[foolip]

Yes, I am secretly hoping that allowfullscreen will be the only attribute of this sort ever shipped, but of course if you think an allowvr still makes the most sense in the end, then that's fine.

[toji]

My only concern is that it's not clear to me how committed the other implementing browser are to the permission delegation spec. If nobody strenuously objects, I'm happy to go that route.

[raymeskhoury]

Just a heads up that we're looking at getting this added to the initial version of Feature Policy (the permission delegation successor) right now.

[ddorwin]

Feature Policy seems like the general direction. See also https://groups.google.com/a/chromium.org/d/msg/blink-dev/vM3RM1OQNFU/FcuMLjVfAgAJ for implementation issues with the iframe attribute.

In the meantime, please remove the allowvr text or mark it as under reconsideration / do not implement.

[ddorwin]

w3c/webappsec-permissions-policy#49 tracks this on the Feature Policy side.

[cvan]

Just commenting so we don't forget that the spec needs to be updated to reflect the Feature Policy dependency. This in scope for 1.1, 1.2?

Also, do we want to call the feature vr or webvr? I say vr, per navigator.vr (#116/#152).

// vr
<iframe enable="vr" src="example.html"></iframe>
<iframe featurepolicy='{"vr": ["*"]}' src="example.html"></iframe>

// or `webvr` …
<iframe enable="webvr" src="example.html"></iframe>
<iframe featurepolicy='{"webvr": ["*"]}' src="example.html"></iframe>

On a related note, something we brought up at the last/first W3C Workshop: permission to access WebVR may want to be managed by the user/UA. If so, I'd recommend adding "vr" to the enum in the Permissions API. So, you'd invoke it like this:

navigator.permissions.query({name: 'vr'}).then(result => {
  if (result.state === 'granted') {
    // Enter VR.
  } else {
    // Unable to enter VR.
  }
  result.addEventListener('change', () => {
    if (result.state === 'granted') {
      // Can enter VR.
    } else {
      // Unable to enter VR.
    }
  });
});

[clelland]

In the latest drafts for Feature Policy, you'd enable it in a cross-origin frame with something like:

<iframe allow="vr" src="https://other.com/example.html">
<iframe allow="webvr" src="https://other.com/example.html">

(depending on the final feature name), or by including an HTTP header like

FeaturePolicy: {"vr": ["*"]}

in the parent document.

Same-origin frames would be able to use VR if the parent document can.

(That shouldn't be necessary to spell out in this doc, though.)

This spec, I think, will need to declare "vr" or "webvr" to be the keyword for the WebVR feature, and that its default allowlist is ["self"] -- which will enable the feature at the top-level, but block by default in cross-origin frames.

This spec will also need to declare when to call into allowed-to-use, and what to do if that algorithm returns false -- whether navigator.vr.getDisplays() returns an empty array, or navigator.vr.getAvailability should return false as well, or something else.

[toji]

Thanks for the update @clelland! Do you have any examples of other specs that declare the keyword and default allow list, or is this new enough syntax that it hasn't propagated out to other specs yet? (Mostly just looking for some reference material)

[clelland]

It's new enough that other specs are just starting to look at how to integrate with it; for now, I'm maintaining a list of features and the rough wording that I'd expect to see eventually merged as an appendix to the feature policy spec. That spec is just live now, on https://wicg.github.io/feature-policy/ -- https://wicg.github.io/feature-policy/#defined-features is what I've been using for external specs. Let me know if that works for you, or if we need to come up with something more precise.

…

On Feb 24, 2017 6:49 PM, "Brandon Jones" ***@***.***> wrote: Thanks for the update @clelland <https://github.com/clelland>! Do you have any examples of other specs that declare the keyword and default allow list, or is this new enough syntax that it hasn't propagated out to other specs yet? (Mostly just looking for some reference material) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#86 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACzHfsOkZhC4SCQa4j1Z3XcAfL5TFO0ks5rf2yIgaJpZM4KBXQS> .

[cvan]

Thanks! See update here too: w3c/webappsec-permissions-policy#38 (comment)

[NellWaliczek]

Addressed by w3c/webappsec-permissions-policy#49