Ash Grigas Assignee
	Description • 10 years ago

With control center V1 in implementation, we need to look at the next iteration of it. Specifically how it encompasses other notifications and state changes in the identity block. This ticket is to outline the initial UX requirements for V2 of control center.

	Ash Grigas Assignee
	Comment 1 • 10 years ago

What Control Center 1 brought us:
More usable and readable site identity
A place for Tracking Protection when it ships

Things we could focus on for CC2
Permissions and permission prompts
Passwords

Things to consider for CC2:
Lost/unnoticed permission prompts (esp. camera & mic)
Push notifications
Storage permissions
Full-screen permissions (WIP) http://people.mozilla.org/~mverdi/projects/fullscreen/
Asking for multiple permissions at once
Microphone and camera permissions

Materials
CC1 spec: http://people.mozilla.org/~shorlander/mockups/Control-Center/Control-Center-i01-02.html

	Marco Mucci [:MarcoM]
	Comment 2 • 10 years ago

Hi Aislinn, can you provide a point value.

	Ash Grigas Assignee
	Comment 3 • 10 years ago

(In reply to Marco Mucci [:MarcoM] from comment #2)
> Hi Aislinn, can you provide a point value.

13

	Ash Grigas Assignee
	Comment 4 • 10 years ago

This is one of several mocks will put wiki link in comment as well

	Ash Grigas Assignee
	Comment 5 • 10 years ago

All breakdown components are documented here:
https://mana.mozilla.org/wiki/display/FIREFOX/Polaris+Control+Center+UX

Go to Section labeled Control Center V2.

Breakdown includes permission notification, control center overview and detail panel for the shown permissions. Comments can be added in the Notes column of the wiki or on this bug.

	Marcos Caceres [:marcosc]
	Comment 6 • 9 years ago

Please don't detach the notification from the browser chrome, otherwise it's easy for sites to create fake permission dialogs. It should be clear that it's the browser asking for the permission on-behalf of the site, rather than the site itself.

	Ash Grigas Assignee
	Comment 7 • 9 years ago

(In reply to Marcos Caceres [:marcosc] from comment #6)
> Please don't detach the notification from the browser chrome, otherwise it's
> easy for sites to create fake permission dialogs. It should be clear that
> it's the browser asking for the permission on-behalf of the site, rather
> than the site itself.

This is just a breakdown ticket not the final visual design. The styling of the doorhanger is not finalized. Thanks for your concern.

	(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo
	Comment 8 • 9 years ago

Comment on attachment 8605266 [details]
notification behavior.png

This is a real improvement, both in the way that it is surfaced in the ID block and in particular in how we deal with multiple notifications coming up at once.

There are a couple of points to clarify:
- I assume that the prompts would not go away automatically if the user clicks somewhere (which is what they currently do).
- When selecting »Select what I share«, the user goes from a prompt state (where changes are applied with the click of a button) into a selection state (where changes are applied immediately). Not sure if that's actually a problem, but I want to make sure that it's a deliberate choice.
- Is it a deliberate choice that there's no more »Yes, always« and »No, never« options?
- As you and Marcos noted, we might need to change the appearance of the prompt.

Marcos, to quickly jump into that: What kinds of attacks are we specifically worried about? What benefit would an attacker get from emulating a Firefox permissions prompt?
Not disagreeing that we should address it, I just want to understand the use cases.

	(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo
	Comment 9 • 9 years ago

NI Ash about the points in the previous comment

	jaramat
	Comment 10 • 9 years ago

(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #8)

I'm not really worried about security of your design, no. It's simply that the user might think the notification/prompt is a part of the page and therefore not pay attention to it. (Not to mention it looks ugly as sin and even more out of place than the current design of about:preferences. What's wrong with current doorhangers anyway, the ones with an arrow pointing to the icon in the url bar AND is overlaying an insignificant yet visible bit of the browser UI? We even have a swood opening animation for them.)

	Marcos Caceres [:marcosc]
	Comment 11 • 9 years ago

(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #8)
> Marcos, to quickly jump into that: What kinds of attacks are we specifically
> worried about?

This isn't about a particular attack. It's about providing users with a means of distinguishing between what is a browser's prompt and what is a web page's prompt. The current proposal would make it impossible to for the user to know who they are "talking" to. So, for instance, a page-generated popup could appear and say: 

============================
     FIREFOX PROMPT

Firefox would like to store
your credit card number to 
save you time:

[___________________________]

         <save>

=============================

Or

==============================
      FIREFOX SECURE SITE

Mozilla Firefox has checked this 
site is safe and secure. 
   
        <   OK   >

==============================

The above two, being BS, of course. 

>  What benefit would an attacker get from emulating a Firefox
> permissions prompt?

In a cross-site scripting attack, it could be kinda devastating as the user would have no trust in the browser chrome (because there is no way to determine if it's the UA asking or if the site is faking it).  

> Not disagreeing that we should address it, I just want to understand the use
> cases.

Maybe even sneaky attacks like: 

1. ask for geolocation.
2. ask for person's age/phone number/, but pretend it's the browser asking.

============================================
   Firefox 

Firefox can help you fill out forms more quickly!

Name:
Phone number:
Credit card:

==============================================

	Ash Grigas Assignee
	Comment 12 • 9 years ago

(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #8)
> Comment on attachment 8605266 [details]
> notification behavior.png
> 
> This is a real improvement, both in the way that it is surfaced in the ID
> block and in particular in how we deal with multiple notifications coming up
> at once.
> 
> There are a couple of points to clarify:
> - I assume that the prompts would not go away automatically if the user
> clicks somewhere (which is what they currently do).
> - When selecting »Select what I share«, the user goes from a prompt state
> (where changes are applied with the click of a button) into a selection
> state (where changes are applied immediately). Not sure if that's actually a
> problem, but I want to make sure that it's a deliberate choice.
> - Is it a deliberate choice that there's no more »Yes, always« and »No,
> never« options?
> - As you and Marcos noted, we might need to change the appearance of the
> prompt.
> 
> Marcos, to quickly jump into that: What kinds of attacks are we specifically
> worried about? What benefit would an attacker get from emulating a Firefox
> permissions prompt?
> Not disagreeing that we should address it, I just want to understand the use
> cases.

Thanks for reviewing this. To clarify:
1. User cannot dismiss this dialogue by clicking anywhere, they must interact with the shown options
2. If the user chooses 'Select what to share' they go to the open doorhanger panel showing all permissions.Nnothing changes until they interact with the highlighted drop-down menus
3. I adjusted the language to make it simpler and since the default behavior is to accept always, I don't think we need to be heavy handed with the language - it makes it more complicated to read/think about
4. Styling for dialogues can certainly revert if needed to an anchored arrow - didn't realize that was an issue initially...