Posted by Lucas Garron, Chrome security and David Benjamin, Chrome networking

As announced last September and supported by further recent research, Google Chrome does not treat SHA-1 certificates as secure anymore, and will completely stop supporting them over the next year. Chrome will discontinue support in two steps: first, blocking new SHA-1 certificates; and second, blocking all SHA-1 certificates.

Step 1: Blocking new SHA-1 certificates

Starting in early 2016 with Chrome version 48, Chrome will display a certificate error if it encounters a site with a leaf certificate that:

1. is signed with a SHA-1-based signature
2. is issued on or after January 1, 2016
3. chains to a public CA

Posted by Zineb Ait Bahajji, WTA, and the Google Security and Indexing teams

[Cross-posted from the Webmaster Central Blog]

At Google, user security has always been a top priority. Over the years, we’ve worked hard to promote a more secure web and to provide a better browsing experience for users. Gmail, Google search, and YouTube have had secure connections for some time, and we also started giving a slight ranking boost to HTTPS URLs in search results last year. Browsing the web should be a private experience between the user and the website, and must not be subject to eavesdropping, man-in-the-middle attacks, or data modification. This is why we’ve been strongly promoting HTTPS everywhere.

As a natural continuation of this, today we'd like to announce that we're adjusting our indexing system to look for more HTTPS pages. Specifically, we’ll start crawling HTTPS equivalents of HTTP pages, even when the former are not linked to from any page. When two URLs from the same domain appear to have the same content but are served over different protocol schemes, we’ll typically choose to index the HTTPS URL if:

• It doesn’t contain insecure dependencies.
• It isn’t blocked from crawling by robots.txt.
• It doesn’t redirect users to or through an insecure HTTP page.
• It doesn’t have a rel="canonical" link to the HTTP page.
• It doesn’t contain a noindex robots meta tag.
• It doesn’t have on-host outlinks to HTTP URLs.
• The sitemaps lists the HTTPS URL, or doesn’t list the HTTP version of the URL.
• The server has a valid TLS certificate.

Posted by Ryan Sleevi, Software Engineer

Over the course of the coming weeks, Google will be moving to distrust the “Class 3 Public Primary CA” root certificate operated by Symantec Corporation, across Chrome, Android, and Google products. We are taking this action in response to a notification by Symantec Corporation that, as of December 1, 2015, Symantec has decided that this root will no longer comply with the CA/Browser Forum’s Baseline Requirements. As these requirements reflect industry best practice and are the foundation for publicly trusted certificates, the failure to comply with these represents an unacceptable risk to users of Google products.

Symantec has informed us they intend to use this root certificate for purposes other than publicly-trusted certificates. However, as this root certificate will no longer adhere to the CA/Browser Forum’s Baseline Requirements, Google is no longer able to ensure that the root certificate, or certificates issued from this root certificate, will not be used to intercept, disrupt, or impersonate the secure communication of Google’s products or users. As Symantec is unwilling to specify the new purposes for these certificates, and as they are aware of the risk to Google’s users, they have requested that Google take preventative action by removing and distrusting this root certificate. This step is necessary because this root certificate is widely trusted on platforms such as Android, Windows, and versions of OS X prior to OS X 10.11, and thus certificates Symantec issues under this root certificate would otherwise be treated as trustworthy.

Symantec has indicated that they do not believe their customers, who are the operators of secure websites, will be affected by this removal. Further, Symantec has also indicated that, to the best of their knowledge, they do not believe customers who attempt to access sites secured with Symantec certificates will be affected by this. Users or site operators who encounter issues with this distrusting and removal should contact Symantec Technical Support.

Further Technical Details of Affected Root:
Friendly Name: Class 3 Public Primary Certification Authority
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Public Key Hash (SHA-1): E2:7F:7B:D8:77:D5:DF:9E:0A:3F:9E:B4:CB:0E:2E:A9:EF:DB:69:77
Public Key Hash (SHA-256):
B1:12:41:42:A5:A1:A5:A2:88:19:C7:35:34:0E:FF:8C:9E:2F:81:68:FE:E3:BA:18:7F:25:3B:C1:A3:92:D7:E2

