1145053 - Improve FTU message so that users understand their camera will open when they click "Start a conversation"

Status: RESOLVED WONTFIX

(Hello (Loop) :: Client, defect)

Description

[Romain Testard [:RT]]

It seems some users are surprised that the first time they click "Start a conversation", their camera opens directly. It feels we should improve either the door hanger message or the wording on the Web page to help users understand that their camera will be turned on once they click "Start a conversation".

Comment 1

[Romain Testard [:RT]]

Holly and Matej, can you please help us there understand how we could make this better?

Comment 2

[Romain Testard [:RT]]

Attachment: current FTU messaging

Comment 3

[Matej Novak [:matej]]

This really surprises me to hear and makes me wonder how much of an edge case we're trying to solve for. This also feels like more of a disclaimer than something we want to communicate in marketing copy.

Could (or should) we add this to the product instead? Maybe the user gets a notification the first time letting them know that their camera will turn on.

Comment 4

[Maire Reavy [:mreavy]]

(In reply to Matej Novak [:matej] from comment #3)
> Could (or should) we add this to the product instead? Maybe the user gets a
> notification the first time letting them know that their camera will turn on.

That's exactly what I was hoping we could do: add a single prompt (something very lightweight) the first time the user tries Hello (explaining that Hello needs access to camera/microphone to work properly) and then let that permission persist for all future uses.

Comment 5

[Eric Shepherd [:sheppy]]

I think a one-time doorhanger would be good, as well as a small link tucked somewhere in the Hello UX that took people to a web page with details on the issue, so they can read more about it, and so we can be clear from "Oh, I didn't see the doorhanger, so how was I supposed to know" issue that might happen down the road. There should be a way to get information after-the-fact, too.

Comment 6

[Steven McArdle]

For me this is entirely WRONG.

I am the architect and lead developer of a WebRTC based Telehealth secure comms platform here in in New Zealand and I very much have a vested interest in WebRTC and especially this subject. 

I must confess that the first time I selected Hello to check it out and my camera turned on without my permission I almost fell off my chair and my instant reaction was "Wooooo..... NO NO NO, you can't do that!!!!". 
Since then my reaction and feelings regarding this "feature" has actually gotten worse as my mind races through possible nefarious usages.

 
I raised this issue on firefox-dev just yesterday after commenting on a Hello bug that had already been closed and being advised to either raise a new bug myself or raise the point on firefox-dev.

This functionality goes against EVERYTHING we have come to understand and accept regarding GUM security in the browser and users being in charge of granting, or denying, permission to GUM requests to access devices, at least for the first time.

Browsers, and web applications in general, have been a relative safe havens for users up until this point, purely because a user could be assured that no web page could activate their camera or microphone without them first granting permission.

I would much rather see FF remove this entirely and take the same approach that Chrome follows which is if the user navigates to a WebRTC URL over HTTPS, they must give permission the first time. After this the browser can remember the granted permission for future visits. Rather than the implemented functionality up until now which has been users grant permission EVERY time they visit the URL (this becomes annoying to users and actually forced me to change the way my call initiation processes work to cater for this).
Users are not surprised by this functionality.

This is much more inline with the "OPT IN" privacy policies of many Countries and Regions such as the EU.

In today's climate with the NSA, as well as other spy agencies, causing people to consider their privacy more closely this issue is even more in focus. 
Basically, if FF can do this then what is to stop the NSA demanding a backdoor from Mozilla so that they can do the same? You definitely won't be able to tell users you have or have not. 
All such agencies require is the public IP address of a target computer (everybody it seems), as returned from say a STUN/TURN server, and boom .... they just got access to my devices should I be running FF, a little over simplified but you get the picture.

So, I believe that not only is this feature a surprise to many users, goes against the principal of "OPT IN" privacy policies of some countries and regions, takes away that feeling of 'comfort & control' from users and could also be used by outside agencies in the future to spy on people.
And that last point alone is news worthy.

Steven McArdle

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to Steven McArdle from comment #6)
> Basically, if FF can do this then what is to stop the NSA demanding a backdoor from
> Mozilla so that they can do the same?

This is a fundamentally flawed argument: the code that enables the camera after clicking the "Start a conversation" button runs with the same system-level privileges as the code that would decide whether to show a permission prompt. And the NSA can "demand a backdoor from Mozilla" regardless of our decision here.

This bug has one particular purpose: ensuring that there is no user surprise from having the camera activate when "Start a conversation" is clicked. This does not require a GUM-style permission prompt, and we will not be adding them to the Hello call flow. Video/microphone access is a fundamental aspect of this feature/product.

Comment 8

[Steven McArdle]

It may well do. However, the button could be scripted so that I don't even need to press it... NO OTHER WebRTC site can do this. The popup GUM permission cannot be scripted.

It's not about the permission it runs with it's about the fact that Hello bypasses the permission granting in the first place.

If FF are going to change the way users have been educated to perceive sandboxing access to the underlying machine then I see this as a BIG deal.

And your last statement that Video/Audio is a fundamental aspect of this feature/product does not differentiate it from ANY OTHER WebRTC product. What it does do is give FF an unfair advantage as it uses a feature nobody else can use.

Comment 9

[Mike de Boer [:mikedeboer]]

Steven, please continue to raise your concerns on the firefox-dev mailing list. As you might have noticed already, people are replying to your messages there so I don't see the need for you to continue using bugs for this purpose.

I will continue to mark your messages as advocacy from here on out. Bugs are meant for technical discussion directly related to the Summary. For more information, I refer to the Bugzilla etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 10

[Sevaan Franks [:sevaan]]

I like the prompt idea first time a conversation window is open:

"Firefox Hello requires the use of your camera and microphone. They will be turned on automatically whenever you join a conversation. [Ok] [Cancel]"

If user clicks okay, camera and mic are activated. If they click cancel, the conversation just closes.

Matej, thoughts?

Comment 11

[Matej Novak [:matej]]

(In reply to Sevaan Franks [:sevaan] from comment #10)
> I like the prompt idea first time a conversation window is open:
> 
> "Firefox Hello requires the use of your camera and microphone. They will be
> turned on automatically whenever you join a conversation. [Ok] [Cancel]"
> 
> If user clicks okay, camera and mic are activated. If they click cancel, the
> conversation just closes.
> 
> Matej, thoughts?

One small change to the string:

"Firefox Hello requires the use of your camera and microphone. They will turn on automatically whenever you join a conversation. [Ok] [Cancel]"

I also wonder if we should offer "Always allow" and "This time only" options. Or does that add too much complexity?

Comment 12

[Florian Quèze [:florian]]

I also like the idea of a prompt the first time Hello is about to grab the camera.

(In reply to Matej Novak [:matej] from comment #11)

> One small change to the string:
> 
> "Firefox Hello requires the use of your camera and microphone. They will
> turn on automatically whenever you join a conversation. [Ok] [Cancel]"

I think we could further reduce the risk of the user clicking through without reading and then being surprised if we changed the label of the button to something less generic than "OK". Maybe "Share devices"?

Comment 13

[Matej Novak [:matej]]

(In reply to Florian Quèze [:florian] [:flo] from comment #12)
> I also like the idea of a prompt the first time Hello is about to grab the
> camera.
> 
> (In reply to Matej Novak [:matej] from comment #11)
> 
> > One small change to the string:
> > 
> > "Firefox Hello requires the use of your camera and microphone. They will
> > turn on automatically whenever you join a conversation. [Ok] [Cancel]"
> 
> I think we could further reduce the risk of the user clicking through
> without reading and then being surprised if we changed the label of the
> button to something less generic than "OK". Maybe "Share devices"?

I worry that "Share devices" may not be clear to people. Maybe it's something like "Allow" or "Accept" that makes someone take more notice of the message. Or even "I understand."

Comment 14

[Steven McArdle]

So, now we are back to the EXACT same thing that the GUM permission dialogue provides.... So why not just make it work the same as every other browser based WebRTC app.

Comment 15

[Sevaan Franks [:sevaan]]

I thought I replied to this bug earlier today, but maybe my I was in a different tab and posted somewhere completely different. Apologies.

With the visual refresh, users will also be able to start audio-only conversations. Should we address this in the message by saying "camera and/or microphone"?

Also, I like Allow.

We want to implement a doorhanger in the conversation window anyway to promote other things, like new features, in the conversation window.

Another angle:

Maybe the message doesn't need to be an Allow or disallow one. Maybe it could just inform the user that their camera and microphone will turn on. They can close the window if they don't like it after. Just throwing that idea out.

Then it's less GUM permission like. Thoughts?

Comment 16

[Mark Banner (:standard8)]

How about something like:

Firefox Hello requires the use of your camera and microphone. They will turn on automatically whenever you join a conversation. [Join] [Leave]

Allow/Accept feel a bit like we're going to ask for deny as well, then you get into the situation of what to do if the user denies it.

I almost changed "...join a conversation" to "open a conversation", but then that makes the buttons feel a bit stranger (especially as the conversation window will be open).

Comment 17

[Fred Wenzel [:wenzel]]

Came across some real-world user confusion here: https://twitter.com/swiftonsecurity/status/578716666252566528

Thanks for taking a look.

Comment 18

[Sevaan Franks [:sevaan]]

Maybe the confusion is simple in the messaging "Start a conversation". What does that mean to users?

In the visual refresh for Hello (currently WIP) when joining an existing conversation a camera icon appears next to the conversation name to communicate the use of the camera. Sub-optons give users the option to start a "Video Conversation" or "Audio-Only Conversation". http://cl.ly/image/0t0D2D3u0n3H

And in Bug 1137197 we are formulating a plan to hide a link generators camera from the conversation after an idle period so the user won't forget their camera is on and take the "saddest corporate photo" like in the original tweet.

This combined with a slight bump in messaging should allay any creepiness.

Comment 19

[Romain Testard [:RT]]

Marking as WON'T FIX since we'll implement bug 1239608 which joins link clickers audio and face muted automatically.