
Evolving Chrome's security indicators - cryo
https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html
======
tokyodude
I am all for secure connections but I do lots of work with apps that run local
webservers (inside your home network). AFAICT there's no way to make that non-
techie friendly secure. The only non-techie friendly solution I know of is the
Plex solution but the Plex solution costs $$$$$$$

[https://blog.filippo.io/how-plex-is-doing-https-for-all-
its-...](https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/)

You can also think of this as an issue for any IoT device that wants to serve
a webpage.

Let's Encrypt doesn't cover this use case because it only provides certs for
domains so every IoT device would need it's own domain or subdomain and that
domain would need to be blessed in the list of domains that Let's Encrypt
doesn't put limits on certs since you need a cert per device.

Some company making a product (for example Plex) can pay to run the dynamic
DNS and partner with a CA but at the moment there is no free and easy way for
some open source project to this.

I wish I knew how to make it happen. Get a giant grant like Let's Encrypt got
or something to enable a solution. I'd love all my projects running local
servers to be able to use HTTPS but at the moment it's way too painful.

~~~
Ajedi32
I actually just started using Let's Encrypt to issue certificates for web
services (router config pages, Firewall, NAS server) on my local network. You
_do_ need your own domain and DNS server so unfortunately it isn't free, but
it _is_ definitely doable.

Basically I just setup [acme-dns][1] on a VPS, pointed the relevant _acme-
challenge domains at that server via a CNAME entry, and gave each device on my
LAN an account on the acme-dns server so they can fulfill challenges at will.

Unfortunately as you said that's probably a little too complex for the average
user, not to mention domains and VPSes aren't free. Probably wouldn't be too
expensive to offer as a service of some kind though; I'm only spending
$3.50/month total, and I'm sure my VPS could handle _much_ more traffic than
it currently does just fulfilling acme challenges for my LAN.

