Posted by Ben McIlwain, Google Registry
The security of the Web is of the utmost importance to Google. One of the most powerful tools in the Web security toolbox is ensuring that connections to websites are encrypted using HTTPS, which prevents Web traffic from being intercepted, altered, or misdirected in transit. We have taken many actions to make the use of HTTPS more widespread, both within Google and on the larger Internet.

We began in 2010 by defaulting to HTTPS for Gmail and starting the transition to encrypted search by default. In 2014, we started encouraging other websites to use HTTPS by giving secure sites a ranking boost in Google Search. In 2016, we became a platinum sponsor of Let’s Encrypt, a service that provides simple and free SSL certificates. Earlier this year we announced that Chrome will start displaying warnings on insecure sites, and we recently introduced fully managed SSL certificates in App Engine. And today we’re proud to announce that we are beginning to use another tool in our toolbox, the HTTPS Strict Transport Security (HSTS) preload list, in a new and more impactful way.

The HSTS preload list is built in to all major browsers (Chrome, Firefox, Safari, Internet Explorer/Edge, and Opera). It consists of a list of hostnames for which browsers automatically enforce HTTPS-secured connections. For example, gmail.com is on the list, which means that the aforementioned browsers will never make insecure connections to Gmail; if the user types http://gmail.com, the browser first changes it to https://gmail.com before sending the request. This provides greater security because the browser never loads an http-to-https redirect page, which could be intercepted.

The HSTS preload list can contain individual domains or subdomains and even top-level domains (TLDs), which are added through the HSTS website. The TLD is the last part of the domain name, e.g., .com, .net, or .org. Google operates 45 TLDs, including .google, .how, and .soy. In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.

The use of TLD-level HSTS allows such namespaces to be secure by default. Registrants receive guaranteed protection for themselves and their users simply by choosing a secure TLD for their website and configuring an SSL certificate, without having to add individual domains or subdomains to the HSTS preload list. Moreover, since it typically takes months between adding a domain name to the list and browser upgrades reaching a majority of users, using an already-secured TLD provides immediate protection rather than eventual protection. Adding an entire TLD to the HSTS preload list is also more efficient, as it secures all domains under that TLD without the overhead of having to include all those domains individually.

We hope to make some of these secure TLDs available for registration soon, and would like to see TLD-wide HSTS become the security standard for new TLDs.

Updated 2017-10-06: To clear up some confusion in the responses to this post, we are not rolling out HSTS to Google's previously launched open TLDs (.how, .soy, and .みんな).

Posted by Stephan Somogyi, Safe Browsing Emeritus and Allison Miller, Security & Privacy

[Cross-posted from The Keyword]

In 2007, we launched Safe Browsing, one of Google’s earliest anti-malware efforts. To keep our users safe, we’d show them a warning before they visited a site that might’ve harmed their computers.

Computing has evolved a bit in the last decade, though. Smartphones created a more mobile internet, and now AI is increasingly changing how the world interacts with it. Safe Browsing also had to evolve to effectively protect users.

And it has: In May 2016, we announced that Safe Browsing was protecting more than 2 billion devices from badness on the internet. Today we’re announcing that Safe Browsing has crossed the threshold to 3 billion devices. We’re sharing a bit more about how we got here, and where we’re going.

What is Safe Browsing?

You may not know Safe Browsing by name, since most of the time we’re invisibly protecting you, without getting in the way. But you may have seen a warning like this at some point:

This notification is one of the visible parts of Safe Browsing, a collection of Google technologies that hunt badness—typically websites that deceive users—on the internet. We identify sites that might try to phish you, or sites that install malware or other undesirable software. The systems that make up Safe Browsing work together to identify, analyze and continuously keep Safe Browsing’s knowledge of the harmful parts of the internet up to date.

This protective information that we generate—a curated list of places that are dangerous for people and their devices—is used across many of our products. It helps keep search results safe and keep ads free from badness; it’s integral to Google Play Protect and keeps you safe on Android; and it helps Gmail shield you from malicious messages.

