7 ms·

Evolving Chrome's security indicators

101 points by cryo 8y ago

panarky 8y ago
I finally trained my mom to look for the green lock and verify the domain name. Now Chrome is gonna eliminate the green?
- liveoneggs 8y ago
  eliminating useful visual information is high style
  - RussianCow 8y ago
    It's not eliminating it per se, it's just flipping the logic: Instead of HTTPS sites having a green lock, now HTTP sites will show a "Not Secure" message. It's a different visual cue, but the same idea.
  - jaas 8y ago
    It's not useful, it's grossly misleading. People think it means the site is safe when that is not the case.
    - liveoneggs 8y ago
      you're right of course. <form>s should be eliminated entirely
- eco 8y ago
  Green lock is probably easier to describe to someone not proficient as a web user but you can still just say, "Make sure it doesn't say Not Secure and verify the domain name".
  - panarky 8y ago
    I'd support this if every insecure page had a prominent, red, "Not Secure" message. But unless you're entering a password, there's no color at all. The difference between secure and insecure is far too subtle for non-experts like my mom.
peterwwillis 8y ago
> 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 8y ago
  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 8y ago
    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 8y ago
      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?)
eganist 8y ago
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 8y ago
  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.
joemccall86 8y ago
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 8y ago
  > 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.
Ajedi32 8y ago
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 8y ago
  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 8y ago
    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.
lucideer 8y ago
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.
- dangrossman 8y ago
  It's not easy to explain to your parents either. "Don't look for the padlock any more, just look for a Not Secure warning... which may not appear until AFTER you put in your credit card details... at which point it's not really helped you at all has it. Huh. I have no idea what Google was thinking here. Better call the bank and cancel your credit card every time Not Secure pops up."
  - RussianCow 8y ago
    To be fair, the "Not Secure" message is always there—it only changes color to red once you start typing into a form field. I do think it should be red by default, because the gray is not obvious enough, but I don't think it's necessarily any harder to explain than the green padlock.
    - eco 8y ago
      It's kind of a weird how it works. Users will be looking at the field they are typing on (or even the keyboard for some users). Then they'll look down for the next field and so on until they reach submit. I think users will often miss the color change entirely. I think it'd make more sense to just make it red if there is any input options on the page at all.
      - cpeterso 8y ago
        Firefox shows an insecure warning in the insecure form field itself so the user will see it.
      - 8y ago
deleted 8y ago
[deleted]
RyanZAG 8y ago
Likely next step: mark only pages that are present in Chrome's preloaded HSTS lists as secure (including their new premium .app domain).
- superflyguy 8y ago
  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.
- icebraining 8y ago
  What's "premium" about .app?
