Sometimes, websites try to use HTTPS to be secure and get it mostly right, but they have minor errors. Until recently, Chrome marked this security state with a yellow “caution triangle” badge on the page security icon in the URL bar.

Starting with version 46, Chrome will mark the “HTTPS with Minor Errors” state using the same neutral page icon as HTTP pages.
There are two reasons for this:
  1. This change is a better visual indication of the security state of the page relative to HTTP.
  2. Chrome users will have fewer security states to learn.

(Not) Warning About Mixed Content

This change will mainly affect HTTPS pages that contain certain mixed content, such as HTTP images.

Site operators face a dilemma: Switching an HTTP site to HTTPS can initially result in mixed content, which is undesirable in the long term but important for debugging the migration. During this process the site may not be fully secured, but it will usually not be less secure than before.

Removing the yellow “caution triangle” badge means that most users will not perceive a warning on mixed content pages during such a migration. We hope that this will encourage site operators to switch to HTTPS sooner rather than later.

Fewer Security States

This change will reduce the number of page security states in Chrome from four to three.

We have to strike a balance: representing the security state of a webpage as accurately as possible, while making sure users are not overwhelmed with too many possible states and details. We’ve come to understand that our yellow “caution triangle” badge can be confusing when compared to the HTTP page icon, and we believe that it is better not to emphasize the difference in security between these two states to most users. For developers and other interested users, it will still be possible to tell the difference by checking whether the URL begins with “https://”.

In the long term, we hope that most sites on the internet will become secure, and we plan to reduce the icon to just two states: secure and not secure. The change announced in this post is a small step in that direction.


Since 2008, we've worked to encrypt the connections between our users and Google servers. Over the years we've announced that Search, Gmail, Drive, and many other products have encrypted connections by default, and most recently, we've made a similar announcement for our ads products.

In this same vein, today we're expanding on the HTTPS Everywhere mission and beginning an initial rollout of HTTPS support for Blogspot. HTTPS is a cornerstone of internet security as it provides several important benefits: it makes it harder for bad actors to steal information or track the activities of blog authors and visitors, it helps check that visitors open the correct website and aren’t being redirected to a malicious location, and it helps detect if a bad actor tries to change any data sent from Blogger to a blog visitor.

While this initial rollout won’t support all of our Blogger users, we wanted to take the first step to make HTTPS available for Blogspot; for those users who want to try it early.

We’re rolling this out gradually and Blogspot authors interested in enabling HTTPS support can begin opting-in today. Simply log into, click on the blog you’d like to make HTTPS enabled, navigate to the Settings page, and select "yes" for "HTTPS Availability". Unfortunately, blogs with custom domains are not supported in this first version.
Once enabled, your blog will become accessible over both HTTP and HTTPS connections. Blogspot authors should be aware that if they choose to encrypt at this time, some of the current functionality of their blog may not work over HTTPS. This can be a result of template, gadgets, and blog post content, and is often caused by mixed content errors, some of which may be fixable by the author themselves.

We’ll also be moving some of our own blogs over to HTTPS gradually, beginning with the Official Google Blog and the Google Online Security Blog.

For the Blogspot authors who try this out - we’re interested to hear your feedback while we continue to improve this feature and its capabilities! For more information, visit our Help Center.



On September 14, around 19:20 GMT, Symantec’s Thawte-branded CA issued an Extended Validation (EV) pre-certificate for the domains and This pre-certificate was neither requested nor authorized by Google.

We discovered this issuance via Certificate Transparency logs, which Chrome has required for EV certificates starting January 1st of this year. The issuance of this pre-certificate was recorded in both Google-operated and DigiCert-operated logs.

During our ongoing discussions with Symantec we determined that the issuance occurred during a Symantec-internal testing process.

We have updated Chrome’s revocation metadata to include the public key of the misissued certificate. Additionally, the issued pre-certificate was valid only for one day.

Our primary consideration in these situations is always the security and privacy of our users; we currently do not have reason to believe they were at risk.


  1. TLS 1.2 must be supported.
  2. A Server Name Indication (SNI) extension must be included in the handshake and must contain the domain that's being connected to.
  3. The cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 must be supported with P-256 and uncompressed points.
  4. At least the certificates in must be trusted.
  5. Certificate handling must be able to support DNS Subject Alternative Names and those SANs may include a single wildcard as the left-most label in the name.

