Broken lock icon in developer tools

[Richard Barnes]

Hey folks,

In the network panel of the developer tools, there's an icon next to the
host name in the "domain" column, which indicates whether the load was
secure or not. Currently, that icon is a lock if the connection was
secure, and a globe if the connection was not secure.

We (the security and UX teams) have been trying to get rid of the globe in
favor of indicators that more explicitly indicate that the connection was
not secure. We can't yet do that in the URL bar, but it seems like we
should be able to in the developer console. After all, we display tons of
security warnings there that we don't make generally visible to users.

We already have a broken lock icon that's used when the user has chosen to
disable mixed content blocking.

Could we use that broken lock icon the developer console for insecure
connections?

Thanks,
--Richard

[Tanvi Vyas]

That's a nice idea Richard!

On 8/13/15 9:12 AM, Aislinn Grigas wrote:
> I'm fine with that. Let's file a bug and see how we can prioritize it.
>
> A

> --
> *Aislinn Grigas* /*(Ash*/)
> Senior Interaction Designer
> Firefox Privacy and Security Team | *m* 978-930-3729 | *irc* aislinn

[J. Ryan Stinnett]

On Thu, Aug 13, 2015 at 11:09 AM, Richard Barnes <rba...@mozilla.com> wrote:
> Could we use that broken lock icon the developer console for insecure
> connections?

Seems like a good idea to me.

- Ryan

[Brian Grinstead]

I agree we have leeway to be more aggressive about how we show connection status in DevTools compared to the identity bar. I have a couple of thoughts:

1) There is some visual consistency now between the icon you see in the URL bar and the icon you see in requests in the netmonitor. Maybe no problem, but this would get rid of that.
2) Lots of people are probably developing over http on localhost or even on file uris. In this context is a ‘scary’ icon too strong of a message?

Thanks,
Brian

> On Aug 13, 2015, at 12:40 PM, Tanvi Vyas <ta...@mozilla.com> wrote:
>
> That's a nice idea Richard!
>
> On 8/13/15 9:12 AM, Aislinn Grigas wrote:
>> I'm fine with that. Let's file a bug and see how we can prioritize it.
>>
>> A
>>
>> On Thu, Aug 13, 2015 at 12:09 PM, Richard Barnes <rba...@mozilla.com <mailto:rba...@mozilla.com>> wrote:
>>
>> Hey folks,
>>
>> In the network panel of the developer tools, there's an icon next
>> to the host name in the "domain" column, which indicates whether
>> the load was secure or not. Currently, that icon is a lock if the
>> connection was secure, and a globe if the connection was not secure.
>>
>> We (the security and UX teams) have been trying to get rid of the
>> globe in favor of indicators that more explicitly indicate that
>> the connection was not secure. We can't yet do that in the URL
>> bar, but it seems like we should be able to in the developer
>> console. After all, we display tons of security warnings there
>> that we don't make generally visible to users.
>>
>> We already have a broken lock icon that's used when the user has
>> chosen to disable mixed content blocking.
>>

>> Could we use that broken lock icon the developer console for
>> insecure connections?
>>

>> Thanks,
>> --Richard
>>
>>
>>
>>
>> --
>> *Aislinn Grigas* /*(Ash*/)
>> Senior Interaction Designer
>> Firefox Privacy and Security Team | *m* 978-930-3729 | *irc* aislinn
>

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools

[Richard Barnes]

Filed bug and posted patch, r? :jryans

https://bugzilla.mozilla.org/show_bug.cgi?id=1194561

[Hallvord Reiar Michaelsen Steen]

On Thu, Aug 13, 2015 at 6:09 PM, Richard Barnes <rba...@mozilla.com> wrote:

> We (the security and UX teams) have been trying to get rid of the globe in
> favor of indicators that more explicitly indicate that the connection was
> not secure. We can't yet do that in the URL bar, but it seems like we
> should be able to in the developer console. After all, we display tons of
> security warnings there that we don't make generally visible to users.
>
> We already have a broken lock icon that's used when the user has chosen to
> disable mixed content blocking.
>

> Could we use that broken lock icon the developer console for insecure
> connections?
>

If you do this, how would you flag "https request with security problem"? I
suppose it's still useful to distinguish between plain old http URLs and
URLs that the developer intended to be https but where the certificate is
bad or some other issue made the connection insecure.
-Hallvord

[Karl Dubost]

