This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec should say something about how long permissions persist (even if we only say that it is UA-specific.) For example: 1. If the user grants permission to a camera, then later closes the tab (but doesn't clear cookies), is the permission still granted if he returns to that page later (no, I think.) 2. What if he puts the tab in the background, then revisits/foregrounds it later? After 10 minutes? After 24 hours? We might say that the answer is UA-specific, but that the UA must set some configurable limit. 3. We have said that the UA may allow the user to grant permanent permissions to certain sites. The spec should mention this possibility, even if the mechanism is UA-specific. 4. Suppose the app requests a camera and the user gives it permission to use all cameras. The app initially uses only a single camera but later decides that it wants a different one. Does it have to request permission again (given that the user granted permission for all cameras)? If it doesn't have to request permission again, how long does the user's grant persist? 10 minutes? 10 hours? Is it UA-specific?
I suggest that this should be addressed in section 10.5 "Implementation Suggestions". I think the right properties to suggest are: - Permissions are given for a particular site (= origin) - Permissions persist at least until the page is closed or navigated away from - Users may allow permissions to persist longer (stored permissions) - Users may revoke permissions at any time I think it's an UA design choice whether permission is given for a particular camera or for all cameras.
Discussed at Media TF meeting May 19. Consensus was not reached.
Rough consensus from the mailing list discussion seems to be: - Stored permission is only given to HTTPS pages (previous consensus, just repeating here for background) - It is an UA choice whether permission is granted for one device, a class of devices, or all devices. UI needs to make clear what is being granted. - Non-stored permission to a device lasts only while a MediaStreamTrack with the device as source exists. Enabling/disabling the track has no effect on permissions. - Non-stored permissions do not survive a page reload (since the MST objects don't survive it either). These are a summary of the points on which I think the ML has rough consensus.
(In reply to Harald Alvestrand from comment #3) > - Non-stored permission to a device lasts only while a MediaStreamTrack with > the device as source exists. Enabling/disabling the track has no effect on > permissions. At first glance I didn't think that this sentence captured the case of giving back a non-stored permission with MediaStreamTrack.stop(), but I think it does. The MediaStreamTrack instance may still be around but it's detached from the source after stop() and therefore no MST with the *device as source* exists.
https://github.com/fluffy/webrtc-w3c/pull/33 This is an informational section under "implementation advice", but it seemed to fit very well there. If something in an authoritative section is needed, suggestions are welcome.
*** Bug 25783 has been marked as a duplicate of this bug. ***
Discussed on telechat June 25. The basic principles seem to be accepted, we still have some discussion on whether there's any benefit to taking away access to labels when all devices are closed.
(In reply to Harald Alvestrand from comment #7) > Discussed on telechat June 25. The basic principles seem to be accepted, we > still have some discussion on whether there's any benefit to taking away > access to labels when all devices are closed. At the telechat Aug 5th we decided to take away access to labels when all devices have been closed, so that part is resolved now.
proposed fix https://github.com/w3c/mediacapture-main/pull/8
Merged pull request (with additions) https://github.com/w3c/mediacapture-main/commit/9ff9379f536c87c422c7789a341c8aed83b933b0