And Safe Browsing doesn’t protect only Google’s products. For many years, Safari and Firefox have protected their users with Safe Browsing as well. If you use an up-to-date version of Chrome, Firefox or Safari, you’re protected by default. Safe Browsing is also used widely by web developers and app developers (including Snapchat), who integrate our protections by checking URLs before they’re presented to their users.

Protecting more people with fewer bits

In the days when web browsers were used only on personal computers, we didn’t worry much about the amount of data Safe Browsing sent over the internet to keep your browser current. Mobile devices changed all that: Slow connections, expensive mobile data plans, and scarce battery capacity became important new considerations.

So over the last few years, we’ve rethought how Safe Browsing delivers data. We built new technologies to make its data as compact as possible: We only send the information that’s most protective to a given device, and we make sure this data is compressed as tightly as possible. (All this work benefits desktop browsers, too!)

We initially introduced our new mobile-optimized method in late 2015 with Chrome on Android, made it more broadly available in mid-2016, when we also started actively encouraging Android developers to integrate it. With the release of iOS 10 in September 2016, Safari began using our new, efficient Safe Browsing update technology, giving iOS users a protection boost.

Safe Browsing in an AI-first world

The internet is at the start of another major shift. Safe Browsing has already been using machine learning for many years to detect much badness of many kinds. We’re continually evaluating and integrating cutting-edge new approaches to improve Safe Browsing.

Protecting all users across all their platforms makes the internet safer for everyone. Wherever the future of the internet takes us, Safe Browsing will be there, continuing to evolve, expand, and protect people wherever they are.

Posted by Devon O’Brien, Ryan Sleevi, Andrew Whalley, Chrome Security

This post is a broader announcement of plans already finalized on the blink-dev mailing list.
Update, 1/31/18: Post was updated to further clarify 13 month validity limitations

At the end of July, the Chrome team and the PKI community converged upon a plan to reduce, and ultimately remove, trust in Symantec’s infrastructure in order to uphold users’ security and privacy when browsing the web. This plan, arrived at after significant debate on the blink-dev forum, would allow reasonable time for a transition to new, independently-operated Managed Partner Infrastructure while Symantec modernizes and redesigns its infrastructure to adhere to industry standards. This post reiterates this plan and includes a timeline detailing when site operators may need to obtain new certificates.

On January 19, 2017, a public posting to the mozilla.dev.security.policy newsgroup drew attention to a series of questionable website authentication certificates issued by Symantec Corporation’s PKI. Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements. During the subsequent investigation, it was revealed that Symantec had entrusted several organizations with the ability to issue certificates without the appropriate or necessary oversight, and had been aware of security deficiencies at these organizations for some time.

This incident, while distinct from a previous incident in 2015, was part of a continuing pattern of issues over the past several years that has caused the Chrome team to lose confidence in the trustworthiness of Symantec’s infrastructure, and as a result, the certificates that have been or will be issued from it.

After our agreed-upon proposal was circulated, Symantec announced the selection of DigiCert to run this independently-operated Managed Partner Infrastructure, as well as their intention to sell their PKI business to DigiCert in lieu of building a new trusted infrastructure. This post outlines the timeline for that transition and the steps that existing Symantec customers should take to minimize disruption to their users.

Information For Site Operators

Starting with Chrome 66, Chrome will remove trust in Symantec-issued certificates issued prior to June 1, 2016. Chrome 66 is currently scheduled to be released to Chrome Beta users on March 15, 2018 and to Chrome Stable users around April 17, 2018.

If you are a site operator with a certificate issued by a Symantec CA prior to June 1, 2016, then prior to the release of Chrome 66, you will need to replace the existing certificate with a new certificate from any Certificate Authority trusted by Chrome.

Additionally, by December 1, 2017, Symantec will transition issuance and operation of publicly-trusted certificates to DigiCert infrastructure, and certificates issued from the old Symantec infrastructure after this date will not be trusted in Chrome.

