
Chrome 56 will mark HTTP pages with password fields as non-secure - vladootz
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html?m=1
======
lucideer
Firefox has started to do this recently and it's been fantastically
informative and helpful.

It's the one new browser feature I never really considered wanting/needing
before, that's really stood out to me as being incredibly valuable since I've
started to see the warnings pop up.

~~~
johndoe4589
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 as my site is pretty niche and driving even more
people away is the last thing I hoped for :( My shared hosting doesn't offer
Let's Encrypt, and makes me pay to "install" a free certificate anyway. So I
have to move everything to a different web host.

~~~
twblalock
> 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 that, you're negligent
and you should stop doing business with the public.

This is a huge red flag. If you really don't think SSL is important, it raises
disturbing questions about your approach to security in general. Which other
standard security practices have you ignored? Are you using strong hashing for
passwords? Are you properly handling input to prevent SQL injection?

~~~
Yver
"insecure", "huge red flag." For a banking site, an e-commerce site, a
webmail, sure. Must an aquarium enthusiast forum be resistant to Man-in-the-
Middle attacks? What about weak ciphers? Should every site be resistant to
offline decryption by a state actor?

~~~
onion2k
Until users stop using the same password everywhere, your aquarium website is
effectively the security for _all_ your users accounts, including their bank.

~~~
a_imho
How is that the websites fault?

~~~
onion2k
It isn't the website's fault that users do things wrong. It's the users'
fault. However, it is the website developer's _job_ to mitigate obvious
problems. We know that users do things that are stupid so we have to work a
little harder. We have to build products that recognise what the basic minimum
standard is, and then try exceed it. If you're transferring passwords across
the internet in plaintext then you haven't managed to do that and you need to
try harder.

------
foota
Pm - "why is this page insecure"

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

Pm - "what if it wasn't a password field"

~~~
bsimpson
Don't you need to use type = "password" to get the _-for-every-character
treatment?

I suppose you could implement your own (e.g. type = "text" with an onKeyDown
listener that cached each keystroke and inserted a _ into the field), but that
sounds like a terrible solution in so many ways.

I would think the laziest possible way to workaround this would be to use a
CDN like Cloudflare to proxy all traffic to your site. Looks like they have a
service called Flexible SSL that terminates HTTPS at the CDN, and sends
unencrypted traffic to your backend:

[https://www.cloudflare.com/ssl/](https://www.cloudflare.com/ssl/)

~~~
dheera
A few solutions:

\- Create a font such that every character shows up as a * and use it for a
text input.

\- make the input field use white text on a white background using a fixed-
width font, monitor length, and display the correct number of *'s above it
using a div.

\- implement the text box ground up from scratch using div's and JS, like
google docs does.

\- implement a HTTPS password field in an iframe and communicate with it over
post messages.

~~~
nkkollaw
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.

~~~
ocdtrekkie
Let's Encrypt is great, but completely useless for... Actually every single
website I host. No wildcard certs, the rapid rotation that requires software
to renew it regularly, etc. The cost of implementing HTTPS for dozens of sites
with no sensitive data is simply not worth it.

When companies like Google and Mozilla decided how to handle HTTPS, they
decided based on their needs and their perception of everyone else's needs,
like banks and major corporations. This led, IMHO, to a complete failure to
recognize a lot of other uses for the Internet, and so their solutions fail to
adequately account for them.

~~~
Karunamon
HTTPS is for the user's benefit, not the site owner's (barring legislation, of
course). Also, HTTPS prevents hijacking, not just sniffing, of content by a
MITM. That includes malware injection.

This has been coming for quite a long time. The time for excuses is over. If
you think the safety of your users is "simply not worth it", well, I'd like to
know what your websites are so I can block them at my firewall. I'm not saying
this to be a dick, I'm saying this because this is an attitude of callous
disregard on display, and it's downright odious given the modern security
climate.

LE is not that hard to use, and I seriously question whether you can't make an
API call once every 90 days per subdomain. The requirements have never been
lower.

~~~
jaas
HTTPS is very much for the site owner's benefit as well. If your site is not
HTTPS then you can't be sure that your users are seeing what you intend them
to see. Ads, malicious script, whatever, can be injected or replace your
content.

------
KirinDave
I've got to say though, that this is a wee bit frustrating as a developer. SSL
libraries are terrible, bug ridden, hard to work with, and there are huge
sacrifices using a pass-through proxy to offer SSL.

The brittleness of SSL libraries manifests not just in the form of security
exploits, but also in the form of delaying the next generation of HTTP
technology. Node doesn't support natively support HTTP/2 due to HTTP2 fitting
issues
[[https://github.com/nodejs/NG/issues/8](https://github.com/nodejs/NG/issues/8)].
Jetty was delayed for Java SLL changes. Same with Go.

If Google wants to make the whole web secure? That's great. But we also need
to work on making it _simple_ to secure. So much research goes into novel
ciphers and optimal ways to defeat timing attacks, and etc etc, but the spike
in complexity means that we're reaching a point where almost no individual or
group can approach a correct implementation.

It worries me that we're approaching a point where we're utterly dependent on
a security standard no one can understand.

~~~
stanleydrew
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 that their users' needs were best served by this
change. Mozilla and Google have been telegraphing their actions in this
direction for years. They have attempted to make a responsible and gradual
transition, and to a large extent have succeeded.

Every once in awhile though, a break needs to be made and some folks will get
left behind until they adapt, or don't.

~~~
KirinDave
> 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.

~~~
interurban
BoringSSL and LibreSSL are two non-trivial projects to improve SSL libraries
that started within the last 2 years. They may not be at an ideal state yet,
but a lot of work is being done to move the baseline to a better state.

------
polygot
I hope they do this for CC numbers too, because I know of a website I had to
use that passed your Name, address, CC number, CC exp, amount; the whole
shebang over plain ol' http to do a payment _shudder_.

~~~
hackinthebochs
Honest question, who is in a position to tap your connection such that this
becomes a serious security concern? IT staff at your company? The admins at
your ISP? The NSA? I'm assuming that public wifi has session-specific
encryption keys. I don't see these as the kinds of concerns that would warrant
the kind of panic that some people seem to show over HTTP.

~~~
BinaryIdiot
> who is in a position to tap your connection such that this becomes a serious
> security concern?

When you use HTTP everything is sent in plain text. This means...

\- Anyone on the same network as you can see all of your traffic. This
includes company networks, coffee shop wifi, your house, the library; any
place that has a WiFi network. Caveat: it's possible to use network isolation
to hide your traffic but this is crazy rare to see and typically is done to
isolate networks, not individual traffic.

\- Your ISP can see and log everything sent over HTTP.

\- Anyone at the router level that your traffic passes through. Your traffic
makes a lot of hopes over various routers on the internet before making it to
your final destination.

Overall it's a terrible idea for anything that needs to be sent securely.

~~~
ec109685
If I have two devices connected to a switch, how can they see each other's
traffic?

~~~
datguacdoh
Just download Wireshark and you'll have an easy to use tool that'll show you
the traffic.

~~~
windowsworkstoo
Not by default, only if you do ARP poisoning, which most consumer switches
wont guard against.

All you'll see without it is broadcast crap.

------
alex_dev
I've been paying rent with www.rentpayment.com which unfortunately serves up
their home page with multiple logins over http. Naturally, emails and tweets
to their support go ignored. Maybe they'll finally respond after more people
ask them why they're "non-secure".

~~~
metakermit
I wrote a short article on this topic with approaches for less tech savvy
folks to set up HTTPS:

[https://medium.com/punk-rock-dev/https-new-year-avoid-the-
no...](https://medium.com/punk-rock-dev/https-new-year-avoid-the-not-secure-
label-eefb99879980#.io1rzm367)

------
ktta
Mods, can we please get the "?m=1" part of the url removed? I think the
current link is for mobile.

~~~
skybrian
But that would make it worse for people on mobile.

~~~
ChristianBundy
Man, someone should really invent a way to make webpages respond to the
dimensions and capabilities of the user's device.

~~~
amiga-workbench
Plain, un-styled HTML?

------
no_wizard
Alright, for what its worth everyone, if you haven't seen this already, here
it is! The Cert bot from EFF!

Get that HTTPS motor running. This really does make it easy.

[https://certbot.eff.org/docs/intro.html](https://certbot.eff.org/docs/intro.html)

------
jvehent
Firefox has a similar feature enabled in dev edition:
[https://blog.mozilla.org/security/2017/01/20/communicating-t...](https://blog.mozilla.org/security/2017/01/20/communicating-
the-dangers-of-non-secure-http/)

~~~
bifurcation
Actually, it's in Beta now, and will be shipping to Firefox release channel
users on Monday or Tuesday.

------
throwaway6845
Countdown until a JS extension that takes a normal <input> field and uses
&bull; characters to make it look like a password field without tripping
Chrome's detector...

~~~
dawnerd
Can we just ban inputs being manipulated on input? It's really annoying for
custom implemented types like phone numbers that do the '(___) ___-____'. Half
the time it seems they break if you mess up.

~~~
tomschlick
I'd be in favor of banning input manipulation but adding custom fields like
phone which would accept regex formatters.

~~~
lucideer
Browsers already support that. Good look convincing managers/clients/designers
that they're sufficient on their own though.

The real problem is UI. Most of these plugins are changing the UI of forms to
something that looks fancier (and more consistent) than the defaults.

~~~
dawnerd
There really does need to be a better way to style inputs. It's all over the
place now. Hell, just making `type=search` look the same across browsers isn't
as straight forward as it should be.

------
SilasX
Stupid question: Is the warning going to show up for localhost i.e. using
chrome to see the local dev version of your website?

~~~
tonymet
see chrome://flags to disable security warnings on localhost -- great for
development

~~~
notatoad
it's weird that the warnings aren't disabled by default on chrome for
localhost: it's officially classed as a "secure origin"

[https://www.chromium.org/Home/chromium-security/prefer-
secur...](https://www.chromium.org/Home/chromium-security/prefer-secure-
origins-for-powerful-new-features)

------
meta_AU
What should be done for routers and printers that are accessed by their IP
address?

~~~
nsgi
The best solution is for them to be accessed through a publicly registered
hostname e.g. [https://router0123.netgear.com](https://router0123.netgear.com)
(that would only resolve locally). They could provision certificates for
themselves using the Let's Encrypt DNS challenge.

~~~
kuschku
So, now we have a single certificate on all routers? What happens if I take
apart a router?

Or would every router get its own certificate? But then netgear would have to
become its own CA.

And in either case DNS hijacking is a massive issue.

~~~
icebraining
_Or would every router get its own certificate? But then netgear would have to
become its own CA._

Why? They could just partner with an existing CA, like Cloudflare does with
Comodo.

And how would DNS hijacking be an issue? The attacker wouldn't be able to
produce a valid cert anyway (the router would come with a custom burned-in key
that it would use to authenticate itself to the CA and get the cert).

~~~
kuschku
> the router would come with a custom burned-in key that it would use to
> authenticate itself to the CA and get the cert

I take apart the router, and get a valid certificate. Now I hijack DNS, and
get you to connect to me.

HTTPS within LAN for this purpose is useless.

~~~
icebraining
_I take apart the router, and get a valid certificate_

You only get a valid certificate for your router's address. But if you can
take apart the router, you don't need to hijack the DNS, you can simply
control its traffic.

But if you're a guest in my home and I see you take apart my router, you'll
have to answer a few questions. Same in an office or coffeshop. Having LAN
access doesn't mean you have complete physical control of the router. So the
HTTPS is _not_ useless.

~~~
kuschku
You only get a valid certificate for your router's address.

Considering basically every router has the same address, I now have a valid
certificate for basically every router.

~~~
icebraining
_Considering basically every router has the same address_

They have the same IP address, not necessarily the same DNS hostname, which is
what the certificates are tied to. The user would just be told to connect to
the hostname (possibly printed in the sticker) rather than to the IP.

~~~
kuschku
That's certainly one option, but what happens now if I change the IP of the
router in its config, because I use multiple in my LAN, one as router, the
others as AP?

There is no option for any of this that isn't completely messy and hacky

~~~
icebraining
On first boot and every time you change its IP, the router sends an
authenticated message to the server to update its DNS records.

As a bonus, the user doesn't have to change anything to keep accessing the
router admin page after the switch.

------
kyledrake
There should be an HTTP Header (or a CSP directive) to allow servers to set
sites as "Not Secure" manually. That would help a lot of people dealing with
phishing attacks on web hosts.

It would function in the same way - if Chrome detects CC/password forms, it
labels the site as Not Secure.

------
vladootz
I know the article is older, but it's January 2017, just a reminde. The
message will appear in the address bar.

------
ryandrake
Not a Chrome user, but this is a great feature, and is at least moving things
in the right direction. Really they should go farther though. The UI treatment
is almost un-noticable, even if they went with the "red triangle" version. How
about a red-background interstitial page or a modal with a clear "Get Me Out
Of Here" and "I Know What I'm Doing" choice for the user?

And for all those "small businesses" that are going to get affected by this?
It's hard to muster up much sympathy at this point. It's 2017, and you're
still horsing around with vanilla http?

------
no_wizard
I'm going to go ahead and make another shameless plug, since a lot of folks
who are hesitant about this new HTTPS stack are worried about deployment, and
thats for the fantastic folks over at Caddy. They make an Apache/Nginx
alternative that has built in letsencrypt renewal support and automatically
encrypts your site by default and serves over https/2.

[https://caddyserver.com/](https://caddyserver.com/)

I am not an affiliated developer, but I am a user, and have recommended this
to others as well, its a solid product.

------
idbehold
How does it handle password inputs that are added to the page with JS?

~~~
progval
Maybe we can make it blink by adding and removing the password field

------
ArlenBales
I'd go a leap further and change the background color of the address bar to
red if it's a non-HTTPS page. No excuse for any site to be HTTP in 2017,
especially with LetsEncrypt. Your host doesn't allow LetsEncrypt? They need to
get with the times, or you need to switch hosts. (Why would you want to use a
host that doesn't see the value of HTTPS?)

~~~
hughes
As stated in the article, that is in fact the long term goal for treatment of
the Google Chrome address bar.

------
HappyTypist
I'm in an A/B test group where all pages are marked either green 'Secure' or
red 'Not Secure', password or not.

I like it.

------
Sarkie
I hope me trying to push this on G+ and Twitter for years helped.

This was always my first install on a new Chrome.

[https://chrome.google.com/webstore/detail/unsecure-login-
not...](https://chrome.google.com/webstore/detail/unsecure-login-
notifier/ledomejmbiemgdfiekmhoheabhonihmi)

------
ifelsehow
Will this also apply to data URIs? Thinking of the recent data URI phishing
exploits [1]

[1]: [https://www.wordfence.com/blog/2017/01/gmail-phishing-
data-u...](https://www.wordfence.com/blog/2017/01/gmail-phishing-data-uri/)

------
stilliard
Working on a new community site to help people move to HTTPS:
[https://blog.movingtohttps.com/dedicated-to-simplifying-
the-...](https://blog.movingtohttps.com/dedicated-to-simplifying-the-move-
from-http-to-https-97d80b08e4dd)

------
LogicX
It's great that Google wants to move more sites to https, and I'm in support
of this, but it also creates challenges for security vendors such as myself.

Currently DNSFilter and others Man in the Middle traffic destined for sites
our customers have decided to block. This works great for http, but not https,
as certificate warnings are presented.

The standard work around is arguably less secure: adding a third-party CA to
all end-points. This can still present problems with HSTS and certificate
pinning.

I'd like to work with Google to create a standard where vendors can either be
on a whitelist or have new recognized SSL cert fields, not to MITM traffic,
but just to present users with a friendlier message explaining whats
happening, and providing a separate [https://](https://) url to visit for
information from the vendor about the block.

Implementing such a standard in browsers would further increase user security,
and provide a viable method for filtering on guest networks where there is no
end-point access.

~~~
scrollaway
Removing insecure HTTP altogether is the road Google is taking. That should
make this a non-issue.

~~~
toast0
How does removing HTTP solve the issue presented:

When actively interrupting an HTTPS connection as a network element, there is
no way to provide information to the user about the reason for the
interruption or steps the user could take to prevent the interruption.

This can be done with HTTP, where a filtering proxy could show a page 'our
software thinks this page violates company policies, but click here to
override or contact IT to fix', or see also captive portals.

Maybe the right answer is simply there's no reasonable way to handle this use
case in a secure manner, but taking away an established use is a real issue.

------
tehlike
What happens if the page is insecure, but the attacker places an iframe in the
page with HTTPS url, which then tricks the user into sending their credentials
(unsuspecting users will think they are logging into the site).

~~~
joshstrange
I'm not sure that really fit what is changing here... If the forum is
submitted it's going over https even if the iframe is on an http page. If an
attacker has the ability to add code (iframe or other) to your site you've
already lost.

~~~
tehlike
that's exactly my point. I am hoping/assuming chrome would notify the user
about this as well.

~~~
joshstrange
Why? IIRC cross-origin will prevent the http page from reaching into the https
iframe and furthermore the password is being sent over https so google doesn't
really care.

~~~
tehlike
But since top lev is insecure, an attacker could inject a legit looking form
whose destination is set to steal passwords.

~~~
joshstrange
I guess it depends on the attack this is supposed to stop. This change does
prevent sniffing of passwords and protects them while in transit but no, it
doesn't prevent MitM attacks. That said google plans on marking all HTTP pages
as "Non-Secure" in the not-too-distant future which will help warn against the
potential for MitM.

------
godDLL
What about services like Sellfy that let you add a button to your site's
pages, that loads a shopping iframe? Will it change the indicator when the
iframe appears after a user clicks the Buy button?

------
cr0sh
Ultimately, how is this plan by Google going to affect sites that are hosted
on a virtual server hosting plan?

For instance, I have a website hosted at Hurricane Electric on a virtual
server plan. I've had hosting there for well over a decade. I like their
service, the virtual host works well for most of my needs. There are two areas
where it doesn't work, though (AFAIK):

1\. I can't run a pure NodeJS website.

2\. I can't set up HTTPS.

Number one isn't relevant to this discussion; but as far as I know, the second
one is a big deal. There isn't any way (AFAIK) to host multiple virtual
servers each with their own certificate.

So right now (well, with the release of v56 of Chrome) - if you have a
Wordpress site or something on a virtual host that has a login - it's going to
show something that says "unsecure" for the login/password form. Honestly, I
am fine with that. My own site isn't a Wordpress site, but I do have a
login/password box on the site, and having it show that it is insecure is not
a big deal to me. While there isn't much or anything I can do about it, I do
understand and support the reasoning.

But...

...in the future, they want to mark -all- non-HTTPS sites as "insecure" \-
regardless of what the site does, presumably. It could just be a collection of
static html pages (no javascript, no forms, nothing special), and it will
still be marked as "insecure"? Does this sound reasonable? Suddenly, all of
these pages will be deemed pariahs and non-trusted because they choose to use
non-encrypted means of presentation?

Is there any solution to this, as it stands? Or are all of us with virtual
hosting solutions going to have to migrate to some cloud-based server
solution, with it's own IP, then obtain our own certificate (easier today, I
know - and cheap to free, too) - just to get around this? Is this the end of
virtual private server hosting (or is it going to be relegated to third-tier)?

I don't currently know what if anything Hurricane Electric plans to do
regarding these changes. I don't want to move to another hosting provider if I
can avoid it (while HE isn't the cheapest for what you get, they are nice in
that they assume you know wtf you are doing - your hosting is basically access
to the server via ssh and sftp - so you better know how to admin and set
things up via a shell, because they aren't going to hold your hand).

I'm thinking I should send an email to them to ask them what they're planning
to do - if anything.

~~~
Vendan
If you are talking about this service:
[http://he.net/web_hosting.html](http://he.net/web_hosting.html), then it's
supported SSL since 2013, at least, with a simple admin panel to set it up...
If it's an actual VPS, then SSL is fully on you, and trivial to set up with
common stacks and LE.

------
ams6110
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.

~~~
vortico
^ 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.

~~~
derefr
Plenty of websites think they only have to secure app.example.com, while
www.example.com can be left uncovered even though it serves
www.example.com/login, because /login POSTs to the app. subdomain, and the
session cookie is only set _by_ and _for_ the app. subdomain.

From a naive perspective, all requests passing private information are
protected in such a scenario. But, of course, since the www. subdomain is
uncovered, it can be MITMed and replaced with a phishing site. (A.K.A. a
"spear-phishing" attack.)

This change somewhat fixes that scenario: the developer can no longer keep the
/login route on the insecure www. subdomain; they'll have to serve that page
securely (either by making www. secure, or, more likely—because it's
lazier—just moving /login to the app. subdomain.)

Even though www. can still be MITMed to replace it with a phishing subdomain,
that subdomain can no longer serve a login form itself. It would have to link
to a "real" phishing FQDN (one the attacker controls enough to get a TLS cert
for), at which point that domain can just be found and blacklisted by the
browser vendors.

In a sense, it forces the attacker into the open, where the attacker
themselves can be caught/blocked, rather than simply their _attack_ being
caught/blocked. (In other words, it forces MITM attackers into a situation
more akin to current botnet malware-writers, where they must put up C&C
infrastructure which can be traced back to them.)

Of course, this isn't nearly as good as just securing the www. subdomain; and
it will force much more work (likely, doing said securing) on those who want
to embed a login form directly on their www. subdomain's landing page. But, in
the interim while we work on universalizing TLS, it _will_ drastically
decrease the _value_ of spear-phishing attacks, just as spam filters
drastically decrease the value of unsolicited bulk email ad campaigns.

------
clamprecht
What if the <form> submits to an https page but the page is served up on an
http page? The form submission will be secure, correct? Will Chrome still mark
as insecure?

~~~
dbbk
The form submission is only half the issue. If the http page gets compromised
the malicious party could simply read the contents of the password input.

~~~
clamprecht
thanks

------
egberts1
Needs to start blocking form fields that have no corresponding input text box
because...these unused fields still get autofilled with cached but
personalized info.

------
agumonkey
Do they send a letsencrypt notice to these domains ? notifying users is
awesome, helping "late" hosts into HTTPS would be perfection.

------
iceman_w
Insecure websites could get around this by not marking the fields as password
fields but using javascript to make them appear so to the user.

------
ZeroClickOk
I think the title must be "Chrome 56 will mark non-HTTPS pages with password
fields as non-secure"

------
thowfaraway
So if we have an http page with a password field that posts via https, it will
be marked non-secure?

~~~
netheril96
Yes, because it is insecure.

------
daryltucker
I'd like to see this with Adobe Flash and third party scripts. (Pandora!)

------
rectangletangle
About time, this is an excellent feature.

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

~~~
vortico
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.

~~~
clairity
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.

~~~
Jweb_Guru
This is ascribing an absurd level of Machiavellian intent to Google. Why can't
people just accept that occasionally, Google engineers do stuff that isn't
profitable to the parent company?

~~~
witty_username
Just speculating, but I think Google is at such a huge scale whenever the
internet wins Google wins. That's why they're trying to improve internet
access with Project Loon and WiFi in Indian railway stations.

If privacy improves that will benefit the internet (privacy has real costs
that don't involve state actors like hackers, etc). Many people, especially in
developing countries, are afraid of transactions over the internet and use
cash on delivery.

------
ai_ja_nai
Thank God

------
johndoe4589
> A substantial portion of web traffic has transitioned to HTTPS so far, and
> HTTPS usage is consistently increasing. We recently hit a milestone with
> more than half of Chrome desktop page loads now served over HTTPS

Well OBVIOUSLY when the traffic is increasingly going to the same top ten
sites like Faceboo, Twitter and Co.

------
malikNF
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.

~~~
derimagia
With free ways to encrypt web coming out, you really have no excuse to not use
https for login forms. People should be informed.

~~~
malikNF
This is not the right way to educate people. This is a sort of like shaming
someone in to doing something. Many small companies are going have an impact
thanks to this.

There are many companies I have personally witnessed that use a direct IP to
access web based solutions to their inhouse software, how are these people
supposed to get a ssl cert.

We need to educate people, not shame them in to doing the things big google
wants from them.

~~~
notatoad
>Many small companies are going have an impact thanks to this.

if those small companies aren't offering secure logins to their users, they
should be impacted. that's the whole point. You shouldn't get to risk your
user's security just be being small. Implementing SSL is not difficult or
expensive, and the prevelance of password re-use means that a small company
with an unsecured login is causing a risk all around the net.

we've been educating people about SSL for years. if they haven't figured it
out yet, it's time to start shaming them.

------
Elrac
"Thanks, Captain Obvious!"

Is there an option to turn this off, for those of us who feel we need it like
a hole in the head?