In order to make testing as easy as possible we have set up https://­cert-test.­sandbox.­google.­com, which requires points 1–3 to be met in order to make a successful connection. Thus, if your TLS client can’t connect to that host then you need to update your libraries or configuration.

No longer serving a cross-sign to Equifax

At the moment the certificate chains that Google properties serve most often include a cross-sign from our CA, GeoTrust, to our previous CA, Equifax. This allows clients that only trust our previous CA to continue to function. However, this cross-sign is only a transitional workaround for such clients and we will be removing it in the future. Clients that include our required set of root CAs (at will not be affected, but any that don’t include the needed GeoTrust root may stop working.


For the last few months, we’ve been raising awareness of the ad injection economy, showing how unwanted ad injectors can hurt user experience, jeopardize user security, and generate significant volumes of unwanted ads. We’ve used learnings from our research to prevent and remove unwanted ad injectors from Google services and improve our policies and technologies to make it more difficult to spread this unwanted software.

Today, we’re announcing a new measure to remove injected ads from the advertising ecosystem, including an automated filter in DoubleClick Bid Manager that removes impressions generated by ad injectors before any bid is made.

Unwanted ad injectors: disliked by users, advertisers, and publishers
Unwanted ad injectors are programs that insert new ads, or replace existing ones, in the pages users visit while browsing the web. Unwanted ad injectors aren’t part of a healthy ads ecosystem. They’re part of an environment where bad practices hurt users, advertisers, and publishers alike.

We’ve received almost 300,000 user complaints about them in Chrome since the beginning of 2015—more than any other issue, and it’s no wonder. Ad injectors affect all sites equally. You wouldn’t be happy if you tried to get the morning news and saw this:
Not only are they intrusive, but people are often tricked into installing them in the first place, via deceptive advertising, or software “bundles.” Ad injection can also be a security risk, as the recent “Superfish” incident showed.

Ad injectors are problematic for advertisers and publishers as well. Advertisers often don’t know their ads are being injected, which means they don’t have any idea where their ads are running. Publishers, meanwhile, aren’t being compensated for these ads, and more importantly, they unknowingly may be putting their visitors in harm’s way, via spam or malware in the injected ads.

Removing injected inventory from advertising
Earlier this quarter, we launched an automated filter on DoubleClick Bid Manager to prevent advertisers from buying injected ads across the web. This new system detects ad injection and proactively creates a blacklist that prevents our systems from bidding on injected inventory. Advertisers and agencies using our platforms are already protected. No adjustments are needed. No settings to change.

We currently blacklist 1.4% of the inventory accessed by DoubleClick Bid Manager across exchanges. However, we’ve found this percentage varies widely by provider. Below is a breakdown showing the filtered percentages across some of the largest exchanges:
We’ve always enforced policies against the sale of injected inventory on our ads platforms, including the DoubleClick Ad Exchange. Now advertisers using DoubleClick Bid Manager can avoid injected inventory across the web.

No more injected ads?
We don’t expect the steps we’ve outlined above to solve the problem overnight, but we hope others across the industry take action to cut ad injectors out of advertising. With the tangle of different businesses involved—knowingly, or unknowingly—in the ad injector ecosystem, progress will only be made if we all work together. We strongly encourage all members of the ads ecosystem to review their policies and practices and take actions to tackle this issue.

Posted by Elie Bursztein - Anti-abuse team, Parisa Tabriz - Chrome Security and Niels Provos - Security team

USENIX Enigma is a new conference focused on security, privacy and electronic crime through the lens of emerging threats and novel attacks. The goal of this conference is to help industry, academic, and public-sector practitioners better understand the threat landscape. Enigma will have a single track of 30-minute talks that are curated by a panel of experts, featuring strong technical content with practical applications to current and emerging threats.

Google is excited to both sponsor and help USENIX build Enigma, since we share many of its core principles: transparency, openness, and cutting-edge security research. Furthermore, we are proud to provide Enigma with with engineering and design support, as well as volunteer participation in program and steering committees.

The first instantiation of Enigma will be held January 25-27 in San Francisco. You can sign up for more information about the conference or propose a talk through the official conference site at


Today, you can find more online security tips in a few seconds than you could use in a lifetime. While this collection of best practices is rich, it’s not always useful; it can be difficult to know which ones to prioritize, and why.

Questions like ‘Why do people make some security choices (and not others)?’ and ‘How effectively does the security community communicate its best practices?’ are at the heart of a new paper called, “ one can hack my mind”: Comparing Expert and Non-Expert Security Practices” that we’ll present this week at the Symposium on Usable Privacy and Security.

This paper outlines the results of two surveys—one with 231 security experts, and another with 294 web-users who aren’t security experts—in which we asked both groups what they do to stay safe online. We wanted to compare and contrast responses from the two groups, and better understand differences and why they may exist.

Experts’ and non-experts’ top 5 security practices

Here are experts’ and non-experts’ top security practices, according to our study. We asked each participant to list 3 practices:
Common ground: careful password management

Clearly, careful password management is a priority for both groups. But, they differ on their approaches.

Security experts rely heavily on password managers, services that store and protect all of a user’s passwords in one place. Experts reported using password managers, for at least some of their accounts, three-times more frequently than non-experts. As one expert said, “Password managers change the whole calculus because they make it possible to have both strong and unique passwords.”

On the other hand, only 24% of non-experts reported using password managers for at least some of their accounts, compared to 73% of experts. Our findings suggested this was due to lack of education about the benefits of password managers and/or a perceived lack of trust in these programs. “I try to remember my passwords because no one can hack my mind,” one non-expert told us.

Key differences: software updates and antivirus software

Despite some overlap, experts’ and non-experts’ top answers were remarkably different.

35% of experts and only 2% of non-experts said that installing software updates was one of their top security practices. Experts recognize the benefits of updates—“Patch, patch, patch,” said one expert—while non-experts not only aren’t clear on them, but are concerned about the potential risks of software updates. A non-expert told us: “I don’t know if updating software is always safe. What [if] you download malicious software?” and “Automatic software updates are not safe in my opinion, since it can be abused to update malicious content.”

Meanwhile, 42% of non-experts vs. only 7% of experts said that running antivirus software was one of the top three three things they do to stay safe online. Experts acknowledged the benefits of antivirus software, but expressed concern that it might give users a false sense of security since it’s not a bulletproof solution.

Next Steps

In the immediate term, we encourage everyone to read the full research paper, borrow experts’ top practices, and also check out our tips for keeping your information safe on Google.

More broadly, our findings highlight fundamental misunderstandings about basic online security practices. Software updates, for example, are the seatbelts of online security; they make you safer, period. And yet, many non-experts not only overlook these as a best practice, but also mistakenly worry that software updates are a security risk.

No practice on either list—expert or non-expert—makes users less secure. But, there is clearly room to improve how security best practices are prioritized and communicated to the vast majority of (non expert) users. We’re looking forward to tackling that challenge.



Google Legal
Tim Willis, Hacker Philanthropist, Chrome Security Team

  • Rules are dangerously broad and vague. The proposed rules are not feasible and would require Google to request thousands - maybe even tens of thousands - of export licenses. Since Google operates in many different countries, the controls could cover our communications about software vulnerabilities, including: emails, code review systems, bug tracking systems, instant messages - even some in-person conversations! BIS’ own FAQ states that information about a vulnerability, including its causes, wouldn’t be controlled, but we believe that it sometimes actually could be controlled information.
  • You should never need a license when you report a bug to get it fixed. There should be standing license exceptions for everyone when controlled information is reported back to manufacturers for the purposes of fixing a vulnerability. This would provide protection for security researchers that report vulnerabilities, exploits, or other controlled information to any manufacturer or their agent.
  • Global companies should be able to share information globally. If we have information about intrusion software, we should be able to share that with our engineers, no matter where they physically sit.
  • Clarity is crucial. We acknowledge that we have a team of lawyers here to help us out, but navigating these controls shouldn’t be that complex and confusing. If BIS is going to implement the proposed controls, we recommend providing a simple, visual flowchart for everyone to easily understand when they need a license.
  • These controls should be changed ASAP. The only way to fix the scope of the intrusion software controls is to do it at the annual meeting of Wassenaar Arrangement members in December 2015.

We’re committed to working with BIS to make sure that both white hat security researchers’ interests and Google users’ interests are front of mind. The proposed BIS rule for public comment is available here, and comments can also be sent directly to If BIS publishes another proposed rule on intrusion software, we’ll make sure to come back and update this blog post with details.