Around the week of October 23, 2018, Chrome 70 will be released, which will fully remove trust in Symantec’s old infrastructure and all of the certificates it has issued. This will affect any certificate chaining to Symantec roots, except for the small number issued by the independently-operated and audited subordinate CAs previously disclosed to Google.

Site operators that need to obtain certificates from Symantec’s existing root and intermediate certificates may do so from the old infrastructure until December 1, 2017, although these certificates will need to be replaced again prior to Chrome 70. Additionally, certificates issued using validation information from Symantec’s infrastructure will have their validity limited to 13 months. Alternatively, site operators may obtain replacement certificates from any other Certificate Authority currently trusted by Chrome, which are unaffected by this distrust or validity period limit.
Reference Timeline

The following is a timeline of relevant dates associated with this plan, which distills the various requirements and milestones into an actionable set of information for site operators. As always, Chrome release dates can vary by a number of days, but upcoming release dates can be tracked here.

Date	Event
Now through ~March 15, 2018	Site Operators using Symantec-issued TLS server certificates issued before June 1, 2016 should replace these certificates. These certificates can be replaced by any currently trusted CA.
~October 24, 2017	Chrome 62 released to Stable, which will add alerting in DevTools when evaluating certificates that will be affected by the Chrome 66 distrust.
December 1, 2017	According to Symantec, DigiCert’s new “Managed Partner Infrastructure” will at this point be capable of full issuance. Any certificates issued by Symantec’s old infrastructure after this point will cease working in a future Chrome update. From this date forward, Site Operators can obtain TLS server certificates from the new Managed Partner Infrastructure that will continue to be trusted after Chrome 70 (~October 23, 2018). December 1, 2017 does not mandate any certificate changes, but represents an opportunity for site operators to obtain TLS server certificates that will not be affected by Chrome 70’s distrust of the old infrastructure.
~March 15, 2018	Chrome 66 released to beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016. As of this date Site Operators must be using either a Symantec-issued TLS server certificate issued on or after June 1, 2016 or a currently valid certificate issued from any other trusted CA as of Chrome 66. Site Operators that obtained a certificate from Symantec’s old infrastructure after June 1, 2016 are unaffected by Chrome 66 but will need to obtain a new certificate by the Chrome 70 dates described below.
~April 17, 2018	Chrome 66 released to Stable.
~September 13, 2018	Chrome 70 released to Beta, which will remove trust in the old Symantec-rooted Infrastructure. This will not affect any certificate chaining to the new Managed Partner Infrastructure, which Symantec has said will be operational by December 1, 2017. Only TLS server certificates issued by Symantec’s old infrastructure will be affected by this distrust regardless of issuance date.
~October 23, 2018	Chrome 70 released to Stable.

Posted by Megan Ruthven Android Security, Ken Bodzak Threat Analysis Group, Neel Mehta Threat Analysis Group

Android Security is always developing new ways of using data to find and block potentially harmful apps (PHAs) from getting onto your devices. Earlier this year, we announced we had blocked Chrysaor targeted spyware, believed to be written by NSO Group, a cyber arms company. In the course of our Chrysaor investigation, we used similar techniques to discover a new and unrelated family of spyware called Lipizzan. Lipizzan’s code contains references to a cyber arms company, Equus Technologies.

Lipizzan is a multi-stage spyware product capable of monitoring and exfiltrating a user’s email, SMS messages, location, voice calls, and media. We have found 20 Lipizzan apps distributed in a targeted fashion to fewer than 100 devices in total and have blocked the developers and apps from the Android ecosystem. Google Play Protect has notified all affected devices and removed the Lipizzan apps.

We’ve enhanced Google Play Protect’s capabilities to detect the targeted spyware used here and will continue to use this framework to block more targeted spyware. To learn more about the methods Google uses to find targeted mobile spyware like Chrysaor and Lipizzan, attend our BlackHat talk, Fighting Targeted Malware in the Mobile Ecosystem.

