Chrome will start flagging pages open over HTTP

While people around the world are inventing 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 reported that from January 2017 (with Chrome version 56), when browsing to Chrome, sites that transmit passwords and credit card numbers via HTTP (i.e., not via HTTPS) will be marked as unsafe. This is done as part of a long-term plan to move to marking all non-HTTPS sites as unsafe, which should encourage site owners to completely switch to using HTTPS.

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

Google’s position on why, not so long ago considered "normal" pages received via HTTP, become "unsafe", is that it is easy to make changes to the objects transmitted via the HTTP protocol (page code, file contents) during the transfer , and the contents of the transmitted data is extremely easy to intercept. There is no such 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, more than half of the sites loaded on desktops today have switched to using HTTPS.

In the near future, Chrome will begin to mark all pages loaded via HTTP in “Incognito” mode as insecure. In the future, Google plans to mark all pages received via the HTTP protocol as unsafe and mark them with a red triangle, which today marks pages received using the “wrong” HTTPS.

Opponents of the “all on HTTPS” approach call their counterarguments, among which:

- not all sites need to hide their content from prying eyes. Say, an online library or encyclopedia is essentially aimed at disseminating knowledge, and probably needs less encryption than a bank’s site.
- not all sites work “through” the domain name, a lot of resources (including on the intranet) work using either IP addresses or “plush” names (either acting only on the local network, or generally registered almost in hosts ), and to such "abnormal" (in fact, completely ordinary) addresses you cannot get "legal" certificates.
- encryption creates an 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 a site working on HTTPS.
- Suspicions of Google's cunning, which for the good purpose of protecting themselves from page modifications hide their need to make it difficult to filter their own ads and tracking modules on the pages of world sites.
- additional problems that law enforcement agencies and providers will encounter when trying to track traffic through programs like SORM and blocking certain resources according to the orders of the courts, which is likely to force Internet users to install a state certificate on all devices, in order to ensure the work of the now state, “legitimate” MITM solution, following the example of how it was supposed to be done in Kazakhstan and some other countries.

Of particular interest is the discussion about the speed of opening pages via HTTP and HTTPS (including taking into account the use of SDPY , HTTP / 2etc.) The transition to these protocols is interesting for sites that are sent from one server, because 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 CDN, additional questions arise regarding the speed of opening the site, which requires additional attention from the site administrator.