foobarbazetc 8y ago
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.
- dangrossman 8y ago
  Not only that, but the red text doesn't appear until it's too late: AFTER they've put their sensitive information into a form, which probably spirited it away with JavaScript before one can change their mind.
  - andyjh 8y ago
    Not true: Currently the "info" indicator appears on first interaction (which _could_ be after they've auto-completed everything, but may not be). This is changing though: In Chrome 68 the info indicator will be there on all HTTP pages, without form interaction required. So this change just changes it from "info" to red warning.
    - weber111 8y ago
      If you type fast, you can probably get a whole username (or personal name, or street address) in without seeing the red warning. (That said, it looks like it _will_ show "not secure" by default, even before you type anything in, on HTTP; it just isn't emphasized unless you enter data.)
- mtgx 8y ago
  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.
deleted 8y ago
[deleted]
tzahola 8y ago
>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 8y ago
  "Encrypted" and "Not Encrypted" would be more accurate labels than "Secure".
tokyodude 8y ago
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-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-... 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.
- Sephr 8y ago
  The solution is for Let's Encrypt or a similar CA to start issuing certificates for direct IP addresses.
  - parliament32 8y ago
    The parent was talking about a device on a home network, I definitely do not want a CA issuing a trusted cert for 192.168.0.1
    - Sephr 8y ago
      Obviously I'm only referring to public IP addresses. Let's Encrypt can't attest anything about local IPs.
      - parliament32 8y ago
        Which is a good idea, until we remember that most residential "local" networks have dynamic IPs. Honestly the best way to deal with this is to have a dynamic dns record pointing to a (sub)domain you own, then get a cert through that.
X-Istence 8y ago
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 8y ago
  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 8y ago
    > 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.
- cpeterso 8y ago
  Chrome and Firefox use HTTPS first for sites in their preloaded HSTS lists. (I don't know if Edge has a preloaded HSTS list.) https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
  - X-Istence 8y ago
    > ut trying HTTPS first would be fantastic and eliminate one round trip for many of my sites that are not in the HSTS preload... It's almost as if you didn't read my post. Unless I can go register all my domains to be in the HSTS preload, I'd much rather Chrome tried HTTPS first, so I don't have to run a web server on port 80 that sends a 303 with https as the protocol.
makecheck 8y ago
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 8y ago
  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.
xg15 8y ago
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 8y ago
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 8y ago
  Perhaps "This site will securely and privately receive your information"
lousken 8y ago
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.
combatentropy 8y ago
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.

101 points by cryo 8y ago

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

liveoneggs 8y ago
eliminating useful visual information is high style
- RussianCow 8y ago
  It's not eliminating it per se, it's just flipping the logic: Instead of HTTPS sites having a green lock, now HTTP sites will show a "Not Secure" message. It's a different visual cue, but the same idea.
- jaas 8y ago
  It's not useful, it's grossly misleading. People think it means the site is safe when that is not the case.
  - liveoneggs 8y ago
    you're right of course. <form>s should be eliminated entirely
eco 8y ago
Green lock is probably easier to describe to someone not proficient as a web user but you can still just say, "Make sure it doesn't say Not Secure and verify the domain name".
- panarky 8y ago
  I'd support this if every insecure page had a prominent, red, "Not Secure" message. But unless you're entering a password, there's no color at all. The difference between secure and insecure is far too subtle for non-experts like my mom.

peterwwillis 8y ago

> 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 8y ago
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 8y ago
  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 8y ago
    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?)

eganist 8y ago

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 8y ago
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.

joemccall86 8y ago

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 8y ago
> 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.

Ajedi32 8y ago

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 8y ago
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 8y ago
  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.

lucideer 8y ago

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.

dangrossman 8y ago
It's not easy to explain to your parents either. "Don't look for the padlock any more, just look for a Not Secure warning... which may not appear until AFTER you put in your credit card details... at which point it's not really helped you at all has it. Huh. I have no idea what Google was thinking here. Better call the bank and cancel your credit card every time Not Secure pops up."
- RussianCow 8y ago
  To be fair, the "Not Secure" message is always there—it only changes color to red once you start typing into a form field. I do think it should be red by default, because the gray is not obvious enough, but I don't think it's necessarily any harder to explain than the green padlock.
  - eco 8y ago
    It's kind of a weird how it works. Users will be looking at the field they are typing on (or even the keyboard for some users). Then they'll look down for the next field and so on until they reach submit. I think users will often miss the color change entirely. I think it'd make more sense to just make it red if there is any input options on the page at all.
    - cpeterso 8y ago
      Firefox shows an insecure warning in the insecure form field itself so the user will see it.
    - 8y ago

deleted 8y ago

[deleted]

RyanZAG 8y ago

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

superflyguy 8y ago
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.
icebraining 8y ago
What's "premium" about .app?

foobarbazetc 8y ago

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.

dangrossman 8y ago
Not only that, but the red text doesn't appear until it's too late: AFTER they've put their sensitive information into a form, which probably spirited it away with JavaScript before one can change their mind.
- andyjh 8y ago
  Not true: Currently the "info" indicator appears on first interaction (which _could_ be after they've auto-completed everything, but may not be). This is changing though: In Chrome 68 the info indicator will be there on all HTTP pages, without form interaction required. So this change just changes it from "info" to red warning.
  - weber111 8y ago
    If you type fast, you can probably get a whole username (or personal name, or street address) in without seeing the red warning. (That said, it looks like it _will_ show "not secure" by default, even before you type anything in, on HTTP; it just isn't emphasized unless you enter data.)
mtgx 8y ago
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.

deleted 8y ago

[deleted]

tzahola 8y ago

>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 8y ago
"Encrypted" and "Not Encrypted" would be more accurate labels than "Secure".

tokyodude 8y ago

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-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-... 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.

Sephr 8y ago
The solution is for Let's Encrypt or a similar CA to start issuing certificates for direct IP addresses.
- parliament32 8y ago
  The parent was talking about a device on a home network, I definitely do not want a CA issuing a trusted cert for 192.168.0.1
  - Sephr 8y ago
    Obviously I'm only referring to public IP addresses. Let's Encrypt can't attest anything about local IPs.
    - parliament32 8y ago
      Which is a good idea, until we remember that most residential "local" networks have dynamic IPs. Honestly the best way to deal with this is to have a dynamic dns record pointing to a (sub)domain you own, then get a cert through that.

X-Istence 8y ago

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 8y ago
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 8y ago
  > 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.
cpeterso 8y ago
Chrome and Firefox use HTTPS first for sites in their preloaded HSTS lists. (I don't know if Edge has a preloaded HSTS list.) https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
- X-Istence 8y ago
  > ut trying HTTPS first would be fantastic and eliminate one round trip for many of my sites that are not in the HSTS preload... It's almost as if you didn't read my post. Unless I can go register all my domains to be in the HSTS preload, I'd much rather Chrome tried HTTPS first, so I don't have to run a web server on port 80 that sends a 303 with https as the protocol.

makecheck 8y ago

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 8y ago
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.

xg15 8y ago

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 8y ago

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 8y ago
Perhaps "This site will securely and privately receive your information"

lousken 8y ago

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.

combatentropy 8y ago

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.