Le 14 août 2015 à 04:50, Brian Grinstead <bgrin...@mozilla.com> a écrit :
> 2) Lots of people are probably developing over http on localhost or even on file uris. In this context is a ‘scary’ icon too strong of a message?

I wonder if this is not part of another feature.
We can imagine for developers testing in local a config panel where they could configure profiles for the sites they are developing.

[example.com]
local http: http://localhost:8080/
remote http: https://example.com/
local folder: /somewhere/over/the/rainbow
(insert here any other useful config)

When developing the devtools would modify the behavior depending on that config and even give useful warnings of the type. "This resource once on the production site might create a security issue. Learn how to fix it…"

--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Andrew Sutherland]

On Thu, Aug 13, 2015, at 03:50 PM, Brian Grinstead wrote:
> 2) Lots of people are probably developing over http on localhost or even
> on file uris. In this context is a ‘scary’ icon too strong of a message?

Note that localhost and file URLs are already classified as "potentially
trustworthy":
https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy.
File URIs do get tricky with the same origin policy, but it's
reasonably sane in Gecko. See
https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file%3A_URIs

Andrew

[Richard Barnes]

On Sun, Aug 16, 2015 at 7:09 PM, Karl Dubost <kdu...@mozilla.com> wrote:

>
> Le 14 août 2015 à 04:50, Brian Grinstead <bgrin...@mozilla.com> a écrit
> :

> > 2) Lots of people are probably developing over http on localhost or even
> on file uris. In this context is a ‘scary’ icon too strong of a message?
>

> I wonder if this is not part of another feature.
>

Yeah, I think that's right. The globe icon right now doesn't indicate
"this is secure and the security didn't work", it indicates "we didn't even
try to be secure". So at the very least, we're not *losing* any
functionality here.

[J. Ryan Stinnett]

Sami also pointed this out in the bug. We currently distinguish 4
security states in the Net Monitor:

1. HTTP request, no attempt made at security: globe icon
2. HTTPS request, security working correctly: green lock icon
3. HTTPS request, succeeded but not very secure (RC4, etc.): gray lock
w/ yellow warning triangle icon
4. HTTPS request, failed due to security issue (cert invalid, etc.):
broken lock icon

If we move ahead with this change state 1 and 4 would use the same
icon, and it would become harder to notice the case of "tried to be
secure, but it failed" (state 4).

Do we think it's important to keep this distinction clear?

- Ryan

[Richard Barnes]

How do we indicate things like "HTTP request, couldn't connect"? It seems
like you could bin the failures of the type you're talking about in with
that, and use something like
"browser/themes/shared/controlcenter/warning-yellow.svg" instead of abusing
a security state.

BTW, I think the use of the broken lock icon in (4) is actually wrong. It
gives the broken lock a completely different semantic than it has in the
URL bar. In that context, it means "you have opted out of security", vs.
"security failed". So it's actually a better semantic match to use the
broken lock for (1) rather than (4).

Conveniently, the patch in the bug fixes that issue :)


>
> - Ryan
>

[Brian Grinstead]

> On Aug 16, 2015, at 5:28 PM, Andrew Sutherland <asuth...@asutherland.org> wrote:
>
> On Thu, Aug 13, 2015, at 03:50 PM, Brian Grinstead wrote:

>> 2) Lots of people are probably developing over http on localhost or even
>> on file uris. In this context is a ‘scary’ icon too strong of a message?
>

> Note that localhost and file URLs are already classified as "potentially
> trustworthy":
> https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy.
> File URIs do get tricky with the same origin policy, but it's
> reasonably sane in Gecko. See
> https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file%3A_URIs

Do we somehow distinguish between localhost http connections and non-trustworthy ones? I don’t believe we do that anywhere in the UI (either in the icon we show in the identity block, the text in the Control Center, or the netmonitor). If the platform has a way to distinguish those connection types it might be nice to surface it somewhere within the netmonitor.

FWIW, I was reminded that we don’t even show file URI traffic in the netmonitor so we don’t need to worry about that.

Brian

[Brian Grinstead]

> On Aug 17, 2015, at 6:18 AM, Richard Barnes <rba...@mozilla.com> wrote:
>
> On Sun, Aug 16, 2015 at 7:09 PM, Karl Dubost <kdu...@mozilla.com> wrote:
>
> Le 14 août 2015 à 04:50, Brian Grinstead <bgrin...@mozilla.com> a écrit :

