Chrome will start marking pages open via HTTP as unsafe

While people around the world invent new useful technologies, other people decide which of the old, proven, but probably not such useful technologies to consider, alas, unsafe and harmful.
Well, Google has announced that from January 2017 (from Chrome version 56), when browsing in Chrome, websites that transmit passwords and credit card numbers using the HTTP protocol (that is, not via HTTPS) will be marked as unsafe. This is done as part of a long-term transition plan to label all non-HTTPS sites as unsafe, which should encourage site owners to switch to HTTPS.

In fact, the analysis will be simpler: the browser will mark the pages received via the HTTP protocol, and in which there are fields for entering passwords or credit card numbers — the analysis for “sending passwords and card numbers via http”, apparently, will not be done. Visually, the innovation will look like in the picture above.

Google’s position on why HTTP pages that have been considered “normal” to become “unsafe” not so long ago is that it is easy to make changes to the objects transmitted via the HTTP protocol (page code, file contents) in the transmission process. , and the contents of the transmitted data is extremely easy to intercept. This is not a risk when using the HTTPS protocol. With this in mind, the corporation seeks to give users a visual indicator of risk when using specific sites and their pages. According to Google reports, more than half of the sites downloaded on desktops today have already switched to using HTTPS.

In the near future, Chrome will begin to mark all pages downloaded via HTTP in Incognito mode as unsafe. In the future, Google plans to mark all pages received via the HTTP protocol as unsafe, and mark them with a red triangle, which is marked today with pages received using the “wrong” HTTPS.
')
Opponents of the “all over HTTPS” approach call their counterarguments, including:

- not all sites need to hide their content from prying eyes. For example, an online library or encyclopedia is essentially aimed at spreading knowledge, and probably needs less encryption than a bank site.
- not all sites work “through” the domain name, the mass of resources (including on the intranet) works with the use of either IP addresses or “plush” names (either acting only on the local network, or generally written in almost in hosts ), and for such "abnormal" (in fact, completely normal) addresses do not get "legal" certificates.
- encryption creates additional load on both server equipment and client devices, which, in particular, can lead to a faster discharge of the smartphone in the process of using the HTTPS site.
- suspicions of Google slyness, which, for the good purpose of protecting against modification of pages, hides their need to impede filtering their own advertisements and tracking modules on the pages of world websites.
- additional problems that law enforcement agencies and providers will encounter when trying to track traffic within programs like SORM and blocking certain resources according to court orders, which most likely will lead to forcing Internet users to install a state certificate for all devices, in order to ensure the work of the now state, “legal” MITM solution, following the example of how it was supposed to be done in Kazakhstan and some other countries.

Separately interesting is the discussion about the speed of opening pages via HTTP and HTTPS (including taking into account the use of SDPY , HTTP / 2 , etc.) the acceleration from their use compensates for the time spent on the initial establishment of a TLS connection. In the case of downloading resources from different servers or from a CDN, additional questions arise regarding the speed of site opening, which requires additional attention from the site administrator.