MD2 Version
Fingerprint (SHA-1): 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
Fingerprint (SHA-256): E7:68:56:34:EF:AC:F6:9A:CE:93:9A:6B:25:5B:7B:4F:AB:EF:42:93:5B:50:A2:65:AC:B5:CB:60:27:E4:4E:70

SHA1 Version
Fingerprint (SHA-1): A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
Fingerprint (SHA-256): A4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09:CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05

Posted by Moheeb Abu Rajab, Google Security Team

“At least 2 or 3 times a week I get a big blue warning screen with a loud voice telling me that I’ve a virus and to call the number at the end of the big blue warning.”
“I’m covered with ads and unwanted interruptions. what’s the fix?”
“I WORK FROM HOME AND THIS POPING [sic] UP AND RUNNING ALL OVER MY COMPUTER IS NOT RESPECTFUL AT ALL THANK YOU.”

Launched in 2007, Safe Browsing has long helped protect people across the web from well-known online dangers like phishing and malware. More recently, however, we’ve seen an increase in user complaints like the ones above. These issues and others—hijacked browser settings, software installed without users' permission that resists attempts to uninstall—have signaled the rise of a new type of malware that our systems haven’t been able to reliably detect.

More than a year ago, we began a broad fight against this category of badness that we now call “Unwanted Software”, or “UwS” (pronounced “ooze”). Today, we wanted to share some progress and outline the work that must happen in order to continue protecting users across the web.

What is UwS and how does it get on my computer?

In order to combat UwS, we first needed to define it. Despite lots of variety, our research enabled us to develop a defining list of characteristics that this type of software often displays:

• It is deceptive, promising a value proposition that it does not meet.
• It tries to trick users into installing it or it piggybacks on the installation of another program.
• It doesn’t tell the user about all of its principal and significant functions.
• It affects the user’s system in unexpected ways.
• It is difficult to remove.
• It collects or transmits private information without the user’s knowledge.
• It is bundled with other software and its presence is not disclosed.

Posted by Alexei Czeskis, Software Engineer

Authenticator for Android is used by millions of users and, combined with 2-Step Verification, it provides an extra layer of protection for Google Accounts.

Our latest version has some cool new features. You will notice a new icon and a refreshed design. There's also support for Android Wear devices, so you'll be able to get verification codes from compatible devices, like your watch.
The new Authenticator also comes with a developer preview of support for NFC Security Key, based on the FIDO Universal 2nd Factor (U2F) protocol via NFC. Play Store will prompt for the NFC permission before you install this version of Authenticator.

Developers who want to learn more about U2F can refer to FIDO's specifications. Additionally, you can try it out at https://u2fdemo.appspot.com. Note that you'll need an Android device running the latest versions of Google Chrome and Authenticator and also a Security Key with NFC support.

You can find the latest Authenticator for Android on the Play Store.

Posted by Noé Lutz, Nathan Parker, Stephan Somogyi; Google Chrome and Safe Browsing Teams


Google Safe Browsing has been protecting well over a billion desktop users against malware, unwanted software, and social engineering sites on the web for years. Today, we’re pleased to announce that we’ve extended our protective umbrella to hundreds of millions of Chrome users on Android.

How To Get It

If you’re an Android user, you probably already have it! This new Safe Browsing client on Android is part of Google Play Services, starting with version 8.1. The first app to use it is Chrome, starting with version 46—we’re now protecting all Android Chrome users by default. If you look at Chrome’s Settings > Privacy menu, you can verify that Safe Browsing is enabled and that you’re protected. Chrome warns you about dangerous sites as shown below. It does this while preserving your privacy, just like on desktop.

What Came Before

The Android platform and the Play Store have long had protection against potentially harmful apps. And as our adversaries have improved their skills in trying to evade us, we’ve improved our detection, keeping Android app users safe. But not all dangers to mobile users come from apps.

What’s New
Social engineering—and phishing in particular—requires different protection; we need to keep an up-to-date list of bad sites on the device to make sure we can warn people before they browse into a trap. Providing this protection on a mobile device is much more difficult than on a desktop system, in no small part because we have to make sure that list doesn’t get stale, yet:

• Mobile data costs money for most users around the world. Data size matters a lot.
• Mobile data speeds are slower than Wi-Fi in much of the world. Data size matters a lot.
• Cellular connectivity quality is much more uneven, so getting the right data to the device quickly is critically important. Data size matters a lot.

