Closed Bug 1031424 Opened 10 years ago Closed 10 years ago

[UX] Design Spike -- Screen sharing permissions UI for WebRTC web apps

Categories

(Firefox :: Site Permissions, defect)

Product:
Firefox
Component:
Site Permissions
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal
Points:
13

Tracking

()

Status:
RESOLVED FIXED
Iteration:
33.3

People

(Reporter: chadw, Assigned: phlsa)

References

Details

(Whiteboard: [ux])

Attachments

(3 files, 4 obsolete files)

Sketches of a flow with better feedback to users
(deleted), image/png
phlsa
: feedback?
jboriss
Details
Icons in Mac menu bar
(deleted), image/png
Details
MVP Wireframe v3.3
(deleted), image/png
Details 
Description:

As a user, I want to be notified when a website would like to share my screen/window/app so that I have control over what is shared.

Acceptance Criteria:
* 2-3 options for UI that balance security concerns, user choice, and user friction.
*Options to be reviewed by GMC by Thursday, July 3rd.
Added to Iteration 33.2
Status: NEW → ASSIGNED
Iteration: --- → 33.2
Points: --- → 13
QA Whiteboard: [qa-]
Summary: Design Spike -- Screen sharing permissions UI for WebRTC web apps → [UX] Design Spike -- Screen sharing permissions UI for WebRTC web apps
Whiteboard: [ux]
Assignee: philippsackl → philipp
Attached image Screen Sharing MVP Wireframe (obsolete) (deleted) — 
This is the most minimal version I could come up with. It is far from optimal both from a user and a security perspective, but it re-uses mostly existing UI so it should be a little easier to implement given our time constraints.

A flow like this only works if we have a whitelist of trusted sites that can use the screen sharing API. For wider use, the feedback to the user is just not clear enough in order to be secure.

There is a second, more thorough version that fixes many of the issues with this flow. I'll add it to this bug as well.
Attachment #8449406 - Flags: feedback?(jboriss)
This flow drops the focus on re-using UI. It provides much clearer feedback to the user as to what is being shared at what time. It also still has some shortcomings (marked as TODO), but they all sound fixable.
Attachment #8449409 - Flags: feedback?(jboriss)
Comment on attachment 8449406 [details]
Screen Sharing MVP Wireframe

A few questions I have while looking at this mockup:
- do we expect the screen sharing to be requested at the same time as the microphone/camera, or separately? (the example I have in mind of a screensharing application is Vidyo, and I think the screen share always starts during an ongoing call).
- When looking at the doorhanger attached in the mockup to your 'global sharing indicator':
-- I really like the clear indication of what's shared, and the obvious mute/unmute/stop sharing buttons. Is this something we should implement independently of screen sharing or the global always-on-screen indicator? I'm thinking we may initially attach this panel to the current webrtc toolbar icon that appears in the navigation toolbar while WebRTC is in use.
-- Can/should this panel display more than one website currently using devices?
Trying to answer some questions .... 

I'm not a UX expert but it the wireframes look like they would allow the functionality an application like webex needs. 

On the question about when things are requested: Some applications might request it all at the same time but most applications will start video and applications sharing at different times but need to be able to do both at the same time. 

Multi sites: WebRTC certainly imagines that multiple tabs from different web sites could use the same camera at the same time. But if the panel is associated with a given tab, seems like it should only display the website for that tab. 

+1 on really clear indication to the user of what is being shared and to who it is shared. 