How does Lipizzan work?

Getting on a target device

Lipizzan was a sophisticated two stage spyware tool. The first stage found by Google Play Protect was distributed through several channels, including Google Play, and typically impersonated an innocuous-sounding app such as a "Backup” or “Cleaner” app. Upon installation, Lipizzan would download and load a second "license verification" stage, which would survey the infected device and validate certain abort criteria. If given the all-clear, the second stage would then root the device with known exploits and begin to exfiltrate device data to a Command & Control server.

Once implanted on a target device

The Lipizzan second stage was capable of performing and exfiltrating the results of the following tasks:

• Call recording
• VOIP recording
• Recording from the device microphone
• Location monitoring
• Taking screenshots
• Taking photos with the device camera(s)
• Fetching device information and files
• Fetching user information (contacts, call logs, SMS, application-specific data)

The PHA had specific routines to retrieve data from each of the following apps:

• Gmail
• Hangouts
• KakaoTalk
• LinkedIn
• Messenger
• Skype
• Snapchat
• StockEmail
• Telegram
• Threema
• Viber
• Whatsapp

We saw all of this behavior on a standalone stage 2 app, com.android.mediaserver (not related to Android MediaServer). This app shared a signing certificate with one of the stage 1 applications, com.app.instantbackup, indicating the same author wrote the two. We could use the following code snippet from the 2nd stage (com.android.mediaserver) to draw ties to the stage 1 applications.

Morphing first stage

After we blocked the first set of apps on Google Play, new apps were uploaded with a similar format but had a couple of differences.

The apps changed from ‘backup’ apps to looking like a “cleaner”, “notepad”, “sound recorder”, and “alarm manager” app. The new apps were uploaded within a week of the takedown, showing that the authors have a method of easily changing the branding of the implant apps.
The app changed from downloading an unencrypted stage 2 to including stage 2 as an encrypted blob. The new stage 1 would only decrypt and load the 2nd stage if it received an intent with an AES key and IV.

Despite changing the type of app and the method to download stage 2, we were able to catch the new implant apps soon after upload.

How many devices were affected?

There were fewer than 100 devices that checked into Google Play Protect with the apps listed below. That means the family affected only 0.000007% of Android devices. Since we identified Lipizzan, Google Play Protect removed Lipizzan from affected devices and actively blocks installs on new devices.

What can you do to protect yourself?

• Ensure you are opted into Google Play Protect. 
• Exclusively use the Google Play store. The chance you will install a PHA is much lower on Google Play than using other install mechanisms.
• Keep “unknown sources” disabled while not using it.
• Keep your phone patched to the latest Android security update.

List of samples

1st stage

Newer version 

Standalone 2nd stage

Posted by Andrew Whalley and Devon O'Brien, Chrome Security

As previously announced, Chrome has been in the process of removing trust from certificates issued by the CA WoSign and its subsidiary StartCom, as a result of several incidents not in keeping with the high standards expected of CAs.

We started the phase out in Chrome 56 by only trusting certificates issued prior to October 21st 2016, and subsequently restricted trust to a set of whitelisted hostnames based on the Alexa Top 1M. We have been reducing the size of the whitelist over the course of several Chrome releases.

Beginning with Chrome 61, the whitelist will be removed, resulting in full distrust of the existing WoSign and StartCom root certificates and all certificates they have issued.

Based on the Chromium Development Calendar, this change is visible in the Chrome Dev channel now, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.

Sites still using StartCom or WoSign-issued certificates should consider replacing these certificates as a matter of urgency to minimize disruption for Chrome users.

Posted by Martin Pelikan, Giles Hogben, and Ulfar Erlingsson of Google’s Security and Privacy team
Mobile apps entertain and assist us, make it easy to communicate with friends and family, and provide tools ranging from maps to electronic wallets. But these apps could also seek more device information than they need to do their job, such as personal data and sensor data from components, like cameras and GPS trackers.

