Jonas, thank you for your response, please find my notes below On Tue, Jul 30, 2013 at 4:18 PM, Jonas Sicking <[email protected]> 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. > I agree. I was making a suggestion to implement "permissionrequest" event under the assumption that Mozilla decided to follow the native & Chrome permissions model for packaged apps, that is to ask the user to approve a list of permissions at the app install time. In this model, when mozBrowser iFrame is loaded by the packaged app, delegating this decision to the "permissionrequest" event listener in packaged app seems logical, doesn't it? > It also means that users have only one recourse if they don't want to > grant a permission: don't install the application. > 100% with you on that. It ends up being a trust decision, e.g. "I trust that the app marketplace will not keep the apps that are malicious" or a brand trust: "I trust Twitter will not knowingly create a malicious app". User in this case relies on the Marketplace's power to remove bad apps from the marketplace. This *revoking power* to me is the most powerful security feature that keeps native apps in line today (marketplace review process - not so much IMHO). While it is better for the user to give his camera permission for the app in-context, it is still not secure. The app can spy on the user all day long after that (mentioned by Paul on bug 853356<https://bugzilla.mozilla.org/show_bug.cgi?id=853356#c8> ). So evolving Paul's idea, may be we can create access/throttling profiles, a bit similar to bluetooth profiles, filesystem quotas, and bandwidth allowances. For camera it could be the amount of minutes it is allowed to work in the background. These profiles would be completely orthogonal to WebAPIs (no API change whatsoever) and will affect only the mode of access or the amount of access, asking the user to grant more access when quota exceeded or profile boundaries crossed. It also means that chrome can't do silent updates since updates can mean > that users need to make a security decision. > Silent update would need to be blocked only if permissions list changed. Yet, is install-time permissions is not the model Mozilla will follow, it becomes a moot point. > Instead we should follow the model that all our other APIs are using. > Right, but the case I originally described was more complex. We created a thin packaged app and run the rest of the code in mozBrowser iframe, which is sandboxed with a different origin. We did that to avoid killing ourselves and Marketplace reviewers with app update requests. Most of our changes are made daily, and are in UI anyway, so serving most code live via an iframe while offlining with appcache, LS & IndexedDB (instead of a packaged zip) works better. Just need to make sure we do not annoy the hell out users with repeated permission requests. > 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. > yep, the word "Permanently" is key here. As a user I could not find a way to confirm the WebRTC permission UI once and for all in an iframe, so on the 10th request I was swearing like a pirate :-) > 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
