On Tuesday, July 30, 2013 10:18:42 PM UTC+2, Jonas Sicking wrote: > 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 > > >
+1 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
