There's more details about this here too: [webmasterworld.com...] and it says January 2017 will start the more overt indicator.

In my niches there are a lot of large well-known high-traffic sites that are still http. In fact I just checked 10 of the top sites and only two of them are https. I would bet that overall there are tens of thousands of high-traffic sites that are still http.

So does this mean that Chrome users won't be able to visit these large well-known sites if they don't convert to https?

So does this mean that Chrome users won't be able to visit these large well-known sites if they don't convert to https?

No. The thread title is misleading, as is the first post. HTTP/1.0 is not being "deprecated". Chrome will merely begin warning users on HTTP pages where a password or credit card info can be entered that the connection is not secure. It's a passive warning, it doesn't mean you can't "get Chrome visitors", not even in a further stage of their plans to mark HTTP as non-secure. At worst, you'll see a red triangle with a "Non-secure" message in the address bar.

i totally agree on the credit card form, although that is a severe breach in the TOS of taking credit cards if the form is not secure anyway.

for logins it is more complex - some sites, like most forums for instance, very little or zero personal data is kept, although of course grabbing someone's email and password is always handy as so many people use the exact same ones on various sites.

obviously google have their reasons for wanting to promote https ... personally i don't see the problem with it, i've a few sites with 'free' certificates, which are available from several places and they seem to work fine. i do admit that my main site has a paid/premium certificate - just in case!

robzilla:

> HTTP/1.0 is not being "deprecated"

I never said it was, although in practice I block almost all HTTP/1.0 accesses anyway: it should be HTTP/1.1 as of many years ago. Which has nothing to do with HTTP or HTTPS in URLs - HTTP/1.x is merely a protocol.

The title is not misleading. And please re-read my opening post, in which I QUOTE threatpost's interpretation of google's action, which ties in with statements in G's blog.

If non-HTTPS sites want visitors they should envisage the reaction of someone who sees an explicit warning that the site is not secure. A lot of people are leery of such warnings and run away.

Quite apart from whether or not G is "forcing" people to use HTTPS, there is a downside to using it anyway, for some people. As of last June HTTPS was supposed to support ONLY TLSv1.1 and TLSv1.2 security protocols. The idea is to force ecommerce and similar sites to be secure; TLSv1.0 is no longer regarded as secure.

That date was moved first to next year and then to 2018, but it WILL happen. The downside of this is that XP, Vista and older versions of Windows 7 will no longer work under HTTPS; nor will a lot of older Androids. Older versions of Safari are also affected. There are still a lot of these operating systems and browsers around. I recommend checking any HTTPS sites you have/manage with [ssllabs.com...] - tighten up the protocols and ciphers and see what happens to the oldies.

So you COULD say, with G pushing for HTTPS sites everywhere (which is what they are slowly doing) that they are knocking out all non-HTTPS sites. It mainly comes down to peoples' trust in google: if they believe the warnings, many of them will avoid web sites so tagged.

I never said it was, although in practice I block almost all HTTP/1.0 accesses anyway: it should be HTTP/1.1 as of many years ago. Which has nothing to do with HTTP or HTTPS in URLs - HTTP/1.x is merely a protocol.

My bad, I always get those versions mixed up. I meant to refer to HTTP/1.1, i.e. the common protocol before HTTP/2. But anyway, you're right, of course: they're phasing out insecure HTTP, not the protocol itself (which is also used for HTTPS, sort of).

Together with your "if you want to get Chrome visitors", I interpreted your post to suggest that Chrome users could no longer visit insecure webpages, when in fact only a warning will be shown. However, I do apologize as my definition of "deprecating" appears to be incorrect, and so, yes, this is indeed another step toward discouraging users from browsing HTTP websites and at the same time encouraging (not forcing) webmasters to upgrade to HTTPS.

I'm all for HTTPS everywhere, and labeling all HTTP pages insecure would technically be accurate, but also seems a little overzealous. But that's how you push things forward, I guess.

The "no" to aristotle's question still holds, of course.

Well I don't know much about these technicalities. And since the pages on my sites are static html, with no scripts, I thought they were already secure enough. So Google doesn't agree?

With insecure HTTP anyone listening in on your users' internet traffic can see exactly which pages they're visiting on your website, and what information they're submitting in forms or through URLs. As with other unsecured yet still popular plain-text protocols (FTP, POP3), it's not a private connection. This can be risky in countries where there's internet censorship and/or surveillance. I think we're a long way off from securing every website, but that is ultimately what Google and others are working towards. With Chrome and their search engine, Google probably has the most leverage of all to make that happen.

what information they're submitting in forms or through URLs

There aren't any forms on my sites -- no registrations, logins, comments, posts, or anything else.

As for submitting information through URLs, I don't know what that refers to.

There aren't any forms on my sites -- no registrations, logins, comments, posts, or anything else.

It's not all about submitted information. On some websites (like controversial blogs) it could be plain text that's the privacy-sensitive part. What's sensitive and what's not can vary, so the tendency is just to encrypt everything.

As for submitting information through URLs, I don't know what that refers to.

Sometimes data is passed on via the GET method rather than POST. As a result, that data becomes part of the URL (e.g. index.php?name=robzilla, sometimes even passwords and e-mail addresses).

well I'm still not planning to do anything at this point. Maybe if the "warning" is big and prominent, I might have to look into it.