Google Chrome and HTTPS Only.

[Geek-9pm]

Google is working on a HTTPS only standard.
Here is the problem. With current HTML you can't always tell if the source is authentic. Sometimes malicious sites with hijack a DNS and give you a fake web page.
A proposed solution is to insist on the secure connection for everything, not just the log in page.

Here is what Google is wanting.
Google’s new Security Panel in Chrome will push developers into an HTTPS future

Web browser security is important, which is why Google is adding a security panel for developers in Chrome 48 beta that lets them visualize and troubleshoot all of their connections.
Writing that it has made security a “first-class citizen in DevTools,” Google’s new panel is at least the easiest way to check which pages are secure, which aren’t — and why.

This idea is not new.
http://www.infoworld.com/article/2621353/encryption/google-protects-its-current-https-traffic-against-future-attacks.html
That was back in 2011.

[Superhuman]

I've been increasingly often wondering in the last few years why increasingly everything is encrypted through Google, even when it's totally non-confidential content and unimportant to secure the page.  Especially since SSL requires greater bandwidth, decreases throughput, and commonly doesn't use a browser cache, it seemed foolish to use it needlessly.  I guess this news sheds some light on what they are doing.  It's too bad that's the measure that is required to deal with it.

[Geek-9pm]

About SSL overhead. On a PC is is hardly a factor. It does make a difference  on a large server. But on a commercial server anything makes a difference. For the commercial people who want to get best return on investment, even a 1 per cent improvement is meaningful.

[camerongray]

It's often hard to determine what is confidential and what isn't so in many ways it's still good to use SSL.  The overheads involved do exist but they are so small it makes no noticeable difference to overall performance.  As far as caching goes, there is nothing stopping a modern browser from caching content served over HTTPS and they do cache it.  When people refer to not being able to cache content they are referring to caching content on some third party server between the remote site and the user's PC - Situations where this sort of caching is employed are not really common enough for this to be a major issue.

[Superhuman]

It's easy to establish if there is personal information involved or not.  In what way and for whom would it be hard to determine confidentiality?

That SSL overhead makes a small difference assumes a user has a decent speed broadband.  If, however, they're using a limited speed connection, or dial-up, it can make a large difference.

I never said there was anything stopping a modern browser from caching HTTPS.  However, AFAIK it's still commonly not cached by default, and many inexperienced users may not be aware of how to change the setting, or of any need to.  Plus, caching confidential data is a potential security risk.  So, if everything gets cached, there's no longer any distinguishing between what shouldn't be cached and what should, for security reasons.  (It'd require some alternate method, which I haven't heard of, if exists.)

[camerongray]

An example of something that may not seem confidential at first glance could be a search engine's search box but for some people they may be using this to search for confidential things.

Browsers do behave differently with respect to caching but this can be overridden using headers sent from the server side so if the person running the site sets the server up correctly to send the appropriate caching headers, the browser should cache the content - Nothing to change on the user's side.

As far as security goes - If you have a site that requires login over HTTPS but then drops back to HTTP after login, it can still be open for session stealing.  The cookies that define the user's logged in session will continue to be sent when they are running over HTTP so these could be sniffed on a public WiFi network and then used to spoof the user's session.  If the entire session runs over HTTPS then this is not possible

[Superhuman]

A browser is going to allow a site's header to override the user's cache setting, and cache restricted data anyway?   Not any browser that's any good at all at privacy, it's not!  Restricted info like credit card numbers, social security number, etc., remaining on your computer needlessly, in the browser's cache is not a good idea, let alone against your explicit permission (settings).

Cookies could be captured on any network if it drops to HTTP.  On a public Wi-Fi, HTTPS only secures it over the network, and it's insecure between the access point and the client computer.  So the cookies could still be captured locally, along with anything else while using SSL/TLS.  It's common that people don't realize this, and do shopping, e-mail, etc., unsecurely in this manner.  The only way to truly and fully secure a connection with unsecured public Wi-Fi is to use a Virtual Private Network (VPN).