> > 2) Lots of people are probably developing over http on localhost or even on file uris. In this context is a ‘scary’ icon too strong of a message?
>

> I wonder if this is not part of another feature.
>
> Yeah, I think that's right. The globe icon right now doesn't indicate "this is secure and the security didn't work", it indicates "we didn't even try to be secure". So at the very least, we're not *losing* any functionality here.
>
> We can imagine for developers testing in local a config panel where they could configure profiles for the sites they are developing.
>
> [example.com]
> local http: http://localhost:8080/
> remote http: https://example.com/
> local folder: /somewhere/over/the/rainbow
> (insert here any other useful config)
>

It’s an interesting feature idea, and it sounds somehow related into resource mapping and local file editing / saving changes back to disk which has been discussed at some length. See the most recent thread here: https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/BCb2lZonQo8. But that's a big project that will take some time, and in the meantime it doesn’t address the concern. That is, by showing the broken lock on local http connections we are taking a valid and common developer workflow and may be making it appear that something has gone wrong.

It’s also overloading the meaning of that broken icon to mean both “this page is supposed to be secure but it didn’t work” (identity block with MCB disabled and active content allowed) and “we didn’t even try to be secure on this page”. Is this the end result that we want to get to eventually for the URL bar, and you are proposing that we just do it first in the netmonitor because of challenges with changing the top-level UI?

At the least I think we should be show the broken lock icon on http requests on https://people.mozilla.org/~tvyas/mixeddisplay.html or https://people.mozilla.org/~tvyas/mixedcontent.html (with MCB disabled).

Brian

[Richard Barnes]

On Mon, Aug 17, 2015 at 4:12 PM, Brian Grinstead <bgrin...@mozilla.com>
wrote:

This bug/discussion is deliberately developer-focused. User are a
different audience, with different considerations.

--Richard


>
> Brian

[Brian Grinstead]

Right, and my concern is developer-focused. Also, the thread started with:

> We (the security and UX teams) have been trying to get rid of the globe in
> favor of indicators that more explicitly indicate that the connection was
> not secure. We can't yet do that in the URL bar, but it seems like we
> should be able to in the developer console

That implies that there is a plan to make this change or some related one to the URL bar eventually. I’m curious what that plan is, because it could affect the best way to proceed in DevTools.

Brian

[Richard Barnes]

On Mon, Aug 17, 2015 at 4:42 PM, Brian Grinstead <bgrin...@mozilla.com>

The plan is *eventually* to shift from the globe to the broken lock icon
for http-schemed navigations. But like 60% of navigations still have that
propertly, so it's not viable.

We don't need to shield developers the same way. This proposal just puts
developers into the future :)

--Richard



>
> Brian

[Jeff Griffiths]

I think the biggest concern that people have pointed out is the re-use
of the lock icon. By showing plain ol' http as a broken lock icon we
create a visual problem, let's call it 'lock fatigue', wherein to the
developer, when they look at this column in the netmonitor, all they
will see is a sea of somewhat visually differentiated locks. Our goal
here should be to help developers quickly differentiate between
different kinds of problems.

We talked about there being a few different possible states for a request:

* localhost / 127.0.0.1 requests
* http requests
* https requests that have ssl / cert problems
* https requests that are 100% valid

There may be be a 5th state we should consider:

* top-level https requests that load insecure content

What I think we want here is two things:
* clear visual differentiation between the above
* great text warnings to accompany each**

Jeff


** we should ensure that localizations of these strings are reviewed as well

[Tanvi Vyas]

Not many people "disable protection" and load mixed active content, so I
don't think we should worry about people confusing the meanings of the
crossed out lock for http and the crossed out lock for mixed active
content on HTTPS. The latter is rare and unless the developer turns
mixed content blocking off completely, they will be aware that they have
just disabled protection.

I do understand the concern of 'lock fatigue'. Perhaps there is
something other than a crossed out lock that we could use for HTTP
connections in the network monitor. A yield sign, a minus sign, an
eavesdropping ear? Perhaps UX can come up with something.

[Richard Barnes]

On Mon, Aug 17, 2015 at 10:27 AM, Richard Barnes <rba...@mozilla.com>
wrote:

>
>

> On Mon, Aug 17, 2015 at 10:18 AM, J. Ryan Stinnett <jry...@gmail.com>

> wrote:
>
>> On Sun, Aug 16, 2015 at 5:35 AM, Hallvord Reiar Michaelsen Steen

