On Tue, Apr 22, 2014 at 7:24 PM, Paul Theriault <[email protected]> wrote: > > On 19 Apr 2014, at 11:42 am, Jonas Sicking <[email protected]> wrote: > >> On Thu, Apr 17, 2014 at 4:07 AM, Paul Theriault <[email protected]> >> wrote: >>> Both APIs have a similar prompt, and would likely have a similar name in >>> the settings app, possibly leading to confusion for the user. So I think we >>> should aim to have a single camera prompt and single camera permission in >>> the settings app. But I am not what the long term plan is for mozCamera, or >>> what the best approach to achieve this unified UI. >> >> Agreed. There's no reason to separate these two security-wise. >> >> One important question is, will we require that application enumerate >> some permission in the app manifest in order to use getUserMedia? We >> did this for geolocation and for the notification APIs, where even >> though normal web pages can use these APIs, if an app wants to use >> them we require the app to enumerate a permission in its manifest. >> >> Requiring the permission to be in the manifest does have the advantage >> that we can make those permissions show up in the settings app's UI >> for configuring application permissions. I'm inclined to require the >> same for getUserMedia for the same reason. > > gUM on b2g currently requires video-capture/audio-capture to be declared in > the manifest, and I agree we should continue this.
Great! >> But I think that regarding what we put in the permissions part of the >> manifest, and what we display to the user both in prompts and in the >> settings UI, we should treat mozCamera and getUserMedia the same. So >> we should figure out a single permission name which would cover both >> APIs. I'm fine with this being "video-capture" if that's what the >> WebRTC team prefers. > > If we are not going to expose mozCamera and video-capture to the same app > levels (i.e. if mozCamera is privileged only), I was thinking we would need > to keep the permissions separate. The thing that I care about the most is that users are never faced with two prompts for the two different camera APIs. There are at least two ways that I think we can accomplish this, both of which are acceptable IMO. 1. Use a single manifest permission and a single nsIPermissionManager permission to cover both APIs. However additional make the navigator.mozCamera attribute disappear if the current app is not privileged. This would mean that the parent process would not enforce that mozCamera is only used by privileged apps. But I think that's ok. I.e. I think it's ok that if a child process manages to hack gecko, it could use the mozCamera API since there would still be a user prompt. The reason for hiding mozCamera from non-privileged APIs is that that makes it easier to deprecate the API as we find a standardized alternative. It obviously doesn't matter if apps that hack gecko would be affected by such a deprecation. The main downside with this solution is that privileged apps that wants to use getUserMedia would also see the navigator.mozCamera API. And that when we deprecate mozCamera, we can't tell apps that only use getUserMedia from apps that use mozCamera, making such deprecation a bit more painful. 2. Use separate manifest and nsIPermissionManager permissions for the two APIs. However when installing an app which requests mozCamera permission, write both the mozCamera permission and the getUserMedia permission into nsIPermissionManager. Then let the getUserMedia permission be the one that guards access to using camera. The mozCamera permission would only be used in the DOM code in order to hide mozCamera API from pages that shouldn't have access to it. So the mozCamera permission would be set to ALLOW during installation, but that would only really mean that the API can be accessed. The getUserMedia permission is what would regulate access to actual camera hardware and what would cause a prompt to come up at time of use. I think this would ensure both that the prompt only comes up once even if both APIs are used, and that the settings app would only bother with one of the two permissions. The latter solution sounds better to me as it only really requires hacks in the PermissionsTable code. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
