Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replacing 'allowusermedia' with policy 'feature's 'camera' and 'microphone'. #440

Closed
wants to merge 4 commits into from

Conversation

stefhak
Copy link
Contributor

@stefhak stefhak commented Mar 30, 2017

Fixes #434

Very first draft - do not merge!!

@stefhak stefhak requested a review from adam-be March 30, 2017 14:15
@raymeskhoury
Copy link

@stefhak thanks so much for looking at this. Sorry for the delay I've been OOO.

@clelland would be best to take a look at the details of the spec integration. I'm definitely not well versed with this spec, but at a high level though I'm wondering if these checks should be done at the same point that we check to see whether the user agent has permission. These feature policy features align exactly with permissions defined in the permissions API (for camera, mic, speakers) and so ideally we want the behavior of this API to be the same whether camera was disabled by feature policy or by the user agent. What do you think?

@stefhak
Copy link
Contributor Author

stefhak commented Apr 4, 2017

@raymeskhoury I think you are right. I need to check a bit more, but my gut feeling is that we should (as you say) talk about whether the app has permission which in turn depends on whether or not it is allowed-to-use rather than involving allowed-to-use here as I've done i the PR.

@@ -195,6 +195,14 @@
permissions <a href=
"https://github.com/w3c/permissions/issues/62">issue 62</a>.</p>
</dd>
<dt>Features</dt>
<dd>
<p>The terms <dfn><a href="https://wicg.github.io/feature-policy/#feature">feature</a></dfn>,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been changed in the most recent draft to "policy-controlled feature", so that we don't camp on such a generic term.

@@ -3543,6 +3551,17 @@
<p>The <code>getSupportedConstraints</code> method is provided to allow
the application to determine which constraints the User Agent
recognizes.</p>
<h4>Feature Definitions</h4>
<p>The <dfn data-lt-nodefault="" data-lt="camera" id=
"camera">camera</dfn> <a>feature</a> controls access to

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above -- I think you'd need to word it something like

<dfn data-lt="camera">camera</dfn> is a <a>policy-controlled feature</a>,
which controls access to video input devices.

@aboba aboba closed this Oct 19, 2017
@aboba aboba reopened this Nov 7, 2017
@aboba
Copy link
Contributor

aboba commented Nov 7, 2017

TPAC feedback indicates that Chrome, Firefox and Safari are considering implementing this.

@raymeskhoury
Copy link

raymeskhoury commented Nov 7, 2017

We've implemented this in Chrome, it's going out in M64: https://dev.chromium.org/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes

I have a PR up on the Permissions spec:
w3c/permissions#163
If we can merge that, then we will get basic integration without needing a change to the mediacapture spec, because it already queries the permissions spec for access. We would only need to do something if we wanted to a custom error message but it may be OK as a first cut.

@alvestrand
Copy link
Contributor

Let's close this one and wait for w3c/permissions#163 to merge.

@alvestrand alvestrand closed this Nov 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants