Inconsistency in network panel: connection is secure but displayed icon is the globe instead of the lock

RESOLVED FIXED in Firefox 68

Status

defect
P3
normal
RESOLVED FIXED
4 years ago
2 months ago

People

(Reporter: sole, Assigned: ns19041997)

Tracking

({DevAdvocacy, good-first-bug})

unspecified
Firefox 68

Firefox Tracking Flags

(firefox68 fixed)

Details

(Whiteboard: [DevRel:P3])

Attachments

(3 attachments)

In the network panel, some resources look as "insecure" but they have been transmitted via https using a local server, and the hover tip insists the connection used to fetch that resource was secure.

Who's right?

See screenshots for the hover tips in action
Keywords: DevAdvocacy
Component: Developer Tools → Developer Tools: Netmonitor
Whiteboard: [DevRel:P3]
Product: Firefox → DevTools

I have submitted a patch which replaces the "globe" icon with "lock" for security-state-local. Please review.
(Although I think that the lock icon is supposed to be there as it is a specific case for localhost).

Harald, quick summary for this.

  1. We have special code path that uses the globe icon for requests coming from localhost
    https://searchfox.org/mozilla-central/rev/44a212460990ffffecf50a8e972d3cbde2e7216b/devtools/client/netmonitor/src/components/RequestListColumnDomain.js#43

  2. That code path above also sets this tooltip: "The connection used to fetch that resource was secure"

I don't know why we are actually having an extra icon for localhost connection. We could just remove the special codepath and treat local connections just like any other connection and use the current securityState to decide what icon & tooltip should be there (just like we do for any other connection).

Of course, we can still indicate localhost connections as well (not sure whether it's needed), but that could be independent from whether it's secure/insecure connection.

Thoughts?

Honza

Flags: needinfo?(hkirschner)

One assumption for the lock would potentially be to represent secure context: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#When_is_a_context_considered_secure . http://localhost and file:// paths are both considered secure.

We could just remove the special codepath and treat local connections just like any other connection and use the current securityState to decide what icon & tooltip should be there (just like we do for any other connection).

This seems a good simplification. Not sure why a globe matches localhost, as it implies an outgoing connection. With the statement above, should we still show a lock (not sure if that is what the platform returns)?

Flags: needinfo?(hkirschner) → needinfo?(odvarko)

(In reply to :Harald Kirschner :digitarald from comment #5)

This seems a good simplification. Not sure why a globe matches localhost, as it implies an outgoing connection. With the statement above, should we still show a lock (not sure if that is what the platform returns)?

Since http://localhost and file:// paths are both considered secure let's use lock for them (and perhaps the platform already returns such state, which would simplify the code base).

Honza

Flags: needinfo?(odvarko)
Keywords: good-first-bug

@Neha: are you still working on this? Should I assign it to you?

Honza

Flags: needinfo?(ns19041997)

@Honza: Yup, I would like to work on this.
It can be assigned to me.
Thanks!

Flags: needinfo?(ns19041997)
Assignee: nobody → ns19041997
Status: NEW → ASSIGNED

@Neha, please see my comment in Phab. The patch is almost ready.

Honza

Flags: needinfo?(ns19041997)
Pushed by jodvarko@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c9f246ee7d19
Fixes inconsistency in network panel: connection is secure but displayed icon is the globe instead of the lock r=Honza
Flags: needinfo?(ns19041997)
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
You need to log in before you can comment on or make changes to this bug.