theDocumentId => 1331851 Google to Delete 'Secure' Label from HTTPS Sites

Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

5/21/2018
12:00 PM
Kelly Sheridan
Kelly Sheridan
Quick Hits
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Google to Delete 'Secure' Label from HTTPS Sites

Google acknowledges HTTPS as the Internet standard with plans to remove 'secure' from all HTTPS sites.

Google plans to remove the "secure" label from HTTPS websites starting in September 2018, a move intended to acknowledge HTTPS as the standard for browser security. Users should expect all the sites they visit to be secured with HTTPS, the company reported last week.

Earlier this year, Google announced plans to mark all HTTP sites as "not secure" and alert users when they visit unencrypted pages. Previously, HTTP usage was too high to brand all unsecured pages with a warning. Now HTTPS is more common so Google is making it the standard by flagging unencrypted websites and removing secure indicators from encrypted ones.

"I like the idea of assuming a 'secure' setting by default and training users to accept a secure, default setting," says Dr. Engin Kirda, co-founder and Chief Architect at Lastline. "I expect users will be more likely to take 'not secure' warnings more seriously rather than actively check that a website is secure, as in the past."

The change will come into effect in Chrome 69. Read more details here.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
5/21/2018 | 3:41:40 PM
Not Secure
I have not visited an external HTTP site for quite some time. I am all for this change. It looks to normalize HTTPS as the standard (which it most definitely is) and shame HTTP as an insecure mode of transit. 
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-23416
PUBLISHED: 2021-07-28
This affects all versions of package curly-bracket-parser. When used as a template library, it does not properly sanitize the user input.
CVE-2021-23417
PUBLISHED: 2021-07-28
All versions of package deepmergefn are vulnerable to Prototype Pollution via deepMerge function.
CVE-2021-23415
PUBLISHED: 2021-07-28
This affects the package elFinder.AspNet before 1.1.1. The user-controlled file name is not properly sanitized before it is used to create a file system path.
CVE-2020-4974
PUBLISHED: 2021-07-28
IBM Jazz Foundation products are vulnerable to server side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 192434.
CVE-2020-5004
PUBLISHED: 2021-07-28
IBM Jazz Foundation products are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 192957.