W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > September 2016

Re: [mediacapture-main] Reinstate strong language on permission ending when tracks stop, lost by editorial mistake

From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
Date: Thu, 08 Sep 2016 16:57:08 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-245664662-1473353826-sysbot+gh@w3.org>
The ["current settings 
object"](https://html.spec.whatwg.org/multipage/webappapis.html#current-settings-object)
 comes from HTML, and it'll be different on a different tab or iframe,
 or after a reload. ["Realms"](https://tc39.github.io/ecma262/#realm),
 [settings 
objects](https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object),
 and 
[globals](https://html.spec.whatwg.org/multipage/webappapis.html#global-object)
 are 
[1-1-1](https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-objects).
 There's a PR waiting for an LGTM to make the use of settings objects 
a little more explicit: https://github.com/w3c/permissions/pull/114.

[Request permission to 
use](https://w3c.github.io/permissions/#request-permission-to-use) 
depends on [permission 
state](https://w3c.github.io/permissions/#permission-state), but it 
doesn't update the permission state unless the UA thinks that reflects
 user intent. That allows Firefox's geolocation behavior, where you 
can get a location back, and then get a prompt on the next request. 
@stefhak's example of closing the lid, driving for a while, and then 
wanting geolocation to prompt again, would have to be handled through 
["new information about the user's 
intent"](https://w3c.github.io/permissions/#new-information-about-the-users-intent).

As @jan-ivar said, the `getUserMedia()` behavior of allowing 
subsequent calls to succeed, *until the script calls `.stop()`*, at 
which point calls prompt again, doesn't automatically fall out of the 
permissions spec's wording. I think you handle that with wording like 
[`revoke()`](https://w3c.github.io/permissions/#dom-permissions-revoke)
 uses: you explicitly say that "calls to `.stop()` are considered to 
be new information that the user intends to revoke permission to use 
this camera/mic/whatever" (on the assumption that they're in response 
to interaction with webpage UI). 
https://github.com/w3c/permissions/pull/125/commits/4ed0e25fe66a8989da8bccb9ade8d386d61e43a4#diff-ec9cfa5f3f35ec1f84feb2e59686c34dR582
 has some updated wording for `revoke()` that you should also look at 
before wording this.

-----

I think Edge's https behavior is allowed in the February version of 
the spec. They have a "stored permission" that happens to be 
auto-revoked when the realm goes away. Even if we treat [Best Practice
 2: Stored 
Permissions](https://w3c.github.io/mediacapture-main/archives/20160222/getusermedia.html#stored-permissions)
 as normative, it says

> It is a User Agent choice whether it offers functionality to store 
permission to each device separately, all devices of a given class, or
 all devices; the choice needs to be apparent to the user, and 
permission must have been granted for the entire set whose permission 
is being stored, …

That says that it needs to be apparent to the user whether the UA is 
going to store each device separately, a class at a time, vs all 
devices together, and doesn't apply to the part of Edge's https 
behavior that we're talking about.

-- 
GitHub Notification of comment by jyasskin
Please view or discuss this issue at 
https://github.com/w3c/mediacapture-main/issues/387#issuecomment-245664662
 using your GitHub account
Received on Thursday, 8 September 2016 16:57:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:30 UTC