To protect our users and help developers navigate this complex environment, Google analyzes privacy and security signals for each app in Google Play. We then compare that app to other apps with similar features, known as functional peers. Creating peer groups allows us to calibrate our estimates of users’ expectations and set adequate boundaries of behaviors that may be considered unsafe or intrusive. This process helps detect apps that collect or send sensitive data without a clear need, and makes it easier for users to find apps that provide the right functionality and respect their privacy. For example, most coloring book apps don’t need to know a user’s precise location to function and this can be established by analyzing other coloring book apps. By contrast, mapping and navigation apps need to know a user’s location, and often require GPS sensor access.

One way to create app peer groups is to create a fixed set of categories and then assign each app into one or more categories, such as tools, productivity, and games. However, fixed categories are too coarse and inflexible to capture and track the many distinctions in the rapidly changing set of mobile apps. Manual curation and maintenance of such categories is also a tedious and error-prone task.

To address this, Google developed a machine-learning algorithm for clustering mobile apps with similar capabilities. Our approach uses deep learning of vector embeddings to identify peer groups of apps with similar functionality, using app metadata, such as text descriptions, and user metrics, such as installs. Then peer groups are used to identify anomalous, potentially harmful signals related to privacy and security, from each app’s requested permissions and its observed behaviors. The correlation between different peer groups and their security signals helps different teams at Google decide which apps to promote and determine which apps deserve a more careful look by our security and privacy experts. We also use the result to help app developers improve the privacy and security of their apps.

Apps are split into groups of similar functionality, and in each cluster of similar apps the established baseline is used to find anomalous privacy and security signals.

These techniques build upon earlier ideas, such as using peer groups to analyze privacy-related signals, deep learning for language models to make those peer groups better, and automated data analysis to draw conclusions.

Many teams across Google collaborated to create this algorithm and the surrounding process. Thanks to several, essential team members including Andrew Ahn, Vikas Arora, Hongji Bao, Jun Hong, Nwokedi Idika, Iulia Ion, Suman Jana, Daehwan Kim, Kenny Lim, Jiahui Liu, Sai Teja Peddinti, Sebastian Porst, Gowdy Rajappan, Aaron Rothman, Monir Sharif, Sooel Son, Michael Vrable, and Qiang Yan.

For more information on Google’s efforts to detect and fight potentially harmful apps (PHAs) on Android, see Google Android Security Team’s Classifications for Potentially Harmful Applications.
References

S. Jana, Ú. Erlingsson, I. Ion (2015). Apples and Oranges: Detecting Least-Privilege Violators with Peer Group Analysis. arXiv:1510.07308 [cs.CR].

T. Mikolov, I. Sutskever, K. Chen, G. S. Corrado, J. Dean (2013). Distributed Representations of Words and Phrases and their Compositionality. Advances in Neural Information Processing Systems 26 (NIPS 2013).

