[UX] Overhaul the site identity and connection information in the identity panel

RESOLVED DUPLICATE of bug 1125402

Status

()

defect
RESOLVED DUPLICATE of bug 1125402
6 years ago
4 years ago

People

(Reporter: dao, Unassigned)

Tracking

(Blocks 1 bug, {uiwanted})

Trunk
Points:
8
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ux])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
attachment 765397 [details] contains some mockups for this. Is this final? Has it been discussed with security folks?
Flags: needinfo?(jboriss)

Comment 1

6 years ago
I think we need to show examples of what the site identity permissions look like for all the potential cases, such as when there's Mixed Content on the page, etc. Boriss, I can help you hash out these cases with whoever on the security team is interested in laying them out with us :)
(Reporter)

Comment 2

6 years ago
Note that this bug is specifically about the site identity and connection security part of the popup.
(Reporter)

Updated

6 years ago
Blocks: 588685
(Reporter)

Comment 3

5 years ago
This needs final mockups or clarification that the existing mockup is good to go.
Keywords: uiwanted
Larissa is right - the mockups need to show more cases. Also, the text for the non-encrypted case shouldn't say the connection is encrypted to prevent eavesdropping.

Here are the cases I can think of off the top of my head:
- no encryption
- domain validation certificate
- domain validation certificate with mixed content
- extended validation certificate (green)
- extended validation certificate with mixed content (I think this would fall back to look like dv with mixed content, but I'm not sure)
- bad certificate that has been overridden by the user (e.g. domain mismatch, expired certificate, etc.)
- bad certificate with override with mixed content

Comment 5

5 years ago
What about Opportunistic Encryption in HTTP/2? This is a bit down the road and can be deferred, and I'm not even sure if this needs or should have a distinct status at all, but it should be taken into consideration.

I don't know who can give input on this … :hurley, :mcmanus, you did the implementation of HTTP/2 – is there something different about it that may require a separate indication?
Flags: needinfo?(mcmanus)
Flags: needinfo?(hurley)

Comment 6

5 years ago
Unauthenticated TLS (let's not call it opportunistic encryption, since that could, in fact, include fully-authenticated TLS as we know it) likely should not (IMHO) have any UI different from what we do for plain, non-encrypted http. It's not something the user should have to know about, and we don't want to confuse the security situation any further.

Not to mention the fact that it's in no way guaranteed that unauthenticated TLS will become part of HTTP/2 to begin with :)
Flags: needinfo?(hurley)
Flags: needinfo?(mcmanus)

Comment 7

5 years ago
If the connection ends up fully authenticated, I hope it involves a "redirect" to https (without the round-trip usually implied by the term), so bookmarking and sharing give the secure page.
(In reply to Jesse Ruderman from comment #7)
> If the connection ends up fully authenticated, I hope it involves a
> "redirect" to https (without the round-trip usually implied by the term), so
> bookmarking and sharing give the secure page.

approaches to doing http:// over TLS do not change the scheme to https:// ; it is merely a routing change for transport over a better link. http/2 carries the scheme explicitly with each request, so this is unambigous to the server. The server may explicitly want to stay on http:// for reasons of mixed-content or even SNI load balancing concerns (depending on how this was bootstrapped).

if it were authenticated we might be able to honor key pins or even STS. That's not fleshed out yet and would probably be added incrementally.
Summary: Identity panel redesign → [UX] Identity panel redesign
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
Whiteboard: [ux] p=0 → [ux] p=8
Whiteboard: [ux] p=8 → [ux] p=8 [qa-]
Assignee: nobody → jboriss
Flags: needinfo?(jboriss)
Status: NEW → ASSIGNED
Whiteboard: [ux] p=8 [qa-] → [ux] p=8 s=33.1 [qa-]
Attached design is ready for implementation, aside from needing to get that icon.  I'll file a followup and look for an icon (we may have one that works already).
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 10

5 years ago
Comment on attachment 8444120 [details]
Mockup: Site identity redesign

YES please use the sloth somewhere! E.g. for high profile sites that don't use TLS or something ;)

Anyhow, how is the identity information for EV certificates supposed to be displayed? E.g. in Bugzilla, the identity panel currently displays the owner (MoFo) and its location (MV, CA, US[1]) as well as the signee (DigiCert). Also, non-EV certs are presented with a blue-ish base color to indicate a non-optimal security level (the optimal security level being "green"); the design seems to propose the "green" level for non-EV certificates – is that intentional?

I'd propose to use the (awesome!) design by :Boriss and merge it with the current way of displaying EV-certs (with additional identity + signee info) using the green check icon, and use the design in the attachment for non-EV-certs but with a blue icon (preferably the sloth![2] or the check icon) and all-black text. 

Can someone of the sec team review this, please?


[1] I wonder why "US" is used instead of "USA" – that seems wrong …
[2] I know I know, the sloth may confuse some. But can we at least have it as the identity icon for non-EV certs or unsigned domains in Nightly, please? :D
Flags: needinfo?(jboriss)
(Reporter)

Comment 11

5 years ago
(In reply to Florian Bender from comment #10)
> Can someone of the sec team review this, please?

Right, see my question in comment 0. Without that this isn't ready for implementation.

(In reply to Larissa Co [:lco] from comment #1)
> I think we need to show examples of what the site identity permissions look
> like for all the potential cases, such as when there's Mixed Content on the
> page, etc. Boriss, I can help you hash out these cases with whoever on the
> security team is interested in laying them out with us :)

The new mockup still doesn't seem comprehensive enough.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: [UX] Identity panel redesign → [UX] Overhaul the site identity and connection information in the identity panel

Comment 12

5 years ago
The mockup also misses all the visual part (ie. icons and Australis panel styling)
Status: REOPENED → ASSIGNED
Iteration: --- → 33.2
Points: --- → 8
QA Whiteboard: [qa-]
Whiteboard: [ux] p=8 s=33.1 [qa-] → [ux]
A couple of other cases that should be covered:
- mixed content
- a domain validation site (as opposed to an extended validation site, as (presumably) shown. On that topic - do we want to include the organization field for extended validation? (for example, on bugzilla the organization is "Mozilla Foundation")).
Iteration: 33.2 → ---
Points: 8 → ---
Iteration: --- → 33.2
Points: --- → 8
(Reporter)

Updated

5 years ago
Blocks: 1014736
See Also: 1014736
Iteration: 33.2 → 33.3
Iteration: 33.3 → 34.1
(Reporter)

Updated

5 years ago
Iteration: 34.1 → ---
(Reporter)

Updated

5 years ago
Assignee: jboriss → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(jboriss)

Comment 14

5 years ago
Any chance this may get picked up again?
Bug 1125402 and friends will rework the identity panel, feedback appreciated. Should we dupe this?
(Reporter)

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1125402
You need to log in before you can comment on or make changes to this bug.