I don't think that we should follow what chrome is doing. Chrome and Android relies on that users make a lot of security decisions up front at installation time. This is bad for security as users have very little context to make a decision on.
It also means that users have only one recourse if they don't want to grant a permission: don't install the application. It also means that chrome can't do silent updates since updates can mean that users need to make a security decision. Instead we should follow the model that all our other APIs are using. I.e. have a modal dialog at runtime where the user can choose to grant or deny, and where they can choose to do so temporarily or permanently. This dialog should be rendered by the system (rather than by an individual app) and should write data into the nsIPermissionManager once the user makes a decision. / Jonas On Jul 10, 2013 2:31 PM, <[email protected]> wrote: > We are creating a cross-browser framework for packaged apps ( > http://github.com/urbien/urbini ) and can provide info on how Chrome does > it, in my opinion much better, without any UX, matching from user's > perspective how native apps do it. > > 1. Packaged app in Chrome can request a videoCapture and audioCapture > permissions in manifest. So the user does not need to allow access to mic > and camera every time. Imagine if Skype would do it like this. Would annoy > the hell out of users. It is understandable why website accessing camera > needs to ask user permission, but even a hosted app, not to mention a > packaged app, should not need to harass the user. > > 2. getUserMedia() in iframe. Chrome as of v29 has a new mechanism, they > allow packaged app to listen to "permissionrequest" event. > webview.addEventListener("permissionrequest", function (e) { > // call e.request.allow() or e.request.deny() > }) > (they use webview tag instead of iframe tag in packaged apps, but this is > not relevant now) > So, providing the packaged app requested permission from the user via a > manifest, the code in iframe can request same permission from packaged app. > > We used both methods in apps built on Urbini framework in Chrome and they > work fine. But now in FF OS and FF packaged app for Android we got stuck. > Let me know if you need more info. > > On Friday, April 26, 2013 11:56:34 PM UTC-4, Paul Theriault wrote: > > In bug 853356, there is some discussion around the permission granting > mechanism to allow content to ask for microphone access via getUserMedia. > The current plan is to use a prompt & permission combination similar to the > way geolocation is handled. To me this API is much more sensitive than > geolocation, and needs stronger mitigation. > > > > > > > > Some thoughts for discussion: > > > > > > > > 1. Current FirefoxOS prompts can not be ignored > > > > Prompts on b2g are modal and can not be ignored - the user must choose > one way or another. Compare this to the door hanger approach for > getUserMedia on desktop: if the user simply ignores the prompt it goes > away. I would like to see "safe if ignored" style of permission request on > FirefoxOS for this use case if possible to prevent the user accidentally > making the wrong choice. > > > > > > > > 2. Current permission indicators are not strong, or always present > > > > For untrusted content, there needs to be some trusted indicator that the > camera/microphone is enabled. At the moment we have small icons in the > taskbar for some permissions but in this case I think we need something > more obvious like a red bar or something that is present for the duration > of recording. (something similar to the call background indicator perhaps) > > > > > > > > 3. The user needs a way to turn off video/audio > > > > The user needs a trusted way to know that video/audio is disabled. The > permission is revoked when the window (app) is closed, but how does the > user know which app is using the camera/mic? Obvious idea would be that > tapping the recording indicator takes you to the app which is using the > permission, so you can turn it off in the app, or close the app. > > > > However I also worry that the UI to close an app isnt very discoverable > (long press on home, swipe up on app thumbnail). So maybe we need something > more explicit here (perhaps combined with the notification from 2.) > > > > > > > > Finally, I imagine that we might provide less intrusive UI for > privileged or certified apps, but exactly what depends on the UI for web > content, and the privileged/certified use cases. > > > > > > > > Thoughts/comments/suggestions etc? > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