Maximum Protection Per Bit

Bytes are big: our mantra is that every single bit that Safe Browsing sends a mobile device must improve protection. Network bandwidth and battery are the scarcest resources on a mobile device, so we had to carefully rethink how to best protect mobile users. Some social engineering attacks only happen in certain parts of the world, so we only send information that protects devices in the geographic regions they’re in.

We also make sure that we send information about the riskiest sites first: if we can only get a very short update through, as is often the case on lower-speed networks in emerging economies, the update really has to count. We also worked with Google’s compression team to make the little data that we do send as small as possible.

Together with the Android Security team, we made the software on the device extra stingy with memory and processor use, and careful about minimizing network traffic. All of these details matter to us; we must not waste our users’ data plans, or a single moment of their battery life.

More Mobile

We hunt badness on the Internet so that you don’t discover it the hard way, and our protection should never be an undue burden on your networking costs or your device’s battery. As more of the world relies on the mobile web, we want to make sure you’re as safe as can be, as efficiently as possible.

Posted by Emily Schechter, Program Manager and Noé Lutz, Software Engineer

Safe Browsing has been protecting over one billion people from traditional phishing attacks on the web for more than eight years. The threat landscape is constantly changing—bad actors on the web are using more and different types of deceptive behavior to trick you into performing actions that you didn’t intend or want, so we’ve expanded protection to include social engineering.

Social engineering is a much broader category than traditional phishing and encompasses more types of deceptive web content. A social engineering attack happens when either:

• The content pretends to act, or looks and feels, like a trusted entity — like a bank or government.
• The content tries to trick you into doing something you’d only do for a trusted entity — like sharing a password or calling tech support.

Below are some examples of social engineering attacks that try to trick you into thinking the content is delivered by Google or Chrome. Other trusted brands are also commonly abused for social engineering attacks.

Posted by Elie Bursztein, Anti-Fraud and Abuse Research and Nicolas Lidzborski, Gmail Security Engineering Lead


We’re constantly working to help make email more secure for everyone. These efforts are reflected in security protections like default HTTPS in Gmail as well as our Safer Email Transparency report, which includes information about email security beyond just Gmail.

To that end, in partnership with the University of Michigan and the University of Illinois, we’re publishing the results of a multi-year study that measured how email security has evolved since 2013. While Gmail was the foundation of this research, the study’s insights apply to email more broadly, not unlike our Safer Email Transparency report. It’s our hope that these findings not only help make Gmail more secure, but will also be used to help protect email users everywhere as well.

Email security strengthens, industry-wide
The study showed that email is more secure today than it was two years ago. Here are some specific findings:

Posted by Ryan Sleevi, Software Engineer

This post updates our previous notification of a misissued certificate for google.com

Following our notification, Symantec published a report in response to our inquiries and disclosed that 23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google and Opera.

However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research.

Symantec performed another audit and, on October 12th, announced that they had found an additional 164 certificates over 76 domains and 2,458 certificates issued for domains that were never registered.

It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. In this case, logging of non-EV certificates would have provided significantly greater insight into the problem and may have allowed the problem to be detected sooner.

After this date, certificates newly issued by Symantec that do not conform to the Chromium Certificate Transparency policy may result in interstitials or other problems when used in Google products.

More immediately, we are requesting of Symantec that they further update their public incident report with:

1. A post-mortem analysis that details why they did not detect the additional certificates that we found.
2. Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.

We are also requesting that Symantec provide us with a detailed set of steps they will take to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. Symantec may consider this latter information to be confidential and so we are not requesting that this be made public.

Posted by 
Adrienne Porter Felt, Chrome Security Engineer and Warning Wizard
Emily Schechter, Safe Browsing Program Manager and Menace to Malware
Ke Wang, Safe Browsing Engineer and Developer of Defense

You’re browsing the web, checking out the latest news on your favorite band, when suddenly you see a red warning screen: “The site ahead contains malware.” These warnings aren’t new—since 2006, Google Safe Browsing has shown them when you navigate to an unsafe site. The warnings protect you from harms caused by unsafe sites, such as malware infections and phishing attacks. But it hasn’t always been clear why a specific website triggers a warning, and you may want to learn more.