[Geek-9pm]

Thanks to both of you. There is so much that could be said about the security and passwords.
The main point of this thread is that Google is recommending that all communications be made more secure and that there should not be any areas in the network where plaintext would be visible to non-authorized personnel.

An argument has been made that some people need to have the right or privilege of looking into your e-mail and your website. But many disagree with that. One of the issues that goes back to 1934 when the communications act was established in the United States was the issue of privacy in communication. At that time it was agreed that all kinds of communication should be under the authority of one central agency, the FCC, and that both radio and telephone conversations were to be considered private even if they were not encoded. Put another way, it was just this illegal to eavesdrop on somebody's telephone conversation as it was to open up their mail. And that policy would  also apply on private communications that was being done over two way radio.
But now we're in a period of time where the whole idea of citizens rights to confidential privacy are being questioned. At the present time some of the biggest companies, Apple, Google and Microsoft, have taken the position that they will protect the privacy of individuals.
This would not prevent law enforcement agencies from getting a warrant and seeking to investigate private communications that have taken place. However, some take the position that law enforcement agencies should be able snoop on your communications at any time they want to. The assertion has been made that this is the only way to protect the country from  organized terrorists.
Really, any organization that has the resources can find ways to hide information that would be very difficult for government agencies to discover unless nobody is allowed to use any kind of VPN, virtual private network.
As for myself, I don't say or do things that are against the law, but still I am not comfortable with other people listening into my conversations or reading my mail. Hopefully private communications will remain private.

Now about Wi-Fi. It has been recommended that all Wi-Fi links use some form of encryption. Otherwise it is much too easy to pick up somebodies access point and see all the information that is being passed back and forth from the client to the access point. Encryption of the data between access points and client ensures that other people can't just drive by and pick up a wireless signal and see what other people are talking about. However, wireless encryption does not help us on the Internet. If the Internet information is not encrypted, then using wireless encryption doesn't do a thing to prevent somebody from tapping in to a wired connection. Of course, tapping into a wired connection is very illegal and probably would be noticed by somebody. Still, full encryption on the Internet would do quite a bit to improve personal privacy.

