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

31–40 of 419 posts

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

#31

Post by Namrog84 »

vortico wrote: post #18
ams6110 wrote: post #12

It should just label HTTP pages as "not secure", full stop. Because they aren't secure. Or at least, any page with a form. Never mind if it's a password field or not.

^ 100% agree. I think just marking HTTP pages with password fields as Not Secure would make HTTP pages without passwords fields appear to be secure. This is obviously not the case---they are just as insecure because you are sending your session cookie which is equivalent to your password---so all pages should be marked Not Secure.

> because you are sending your session cookie which is equivalent to your password

This is extremely different for most users that don't use password managers and/or unique passwords per site. As if your password is leaked. Maybe all your other sites are now leaked(with same pass) . The same can't be said of cookies.

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

#32

Post by clairity »

vortico wrote: post #19
myf01d wrote: post #7

Advancing HTTPS is one of a few good things Google made in the recent years. Thanks Google.

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.

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

#33

Post by Klathmon »

brak1 wrote: post #30
paulddraper wrote: post #17

Earlier quoted context omitted.

> onKeyDown Right-click paste from my password manager, and it doesn't work. Thanks. --- This idea is terrible in general, but if you do, against all that is holy, implement it, please, please use onInput.

also type='password' don't get their submitted values suggested for the autocomplete thing in broswers.

You can avoid this by using `autocomplete='off'`. Most browsers will still allow you to autocomplete the field because many were abusing that attribute, but they won't save what you put in it.

It's still a horrible idea, but it'd work.

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

#34

Post by tehlike »

jbverschoor wrote: post #20
myf01d wrote: post #7

Advancing HTTPS is one of a few good things Google made in the recent years. Thanks Google.

Thanks let's encrypt. Google should've started way way earlier

I work for google, and i had a fair amount of work on moving Ads to HTTPS (moved mobile app ads to https)

The work actually started quite a while back, but the overall ads industry and internet as a whole moves really really slow. Add the mobile ecosystem to the equation, and there is a bunch of issues.

The whole work is a combination of a bunch of things (in no chronological order): 1. Google pushed search ranking changes. 2. Google moved all of ads to HTTPS, and this took some time to make it happen. 3. Apple created ATS to make people think about it. 4. Apple wanted to enforce ATS for non-web content, had to back out. 5. Let's encrypt made access to certs free. 6. Big vendors joined.

Unfortunately, the world is slow when it comes to changes like these, but i am quite happy with the outcome so far.

edit: added context.

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

#35

Post by [deleted] »

JoshTriplett wrote: post #16
UnoriginalGuy wrote: post #10

Earlier quoted context omitted.

That's literally what my router's login page does. It is a text box but has JavaScript which converts each non-* character into a * character and stores the actual value in a JS variable. Why? They added a "Show Password" radio and I guess they figured this hack made more sense than simply using JS to update the DOM to turn it from a type password to a type text.

My previous router did this to obscure password length, by inserting three stars into the field for every character typed. Which completely broke browser password managers, and the ability to paste the password.

[deleted]

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

#38

Post by mappu »

brettz wrote: post #23
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"

So accurate. We had this exact discussion. Going to go with insecure warnings until we get https up shortly. For those wondering you can mask a normal text field in css input { -webkit-text-security: disc; }.

My colleague used a custom web font where every glyph was replaced with a filled circle. Better browser compatibility, you know.

Although our reason was actually to do with password managers. At $DAYJOB we have a CRM/ERP system with lots of password fields for other entities (not the current cookie user). It's increasingly difficult to opt out of browser autofill, and LastPass in particular was corrupting password data in the system whenever forms were submitted.

Post reply on HN