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: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Thu, 08 Sep 2016 20:05:54 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-245722868-1473365152-sysbot+gh@w3.org>
> [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.

@jyasskin Thanks, I missed that part. Might it be clearer if we add 
(**in bold**):

*"4. If the user grants permission, return "granted"; otherwise return
 "denied". If the user’s interaction indicates they intend this choice
 to apply to* **this or** *other realms, then treat this as new 
information about the user’s intent for ~~other~~ realms with the same
 origin."* ?

I sort of read "other realms" as an implication that this 
automatically affected the current realm, when it sounds like it only 
affects the current request.

> 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.

Ah, I read it differently, as the paragraph starts with a choice as 
well, so there are two "choices" here (showing whole paragraph):

*"When permission is requested for a device, the User Agent may* 
***choose*** *to store that permission, if granted, for later use by 
the same origin, so that the user does not need to grant permission 
again at a later time. [RTCWEB-SECURITY-ARCH] Section 5.2 requires 
that such storing MUST only be done when the page is secure (served 
over HTTPS and having no mixed content). 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, e.g., to store permission to use all 
cameras the user must have given permission to use all cameras and not
 just one."*

On rereading it, it probably refers to the latter, though how odd to 
require a detail like what parts to store to be apparent, when whether
 *it is being stored* is not?

Then there's the wording of the latter choice itself: "[UA] offers 
functionality to store", which could be read as offering storage as a 
user option only, making the whole thing inherently apparent.

There's additional non-normative support under [Privacy and Security 
Considerations](https://w3c.github.io/mediacapture-main/getusermedia.html#privacy-and-security-considerations)
 which would disqualify Edge's `https` same-realm behavior:

*"In the case of persistent authorization via a stored permission, it 
is important that it is easy to find the list of granted permissions 
and revoke permissions that the user wishes to revoke.*

*Once permission has been granted, the User Agent should make two 
things readily apparent to the user:*

 1. *That the page has access to the devices for which permission is 
given*
 2. *Whether or not any of the devices are presently recording ("on 
air") indicator"*

I checked, and Edge has no permission indicator or list after streams 
have stopped, while the page remains open, so this "temporary stored 
permission" would not qualify.

Then again, this is all non-normative, and would disqualify Chrome 
(persistence is not user apparent) and Firefox ("Always Allow" extends
 to all same-kind devices) as well.

If Edge wants to pursue this instead of going "full-Chrome" I would 
probably support it. :)

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at 
https://github.com/w3c/mediacapture-main/issues/387#issuecomment-245722868
 using your GitHub account
Received on Thursday, 8 September 2016 20:06:01 UTC

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