This is a plain text message and does not contain nay hidden codes. 

 h)+_)lfi48][pide9049vbmj 298fjniruve3es.;'f]=;r
Just ignore the above.
I was just clearing my throat while using speech recognition.

[BC_Programmer]

A browser is going to allow a site's header to override the user's cache setting, and cache restricted data anyway?

The server-side Cache Response Directives that are part of the http header indicate when resources can be cached. A Bank website might have a header image with the bank's logo; there is no reason for that to need to be re-downloaded by the client at every page load, so the server indicates that it is a cacheable resource. Conversely, pages that contain, say, account information would likely use a no-store directive which would indicate to browsers not to cache the data.

Browsers don't cache data by default over HTTPS, but those defaults can be overridden on a file-by-file basis with the cache-control headers sent from the server.

of course, whether the browsers respect these settings is another matter entirely. They might cache information marked as no-store or they might not cache information marked as cacheable (which would be the case if caching is shut off completely, for example).

Restricted info like credit card numbers, social security number, etc., remaining on your computer needlessly, in the browser's cache is not a good idea, let alone against your explicit permission (settings).

data such as stylesheets, images, and other ancillary data- which typically constitutes the bulk of most webpage data don't contain any private information and thus will almost always be marked as cacheable.

The overhead of HTTP is not mostly in raw data size- which remains approximately the same, particularly considering HTTPS supports HTTP2 which adds compression features. The primary overhead is that HTTPS requires additional round trips/connections which will suffer connection latency. This definitely affects connections such as 3G or, say, dial-up, but the main factor is not the amount of data, but entirely a result of the additional round trips paired with those connections typically having very poor ping times.

Google's Push for HTTPS typically makes use of SPDY, which has the rather interesting trait of being faster than HTTP for most purposes. This is primarily because SPDY uses features of HTTP2, which requires HTTPS. This can be seen in action here.

[Geek-9pm]

BC_Programmer,
Great find!.
A picture or visual aid is worth a thousand words.
The link is the post above makes it clear that spree-time  is a non-issue with a secure connection.
Most of the stuff we need to keep private is not part of the HTML tags and style features.Text data itself is fast enough. There might be no need to encrypt pictures. But even then, the encryption overhead is very small.

Actually, a JPEG file is already a form of encoding that takes some time to do. But it is done to improve bandwidth, not overload it.

To put it bluntly, the argument that privacy slows down the internet is a false idea.

As for piing and latency, these are not real issue in real world communications. Unless you are flying a warship over the Internet.  

[Superhuman]

However, some take the position that law enforcement agencies should be able snoop on your communications at any time they want to. The assertion has been made that this is the only way to protect the country from  organized terrorists.

I think it's dubious exactly how effective this assertion is.  It is allowing the terrorists to succeed in instilling fear in us, and sacrificing our original liberties as a result.  Then they win.  There are other methods of deterring terrorism, including attacking it where it festers from.  Even if one assumes all the snooping on data is effective at foiling terrorist plots, there is the question of if it's better to live relatively "safely" in fear and paranoia, or to courageously live with essentially unimpeded liberty and possibly have some risk of another terrorist plot slipping through undetected.  I would choose the latter, no contest.

Really, any organization that has the resources can find ways to hide information that would be very difficult for government agencies to discover unless nobody is allowed to use any kind of VPN, virtual private network.

You have reiterated much of what I mentioned, but don't quite seem to comprehend some aspects.  VPN is only for securing wireless communication between routers and client devices, and only where needed.  Routers/access points that have their built in authentication and encryption turned on, are already secure to use.  And of course ethernet is wired and doesn't need wireless security protocols.

As for myself, I don't say or do things that are against the law, but still I am not comfortable with other people listening into my conversations or reading my mail. Hopefully private communications will remain private.

Yes, there's much reason why law-abiding people would want their private communication to actually be private.

Now about Wi-Fi. It has been recommended that all Wi-Fi links use some form of encryption. Otherwise it is much too easy to pick up somebodies access point and see all the information that is being passed back and forth from the client to the access point.

Routers do usually have their security turned on, unless the owner specifically turns it off.  This is commonly only done on public Wi-Fi networks.

Browsers don't cache data by default over HTTPS, but those defaults can be overridden on a file-by-file basis with the cache-control headers sent from the server.

data such as stylesheets, images, and other ancillary data- which typically constitutes the bulk of most webpage data don't contain any private information and thus will almost always be marked as cacheable.

Ah... this makes sense.  Thanks.

[Superhuman]

Google's Push for HTTPS typically makes use of SPDY, which has the rather interesting trait of being faster than HTTP for most purposes. This is primarily because SPDY uses features of HTTP2, which requires HTTPS. This can be seen in action here.

That page says my browser doesn't support HTTP2, and hence isn't accurate.  But, when I click each protocol it does display the secure data faster than regular HTTP, and reports it as a fraction of the load time.  Seems accurate to me.

spree-time

   

Actually, a JPEG file is already a form of encoding that takes some time to do. But it is done to improve bandwidth, not overload it.

And a PNG takes significantly more processing time, but it is also very quick on modern computers.

To put it bluntly, the argument that privacy slows down the internet is a false idea.

Using security on all pages did used to slow down the internet.  It's only these recent security protocols (I hadn't yet heard about) employing compression that have now changed that.

As for piing and latency, these are not real issue in real world communications. Unless you are flying a warship over the Internet.  

Indeed they are an issue with dial-up, even 3G, as BC_Programmer says:

The primary overhead is that HTTPS requires additional round trips/connections which will suffer connection latency. This definitely affects connections such as 3G or, say, dial-up, but the main factor is not the amount of data, but entirely a result of the additional round trips paired with those connections typically having very poor ping times.