- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Apr 2016 20:43:40 +0000
- To: public-media-capture-logs@w3.org
@jyasskin I'd go out on a limb and suggest that when arguments rely on conflation, they're rarely good. By "access" I mean the site can access the user's camera or mic. By "persistent permission" I mean the UA policy setting (prompt, grant, or deny) for dealing with new requests for access. If you are using any other terms, please define them. Another mistake: Note how `'prompt'` is a command, whereas `'granted'` and `'denied'` are not. If this a setting for how the UA is to respond to new requests, then they should all be commands. We should rename them to `'grant'` and `'deny'` (or even `'auto-grant'` and `'auto-deny'` if you will) to make this clearer. > If I decide that foo.com shouldn't have access to my camera, and I revoke it from some global menu, I certainly don't want it to keep recording me from that tab I still have open. Did you see that I showed two examples, and how they were different? The first one (the "in-call" doorhanger) deals directly with any current cam+mic access. The second (global "about:permissions") dealt with UA policy settings for new requests, whether to auto-grant, auto-deny or prompt. We could certainly entertain conflating the two in UX, but not in programming specs please. The language we use to discuss and specify with needs to be sharp and clear. Chrome is no different. Try this: 1. In Chrome, go to https://jsfiddle.net/srn9db4h/ and see camera turn on. 2. Click on the camera icon in the URL bar 3. Select "Always block camera and microphone access" and hit `Done`. Did the camera go away? -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/334#issuecomment-213106791 using your GitHub account
Received on Thursday, 21 April 2016 20:43:42 UTC