Earlier quoted context omitted.
As with most things, progress isn't clean or easy. Shifts in policy or practice cause disruptions, and then people adjust. The world is a dynamic place. Software is no exception. SSL libraries will get better if they get used more. The developers will make them better. Or if they can't, we'll find a solution that works. The question is whether the benefit of the disruption outweighs the cost. Browser-makers decided t…
> SSL libraries will get better if they get used more. The developers will make them better. Or if they can't, we'll find a solution that works. I keep hearing this, but failing to see it. Since OpenSSL's inception.
Chrome 56 will mark HTTP pages with password fields as non-secure
271–280 of 419 posts
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#272Earlier 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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#273Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#274Earlier quoted context omitted.
If there's not sensitive data, then there's no password field (passwords are by definition sensitive), and Chrome won't show a warning. So what's the problem?
Passwords are NOT by definition sensitive, and this is the sort of absolutist nonsense that I'm complaining about. Passwords are only as sensitive as the data they access.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#275Earlier quoted context omitted.
Shower Thought: Why doesn't the browser hash the inputs for all password fields, then compare them when attempting to submit a form, and alert the user that they are doing something insecure?
Because my passwords for google.com, gmail.com, youtube.com, and google.co.uk are exactly the same, and the browser has no way of knowing that that's okay. (Google specifically has probably rerouted everything through google.com these days, but the general problem exists.)
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#276Earlier quoted context omitted.
It may take way more than 5 minutes. My experience with let's encrypt so far: - the name of their tool was changed form "letsencrypt" to "certbot", breaking my cronjob - for daemons that try to access the cert/key as non-privileged users, additional fiddling with permissions is necessary, which may even be overwritten on cert update if done incorrectly - when the certs are renewed, daemons need to reload them. This m…
> I, for one, opted to renew my startcom certificate for another 3 years instead. Wait really? When did you do this? I thought all certs signed by their root after sometime in October or November are all considered invalid due to their shenanigans with WoSign. Not so? https://news.ycombinator.com/item?id=12787029
> Distrust certificates with a notBefore date after October 21, 2016
Just in time!
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#277Earlier quoted context omitted.
Security follows a weakest link approach. With your aquarium enthusiasts forum that weakest link would be shared passwords between that forum and other, more important sites.
Shower Thought: Why doesn't the browser hash the inputs for all password fields, then compare them when attempting to submit a form, and alert the user that they are doing something insecure?
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#278Earlier quoted context omitted.
Because my passwords for google.com, gmail.com, youtube.com, and google.co.uk are exactly the same, and the browser has no way of knowing that that's okay. (Google specifically has probably rerouted everything through google.com these days, but the general problem exists.)
I have this exact problem with LastPass. One of my few pain points with it.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#279Earlier quoted context omitted.
Honestly, why would you do any of those things, now that installing a certificate takes 5 minutes and is free, with Let's Encrypt? I know that you're just exploring solutions because it's interesting, but all those things take longer than Let's Encrypt.
If the only thing you host is a small blog without ads on a server that you have complete control over and spun up last month or something, sure it's 5 minutes. In the real world, for many commercial operations, and especially for legacy code, there can be significant hurdles. For example, it took the NY Times 2 years to move to HTTPS, significantly more than 5 minutes, and they haven't even migrated 100% yet. https:…
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#280Earlier quoted context omitted.
Security follows a weakest link approach. With your aquarium enthusiasts forum that weakest link would be shared passwords between that forum and other, more important sites.
Shower Thought: Why doesn't the browser hash the inputs for all password fields, then compare them when attempting to submit a form, and alert the user that they are doing something insecure?