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: Wed, 07 Sep 2016 03:28:14 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-245164716-1473218892-sysbot+gh@w3.org>
> If requesting access to the device doesn't imply changing the stored
 permissions, I think we have consistent specifications (and agreement
 on intended behavior).

@alvestrand I think I see what you mean now, that by saying we skip 
the check for permission when a device is already open, we avoid 
talking about any access implied by a successful request, or the scope
 of such implied access.

But I worry we need to be explicit about this implied access, or 
people will get confused.

I've used your "access" term above, but I don't think people will get 
it. "Permission" and "access" are synonymous to most people, and the 
distinction you're making was too subtle for me until today.

It's confusing terminology anyway to say a request can succeed without
 any permission having been given.

Besides, according to @jyasskin :

> Getting permission to access/use a thing does not imply that this 
permission will be "stored".

So he says permission is implicit in any successful request, even when
 never stored, which matches how people talk. What got lost from the 
February text ("Unless there is a stored permission for the source in 
question, the given permission is revoked") was the revocation of this
 implicit "given permission" we got from the request algorithm. I 
don't know the perfect wording, but without explicitly stating when it
 must end, it seems unclear - at least to me -  whether e.g. Edge's 
`https` behavior is compliant.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at 
https://github.com/w3c/mediacapture-main/issues/387#issuecomment-245164716
 using your GitHub account
Received on Wednesday, 7 September 2016 03:28:20 UTC

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