To demystify these warnings, we’re launching a Site Status section in the Transparency Report. The next time you come across a Safe Browsing warning, you can search for the blocked website in the Transparency Report to learn why it’s been flagged by our systems.

The new Site Status section of the Transparency Report replaces our previous Safe Browsing diagnostic page. It includes a clearer interface and simpler explanations of the issues, such as details for sites that host unwanted software. We’ve added it to the Transparency Report so that the Safe Browsing section of the report is a one-stop shop for information to help you understand what Safe Browsing is and how it works.
If a favorite website shows up as “dangerous,” it’s often due to user-uploaded bad content or a temporary malware infection. The Site Status will return to normal once the webmaster has cleaned up the website. To help speed up this process, we automatically give the webmaster a heads-up about the problem via Search Console; if you use Google Analytics, we’ll also warn you there if your site has malware on it. (Webmasters, check the help center to learn how to remove malware from your websites.)

We’re constantly working to keep users safe and informed online. Visit the updated Site Status section in the Transparency Report to experience it yourself.

Posted by Lucas Garron and Chris Palmer, Chrome security team

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.

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.

Posted by Jo-el van Bergen, Software Engineer, Security.

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 https://www.blogger.com, 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.

Posted by Kurt Thomas and Elie Bursztein, Google Anti-Fraud and Abuse Research

Recently, we teamed up with top researchers exploring innovative anti-abuse strategies to build a holistic understanding of for-profit abuse. The full report, which you can read here, was presented in June at the Workshop on the Economics of Information Security 2015.

Over the last decade, Internet crime has matured into an underground economy where a large number of globally distributed criminals trade in data, knowledge, and services specifically geared towards defrauding users and businesses. Within this black market, criminals buy and sell compromised machines, scam hosting, exploit kits, and wholesale access to pilfered user records including usernames and passwords, credit card numbers, and other sensitive personal data. The availability of such specialized resources has transformed for-profit abuse into a cooperative effort among criminals each satisfying a cog in a supply chain.
Profiting from abuse: a bird's eye view

Here’s an example of the underground value chain required to make money from spamming knock-off luxury products:

In aggregate, the problem may appear intractable to stop. However, if we view this scenario in an economic light, then increasing the cost of fake accounts, phone numbers, or compromised websites cuts into the profitability of abuse. In the end, abuse propped up by cost-ineffective resources will crumble.

Collaborating to better understand the underground

Given the complex underbelly of abuse, we pulled together experts from industry and academia to build a systematic understanding of how criminals operate. Our previous example represents just one configuration of a value chain. In our example, revenue originates solely from victims buying counterfeit products. Criminals could adapt this strategy to scam users into paying for fake anti-virus, defraud advertisers via clickbots, or liquidate a victim’s banking assets. Regardless of the composition, we argue there is always a profit center through which victims transfer new capital into the underground. These schemes form a spectrum between selling products to unwitting victims to outright theft. A medley of alternatives such as dating scams, call-center scams, premium SMS fraud, DDoS extortion, or even stealing and re-selling gaming assets all fall within this spectrum and ultimately derive a payout from victims outside the underground.

These profit centers are in turn propped up by an ecosystem of support infrastructure that can be configured arbitrarily by criminals per their requirements. This infrastructure includes compromised hosts, human labor, networking and hosting, and accounts and engagement—all available for a fee. For example, 1,000 Google accounts cost on the order of $170, compared to CAPTCHAs which cost $1 per thousand. These costs reflect socio-economic factors as well as the impact of technical, legal, and law enforcement interventions on the availability of resources.
Redefining the abuse arms race
Client and server-side security has dominated industry’s response to digital abuse over the last decade. The spectrum of solutions—automated software updates, personal anti-virus, network packet scanners, firewalls, spam filters, password managers, and two-factor authentication to name a few—all attempt to reduce the attack surface that criminals can penetrate.

While these safeguards have significantly improved user security, they create an arms race: criminals adapt or find the subset of systems that remain vulnerable and resume operation. To overcome this reactive defense cycle, we are improving our approach to abuse fighting to also strike at the support infrastructure, financial centers, and actors that incentivize abuse. By exploring the value chain required to bulk register accounts, we were able to make Google accounts 30–40% more expensive on the black market.

