
Updated Firefox Security Indicators - robin_reala
https://blog.mozilla.org/tanvi/2016/01/26/updated-firefox-security-indicators/
======
K0nserv
Even more interesting: In the current Firefox nightly inputs with
`type="password"` on insecure origins are being marked explicitly as insecure.
This also includes common anti patterns such as loading an iframe from a
secure origin on an insecure page.

There's a screenshot of this on my latest blog post[1] and another article[2]
on this topic.

I am very happy to see browser vendors pushing for HTTPS adoption and forcing
the hands of developers. Further highlighting poor security like this also
means that users are made aware and can opt out of using websites with poor
security practices.

1: [https://hugotunius.se/2016/01/24/how-browser-vendors-are-
pus...](https://hugotunius.se/2016/01/24/how-browser-vendors-are-pushing-for-
https-adoption.html)

2: [https://www.fxsitecompat.com/en-CA/docs/2015/non-https-
sites...](https://www.fxsitecompat.com/en-CA/docs/2015/non-https-sites-
containing-login-form-will-be-marked-insecure/)

~~~
mikegerwitz
This is a good, important feature.

Do you know what the plans are for enabling this in all editions of Firefox?

~~~
DCoder
The old plan was to enable it in Fx 44 (the one that was just released). But a
couple of bugs caused a delay and it was pushed back. It was just enabled in
nightly/dev builds [0], so Fx 46 will probably have it.

[0]:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10](https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10)