Ú. Erlingsson (2016). Data-driven software security: Models and methods. Proceedings of the 29th IEEE Computer Security Foundations Symposium (CSF'16), Lisboa, Portugal.

Posted by Wei Liu, Product Manager, reCAPTCHA
When we launched reCAPTCHA ten years ago, we had a simple goal: enable users to visit the sites they love without worrying about spam and abuse. Over the years, reCAPTCHA has changed quite a bit. It evolved from the distorted text to street numbers and names, then No CAPTCHA reCAPTCHA in 2014 and Invisible reCAPTCHA in March this year.

By now, more than a billion users have benefited from reCAPTCHA and we continue to work to refine our protections.

reCAPTCHA protects users wherever they may be online. As the use of mobile devices has grown rapidly, it’s important to keep the mobile applications and data safe. Today, on reCAPTCHA’s tenth birthday, we’re glad to announce the first reCAPTCHA Android API as part of Google Play Services.

With this API, reCAPTCHA can better tell human and bots apart to provide a streamlined user experience on mobile. It will use our newest Invisible reCAPTCHA technology, which runs risk analysis behind the scene and has enabled millions of human users to pass through with zero click everyday. Now mobile users can enjoy their apps without being interrupted, while still staying away from spam and abuse.

reCAPTCHA Android API is included with Google SafetyNet, which provides services like device attestation and safe browsing to protect mobile apps. Mobile developers can do both the device and user attestations in the same API to mitigate security risks of their apps more efficiently. This adds to the diversity of security protections on Android: Google Play Protect to monitor for potentially harmful applications, device encryption, and regular security updates. Please visit our site to learn more about how to integrate with the reCAPTCHA Android API, and keep an eye out for our iOS library.

The journey of reCAPTCHA continues: we’ll make the Internet safer and easier to use for everyone (except bots).

Posted by Josh Armour Security Program Manager

On 00:00:01 UTC of June 17th and 18th, 2017 we’ll be hosting the online qualification round of our second annual Capture The Flag (CTF) competition. In a ‘Capture the Flag’ competition we create security challenges and puzzles in which contestants can earn points for solving them. We will be inviting the top 10 finalist teams to a secret undisclosed location (spoiler alert: it’s Google) to compete onsite for a prize pool of over USD$31,337 and we’ll help subsidize travel to the venue for the finals to four participants for each of the ten finalist teams. In addition to grand prizes given at the finals, we’ll be rewarding some of the best and creative write-ups that we receive during the qualifying round. We want to give you an opportunity to share with the world the clever way you solve challenges.

Why do we host these competitions?

There are three main reasons why we host these competitions.

First, as we've seen with our Vulnerability Reward Program, the security community’s efforts help us better protect Google users, and the web as a whole. We’d like to give the people who solve a single challenge or two in a very clever way a chance to teach us and the security community, even if they don’t qualify for the finals. We also think that these challenges allows us to share with the world the types of problems our security team works on every day.

Second, we want to engage the broader security community and reach out to as many people involved as possible. At the Google CTF last year the winning team, ‘Pasten’ from Israel, earned over 4,700 points competing against 2,400 teams out of which 900 were able to solve at least one of our challenges. Thanks to the community's feedback, we used what we learned last year to make our CTF even better this time.

Lastly, we also want to grow the security community. Upon observing how last year's competition engaged new players from all over the world, we want to continue to create a safe space for people to come and learn while trying to solve challenges and having fun. Our internal security team employs several people who actively compete in CTF competitions in their spare time, so we value this activity and want to give back to and help grow our community.

We hope to virtually see you at the 2nd annual Google CTF on June 17th at 00:00:01 UTC. Check this site (g.co/ctf) for more details, as they become available.

The Big Picture

At Google, we aim to reward the hard work of hackers and security researchers. One such avenue is our Google Vulnerability Rewards Programs. Many of the best bug hunters enjoy participating in ‘Capture The Flag’ contests, and great vulnerabilities have been discovered and disclosed at them. During last year's Google CTF we also received some security bug reports in our scoreboard, for which we gave out rewards under the VRP. Another way we reward this community is with our Vulnerability Research Grants Program and our Patch Rewards Program. We look forward to the best contestants taking some time to explore our other programs for opportunities to make some money and help improve the security of the internet.

Posted by Mayank Jain and Scott Roberts, Android Security team

[Cross-posted from the Android Developers Blog]

Two years ago, we launched the Android Security Rewards program. In its second year, we've seen great progress. We received over 450 qualifying vulnerability reports from researchers and the average pay per researcher jumped by 52.3%. On top of that, the total Android Security Rewards payout doubled to $1.1 million dollars. Since it launched, we've rewarded researchers over $1.5 million dollars.

Here are some of the highlights from the Android Security Rewards program's second year:

• There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise, our highest award amount possible.
• We paid 115 individuals with an average of $2,150 per reward and $10,209 per researcher.
• We paid our top research team, C0RE Team, over $300,000 for 118 vulnerability reports.
• We paid 31 researchers $10,000 or more.

Thank you to all the amazing researchers who submitted complete vulnerability reports to us last year.

Improvements to Android Security Rewards program

We’re constantly working to improve the Android Security Rewards program and today we’re making a few changes to all vulnerability reports filed after June 1, 2017.

Because every Android release includes more security protections and no researcher has claimed the top reward for an exploit chains in 2 years, we’re excited to increase our top-line payouts for these exploits.

• Rewards for a remote exploit chain or exploit leading to TrustZone or Verified Boot compromise increase from $50,000 to $200,000.
• Rewards for a remote kernel exploit increase from $30,000 to $150,000.

In addition to rewarding for vulnerabilities, we continue to work with the broad and diverse Android ecosystem to protect users from issues reported through our program. We collaborate with manufacturers to ensure that these issues are fixed on their devices through monthly security updates. Over 100 device models have a majority of their deployed devices running a security update from the last 90 days. This table shows the models with a majority of deployed devices running a security update from the last two months:

Manufacturer	Device
BlackBerry	PRIV
Fujitsu	F-01J
General Mobile	GM5 Plus d, GM5 Plus, General Mobile 4G Dual, General Mobile 4G
Gionee	A1
Google	Pixel XL, Pixel, Nexus 6P, Nexus 6, Nexus 5X, Nexus 9
LGE	LG G6, V20, Stylo 2 V, GPAD 7.0 LTE
Motorola	Moto Z, Moto Z Droid
Oppo	CPH1613, CPH1605
Samsung	Galaxy S8+, Galaxy S8, Galaxy S7, Galaxy S7 Edge, Galaxy S7 Active, Galaxy S6 Active, Galaxy S5 Dual SIM, Galaxy C9 Pro, Galaxy C7, Galaxy J7, Galaxy On7 Pro, Galaxy J2, Galaxy A8, Galaxy Tab S2 9.7
Sharp	Android One S1, 507SH
Sony	Xperia XA1, Xperia X
Vivo	Vivo 1609, Vivo 1601, Vivo Y55

Source: Google, May 29, 2017

Thank you to everyone who helped make Android safer and stronger in the past year. Together, we made a huge investment in security research that helps Android users everywhere. If you want to get involved to make next year even better, check out our detailed Program Rules. For tips on how to submit complete reports, see Bug Hunter University.

Posted by Sri Somanchi, Product Manager, Gmail anti-spam
Today we announced new security features for Gmail customers, including early phishing detection using machine learning, click-time warnings for malicious links, and unintended external reply warnings. In addition, we have also updated our defenses against malicious attachments.

Let’s take a deeper look at the new defenses against malicious attachments. We now correlate spam signals with attachment and sender heuristics, to predict messages containing new and unseen malware variants. These protections enable Gmail to better protect our users from zero-day threats, ransomware and polymorphic malware.

In addition, we block use of file types that carry a high potential for security risks including executable and javascript files.

Machine learning has helped Gmail achieve more than 99% accuracy in spam detection, and with these new protections, we’re able to reduce your exposure to threats by confidently rejecting hundreds of millions of additional messages every day.
Constantly improving our automatic protections

These new changes are just the latest in our ongoing work to improve our protections as we work to keep ahead of evolving threats. For many years, scammers have tried to use dodgy email attachments to sneak past our spam filters, and we’ve long blocked this potential abuse in a variety of ways, including:

• Rejecting the message and notifying the sender if we detect a virus in an email.
• Preventing you from sending a message with an infected attachment.
• Preventing you from downloading attachments if we detect a virus.

While the bad guys never rest, neither do we.

These protections were made possible due to extensive contribution from Vijay Eranti & Timothy Schumacher (Gmail anti-spam) & Harish Gudelly (Google anti-virus) & Lucio Tudisco (G Suite anti-abuse)