UX for getUserMedia in FirefoxOS

[Paul Theriault]

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?

[Alfredo Yang]

Followings are my thoughts about 2 & 3.

Add an item on notification bar. This item displays info about current recording audio/video and it keeps on the notification until recording stops.

When user presses this item, it brings the corresponding web content/ap to top layer. And it may need an extra button on the item to close web content/ap directly in case of malicious content with invisible UI.

[iba...@mozilla.com]

Hi everyone, I'm the UX lead on Firefox for Android, so I can comment on what we've done there with regard to WebRTC/gUM. I'll also look to FxOS UX people for their thoughts here, although they may be fairly similar.

------------

Permissions - https://bugzilla.mozilla.org/show_bug.cgi?id=862377
We're using our existing 'doorhanger' notifications to let users choose whether they would like to share either their camera or mic (or both) with a website that is requesting it, there is a mockup of that here https://bug862377.bugzilla.mozilla.org/attachment.cgi?id=750068

Visual Indicator - https://bugzilla.mozilla.org/show_bug.cgi?id=874401
We are using the Android notification bar to display an icon to alert users that their camera or microphone (or both) is on. We also provide a message about it in the notification tray.

Notification bar (top left corner): http://cl.ly/image/210e0B14072C
Icons for Camera, Mic, Camera+Mic: http://cl.ly/image/3z3H2P2p122K
Notification tray: http://cl.ly/image/0y2N3M2i151d

------------

In the bug mentioned here, https://bugzilla.mozilla.org/show_bug.cgi?id=853356#c16, it sounds like Paul and others are also looking for some kind of 'recording bar' to visually indicate if your mic or camera are on. We're not doing this on Android, but I also don't have a strong opinion about this one way or the other for FxOS.

Other UX folk, is this a pattern being used elsewhere in FxOS that would make this appropriate here too?

[pther...@mozilla.com]

On Saturday, June 15, 2013 6:08:28 AM UTC+10, iba...@mozilla.com wrote:
> Hi everyone, I'm the UX lead on Firefox for Android, so I can comment on what we've done there with regard to WebRTC/gUM. I'll also look to FxOS UX people for their thoughts here, although they may be fairly similar.
>
>
>
> ------------
>
>
>
> Permissions - https://bugzilla.mozilla.org/show_bug.cgi?id=862377
>
> We're using our existing 'doorhanger' notifications to let users choose whether they would like to share either their camera or mic (or both) with a website that is requesting it, there is a mockup of that here https://bug862377.bugzilla.mozilla.org/attachment.cgi?id=750068

So on Firefox OS, most of the time (unless we are in a browser window) there is nothing to 'hang' the door hanger off. But apart from that, those prompts seem good to me (though they would need to be modified to match the style of Firefox OS prompts)

>
>
>
> Visual Indicator - https://bugzilla.mozilla.org/show_bug.cgi?id=874401
>
> We are using the Android notification bar to display an icon to alert users that their camera or microphone (or both) is on. We also provide a message about it in the notification tray.

That indicator looks a bit subtle to me, but I understand this is the android style. I'm not really fussed about how we do this for Firefox OS so long as a) there is some persistent notification that the camera/microphone is on, and b) the user can see which app is using the camera/microphone so they can turn it off (or kill the app as a last resort).

[Alfredo Yang]

> >
>
> > Permissions - https://bugzilla.mozilla.org/show_bug.cgi?id=862377
>
> >
>
> > We're using our existing 'doorhanger' notifications to let users choose whether they would like to share either their camera or mic (or both) with a website that is requesting it, there is a mockup of that here https://bug862377.bugzilla.mozilla.org/attachment.cgi?id=750068
>
> So on Firefox OS, most of the time (unless we are in a browser window) there is nothing to 'hang' the door hanger off. But apart from that, those prompts seem good to me (though they would need to be modified to match the style of Firefox OS prompts)

Firefox on desktop and Android display prompt UI on AP side, not system level.
There is another discussion about it [1].

According to B2G UX building block [2] and geolocation, it could be better to use ContentPermissionPrompt [3] instead of prompting by ap level.


[1] https://groups.google.com/forum/#!searchin/mozilla.dev.b2g/[b2g]$20UX$20for$20getUserMedia$20in$20FirefoxOS/mozilla.dev.b2g/GYVoPceSFkU/8mfCayZpgNsJ
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/UX/Building_blocks/Confirmation
[3] https://mxr.mozilla.org/mozilla-central/source/b2g/components/ContentPermissionPrompt.js

[gene.v...@urbien.com]

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.

[Jonas Sicking]

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

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>

[Jan Jongboom]

+1

[Gene Vayngrib]

Jonas, thank you for your response, please find my notes below

On Tue, Jul 30, 2013 at 4:18 PM, Jonas Sicking <jo...@sicking.cc> 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 :-)