~~~
K0nserv
Fx 46 is scheduled to be released on the 19th of April FYI
[https://wiki.mozilla.org/RapidRelease/Calendar](https://wiki.mozilla.org/RapidRelease/Calendar)

------
wooptoo
Somewhat off-topic: I feel that Firefox has improved significantly lately,
even though it ceased to be the "star" browser a while ago. Its usability is
much better than other browsers. On Linux for example, it integrates with GTK
and the rest of the OS seamlessly. Also websites tend to display and function
more accurately than in Chrome. This is subjective, it might be just me who
experienced more broken websites lately.

~~~
_asummers
I have noticed that Firefox on Android seems to keep up much better on bigger
pages. I regularly browse SBNation sites and Chrome locks up to the point that
I have to kill the entire browser. Firefox handles it much better, also in my
anecdotal experience. That it allows you to install plug-ins like uBlock is
simply a bonus.

That being said, the performance on OSX at my last check seemed to be inferior
to Chrome unfortunately. The development tools are still inferior, too. I want
to move away from Chrome on OSX but still can't justify it.

------
phlo
I disagree with their rationale in changing the padlock used to indicate a DV
certificate from grey to green (and thus mirroring EV certs) to a point: Yes,
the _connection_ is secure, but given the numerous free and automated options
to obtain DV certificates, phishing sites are going to increasingly use TLS,
and mostly do so using DV certificates.

I guess this boils down to me actually favouring a clear divide between EV and
DV. My EV connection to bankofamerica.com should be as visually different from
the DV connection to the phishing site bank0famer1ca.com as possible. As it
is, the Firefox UI improves visibility of encryption while I think it might be
more appropriate to improve the differentiation between encryption and
authentication.

As for all the other states: good work. The new iconography seems more
streamlined and clear to me.

~~~
_nedR
For me the presence of the organisations name in green letters emphasizes the
difference. (Besides the green/grey lock difference alone is small enough to
miss)

The UI choice i don't like is having a hazard sign for secure websites with
mixed active content blocked . Hazard sign implies some hazard exists - but in
this case the hazard has been averted, so why show a hazard sign still?

~~~
phlo
> Hazard sign implies some hazard exists - but in this case the hazard has
> been averted, so why show a hazard sign still?

The way I see it, the browser actively blocked a hazardous action. The site
continues to be hazardous, and another browser might not properly block the
action in question. As long as the site is trying to do hazardous things, it
should be considered as such (and warned against).

------
leeoniya
what i really want is an indicator of how many 3rd party https domains have
dumped active content onto the page. better yet, disallow this behavior
entirely.

the fact that banks and other critical portals can dump third party scripts
like optimizely and stuff from https cdns is truly disturbing.

it's such an obvious oversight to me that i dont understand how a green
anything can be shown on mixed https domain sites. am i not understanding
something?

~~~
icebraining
Mixed content means HTTP+HTTPS resources, not HTTPS-only resources from
multiple domains.

And it's not always clear what's "third-party", as a common optimization
technique is to serve static assets form a second domain, to increase the
number of parallel connections.

~~~
pdkl95
> what's "third-party"

That's already defined by the same-origin policy.

> a common optimization technique

Optimization should never happen at the expense of security. (and yes, 3rd
party scripts are a security risk)

> increase the number of parallel connections.

I believe that trick is to save bandwidth by not sending the (large) cookies
that would normally be sent to the normal domain.

~~~
extra88
Working around browsers' maximum concurrent connections settings is a major
reason to use multiple hosts. This table of browser [0] is somewhat dated but
these limitations have been have always been present since the first browsers,
I doubt they've radically changed in the last few years.

[0] [http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-
co...](http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-connection-
to-same.html)

~~~
pdkl95
I could have outdated information; in either case speed isn't as important as
security.

Why haven't servers started advertising how many connections they are willing
to accept? The need for other domains could be easily removed with something
like an HTTP response header:

    
    
        200 Ok
        ...
        X-Max-Parallel-Connection: 10
        ...
    

This type of header could even be used to give per-page values:

    
    
        X-Max-Parallel-Connection: 20, scope=local-page-only
    

(there's probably a better way to phrase these, but that works as an example)

Yes, I know these are not supported by browsers _yet_ , but sensibility is one
of the best features of HTTP.

~~~
icebraining
That's been kinda pre-empted by HTTP2, with its TCP multiplexing and server
pushing.

------
angry-hacker
I think it's safe to assume HTTPS when it comes to browser indications is
broken. In a sense that majority of user don't care or understand.

I once had a client who wanted an EV cert, so the company name gets "shown
nicely in the address bar". After explaining about encryption for half an
hour, the only question was why should I care. It was a simple website for a
company. Contacts and about us mainly.

I often ask regular users, and they don't know what difference does it make,
the click everything and as far as they care, the lock can even be purple.
Which doesn't mean we shouldn't keep pushing https mainstream of course.

Correct me if I'm wrong.

~~~
seanwilson
> I think it's safe to assume HTTPS when it comes to browser indications is
> broken. In a sense that majority of user don't care or understand.

I'd agree with this as well. I find summarising it as "if you enter secret
details when the green lock isn't there, a hacker could steal them" isn't
concrete enough to sink in for most non-technical users. To really understand
what the HTTPS lock icon means let alone what mixed content warnings means
requires a lot of background knowledge most of us take for granted (web
servers, networking, hacking, how a web page loads scripts/images/css).

Given many people still use simple passwords and the same passwords everywhere
because of lack of understanding of what hackers can do, I think it's a lost
cause.

People do pay attention to e.g. Chrome's big red "this site is not secure"
screen that you have to bypass when there's something wrong with the SSL
certificate though. Showing something like this as standard would help.

~~~
_asummers
I managed to get my mother to use a password manager. I did my due diligence
in explaining the security aspects, as far as "well if someone gets your
Facebook password, how likely is that to be your Gmail password" , but mostly
had to frame it as a convenience feature of being able to use all these
complicated passwords without having to remember any of them.

~~~
seanwilson
I've lost count of how often I've heard friends and family say things like
"well there's nothing important in my computer/email/Facebook anyway". I try
to explain about how hackers can use credentials to eventually get into their
bank accounts, steal their identity, use their computer in botnet and spam
schemes etc. but it usually comes across as farfetched for some reason. I'm
sure it sinks in when they or someone they know is directly impacted by a
hacker but I think the problem is this doesn't happen often enough.

~~~
avian
I think the part that is hard to grasp for people without a technical
background is the danger of automated attacks. It's hard to explain that even
if nobody is interested specifically in their computer/email/Facebook, they
can still be a victim of a dragnet kind of an effort.

~~~
seanwilson
Yeah, I struggle to think of any good analogy that would help explain the
problem. You could explain HTTP as like sending a postal letter where an
attacker can intercept and read the letter undetected, reply back as if they
were the receiver etc . but that's already pretty abstract. Drawing a real-
world analogy with automated password attacks seems even harder.

~~~
dsp1234
"There's a gang around here that like to walk up to every car in the parking
lot and try every door. They aren't targeting you specifically, they just try
every door knowing that some doors will be unlocked. So always lock your
doors"

------
owenwil
November 2015 these rolled out, not sure why they're republishing them now

~~~
lorenzhs
The post is from November 3, 2015. I'm not sure why this was resubmitted now.

------
hackuser
Has Mozilla studied how end users acutally understand and respond to those
icons?

I have no idea what they mean, other than the plain grey lock and plain green
EV lock and name.

------
perlgeek
The real truble with Firefox UX regarding security is that a HTTPS connection
with an untrusted certificate is more hassle than an unencrypted connection.
But from a security concern, HTTPS with an untrusted certificate is better, it
prevents passive eavesdropping at least. It's certainly not _worse_ than
unencrypted traffic.

And yet firefox continues to make it hard to accept untrusted certificates.

~~~
CaptSpify
Everyone always defends this, and I can't understand why. Here's the way I see
it:

unsecure-cert= me + some unknown entity can read it.

no-cert = me + anyone can read it.

I'd rather have some shady unknown entity read it, than _everyone_ read it. Of
course, a warning for both should exist, but IMO, the 2nd is much worse. Am I
mis-understanding how this works?

~~~
agwa
An encrypted-but-unauthenticated connection is not readable just by some
unknown entity, but by an arbitrary, unbounded number of unknown entit _ies_ ,
which is practically the same as "anyone."

Anyone who's in a position to passively eavesdrop an unencrypted connection is
usually able to actively eavesdrop an encrypted-but-unauthenticated connection
with just a bit more work.

~~~
CaptSpify
OK, so then lets change my equation:

unsecure-cert= me + some unknown entity + possibly others

no-cert = me + some unknown entity + absolutely others

So, and insecure-cert still seems like the lesser evil?

~~~
agwa
An unencrypted connection isn't "absolutely" seen by others. If no one
eavesdrops on it, it's private, just as an encrypted-but-unauthenticated
connection is private if no one actively attacks it.

Theoretically, an untrusted cert is the lesser evil since active attacks
should be harder/more expensive than passive attacks, but no one knows exactly
how much harder/more expensive they are in practice. This makes me very
hesitant to declare one better than the other.

Ultimately, browsers are going to start warning about unencrypted connections,
and hopefully one day browsers will treat them just as severely as connections
with untrusted certs. Unfortunately, we have to undo decades of bad practices
first, which is a slow process.

------
castell
Why not a red "open lock" icon?

~~~
marcosdumay
People look for a lock - that's the only thing everybody knows about web
encryption. An open lock is still a lock, thus plenty of people will
understand it as secure.

On what case do you want the open lock? If this is about the active mixed
content warning, I do think it's worse than the previous version. But well, it
can only happen by manual intervention, so nobody will ever see it.

------
Too
Ok, so how do i explain in two sentences to my mom if she is actually on her
bank or not?

Can the company name text inside the green bar for EV certificates be spoofed
and used for phising?

------
marcosdumay
Still no warning on HTTP sites.

------
facepalm
Too complicated...