>> <hst...@mozilla.com> wrote:

>> > On Thu, Aug 13, 2015 at 6:09 PM, Richard Barnes <rba...@mozilla.com>
>> wrote:
>> >
>> >> We (the security and UX teams) have been trying to get rid of the
>> globe in
>> >> favor of indicators that more explicitly indicate that the connection
>> was
>> >> not secure. We can't yet do that in the URL bar, but it seems like we

So I did my research, and it turns out that failed HTTP requests just
result in the globe icon. To be consistent with that, we would just show
the lock, or maybe a gray lock instead of green. I've updated the patch on
the bug to:

- Show a warning triangle for HTTPS we refuse to connect to
- Show a red square for the status when we can't connect (e.g., due to a
security or network failure)

That way we have two clear states for HTTPS (ok, weak, failure) and three
clear states for HTTP (nonsecure and failure), and any case where we fail
to connect is a red square. Obviously, you can distinguish between "red
square - failed to connect" and "red square - HTTP error" by the presence
of the HTTP error code.

This seems like a pretty clear iconography to me. In fact, much clearer
than what we have now, where there's no indication of failure when you fail
to connect to an HTTPS site.

--Richard

[Tim Nguyen]

As I mentioned on IRC, using the lock everywhere will create confusion, as we always used the lock for https, no matter how broken it is, in the urlbar. Introducing the lock for http will likely confuse people.

We should just ditch the lock, since it's only confusing things. I have a simple proposal that passes the message in a straightforward way.

Good & bad are words we understand pretty well, so why not use that for representation ?

Anyway, here it is :
https://jsfiddle.net/ntim/ny942sxm/embedded/result/

- The "good" icon is used when everything is perfect (secure https).
- The "warning" icon is used when there are some small security problems (broken https, mixed content)
- The "bad" icon is used when the page isn't secure (aka http)
- The "neutral" icon is used when we can't warn the dev about anything yet, since the dev isn't at the stage of debugging security yet. (localhost, file://)

[J. Ryan Stinnett]

(Copying my recent bug comment, just to keep people in the loop...)

I am tempted to accept Richard's revised proposal (attached to the
bug), as we're not losing data by merging states (like we did in the
previous version) and it seems like an overall improvement to me.

On the whole, I think this discussion has highlighted that we really need:

* Text tooltips to precisely explain the meaning of each icon
* UX should spend some time thinking deeply about the specific icons
we should use

But, I think those could be handled as follow ups to this.

The one unresolved issue I see from our IRC discussion is the
treatment of localhost URLs. This current version gives HTTP to
localhost a broken lock. Is this issue a blocker to making a change
here, after reviewing the comparison images?

- Ryan

[Richard Barnes]

On Mon, Aug 24, 2015 at 6:29 PM, Aislinn Grigas <agr...@mozilla.com> wrote:

> Can you clarify what you mean by 'red square'? I'm sure we can find a
> connection error icon if need be...
>

There are two axes here: The simple "what happened to the connection" icon
on the left side, and the "security state" icon in the middle. The red
square is an already-existing icon; I just made its use more consistent.


> What is the proposal for the 2 https vs 3 http icons? Design should review
> them before this launches.
>

The security states and icons as they exist in the current patch are:

1. HTTPS OK - green lock
2. HTTPS weak - grey lock with yellow warning triangle
3. HTTPS failed - grey warning triangle
4. HTTP OK - struck-through lock
5. localhost - globe

Before: https://bug1194561.bmoattachments.org/attachment.cgi?id=8650096
After: https://bug1194561.bmoattachments.org/attachment.cgi?id=8652046

Jeff already filed a follow-up bug for review of these icons:
https://bugzilla.mozilla.org/show_bug.cgi?id=1195839



> A

> --
> *Aislinn Grigas* *(Ash*)

[Jeff Griffiths]

On Mon, Aug 24, 2015 at 4:04 PM, Richard Barnes <rba...@mozilla.com> wrote:
...

> The security states and icons as they exist in the current patch are:
>
> 1. HTTPS OK - green lock
> 2. HTTPS weak - grey lock with yellow warning triangle
> 3. HTTPS failed - grey warning triangle
> 4. HTTP OK - struck-through lock
> 5. localhost - globe
>
> Before: https://bug1194561.bmoattachments.org/attachment.cgi?id=8650096
> After: https://bug1194561.bmoattachments.org/attachment.cgi?id=8652046

This looks pretty great to me!