[1]: [https://github.com/joohoi/acme-dns](https://github.com/joohoi/acme-dns)

~~~
xg15
It's good that there is at least a way to do it, but it's still absurd that
showing a page from a server in a LAN on a browser in the same LAN now
requires third-party services on the internet and incurs running costs.

(* yes, you could simply tolerate the insecurity warning if you're ok with not
using more recent JS/CSS features. I imagine though the warnings will become
more obnoxious and the amount of features you can't use will grow.)

(* yes, you can install your own root CA cert. For admin pages, this is even a
reasonable thing to do - however, you'll need to do it on _any_ machine that
is expected to open your page. So say goodbye to raspberry pi media
experiments or kiosk systems.)

~~~
Ajedi32
The problem is that the address associated with a publicly trusted cert _has_
to be universal. We can't give users certificates for
`[https://192.168.1.1/`](https://192.168.1.1/`) or `[https://my-
router.local/`](https://my-router.local/`), because then attackers could get
certs for those names as well, which would defeat the whole purpose of HTTPS.

DNS is well suited for allocating unique, memorable names to devices, but, as
you said, it _does_ rely on third party services (registrars, at the very
least) to operate. If we don't want to rely on third party services, we'll
need to come up with an alternative to DNS that accomplishes the same goals.

------
peterwwillis
> Users should expect that the web is safe by default

I don't expect this of anything else in my life. Why in the world would I
expect the web to be safe?

To be clear: the only thing this is assuring is that your connection is
secure. Your content may not be. Hell, the web server may not be. There's no
way a browser can know these things. And they're going to assure the user
they're secure by default?

Lots of phishing sites use valid connections to trick you into giving your
SSN, credit card, and other data. This is not safe or secure. But the browser
is telling me it is.

~~~
geofft
You expect text messages to be intercepted in transit? You expect people to
steal things out of your checked luggage? You expect your credit card number
to be stolen whenever you give it to a restaurant to swipe?

All of these things happen with some frequency, sure, but I personally
_expect_ that they don't, which is why I'm disappointed and upset when they do
happen.

And the fact that the browser can't assure any other security besides
transport security on its end is exactly why it shouldn't be displaying an
indicator saying "Secure," when all it means is "In this particular way, it is
not insecure; for everything else I have no idea." If it knows it's insecure
in a particular way, it should display a warning or possibly an error. If it
doesn't, it's meaningless to claim "Secure." That's how the rest of the world
works: the State Department gives you warnings about high-risk travel areas,
but it doesn't say that any place is safe and crimes won't happen to you
there.

~~~
yrro
Guess I'm the only person who never sends sensitive information by text, never
checks valuables into baggage, and never hands my credit card to the person
serving me? (Ok, this last one has become way less important since the rollout
of Chip & PIN).

~~~
geofft
Sure, there are people who do that, and there are people who do all their web
browsing in Tor. Such people are important and there should be tools (like Tor
Browser) built for them, but they're also very much not the target audience of
the _default_ case. Chrome is a mass-market browser, not a browser built for
people with specific uncommon security needs.

(What do you do at restaurants - pay with cash? Insist on walking up to the
PoS device?)

------
foobarbazetc
Removing the lock entirely is just wrong.

It’s a really quick indicator that I’ve either set something up right or not.

Also if I’m on chase.com and I don’t see a lock of any kind I’m going to NOPE
out. And I’m a tech person.

Imagine explaining to my parents that after all this training to look for the
lock they now shouldn’t look for the lock, but look for this red text instead.

Bad move.

~~~
mtgx
I think the best compromise is to at least show HTTPS in green. Not showing
anything at all seems wrong somehow.

I understand why they don't want to show "Secure" for websites that may have
already been breached and lost your plaintext password. But I don't understand
why they need to remove https and http from the URL. Is that really a big UX
step forward? Or one backwards? Sometimes removing too many interface elements
causes a regression in intuitiveness and good UX.

Unless they're preparing for the replacement of the HTTP protocol, and they
don't want people to freak out when they see the new labels? That could
explain it. But other than that, I don't see a good reason for eliminating
HTTPS/HTTP from the URL.

~~~
callalex
They aim to replace https with quic when it’s ready for prime time.

~~~
f2n
Do you have a source for that? I assumed the lessons learned from SPDY and
QUIC eventually went into HTTP 2

------
lucideer
The biggest problem here is not that the green lock is being eliminated, but
rather that HTTP pages will show a low-contrast grey message _unless and
until_ you type into an input.

By default, if you're not typing in a form, Chrome will show no major eye-
catching colour-differentiation between HTTP and HTTPS. That's a major
regression in user security.

~~~
magicalist
I believe you're mistaken, conflating two different steps. There's still going
to be a lock for HTTPS while the "Not Secure" message doesn't turn red for
HTTP until you type in a text box.

The post indicates that by the time the lock disappears ("eventually"), then
all HTTP sites will be marked as not secure in red. In the meantime it's
removing the "Secure" text with the lock _and_ HTTP sites will get their "Not
Secure" turned red when you type in a text field. Those seem like fine steps.

> _That 's a major regression in user security._

Turning red is more functionality than today, not less.

~~~
deathanatos
What the poster you're replying to is saying is that the reduction of contrast
between secure and not (prior to anything being typed into the page) is the
reduction in functionality.

That is, there is now nothing eye-catchingly different between HTTP and non-
HTTPs aside from a small monochrome marker; I think OP's concern is that that
will get lost in people's vision next to the URL — they won't notice it. (And
I somewhat agree w/ that.)

~~~
jjoonathan
That's exactly the intent. Too many false positives will teach people to
ignore the red marker, so putting it in place before the web catches up would
be counterproductive.

------
joemccall86
The more I think about this the more I'm actually on board with it. Users
can't assume that a site is safe anymore because of a green padlock because
HTTPS is so easy/cheap to implement, and this is a step toward re-training
users to use a different means to confirm they are entering information into a
correct page. There's too much risk for the green padlock to be used as a
false sense of security.

Combine this with marking HTTP sites as explicitly insecure and I fail to see
any downsides with this becoming the new norm (assuming other browsers follow
suit).

~~~
giobox
> Users can't assume that a site is safe anymore because of a green padlock
> because HTTPS is so easy/cheap to implement

I don't think this has meaningfully changed today vs the past as you suggest.
HTTPS has been cheap and _relatively_ (for an engineer anyway) easy to
implement if you cared for quite some time, even before the advent of free SSL
certificate services like Letsencrypt etc.

I certainly don't agree that widespread SSL/HTTPS has somehow devalued the
significance of the green padlock as you are implying - the level of security
it implies for your in-transit requests is still much the same as it always
was, it just happens to be used on many more sites than in days past.

For this argument to hold, we would need to assume that for some reason in the
past, only "good actors" of some kind used HTTPS due to its
expense/complexity, and therefore the padlock was somehow certifying their
good intent. This has never been the case, and HTTPS (perhaps with some small
degree of exception for the newer Extended Validation certs...) continues to
really only indicate your requests will be encrypted in transit only.

------
eganist
There's nothing lost from keeping the green lock and adding the red "not
secure" warning in place of having no warning at all.

There's no reason to maintain a "no-indicator" state, UX or otherwise. Keep
the green lock for sites which implement it correctly.

peterwwillis makes a good point in another top level comment -- and my own
research in securing products suggests much of the same, specifically that
many users don't assume things are secure. I'd extend that argument by stating
most users don't assume things are _insecure_ either unless the security of
the system is specifically called out.

In other words, _it 's generally out-of-mind._

Considering this, you should be keeping green locks and red warnings going
forward and never having a no-warning state except perhaps on private networks
where the security of the connection is to be determined by the team which
owns that private network. There's an entire industry of "Secured By" badges
which CAs managed to market to draw attention to connection security in a
space where standard indicators should be serving that role based on standard
--not marketing--metrics.

(This will probably prepend a later letter I'll write up about Google
Security's unilateral changes the past few years. This and HPKP are two that
come to mind.)

Edit: A good point was raised by twitter user @akanygren on this topic,
notably that since there's no assurance other vendors will share this same
approach, this will immediately sow UX confusion. The corollary I'd attach to
that is that with Chrome as a plurality player eliminating a decision-point in
their UI, other browsers now gain a marketable competitive advantage by
labeling secure connections as such and are dis-incentivized to follow suit
because they stand to benefit by maintaining some variant of the status quo.

[https://twitter.com/akanygren/status/997178362669010944](https://twitter.com/akanygren/status/997178362669010944)

[https://twitter.com/eganist/status/997186215249137665](https://twitter.com/eganist/status/997186215249137665)

~~~
ovao
There is actually appeal to having no indicator: the absense of an indicator
doesn’t inadvertently suggest anything about the site’s _overall_ security.
The padlock icon we’re so accustomed to can create a false sense of security,
as every other aspect _except_ the connection to all servers may actually be
insecure.

You may, for instance, be transmitting credentials that may be stored in plain
text, be easily accessible to third-parties or may even be handed directly to
black markets. The padlock itself says nothing about any of those details.

A better approach to no icon at all, I think, is simply “secure connection”
wording. Trying to distill a lot of complexity and nuance into a single icon
is what’s ultimately problematic. It works somewhat well, but not quite well
enough.

~~~
RussianCow
> A better approach to no icon at all, I think, is simply “secure connection”
> wording.

The problem is, most people won't understand the difference between that and
just "secure"; arguably, the people who understand what "secure connection"
means are those for whom this change doesn't matter.

~~~
ovao
It's a fair point. I can't think of any perfect solution, only solutions that
are less worse than others at conveying the 'Right Thing'.

------
X-Istence
Is this also going to cause Chrome to attempt HTTPS before falling back to
HTTP?

That would be the more useful change. If HTTPS fails (due to hostname mismatch
for example), fall back to HTTP and warn, but trying HTTPS first would be
fantastic and eliminate one round trip for many of my sites that are not in
the HSTS preload...

~~~
Ajedi32
Fail-open security is useless against any actual attack. The attacker would
just block the TLS connection then intercept the resulting plain HTTP request.

Google already defaults to linking HTTPS versions of pages in its search
results, which is a much better solution IMO. (Attacker can't intercept the
connection to Google because of HSTS, and can't intercept the connection to
the site you visit because it's a direct HTTPS link.)

~~~
X-Istence
> Fail-open security is useless against any actual attack.

Except that if the user is not visiting for the first time, then HSTS comes
into play if the security headers are set, browsers can let the user know
something is amiss.

We both agree that fail-open security is useless, but right now Chrome and
other browsers default to going to port 80 for first visit instead of port
443. All I am asking is that the default becomes 443, and the fall-back, for
first visit, is port 80.

This way I can stop running web servers on port 80 that do nothing but send a
303 with https as the protocol for that particular domain.

------
makecheck
Kind of not understanding the “why” here.

If they’re going to change a status indicator _during_ form entry, the
indicator needs to be right in the user’s face (i.e. floating over the
cursor). Anything else might be missed. Even so, pointless dynamics; mark the
page red always, and stop trying not to offend those implementing blatantly-
unsafe forms.

Also, a minimum of a green default checkmark seems in order, even in this
wonderful secure-by-default future. Continue to train people to demand better
security and look for safer-web indicators.

~~~
coldacid
And with each new generation of security features, we get bigger, better, more
in-your-face "safer-web indicators", a veritable Lensman Arms Race of
iconography.

------
RyanZAG
Likely next step: mark only pages that are present in Chrome's preloaded HSTS
lists as secure (including their new premium .app domain).

~~~
superflyguy
Most people don't use very many sites. We do, yes, but the most will revisit
the same sites over and over. And they'll be entering their personal/card
details into fewer. Why not have a browser popup each time you enter this info
into a site for the first time? And a warning if the site is not on a browser
supported whitelist? Don't "phone home" with people's sites; browsers could
maintain white/black lists. Making users see if they think the site they're on
is dodgy is like expecting people to only download code in source form and
check it before compiling it. If my mum uses the same 4 shopping sites and one
bank it shouldn't let her log into another one - fake or not - without at the
very least a "wtf are you doing" warning.

------
panarky
I finally trained my mom to look for the green lock and verify the domain
name. Now Chrome is gonna eliminate the green?

~~~
liveoneggs
eliminating useful visual information is high style

~~~
jaas
It's not useful, it's grossly misleading. People think it means the site is
safe when that is not the case.

~~~
liveoneggs
you're right of course. <form>s should be eliminated entirely

------
Ajedi32
This seems like a good move long-term. It always did seem a little misleading
to me for Chrome to be labeling a site as "Secure" when really all it's
talking about is the security of your connection to the site.

I wonder how they're planning to handle EV certificates. They don't seem to be
mentioned anywhere in this post. I seem to recall at least one person at
Google advocating for removing EV indicators entirely.

~~~
geofft
EV certificates are nothing other than a way for the CAs to make money now
that people have realized that the CAs' core product is worth approximately
$0.

Argument 1: this person was able to get an EV cert for "Stripe, Inc. [US]", an
entity they registered in Kentucky, no relation to the Stripe, Inc. of
California whose website is stripe.com. They were not able to get a
certificate for stripe.com. (The CA revoked it, and then later apologized for
revoking it because there was no reason by their policy to do so.)
[https://stripe.ian.sh/](https://stripe.ian.sh/)

Argument 2: the actual website for MasterCard's SecureCode is
[https://www.mycardsecure.com/](https://www.mycardsecure.com/) , whose EV cert
is "Arcot Systems LLC [US]". The fact that it has a meaningless domain name is
in no way fixed by it having a meaningless (but technically accurate, Arcot is
the contractor for SecureCode) EV cert. How do you know you're actually
supposed to type your personal information there?

Argument 3: the web's security model is based on origins (domain names), not
on EV certs. If Stripe switches tomorrow to stripeiscool.com and a domain
squatter gets stripe.com, my browser will still send cookies to stripe.com,
even though it no longer has an EV cert, and it certainly won't send cookies
to stripeiscool.com, even if it has an EV cert with the same organization.
Even if EV were a good idea in the abstract, it lacks a plan to make it work
with the web as actually deployed.

~~~
Ajedi32
Counter-argument: domain names are notoriously bad at conveying the identity
of real-world entities. How is a user supposed to know that my-bank.com is the
domain for their bank, as opposed to mybank.com or my-bank.org? EV certs can
serve much the same role that the "Verified" indicator does on social media
sites; it provides some assurance that the name you're seeing on screen really
_does_ belong to the person or company you think it does.

There are obviously issues with EV as it's currently implemented, but I
believe the solution to that is to fix those issues, not to eliminate the
indicator entirely.

~~~
geofft
A better long-term solution (although maybe too long-term) is to move to some
auth mechanism that knows about your origin. When you get a bank account, you
should get a U2F device (which should cost <$20, which should be far less than
the amount the bank is already spending on securing your account) that you
enroll then and there, and so if you end up at my-bank.org by mistake, it
doesn't matter, your U2F device doesn't have a shared key with the origin and
you can't log in. Or do the same sort of thing with WebAuthn. Or you scan a QR
code with your phone and get a link to the bank's mobile website and bookmark
it, or whatever.

Attack 1 makes me worry about whether this is solvable at all. There's a lot
of "First Bank and Trust"s out there, and they'd all need an EV certificate
for the same string, so avoiding the attack seems genuinely hard. Like social
media (or curated app stores), the only way it can really work is if the
"verified" marker creates first-class and second-class entities: the entities
approved by the powerful as reasonable to do business with, and the entities
that aren't. Someone makes a decision about which First Banks and Trusts are
"real" and which ones aren't, and you can't appeal it.

------
xg15
I find it somewhat worrysome that the hassle of obtaining and maintaining
certs is now handwaved away with saying "we now have let's encrypt".

I think it's important to keep in mind that even if their certificates are
free, they are still a permanent dependency of your site. Moreover the fact
that they _can_ offer certificates for free works because of the concerted
industry effort going on currently to move the whole web to https.

They are well-supported but, for sites with no budget for commercial certs,
will still stay a single point of failure. If they should, after the
transition to 100% https is completed, not bevable to offer free certs
anymore, what exactly would be the plan B?

------
robocat
Chrome Android shows this text if you click the lock:

"Your information (for example passwords or credit cards) is private when sent
to this site"

That sounds so wrong because it implies you can trust the site... but writing
something clearer is hard!

~~~
anchpop
Perhaps "This site will securely and privately receive your information"

------
combatentropy
I still am against hiding the protocol. Color https green and http red if you
want to (though I think http deserves a less condemnatory color like yellow).

Hiding it, unhiding it, is too much magic. Yes, I believe web users need a
certain level of technical understanding, so that they are savvy enough when
they see it elsewhere, like in an email or some other document.

I am for hiding the inner workings of things, but I believe the URL is part of
the user interface.

------
tzahola
>Users should expect that the web is safe by default

In the age of Let’s Encrypt I wouldn’t say that HTTPS implies safety. I can
register a phishing site in 5 minutes with fake credentials, the configure
let’s encrypt to get that little padlock icon. No questions asked.

HTTPS only guarantees that your traffic is not spied on or modified en route,
but for ordinary users that wasn’t an issue in the first place.

~~~
cpeterso
"Encrypted" and "Not Encrypted" would be more accurate labels than "Secure".

------
lousken
They should have used word Encrypted instead of Secure, it's misleading. Now I
think they should at least keep the padlock green. Also next logical step
should be blocking javascript on http sites by default.