Success stories from our academic partners include disrupting payment processing for illegal pharmacies and counterfeit software outlets advertised by spam, cutting off access to fake accounts that pollute online services, and disabling the command and control infrastructure of botnets.

Posted by Stephan Somogyi, Security & Privacy PM, and Adam Eijdenberg, Certificate Transparency PM

On September 14, around 19:20 GMT, Symantec’s Thawte-branded CA issued an Extended Validation (EV) pre-certificate for the domains google.com and www.google.com. 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.

Posted by Adam Langley, Security Engineer

As the previously announced transition to SHA-256 certificates is nearing completion, we are planning the next changes to Google’s TLS configuration. As part of those changes, we expect to disable support for SSLv3 and RC4 in the medium term.

SSLv3 has been obsolete for over 16 years and is so full of known problems that the IETF has decided that it must no longer be used. RC4 is a 28 year old cipher that has done remarkably well, but is now the subject of multiple attacks at security conferences. The IETF has decided that RC4 also warrants a statement that it too must no longer be used.

Because of these issues we expect to disable both SSLv3 and RC4 support at Google’s frontend servers and, over time, across our products in general, including Chrome, Android, our webcrawlers and our SMTP servers. (Indeed, SSLv3 support has already been removed from Chrome.) The SSL Pulse survey of the top 200,000 HTTPS sites finds that, already, 42% of sites have disabled RC4 and 65% of sites have disabled SSLv3.

If your TLS client, webserver or email server requires the use of SSLv3 or RC4 then the time to update was some years ago, but better late than never. However, note that just because you might be using RC4 today doesn’t mean that your client or website will stop working: TLS can negotiate cipher suites and problems will only occur if you don’t support anything but RC4. (Although if you’re using SSLv3 today then things will stop working when we disable it because SSLv3 is already a last resort.)

Minimum standards for TLS clients

Google's frontend servers do a lot more than terminate connections for browsers these days; there are also lots of embedded systems talking to Google using TLS. In order to reduce the amount of work that the deprecation of outdated cryptography causes, we are also announcing suggested minimum standards for TLS clients today. This applies to TLS clients in general: certainly those that are using TLS as part of HTTPS, but also, for example, SMTP servers using STARTTLS.

We can't predict the future, but devices that meet these requirements are likely to be able to continue functioning without changes to their TLS configuration up to 2020. You should expect these standards to be required in cases where Google runs certification programs, but it’s a very good idea to meet them anyway.

Devices that don’t meet these standards aren’t going to stop working anytime soon (unless they depend on RC4 or SSLv3—see above), but they might be affected by further TLS changes in the coming years.

Specifically, we are requiring:

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 https://pki.google.com/roots.pem 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.

Posted by Vegard Johnsen, Product Manager, Google Ads Traffic Quality

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 
Iulia Ion, Software Engineer - Rob Reeder, Research Scientist - Sunny Consolvo, User Experience Researcher

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, “...no 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

Posted by Vegard Johnsen, Product Manager Google Ad Traffic Quality

Today the Trustworthy Accountability Group (TAG) announced a new pilot blacklist to protect advertisers across the industry. This blacklist comprises data-center IP addresses associated with non-human ad requests. We're happy to support this effort along with other industry leaders—Dstillery, Facebook, MediaMath, Quantcast, Rubicon Project, TubeMogul and Yahoo—and contribute our own data-center blacklist. As mentioned to Ad Age and in our recent call to action, we believe that if we work together we can raise the fraud-fighting bar for the whole industry.

Data-center traffic is one of many types of non-human or illegitimate ad traffic. The newly shared blacklist identifies web robots or “bots” that are being run in data centers but that avoid detection by the IAB/ABC International Spiders & Bots List. Well-behaved bots announce that they're bots as they surf the web by including a bot identifier in their declared User-Agent strings. The bots filtered by this new blacklist are different. They masquerade as human visitors by using User-Agent strings that are indistinguishable from those of typical web browsers.

In this post, we take a closer look at a few examples of data-center traffic to show why it’s so important to filter this traffic across the industry.

Impact of the data-center blacklist

