Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome 56 will mark HTTP pages with password fields as non-secure

security.googleblog.com

Post reply on HN
Print view View original

171–180 of 419 posts

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#171

Post by madeofpalk »

twblalock wrote: post #167
wfunction wrote: post #160

Earlier quoted context omitted.

> You're being pretty irresponsible if you aren't using SSL for passwords. So you're gonna tell me the owner of this site is irresponsible because it has a page with a password field that is not using SSL? http://www.w3schools.com/html/tryit.asp?filename=tryhtml_inp... How can you make any claim without having any idea what (if anything) the password is protecting?

Are you seriously suggesting that a password field in an online code editor on an HTML tutorial site is comparable to the situation we are discussing here?

The point is the result is the same - Chrome will flag that page is insecure.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#172

Post by madeofpalk »

foota wrote: post #3

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"

Pm - "why is this page insecure"

Developer - "chrome labels password fields as insecure over http"

Pm - "what if it wasn't http?"

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#173

Post by a3_nm »

malikNF wrote: post #158

This is such a dumb idea on google's part (and mozilla's) because people are now going to program dumb workarounds for this. Google seriously has to stop trying to police the god damn web.

Note that they have a "long-term plan to mark all HTTP sites as non-secure", so dumb workarounds will not work forever.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#174

Post by eru »

dTal wrote: post #110
guscost wrote: post #11

Earlier quoted context omitted.

> an onKeyDown listener that cached each keystroke and inserted a into the field... sounds like a terrible solution in so many ways. For anyone who is wondering what these ways are, here are a couple: 1) Backspace is a crufty special case 2) What happens when someone highlights text in the input box and types over it?

More broadly: a text input box is in fact a small but surprisingly comprehensive text editor. It supports a cursor with insert, delete, and overstrike; highlighting, undo/redo, cut/copy/paste; and shortcut keys for all that. It supports every keyboard layout and every input method. It obeys standardized focus rules. It's even got word wrap and spell checkers these days. So, you want to go your own way? How much of th…

You can: you'll just get a buggy half-assed implementation. In a corporate envirnonment with bad politics, that might still be the only way to go. (Apart from quitting.)

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#175

Post by sirbearington »

wfunction wrote: post #160
twblalock wrote: post #156

Earlier quoted context omitted.

> Now all my users are going to hear that my site is insecure, when nothing at all changed. You're being pretty irresponsible if you aren't using SSL for passwords. You users should be told that your site is insecure, because it is. You should care more about the security of your users. If your hosting does not allow SSL, you have an obligation to change hosts for the safety of your users. If you aren't willing to do…

> You're being pretty irresponsible if you aren't using SSL for passwords. So you're gonna tell me the owner of this site is irresponsible because it has a page with a password field that is not using SSL? http://www.w3schools.com/html/tryit.asp?filename=tryhtml_inp... How can you make any claim without having any idea what (if anything) the password is protecting?

It doesn't matter what the password is protecting on any particular site. Password reuse is common enough -- who knows what else the user is protecting with that password.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#176

Post by a3_nm »

clairity wrote: post #32
vortico wrote: post #19

Earlier quoted context omitted.

It's one of the few things they do that I can't find a reason they would be financially motivated to do so, other than increase developers' opinions about the company as a whole, which is a good thing for all.

google competes with the likes verizon, comcast and at&t, and the data google gathers on you is very valuable. why would they want to share that data with the line operators for free? sorry to say, but https is not an altruistic move by google.

Exactly. My understanding of the push towards HTTPS by Google is that they control the websites more than they control the connectivity, so they want to make sure that ISPs can only aspire to be substitutable intermediaries between users and websites. Putting everything in HTTPS makes traffic opaque to ISPs.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#177

Post by eru »

Aldo_MX wrote: post #87
foota wrote: post #3

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"

I've seen that: https://www.bancomer.com/index.jsp Click "Acceso a clientes" and write numbers.

I don't even get to that badness: the browser needs to accept third-party cookies first. (I wonder what badness is behind all there.)

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#178

Post by wfunction »

sirbearington wrote: post #175
wfunction wrote: post #160

Earlier quoted context omitted.

> You're being pretty irresponsible if you aren't using SSL for passwords. So you're gonna tell me the owner of this site is irresponsible because it has a page with a password field that is not using SSL? http://www.w3schools.com/html/tryit.asp?filename=tryhtml_inp... How can you make any claim without having any idea what (if anything) the password is protecting?

It doesn't matter what the password is protecting on any particular site. Password reuse is common enough -- who knows what else the user is protecting with that password.

> who knows what else the user is protecting with that password

How does it even matter when the password field is never even read? There are better alternatives. Chrome could just give a security error when the password is actually accessed. Or alternatively it could prevent the page from storing any data locally or sending any data to any server if the password field is non-empty. Just because a password field exists that doesn't mean the page is insecure.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#180

Post by godzillabrennus »

inlined wrote: post #154
johndoe4589 wrote: post #95

Earlier quoted context omitted.

Kinda like how your antivirus tells you about how the formidable threats it saved your ass from today? Or like "did you know your house COULD have been ransacked today, but it didn't happen!!" Now all my users are going to hear that my site is insecure, when nothing at all changed. How long ago did they announce that? I think just a couple months? They should have announced this much sooner. It's going to hit me hard…

Shameless plug (since I work on Firebase) but if your site works on static hosting + BaaS, Firebase Hosting will give you free SSL + CDN support.

http://www.Netlify.com gives a free tier away with static HTML hosting + ssl + cdn as well.
Post reply on HN