marked all HTTP web pages as insecure and is planning to explicitly and actively inform users that HTTP connections provide no data security protections. Google is ready to give New Year gift to the Internet users, who are concerned about their privacy and security. The Chromium Project's security team hasand is planning to explicitly and actively inform users that HTTP connections provide no data security protections.





Let's Encrypt, launched by the non-profit foundation EFF (Electronic Frontier Foundation) in collaboration with big and reputed companies including Mozilla, Cisco, and Akamai to offer free HTTPS/SSL certificates for those running servers on the Internet at the beginning of 2015. There are also projects like, launched by the non-profit foundation EFF (Electronic Frontier Foundation) in collaboration with big and reputed companies including Mozilla, Cisco, and Akamai tofor those running servers on the Internet at the beginning of 2015.

This is not the first time when Google is taking initiative to encourage website owners to switch to HTTPS by default. Few months ago, the web Internet giant also made changes in its search engine algorithm in an effort to give a slight ranking boost to the websites that use encrypted HTTPS connections.

"We, the Chrome Security Team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure," the team writes in its blog post. The post continues, "the goal of this proposal is to more clearly display to users that HTTP provides no data security."

"We all need data communication on the web to be secure (private, authenticated, untampered). When there is no data security, the UA should explicitly display that, so users can make informed decisions about how to interact with an origin."

Users always compromise between their security and the flexibility/freedom while browsing the Internet. Now when I talk about Security, it means to reduce and lessen the online attack vectors, which generally minimizes our freedom to use some or more features.





The security team also remarks that HTTPS traffic usually produces a change to the user interface notification like new address bar indicators for the various browsers, yet insecure HTTP traffic does not. The security indicators and warnings are supposed to protect users from site-forgery attacks, such as man-in-the-middle attacks or 'phishing' sites.

"We know that people do not generally perceive the absence of a warning sign," the Google Chome Security Team wrote. "Yet the only situation in which web browsers are guaranteed not to warn users is precisely when there is no chance of security: when the origin is transported via HTTP."

The researchers' team suggests that browsers instead define three basic sates of transport layer security:

Secure (valid HTTPS, other origins like (*, localhost, *))

(valid HTTPS, other origins like (*, localhost, *)) Dubious (valid HTTPS but with mixed passive resources, valid HTTPS with minor TLS errors)

(valid HTTPS but with mixed passive resources, valid HTTPS with minor TLS errors) Non-secure (broken HTTPS, HTTP)

More specifically, Google is encouraging user agent (UA) vendors to take a phased approach to implementing these changes given the needs of their users and their product design constraints.

"Generally, we suggest a phased approach to marking non-secure origins as non-secure," the team wrote. "For example, a UA vendor might decide that in the medium term, they will represent non-secure origins in the same way that they represent Dubious origins. Then, in the long term, the vendor might decide to represent non-secure origins in the same way that they represent Bad origins."