When observing the traffic generated by the IP addresses in the newly shared blacklist, we found significantly distorted click metrics. In May of 2015 on DoubleClick Campaign Manager alone, we found the blacklist filtered 8.9% of all clicks. Without filtering these clicks from campaign metrics, advertiser click-through rates would have been incorrect and for some advertisers this error would have been very large.

Below is a plot that shows how much click-through rates in May would have been inflated across the most impacted of DoubleClick Campaign Manager’s larger advertisers.
Two examples of bad data-center traffic

There are two distinct types of invalid data-center traffic: where the intent is malicious and where the impact on advertisers is accidental. In this section we consider two interesting examples where we’ve observed traffic that was likely generated with malicious intent.

Publishers use many different strategies to increase the traffic to their sites. Unfortunately, some are willing to use any means necessary to do so. In our investigations we’ve seen instances where publishers have been running software tools in data centers to intentionally mislead advertisers with fake impressions and fake clicks.

First example

UrlSpirit is just one example of software that some unscrupulous publishers have been using to collaboratively drive automated traffic to their websites. Participating publishers install the UrlSpirit application on Windows machines and they each submit up to three URLs through the application’s interface. Submitted URLs are then distributed to other installed instances of the application, where Internet Explorer is used to automatically visit the list of target URLs. Publishers who have not installed the application can also leverage the network of installations by paying a fee.

At the end of May more than 82% of the UrlSpirit installations were being run on machines in data centers. There were more than 6,500 data-center installations of UrlSpirit, with each data-center installation running in a separate virtual machine. In aggregate, the data-center installations of UrlSpirit were generating a monthly rate of at least half a billion ad requests— an average of 2,500 fraudulent ad requests per installation per day.

Second example

HitLeap is another example of software that some publishers are using to collaboratively drive automated traffic to their websites. The software also runs on Windows machines, and each instance uses the Chromium Embedded Framework to automatically browse the websites of participating publishers—rather than using Internet Explorer.

Before publishers can use the network of installations to drive traffic to their websites, they need browsing minutes. Participating publishers earn browsing minutes by running the application on their computers. Alternatively, they can simply buy browsing minutes—with bundles starting at $9 for 10,000 minutes or up to 1,000,000 minutes for $625.

Publishers can specify as many target URLs as they like. The number of visits they receive from the network of installations is a function of how long they want the network of bots to spend on their sites. For example, ten browsing minutes will get a publisher five visits if the publisher requests two-minute visit durations.

In mid-June, at least 4,800 HitLeap installations were being run in virtual machines in data centers, with a unique IP associated with each HitLeap installation. The data-center installations of HitLeap made up 16% of the total HitLeap network, which was substantially larger than the UrlSpirit network. 

In aggregate, the data-center installations of HitLeap were generating a monthly rate of at least a billion fraudulent ad requests—or an average of 1,600 ad requests per installation per day.

Not only were these publishers collectively responsible for billions of automated ad requests, but their websites were also often extremely deceptive. For example, of the top ten webpages visited by HitLeap bots in June, nine of these included hidden ad slots -- meaning that not only was the traffic fake, but the ads couldn’t have been seen even if they had been legitimate human visitors.

http://vedgre.com/7/gg.html is illustrative of these nine webpages with hidden ad slots. The webpage has no visible content other than a single 300×250px ad. This visible ad is actually in a 300×250px iframe that includes two ads, the second of which is hidden. Additionally, there are also twenty-seven 0×0px hidden iframes on this page with each hidden iframe including two ad slots. In total there are fifty-five hidden ads on this page and one visible ad. Finally, the ads served on http://vedgre.com/7/gg.html appear to advertisers as though they have been served on legitimate websites like indiatimes.com, scotsman.com, autotrader.co.uk, allrecipes.com, dictionary.com and nypost.com, because the tags used on http://vedgre.com/7/gg.html to request the ad creatives have been deliberately spoofed.

An example of collateral damage

Unlike the traffic described above, there is also automated data-center traffic that impacts advertising campaigns but that hasn’t been generated for malicious purposes. An interesting example of this is an advertising competitive intelligence company that is generating a large volume of undeclared non-human traffic.