For me, the most important thing to get going first is application sharing and second priority is desktop sharing but I understand that just my priorities not necessarily others peoples.
(In reply to Cullen Jennings from comment #5)
> Trying to answer some questions .... 
> 
> I'm not a UX expert but it the wireframes look like they would allow the
> functionality an application like webex needs. 
> 
> On the question about when things are requested: Some applications might
> request it all at the same time but most applications will start video and
> applications sharing at different times but need to be able to do both at
> the same time. 

The syntax at: https://fluffy.github.io/w3c-screen-share/ does not seem
to allow you to request both.


> Multi sites: WebRTC certainly imagines that multiple tabs from different web
> sites could use the same camera at the same time. But if the panel is
> associated with a given tab, seems like it should only display the website
> for that tab. 
> 
> +1 on really clear indication to the user of what is being shared and to who
> it is shared. 
> 
> For me, the most important thing to get going first is application sharing
> and second priority is desktop sharing but I understand that just my
> priorities not necessarily others peoples.
@EKR, true. I should have been more precise. Just meant that the JS would do multiple calls to GUM all around same time.
Hey Cullen, thanks for the clarifications!

(In reply to Cullen Jennings from comment #5)
> I'm not a UX expert but it the wireframes look like they would allow the
> functionality an application like webex needs. 

Excellent! :)

> On the question about when things are requested: Some applications might
> request it all at the same time but most applications will start video and
> applications sharing at different times but need to be able to do both at
> the same time. 

Hm, both of the flows don't handle that case particularly well at the moment. I'll come up with something...

> Multi sites: WebRTC certainly imagines that multiple tabs from different web
> sites could use the same camera at the same time. But if the panel is
> associated with a given tab, seems like it should only display the website
> for that tab.

UI-wise, I think the only thing we need to take into account here is that there the global indicator. Everything else is being done on a per-tab basis anyway. This sounds like something we can/will not allow for the first version though, right?

> For me, the most important thing to get going first is application sharing
> and second priority is desktop sharing but I understand that just my
> priorities not necessarily others peoples.

So about that... Application sharing is a concept that is pretty hard to communicate to the user. This is particularly true on Windows, where the concept of multiple windows belonging to one application isn't communicated by the OS at all. The more graspable solution would be single window sharing. Would it make sense to use that instead from your point of view?
Flags: needinfo?(fluffy)
(In reply to Florian Quèze [:florian] [:flo] from comment #4)
> Comment on attachment 8449406 [details]
> Screen Sharing MVP Wireframe
> 
> A few questions I have while looking at this mockup:
> - do we expect the screen sharing to be requested at the same time as the
> microphone/camera, or separately? (the example I have in mind of a
> screensharing application is Vidyo, and I think the screen share always
> starts during an ongoing call).

Very good point. I'll include that in the upcoming version.

> - When looking at the doorhanger attached in the mockup to your 'global
> sharing indicator':
> -- I really like the clear indication of what's shared, and the obvious
> mute/unmute/stop sharing buttons. Is this something we should implement
> independently of screen sharing or the global always-on-screen indicator?
> I'm thinking we may initially attach this panel to the current webrtc
> toolbar icon that appears in the navigation toolbar while WebRTC is in use.
> -- Can/should this panel display more than one website currently using
> devices?

Yes and yes :)
I don't know what's the right component for this bug, but it isn't "Web Apps".
Component: Web Apps → General
Attached image MVP Wireframe v2 (obsolete) (deleted) — 
Iterating on the minimal version, this includes a couple of improvements.

Most importantly: unifying the panels.
The global sharing options and the initial permissions doorhanger are now the same except for the »Mute« and »Stop sharing« buttons. That makes the UI much more consistent and flexible.

When a site requests additional permissions, we can just re-surface the global panel and show the new state of permissions.
Attachment #8449406 - Attachment is obsolete: true
Attachment #8449406 - Flags: feedback?(jboriss)
Attachment #8450279 - Flags: feedback?(jboriss)
(In reply to Philipp Sackl [:phlsa] from comment #11)
> Created attachment 8450279 [details]

> Most importantly: unifying the panels.
> The global sharing options and the initial permissions doorhanger are now
> the same

Changing the devices during a call is currently not possible and from the discussion in bug 880312, it isn't clear if it is ever going to become possible.
See bug 1033326 - we're planning to support RTPSender/Receiver, and use that to allow replacing devices in live calls.

RTPSender/Receiver (at least the simple case above) is planned to be supported in FF 34, so it wouldn't be possible in 33, so for now we wouldn't be able to change A/V sources.  ALso, the above bug will not enable fully removing a stream or adding one; that will come with further RTPSender support.  (Removing can be simulated to a degree, perhaps).
(In reply to Randell Jesup [:jesup] from comment #13)
> See bug 1033326 - we're planning to support RTPSender/Receiver, and use that
> to allow replacing devices in live calls.
> 
> RTPSender/Receiver (at least the simple case above) is planned to be
> supported in FF 34, so it wouldn't be possible in 33, so for now we wouldn't
> be able to change A/V sources. 

Note: "wouldn't be possible" is given current priorities; if this is critical for 33, we can see if we can rejuggle (something else would likely get delayed to 34).  

Cullen/Philipp - what's the priority of this for 33 in your opinions?
Flags: needinfo?(philipp)
(In reply to Randell Jesup [:jesup] from comment #14)
> (In reply to Randell Jesup [:jesup] from comment #13)
> > See bug 1033326 - we're planning to support RTPSender/Receiver, and use that
> > to allow replacing devices in live calls.
> > 
> > RTPSender/Receiver (at least the simple case above) is planned to be
> > supported in FF 34, so it wouldn't be possible in 33, so for now we wouldn't
> > be able to change A/V sources. 
> 
> Note: "wouldn't be possible" is given current priorities; if this is
> critical for 33, we can see if we can rejuggle (something else would likely
> get delayed to 34).  
> 
> Cullen/Philipp - what's the priority of this for 33 in your opinions?

I would assume that changing the application that is being shared should be supported. Changing the webcam and microphone sounds like an edge case to me.
Perhaps Cullen has a clearer opinion on this.
Anyway, the UI changes to reflect changes there would be trivial, so I can add them once we have a decision.
Flags: needinfo?(philipp)
Actually, changing the application being shared seems like a real
edge case. I think that can wait for 34
(In reply to Eric Rescorla (:ekr) from comment #16)
> Actually, changing the application being shared seems like a real
> edge case. I think that can wait for 34

This is completely anecdotal, but it happens a lot in our meetings on Vidyo.
Depends on the use case.
(In reply to Philipp Sackl [:phlsa] from comment #11)
> Created attachment 8450279 [details]
> MVP Wireframe v2
> 
> Iterating on the minimal version, this includes a couple of improvements.

From an IRC conversation I've just had with Maire, it seems the high priority part here is to get something working soon for screen sharing.

I like lots of the UI enhancements I'm seeing in your mockup, but I don't think they relate directly to adding support for screensharing.

I'm wondering if just this tiny part (http://i.imgur.com/3C5T1r1.png) of your mockup added to our existing permission door hanger and tweaking the current "Would you like to share your camera and microphone with <hostname>" string wouldn't be enough for a first version.

I also have some concerns about the global sharing indicator on top of the screen, especially the Mac OS version inside the global menu bar: I'm afraid drawing there would require additions to the Mac-specific parts of our platform.
Certainly the driving consideration is to support the security aspect of screen sharing (though it also has to be usable, not just secure).  

I'd *love* to have a number of usability enhancements to getUserMedia requests and activity notifications, and this mockup does get us a lot of that.  However, we're also focused on what's needed and feasible for Fx33, given we really want/need screen sharing for that release.  So descoping (if it fits the needs) is certainly an option, especially if we can keep the momentum towards getting a more-complete implementation in 34. 

If Mac is a special problem, I'd even go with a reduced implementation (that meets minimum needs) on Mac for a release while getting more on other platforms - but I'm not the person to make that call, if that even is an option/useful.
(In reply to Florian Quèze [:florian] [:flo] from comment #18)
> (In reply to Philipp Sackl [:phlsa] from comment #11)
> > Created attachment 8450279 [details]
> > MVP Wireframe v2
> > 
> > Iterating on the minimal version, this includes a couple of improvements.
> 
> From an IRC conversation I've just had with Maire, it seems the high
> priority part here is to get something working soon for screen sharing.
> 
> I like lots of the UI enhancements I'm seeing in your mockup, but I don't
> think they relate directly to adding support for screensharing.
> 
> I'm wondering if just this tiny part (http://i.imgur.com/3C5T1r1.png) of
> your mockup added to our existing permission door hanger and tweaking the
> current "Would you like to share your camera and microphone with <hostname>"
> string wouldn't be enough for a first version.
> 
> I also have some concerns about the global sharing indicator on top of the
> screen, especially the Mac OS version inside the global menu bar: I'm afraid
> drawing there would require additions to the Mac-specific parts of our
> platform.

The problem is, that there is no such thing as the green light next to your webcam for screen sharing. That means the user has no indication for if and what is being shared when the tab he's sharing from is not focused (and even then it's very subtle).
That's bad. So if it is in any way humanely possible, we should avoid this situation. If the wide indicator in the Mac toolbar is a problem, we could also use a standard NSStatusItem for now.
(In reply to Philipp Sackl [:phlsa] from comment #20)

> The problem is, that there is no such thing as the green light next to your
> webcam for screen sharing. That means the user has no indication for if and
> what is being shared when the tab he's sharing from is not focused (and even
> then it's very subtle).
> That's bad.

Yes, it's bad. Is it worse than sharing the microphone (which also doesn't have a green light)? Both microphone and screen sharing have very obvious and serious privacy implications if the user forgets the sharing is happening. I don't think this has stopped us from letting web applications use the microphone though.

> So if it is in any way humanely possible, we should avoid this
> situation. 

Agreed, we should avoid this situation. My doubts are about whether it's possible within the timeframe Maire's team have in mind.

> If the wide indicator in the Mac toolbar is a problem, we could
> also use a standard NSStatusItem for now.

The NSStatusItem API doesn't seem used at all currently (http://mxr.mozilla.org/mozilla-central/search?string=NSStatusItem). This is actually what I had in mind when I said "drawing there would require additions to the Mac-specific parts of our platform".
(In reply to Florian Quèze [:florian] [:flo] from comment #21)
> (In reply to Philipp Sackl [:phlsa] from comment #20)
> 
> > The problem is, that there is no such thing as the green light next to your
> > webcam for screen sharing. That means the user has no indication for if and
> > what is being shared when the tab he's sharing from is not focused (and even
> > then it's very subtle).
> > That's bad.
> 
> Yes, it's bad. Is it worse than sharing the microphone (which also doesn't
> have a green light)? Both microphone and screen sharing have very obvious
> and serious privacy implications if the user forgets the sharing is
> happening. I don't think this has stopped us from letting web applications
> use the microphone though.

Both are bad, but screen sharing is worse, because it provides a more direct path to the users information. Anyway, we shouldn't justify current shortcomings with the shortcomings of the past.

If the Mac indicator is the straw that breaks the camels back, we could leave it out and just have an indicator on Windows. Then at least 90% of the Fx user base would have a much better experience.
Also, if the floating doorhanger that extends from the global indicator is a huge problem, we could also just switch to the tab that is sharing and automatically open the doorhanger from the URL bar there.
Flags: needinfo?(fluffy)
Flags: needinfo?(fluffy)
Iteration: 33.2 → 33.3
Blocks: 1035577
Feedback provided by Madhava - bug marked as resolved.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Marco Mucci [:MarcoM] from comment #23)
> Feedback provided by Madhava - bug marked as resolved.

Where is Madhava's feedback? I still see pending requests for feedback from Boriss.
Flags: needinfo?(mmucci)
(In reply to Florian Quèze [:florian] [:flo] from comment #24)
> (In reply to Marco Mucci [:MarcoM] from comment #23)
> > Feedback provided by Madhava - bug marked as resolved.
> 
> Where is Madhava's feedback? I still see pending requests for feedback from
> Boriss.

Adding Madhava to the 'needinfo' so he can reply.
Flags: needinfo?(mmucci) → needinfo?(madhava)
Attached image MVP Wireframe v3.1 (obsolete) (deleted) — 
Updated the MVP wireframe as discussed with Florian in meatspace.
Attachment #8450279 - Attachment is obsolete: true
Attachment #8450279 - Flags: feedback?(jboriss)
Attached image MVP Wireframe v3.2 (obsolete) (deleted) — 
Some minor fixes
Attachment #8453794 - Attachment is obsolete: true
Attached image Icons in Mac menu bar (deleted) — 
On Mac, we can put three separate status items into the menu bar that represent the different shared items.
The latest wireframe looks really good.  A few comments:

Green is a colour we reserve for EV certs; i.e., stuff that we know is properly secure.  We have a feature coming up where we have secure media sharing.  I'd like to reserve green here for indicating that.  Can we use orange or something stronger here?  (I'd say red, in the spirit of the red "recording" button, but that might be too attention-grabbing.  We also have to be sensitive to the common red-green blindness in the design; probably by tinting the green slightly toward blue).

The general direction we're heading in doesn't involve sharing of the entire screen.  Sharing a specific application is more likely going to be the only option.  The reason there being that we can then remove Firefox from the list and avoid all of the security issues, until we get to the point where we can do tab sharing securely (or at least more securely).
Florian, here's the text for the tooltips. Let me know if anything is missing.

Left side (camera and microphone):
Your camera and microphone are being shared with webex.com. Click to control sharing.
Your microphone is being shared with webex.com. Click to control sharing.
Your camera is being shared with webex.com. Click to control sharing.

When something is shared with multiple pages:
Your camera and microphone are being shared with 3 pages. Click to control sharing.

Right side (screen sharing):
Your screen is being shared with webex.com. Click to control sharing.
The application Microsoft Powerpoint is being shared with webex.com. Click to control sharing.
(In reply to Martin Thomson [:mt] from comment #29)
> The latest wireframe looks really good.

Thanks :)

> Green is a colour we reserve for EV certs; i.e., stuff that we know is
> properly secure.  We have a feature coming up where we have secure media
> sharing.  I'd like to reserve green here for indicating that.  Can we use
> orange or something stronger here?  (I'd say red, in the spirit of the red
> "recording" button, but that might be too attention-grabbing.  We also have
> to be sensitive to the common red-green blindness in the design; probably by
> tinting the green slightly toward blue).

Sounds reasonable. I'll have to check if there are any other parts of the UI that would be affected by changing that color, but using orange sounds like a good idea.
FYI, camera sharing is using green right now (http://cl.ly/image/3w0p0T2f1N2w). We could change that as part of this effort though.

> The general direction we're heading in doesn't involve sharing of the entire
> screen.  Sharing a specific application is more likely going to be the only
> option.  The reason there being that we can then remove Firefox from the
> list and avoid all of the security issues, until we get to the point where
> we can do tab sharing securely (or at least more securely).

We just had a discussion on vidyo about this. Generally, users will demand sharing an entire screen, because that's what most other products in that space offer.
The result of the discussion was that we can enable sharing Firefox (and the full screen) in 33 because of the whitelisting (only a few hand-picked sites will be able to use screen sharing at all) and make the security aspect a priority for the work for 34.
(In reply to Philipp Sackl [:phlsa] from comment #31)
> The result of the discussion was that we can enable sharing Firefox (and the
> full screen) in 33 because of the whitelisting (only a few hand-picked sites
> will be able to use screen sharing at all) and make the security aspect a
> priority for the work for 34.

I'm not sure that I'm happy with that conclusion, but I suppose that I can live with it.

What are the plans regarding whitelisting?  Is there a bug tracking that?
...I should really read the words on these things, because the implied conclusion here isn't right.

(The wireframe says)
> We should really allow sharing the browser.  Not doing so would be pretty useless
> for two reasons:
> * People would just open a different browser and then share that

This is actually much better from a security perspective than sharing the first-party browser.  Why?  Because the bulk of the security threat comes from the *combination* of being able to see content and being able to control it.  Another browser will be much harder for an adversary to control (not impossible, depending on what is being displayed there, but enough harder that an effective attack would have to rely on social engineering, probably).

> * When the entire screen gets shared, the browser will be shared anyway

This is one of the reasons that we want to avoid sharing the entire screen.  I think that if we have a whitelisted site, then we'll probably want to share anything.  For a drive-by site, the level of risk that is associated with sharing, combined with the difficulty we'd have explaining this to anyone makes entire screen sharing equivalent to same-browser sharing to tab sharing.

The other, less compelling reason is that we want to avoid situations where the user is prompted with only one choice.  That removes some (all) of the active consent, making us less sure that the consent is intentional.  Given that the number of screens has an expected value of ~1, this is a problem we should be trying to avoid.
(In reply to Martin Thomson [:mt] from comment #32)

> What are the plans regarding whitelisting?  Is there a bug tracking that?

Not yet. We are discussing the expected UX here. And bug 1035577 is a breakdown bug where I'll file all the implementation bugs. You may want to cc yourself to the breakdown if you want to see all the pieces.
The code being added in bug 983504 indicates that it's possible to share any combination of camera, microphone, and (screen or app). But the mocks here only allow microphone and (screen or app). Is that to mean we don't want to allow sharing a camera with (screen or app), or that it requires 2 separate permission prompts?

Can we reasonably implement a single request as multiple prompts?
Flags: needinfo?(philipp)
Comment on attachment 8453837 [details]
MVP Wireframe v3.2

Hi, I'm link-surfing and a late-comer to this bug which is already closed, so pardon my poor timing, but my immediate reaction to the screen-sharing wireframe was that it is fairly nondescript and insufficiently alarming considering what was going on. Have we considered a watching eye or something instead? Seeing what I'm doing can be worse than seeing me. Just 2 cents.
(In reply to Justin Dolske [:Dolske] from comment #35)
> The code being added in bug 983504 indicates that it's possible to share any
> combination of camera, microphone, and (screen or app).

As Jan-Ivar's reply to your question in bug 983504 comment 100 indicates, each getUserMedia request can return at most one video stream. Getting app/screen sharing is done by the web app by adding constraints on the kind of video stream it wants to get.

> But the mocks here
> only allow microphone and (screen or app). Is that to mean we don't want to
> allow sharing a camera with (screen or app), or that it requires 2 separate
> permission prompts?

We think the common use case for a web app using screen/app sharing is to first initiate an audio or audio+video call, and then initiate the screen sharing in a second getUserMedia call after the user has clicked some UI.

Requesting screen sharing + the microphone in a single getUserMedia request is an edge case; the current getUserMedia API allows it, so we designed the UI to allow it, even though the UI in that case is slightly awkward. We don't expect this case to be frequently visible for users.

> Can we reasonably implement a single request as multiple prompts?

No, and we are not trying to do that.
Flags: needinfo?(philipp)
(In reply to Jan-Ivar Bruaroey [:jib] from comment #36)
> Comment on attachment 8453837 [details]
> MVP Wireframe v3.2
> 
> Hi, I'm link-surfing and a late-comer to this bug which is already closed,
> so pardon my poor timing, but my immediate reaction to the screen-sharing
> wireframe was that it is fairly nondescript and insufficiently alarming
> considering what was going on. Have we considered a watching eye or
> something instead? Seeing what I'm doing can be worse than seeing me. Just 2
> cents.

I'm not sure if your comment is about the screensharing icon used in the mockup or about something else. If your concern is about the icon, don't worry, the icons in the mockups here are just placeholders, and you'll still have time to provide input in the bug where we'll create the final icons.
(In reply to Florian Quèze [:florian] [:flo] from comment #37)

> > Can we reasonably implement a single request as multiple prompts?
> 
> No, and we are not trying to do that.

Perfect, thanks. Concern withdrawn!
(In reply to Florian Quèze [:florian] [:flo] from comment #37)
> Requesting screen sharing + the microphone in a single getUserMedia request
> is an edge case; the current getUserMedia API allows it, so we designed the
> UI to allow it, even though the UI in that case is slightly awkward. We
> don't expect this case to be frequently visible for users.

The API isn't solid yet.  The latest proposals would not permit that.  On the other hand, one of the proposals would permit the capture of audio output from an application.  Not that we'd be interested in implementing that though.
(In reply to Jan-Ivar Bruaroey [:jib] from comment #36)
> Hi, I'm link-surfing and a late-comer to this bug which is already closed,
> so pardon my poor timing, but my immediate reaction to the screen-sharing
> wireframe was that it is fairly nondescript and insufficiently alarming
> considering what was going on. Have we considered a watching eye or
> something instead? Seeing what I'm doing can be worse than seeing me. Just 2
> cents.

I think that the notification requirements aren't especially high if we get the consent interaction right.  Here I think that we have a little more work to do, but what has been proposed is adequate for an early release.

Ultimately, I think that we need to provide better feedback about what is being shared, probably by showing previews, both in the selection dialogs and in the feedback dialogs.  That's a reasonably meaty technical undertaking, with a fairly low ROI given the current whitelisting approach.
Flags: needinfo?(fluffy)
Depends on: 983504
Attached image MVP Wireframe v3.3 (deleted) — 
Change strings to support window sharing instead of application sharing.
Attachment #8453837 - Attachment is obsolete: true
Flags: firefox-backlog+
When a user selects WebEx from the doorhanger. does it bring up an additional screen from WebEx giving the user an opportunity to see their Privacy Policy? If not, in the third column displaying the doorhanger text in the MVP, can you add a link to WebEx' Privacy Policy in connection with the statement "Would you like to share your screen with webex.com?" This makes it more transparent for users who want to learn more about how WebEx uses their data. 

For the URL, Cisco should let us know if they want the link to go to their main privacy policy (http://www.cisco.com/web/siteassets/legal/privacy_full.html) or to 1 of the 4 WebEx specific notices referenced on the right hand side of the main privacy policy.  

LMK your thoughts on this.

Thanks,
Mika
(In reply to Mika from comment #43)
> When a user selects WebEx from the doorhanger. does it bring up an
> additional screen from WebEx giving the user an opportunity to see their
> Privacy Policy? If not, in the third column displaying the doorhanger text
> in the MVP, can you add a link to WebEx' Privacy Policy in connection with
> the statement "Would you like to share your screen with webex.com?" This
> makes it more transparent for users who want to learn more about how WebEx
> uses their data.

There are a couple of things to consider here.

The first is that we don't do any kind of privacy policy notification for all other uses of media capture, so this seems a bit out of place. 

The second is that this approach doesn't necessarily scale. While we are maintaining a whitelist, it's possible that we could require that requests to be added also require a link to a privacy policy (although I worry about link stability I those cases) -- but if we ever move to a more general security mechanism that doesn't require whitelisting, this kind of thing won't be possible.
(In reply to Adam Roach [:abr] from comment #44)
> (In reply to Mika from comment #43)
> > When a user selects WebEx from the doorhanger. does it bring up an
> > additional screen from WebEx giving the user an opportunity to see their
> > Privacy Policy? If not, in the third column displaying the doorhanger text
> > in the MVP, can you add a link to WebEx' Privacy Policy in connection with
> > the statement "Would you like to share your screen with webex.com?" This
> > makes it more transparent for users who want to learn more about how WebEx
> > uses their data.
> 
> There are a couple of things to consider here.
> 
> The first is that we don't do any kind of privacy policy notification for
> all other uses of media capture, so this seems a bit out of place. 
> 
> The second is that this approach doesn't necessarily scale. While we are
> maintaining a whitelist, it's possible that we could require that requests
> to be added also require a link to a privacy policy (although I worry about
> link stability I those cases) -- but if we ever move to a more general
> security mechanism that doesn't require whitelisting, this kind of thing
> won't be possible.

Good points that I wasn't aware of. Is there another way to give users access to the privacy notices of third party services, like Webex and anyone else on the whitelist? Same issue, if a non-whitelist process under consideration.

One idea, although not very good is that we can include a note in the Firefox Browser Privacy Notice that use of screensharing using third party services is subject to their privacy practices.  But this isn't useful b/c the notice isn't accessible to users at the time of screensharing.

Open to ideas.  
Mika
What does "a 3rd party service" mean here? (I'm also not terribly familiar with "WebEx".)

If the user is on webex.com (as the mocks imply), I'd agree that there doesn't need to be any extra Privacy policy UI. It's pretty clear you're on that web site (i.e., it's in the URL bar), and that implies the site itself is involved in things.
Blocks: 1040061
Philipp - can you add screenshots of what the UI looks like after the user initiates screensharing using WeBEx.  Also, what are the other services that we'll consider whitelisting right now?  Will the UI look different depending on what service the user selects?

"Third Party service" is a service provided by a non-Mozilla entity.  If it's clear to the user that they are using a non-Mozilla service for screensharing, there might not be any issue here.  If it's not clear, then our policy practice is to notify the user.  Seeing the UI after the user starts webex, might answer this.
I think that this is perfectly clear.  The prompt highlights the current page.  (In the example, either "this page" or something like "webex.com".)  The prompt is triggered by navigating to a page, or clicking something on the page.

As to what might be whitelisted, that's going to have to be sites that pass some sort of "trust" test.  That's probably something that :mreavy is tracking, if we are even considering other options.
Component: General → Device Permissions
Flags: needinfo?(madhava)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: