4 ms·

And it's also why https everywhere is important. If your bank/shop/confidential whatever website isn't accessed via https, you should leave immediately. Once ht

And it's also why https everywhere is important. If your bank/shop/confidential whatever website isn't accessed via https, you should leave immediately. Once https is close to 100%, browsers could display a warning: "You seem to be entering confidential information on a non-https website. This is probably wrong". (Ironically, IE used to ship with exactly that warning years ago, but they were way too much ahead of their time)

pfg 10y ago
That's a good point, and exactly what Chrome is planning on doing[1]. Firefox has a similar feature for HTTP-only sites using password fields (I think it's currently enabled in Firefox Developer Edition). [1]: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...
- byuu 10y ago
  > Firefox has a similar feature for HTTP-only sites using password fields Man, people really don't think these things through, do they? The end result of making that enabled by default would be that sites start using plaintext for their password fields. Try detecting <input name='password'> and sites start changing it to <input name='p4ssw0rd'> to get around it. Throw warnings on any POST submission and watch sites start using GET for passwords. You can't force people into good practices. You need to make the HTTPS portion so easy that they have to go out of their way to undermine security. Let's Encrypt was a good first start. Now we need at least one competitor to them for free certificates to push innovation forward. And we need Apache and nginx to auto-negotiate TLS certificates and OCSP stapling with zero configuration changes. The default config should opt-in to this, and you'll have to manually disable it. Caddy was a good step there, but nobody uses Caddy. They use Apache, nginx, or IIS.

pfg 10y ago

That's a good point, and exactly what Chrome is planning on doing[1]. Firefox has a similar feature for HTTP-only sites using password fields (I think it's currently enabled in Firefox Developer Edition). [1]: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...

byuu 10y ago
> Firefox has a similar feature for HTTP-only sites using password fields Man, people really don't think these things through, do they? The end result of making that enabled by default would be that sites start using plaintext for their password fields. Try detecting <input name='password'> and sites start changing it to <input name='p4ssw0rd'> to get around it. Throw warnings on any POST submission and watch sites start using GET for passwords. You can't force people into good practices. You need to make the HTTPS portion so easy that they have to go out of their way to undermine security. Let's Encrypt was a good first start. Now we need at least one competitor to them for free certificates to push innovation forward. And we need Apache and nginx to auto-negotiate TLS certificates and OCSP stapling with zero configuration changes. The default config should opt-in to this, and you'll have to manually disable it. Caddy was a good step there, but nobody uses Caddy. They use Apache, nginx, or IIS.