This company uses bots to scrape the web to find out which ad creatives are being served on which websites and at what scale. The company’s scrapers also click ad creatives to analyse the landing page destinations. To provide its clients with the most accurate possible intelligence, this company’s scrapers operate at extraordinary scale and they also do so without including bot identifiers in their User-Agent strings.

While the aim of this company is not to cause advertisers to pay for fake traffic, the company’s scrapers do waste advertiser spend. They not only generate non-human impressions; they also distort the metrics that advertisers use to evaluate campaign performance—in particular, click metrics. Looking at the data across DoubleClick Campaign Manager this company’s scrapers were responsible for 65% of the automated data-center clicks recorded in the month of May.

Going forward

Google has always invested to prevent this and other types of invalid traffic from entering our ad platforms. By contributing our data-center blacklist to TAG, we hope to help others in the industry protect themselves.

We’re excited by the collaborative spirit we’ve seen working with other industry leaders on this initiative. This is an important, early step toward tackling fraudulent and illegitimate inventory across the industry and we look forward to sharing more in the future. By pooling our collective efforts and working with industry bodies, we can create strong defenses against those looking to take advantage of our ecosystem. We look forward to working with the TAG Anti-fraud working group to turn this pilot program into an industry-wide tool.

Posted by 
Neil Martin, Export Compliance Counsel, Google Legal
Tim Willis, Hacker Philanthropist, Chrome Security Team

Cross-posted on the Google Public Policy Blog

As the usage and complexity of software grows, the importance of security research has grown with it. It’s through diligent research that we uncover and fix bugs — like Heartbleed and POODLE — that can cause serious security issues for web users around the world.

The time and effort it takes to uncover bugs is significant, and the marketplace for these vulnerabilities is competitive. That’s why we provide cash rewards for quality security research that identifies problems in our own products or proactive improvements to open-source products. We’ve paid more than $4 million to researchers from all around the world - our current Hall of Fame includes researchers from Germany, the U.S., Japan, Brazil, and more than 30 other countries.

Problematic new export controls

With the benefits of security research in mind, there has been some public head scratching and analysis around proposed export control rules put forth by the U.S. Department of Commerce that would negatively affect vulnerability research.

The Commerce Department's proposed rules stem from U.S. membership in the Wassenaar Arrangement, a multilateral export control association. Members of the Wassenaar Arrangement have agreed to control a wide range of goods, software, and information, including technologies relating to "intrusion software" (as they've defined that term).

We believe that these proposed rules, as currently written, would have a significant negative impact on the open security research community. They would also hamper our ability to defend ourselves, our users, and make the web safer. It would be a disastrous outcome if an export regulation intended to make people more secure resulted in billions of users across the globe becoming persistently less secure.

Google comments on proposed rules

Earlier today, we formally submitted comments on the proposed rules to the United States Commerce Department’s Bureau of Industry and Security (BIS). Our comments are lengthy, but we wanted to share some of the main concerns and questions that we have officially expressed to the U.S. government today:

• 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.

Posted by Moheeb Abu Rajab and Stephan Somogyi, Google Safe Browsing Team

Last year, we announced our increased focus on unwanted software (UwS), and published our unwanted software policy. This work is the direct result of our users falling prey to UwS, and how badly it was affecting their browsing experience. Since then, Google Safe Browsing’s ability to detect deceptive software has steadily improved.

In the coming weeks, these detection improvements will become more noticeable in Chrome: users will see more warnings (like the one below) about unwanted software than ever before.

We want to be really clear that Google Safe Browsing’s mandate remains unchanged: we’re exclusively focused on protecting users from malware, phishing, unwanted software, and similar harm. You won’t see Safe Browsing warnings for any other reasons.

Unwanted software is being distributed on web sites via a variety of sources, including ad injectors as well as ad networks lacking strict quality guidelines. In many cases, Safe Browsing within your browser is your last line of defense.

Google Safe Browsing has protected users from phishing and malware since 2006, and from unwanted software since 2014. We provide this protection across browsers (Chrome, Firefox, and Safari) and across platforms (Windows, Mac OS X, Linux, and Android). If you want to help us improve the defenses for everyone using a browser that integrates Safe Browsing, please consider checking the box that appears on all of our warning pages:
Safe Browsing’s focus is solely on protecting people and their data from badness. And nothing else.