Closed Bug 1154742 Opened 9 years ago Closed 9 years ago

Breakdown: Version 2 of control center UX design

Categories

(Firefox :: General, defect)

x86
macOS
defect
Not set
normal
Points:
13

Tracking

()

RESOLVED FIXED
Iteration:
41.1 - May 25
Tracking Status
firefox40 --- affected

People

(Reporter: agrigas, Assigned: agrigas)

References

Details

Attachments

(1 file)

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.
Flags: firefox-backlog?
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
Hi Aislinn, can you provide a point value.
Status: NEW → ASSIGNED
Iteration: --- → 40.2 - 27 Apr
Flags: qe-verify-
Flags: needinfo?(agrigas)
Flags: firefox-backlog?
Flags: firefox-backlog+
(In reply to Marco Mucci [:MarcoM] from comment #2)
> Hi Aislinn, can you provide a point value.

13
Flags: needinfo?(agrigas)
Points: --- → 13
Iteration: 40.2 - 27 Apr → 40.3 - 11 May
Blocks: 1161553
Iteration: 40.3 - 11 May → 41.1 - May 25
Depends on: 1129061
This is one of several mocks will put wiki link in comment as well
Attachment #8605266 - Flags: ui-review?(shorlander)
Attachment #8605266 - Flags: ui-review?(philipp)
Attachment #8605266 - Flags: ui-review?(mverdi)
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.
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.
(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.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
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.
Flags: needinfo?(mcaceres)
Attachment #8605266 - Flags: ui-review?(shorlander)
Attachment #8605266 - Flags: ui-review?(philipp)
Attachment #8605266 - Flags: ui-review?(mverdi)
Attachment #8605266 - Flags: ui-review+
NI Ash about the points in the previous comment
Flags: needinfo?(agrigas)
(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.)
(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:

==============================================
Flags: needinfo?(mcaceres)
(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...
Flags: needinfo?(agrigas)
Blocks: 675533
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: