Author Archives: Google Security PR

Protect your accounts from data breaches with Password Checkup

Posted by Jennifer Pullman, Kurt Thomas, and Elie Bursztein, Security and Anti-abuse research

Google helps keep your account safe from hijacking with a defense in depth strategy that spans prevention, detection, and mitigation. As part of this, we regularly reset the passwords of Google accounts affected by third-party data breaches in the event of password reuse. This strategy has helped us protect over 110 million users in the last two years alone. Without these safety measures, users would be at ten times the risk of account hijacking.

We want to help you stay safe not just on Google, but elsewhere on the web as well. This is where the new Password Checkup Chrome extension can help. Whenever you sign in to a site, Password Checkup will trigger a warning if the username and password you use is one of over 4 billion credentials that Google knows to be unsafe.

Password Checkup was designed jointly with cryptography experts at Stanford University to ensure that Google never learns your username or password, and that any breach data stays safe from wider exposure. Since Password Checkup is an early experiment, we’re sharing the technical details behind our privacy preserving protocol to be transparent about how we keep your data secure.
Key design principles

We designed Password Checkup with three key principles in mind:

  • Alerts are actionable, not informational: We believe that an alert should provide concise and accurate security advice. For an unsafe account, that means resetting your password. While it’s possible for data breaches to expose other personal data such as a phone number or mailing address, there’s no straightforward next step to re-securing that data. That’s why we focus only on warning you about unsafe usernames and passwords.
  • Privacy is at the heart of our design: Your usernames and passwords are incredibly sensitive. We designed Password Checkup with privacy-preserving technologies to never reveal this personal information to Google. We also designed Password Checkup to prevent an attacker from abusing Password Checkup to reveal unsafe usernames and passwords. Finally, all statistics reported by the extension are anonymous. These metrics include the number of lookups that surface an unsafe credential, whether an alert leads to a password change, and the web domain involved for improving site compatibility.
  • Advice that avoids fatigue: We designed Password Checkup to only alert you when all of the information necessary to access your account has fallen into the hands of an attacker. We won’t bother you about outdated passwords you’ve already reset or merely weak passwords like “123456”. We only generate an alert when both your current username and password appear in a breach, as that poses the greatest risk.
Settling on an approach

At a high level, Password Checkup needs to query Google about the breach status of a username and password without revealing the information queried. At the same time, we need to ensure that no information about other unsafe usernames or passwords leaks in the process, and that brute force guessing is not an option. Password Checkup addresses all of these requirements by using multiple rounds of hashing, k-anonymity, private information retrieval, and a technique called blinding.

Our approach strikes a balance between privacy, computation overhead, and network latency. While single-party private information retrieval (PIR) and 1-out-of-N oblivious transfer solve some of our requirements, the communication overhead involved for a database of over 4 billion records is presently intractable. Alternatively, k-party PIR and hardware enclaves present efficient alternatives, but they require user trust in schemes that are not widely deployed yet in practice. For k-party PIR, there is a risk of collusion; for enclaves, there is a risk of hardware vulnerabilities and side-channels.

A look under the hood

Here’s how Password Checkup works in practice to satisfy our security and privacy requirements.

Protecting your accounts

Password Checkup is currently available as an extension for Chrome. Since this is a first version, we will continue refining it over the coming months, including improving site compatibility and username and password field detection.

Acknowledgements

This post reflects the work of a large group of Google engineers, research scientists, and others including: Niti Arora, Jacob Barrett, Borbala Benko, Alan Butler, Abhi Chaudhuri, Oxana Comanescu, Sunny Consolvo, Michael Dedrick, Kyler Emig, Mihaela Ion, Ilona Gaweda, Luca Invernizzi, Jozef Janovský, Yu Jiang, Patrick Gage Kelly, Guemmy Kim, Ben Kreuter, Valentina Lapteva, Maija Marincenko, Grzegorz Milka, Angelika Moscicki, Julia Nalven, Yuan Niu, Sarvar Patel, Tadek Pietraszek, Ganbayar Puntsagdash, Ananth Raghunathan, Juri Ranieri, Mark Risher, Masaru Sato, Karn Seth, Juho Snellman, Eduardo Tejada, Tu Tsao, Andy Wen, Kevin Yeo, Moti Yung, and Ali Zand.

Google Public DNS now supports DNS-over-TLS

Posted by Marshall Vale, Product Manager and Puneet Sood, Software Engineer

Google Public DNS is the world’s largest public Domain Name Service (DNS) recursive resolver, allowing anyone to convert Internet domain names like www.example.com into Internet addresses needed by an email application or web browser. Just as your search queries can expose sensitive information, the domains you lookup via DNS can also be sensitive. Starting today, users can secure queries between their devices and Google Public DNS with DNS-over-TLS, preserving their privacy and integrity.

The DNS environment has changed for the better since we launched Google Public DNS over eight years ago. Back then, as today, part of Google Public DNS’ mission has been to improve the security and accuracy of DNS for users all over the world. But today, there is an increased awareness of the need to protect users’ communication with their DNS resolvers against forged responses and safeguard their privacy from network surveillance. The DNS-over-TLS protocol specifies a standard way to provide security and privacy for DNS traffic between users and their resolvers. Now users can secure their connections to Google Public DNS with TLS, the same technology that protects their HTTPS web connections.

We implemented the DNS-over-TLS specification along with the RFC 7766 recommendations to minimize the overhead of using TLS. These include support for TLS 1.3 (for faster connections and improved security), TCP fast open, and pipelining of multiple queries and out-of-order responses over a single connection. All of this is deployed with Google’s serving infrastructure which provides reliable and scalable management for DNS-over-TLS connections.

Use DNS-over-TLS today

Android 9 (Pie) device users can use DNS-over-TLS today. For configuration instructions for Android and other systems, please see the documentation. Advanced Linux users can use the stubby resolver from dnsprivacy.org to talk to Google’s DNS-over-TLS service.

If you have a problem with Google Public DNS-over-TLS, you can create an issue on our tracker or ask on our discussion group. As always, please provide as much information as possible to help us investigate the problem!

New Keystore features keep your slice of Android Pie a little safer


Posted by Brian Claire Young and Shawn Willden, Android Security; and Frank Salim, Google Pay

[Cross-posted from the Android Developers Blog]

New Android Pie Keystore Features

The Android Keystore provides application developers with a set of cryptographic tools that are designed to secure their users' data. Keystore moves the cryptographic primitives available in software libraries out of the Android OS and into secure hardware. Keys are protected and used only within the secure hardware to protect application secrets from various forms of attacks. Keystore gives applications the ability to specify restrictions on how and when the keys can be used.
Android Pie introduces new capabilities to Keystore. We will be discussing two of these new capabilities in this post. The first enables restrictions on key use so as to protect sensitive information. The second facilitates secure key use while protecting key material from the application or operating system.

Keyguard-bound keys

There are times when a mobile application receives data but doesn't need to immediately access it if the user is not currently using the device. Sensitive information sent to an application while the device screen is locked must remain secure until the user wants access to it. Android Pie addresses this by introducing keyguard-bound cryptographic keys. When the screen is locked, these keys can be used in encryption or verification operations, but are unavailable for decryption or signing. If the device is currently locked with a PIN, pattern, or password, any attempt to use these keys will result in an invalid operation. Keyguard-bound keys protect the user's data while the device is locked, and only available when the user needs it.
Keyguard binding and authentication binding both function in similar ways, except with one important difference. Keyguard binding ties the availability of keys directly to the screen lock state while authentication binding uses a constant timeout. With keyguard binding, the keys become unavailable as soon as the device is locked and are only made available again when the user unlocks the device.
It is worth noting that keyguard binding is enforced by the operating system, not the secure hardware. This is because the secure hardware has no way to know when the screen is locked. Hardware-enforced Android Keystore protection features like authentication binding, can be combined with keyguard binding for a higher level of security. Furthermore, since keyguard binding is an operating system feature, it's available to any device running Android Pie.
Keys for any algorithm supported by the device can be keyguard-bound. To generate or import a key as keyguard-bound, call setUnlockedDeviceRequired(true) on the KeyGenParameterSpec or KeyProtection builder object at key generation or import.

Secure Key Import

Secure Key Import is a new feature in Android Pie that allows applications to provision existing keys into Keystore in a more secure manner. The origin of the key, a remote server that could be sitting in an on-premise data center or in the cloud, encrypts the secure key using a public wrapping key from the user's device. The encrypted key in the SecureKeyWrapper format, which also contains a description of the ways the imported key is allowed to be used, can only be decrypted in the Keystore hardware belonging to the specific device that generated the wrapping key. Keys are encrypted in transit and remain opaque to the application and operating system, meaning they're only available inside the secure hardware into which they are imported.

Secure Key Import is useful in scenarios where an application intends to share a secret key with an Android device, but wants to prevent the key from being intercepted or from leaving the device. Google Pay uses Secure Key Import to provision some keys on Pixel 3 phones, to prevent the keys from being intercepted or extracted from memory. There are also a variety of enterprise use cases such as S/MIME encryption keys being recovered from a Certificate Authorities escrow so that the same key can be used to decrypt emails on multiple devices.
To take advantage of this feature, please review this training article. Please note that Secure Key Import is a secure hardware feature, and is therefore only available on select Android Pie devices. To find out if the device supports it, applications can generate a KeyPair with PURPOSE_WRAP_KEY.

Tackling ads abuse in apps and SDKs

Posted by Dave Kleidermacher, VP, Head of Security & Privacy - Android & Play

Providing users with safe and secure experiences, while helping developers build and grow quality app businesses, is our top priority at Google Play. And we’re constantly working to improve our protections.

Google Play has been working to minimize app install attribution fraud for several years. In 2017 Google Play made available the Google Play Install Referrer API, which allows ad attribution providers, publishers and advertisers to determine which referrer was responsible for sending the user to Google Play for a given app install. This API was specifically designed to be resistant to install attribution fraud and we strongly encourage attribution providers, advertisers and publishers to insist on this standard of proof when measuring app install ads. Users, developers, advertisers and ad networks all benefit from a transparent, fair system.

We also take reports of questionable activity very seriously. If an app violates our Google Play Developer policies, we take action. That’s why we began our own independent investigation after we received reports of apps on Google Play accused of conducting app install attribution abuse by falsely claiming credit for newly installed apps to collect the download bounty from that app’s developer.

We now have an update regarding our ongoing investigation:

  • On Monday, we removed two apps from the Play Store because our investigation discovered evidence of app install attribution abuse.
  • We also discovered evidence of app install attribution abuse in 3 ad network SDKs. We have asked the impacted developers to remove those SDKs from their apps. Because we believe most of these developers were not aware of the behavior from these third-party SDKs, we have given them a short grace period to take action.
  • Google Ads SDKs were not utilized for any of the abusive behaviors mentioned above.
  • Our investigation is ongoing and additional reviews of other apps and third party SDKs are still underway. If we find evidence of additional policy violations, we will take action.
We will continue to investigate and improve our capabilities to better detect and protect against abusive behavior and the malicious actors behind them.

ASPIRE to keep protecting billions of Android users

Posted by Billy Lau and René Mayrhofer, Android Security & Privacy Team

Customization is one of Android's greatest strengths. Android's open source nature has enabled thousands of device types that cover a variety of use cases. In addition to adding features to the Android Open Source Project, researchers, developers, service providers, and device and chipset manufacturers can make updates to improve Android security. Investing and engaging in academic research advances the state-of-the-art security techniques, contributes to science, and delivers cutting edge security and privacy features into the hands of end users. To foster more cooperative applied research between the Android Security and Privacy team and the wider academic and industrial community, we're launching ASPIRE (Android Security and PrIvacy REsearch).

ASPIRE's goal is encouraging the development of new security and privacy technology that impacts the Android ecosystem in the next 2 to 5 years, but isn't planned for mainline Android development. This timeframe extends beyond the next annual Android release to allow adequate time to analyze, develop, and stabilize research into features before including in the platform. To collaborate with security researchers, we're hosting events and creating more channels to contribute research.

On October 25th 2018, we invited top security and privacy researchers from around the world to present at Android Security Local Research Day (ASLR-D). At this event, external researchers and Android Security and Privacy team members discussed current issues and strategies that impact the future direction of security research—for Android and the entire industry.

We can't always get everyone in the same room and good ideas come from everywhere. So we're inviting all academic researchers to help us protect billions of users. Research collaborations with Android should be as straightforward as collaborating with the research lab next door. To get involved you can:

  1. Submit an Android security / privacy research idea or proposal to the Google Faculty Research Awards (FRA) program.
  2. Apply for a research internship as a student pursuing an advanced degree.
  3. Apply to become a Visiting Researcher at Google.
  4. If you have any security or privacy questions that may help with your research, reach out to us.
  5. Co-author publications with Android team members, outside the terms of FRA.
  6. Collaborate with Android team members to make changes to the Android Open Source Project.

Let’s work together to make Android the most secure platform—now and in the future.

Announcing the Google Security and Privacy Research Awards

Posted by Elie Bursztein and Oxana Comanescu, Google Security and Privacy Group

We believe that cutting-edge research plays a key role in advancing the security and privacy of users across the Internet. While we do significant in-house research and engineering to protect users’ data, we maintain strong ties with academic institutions worldwide. We provide seed funding through faculty research grants, cloud credits to unlock new experiments, and foster active collaborations, including working with visiting scholars and research interns.

To accelerate the next generation of security and privacy breakthroughs, we recently created the Google Security and Privacy Research Awards program. These awards, selected via internal Google nominations and voting, recognize academic researchers who have made recent, significant contributions to the field.

We’ve been developing this program for several years. It began as a pilot when we awarded researchers for their work in 2016, and we expanded it more broadly for work from 2017. So far, we awarded $1 million dollars to 12 scholars. We are preparing the shortlist for 2018 nominees and will announce the winners next year. In the meantime, we wanted to highlight the previous award winners and the influence they’ve had on the field.
2017 Awardees

Lujo Bauer, Carnegie Mellon University
Research area: Password security and attacks against facial recognition

Dan Boneh, Stanford University
Research area: Enclave security and post-quantum cryptography

Aleksandra Korolova, University of Southern California
Research area: Differential privacy

Daniela Oliveira, University of Florida
Research area: Social engineering and phishing

Franziska Roesner, University of Washington
Research area: Usable security for augmented reality and at-risk populations

Matthew Smith, Universität Bonn
Research area: Usable security for developers


2016 Awardees

Michael Bailey, University of Illinois at Urbana-Champaign
Research area: Cloud and network security

Nicolas Christin, Carnegie Mellon University
Research area: Authentication and cybercrime

Damon McCoy, New York University
Research area: DDoS services and cybercrime

Stefan Savage, University of California San Diego
Research area: Network security and cybercrime

Marc Stevens, Centrum Wiskunde & Informatica
Research area: Cryptanalysis and lattice cryptography

Giovanni Vigna, University of California Santa Barbara
Research area: Malware detection and cybercrime


Congratulations to all of our award winners.

Industry collaboration leads to takedown of the “3ve” ad fraud operation

Posted by Per Bjorke, Product Manager, Ad Traffic Quality

For years, Google has been waging a comprehensive, global fight against invalid traffic through a combination of technology, policy, and operations teams to protect advertisers and publishers and increase transparency throughout the advertising industry.

Last year, we identified one of the most complex and sophisticated ad fraud operations we have seen to date, working with cyber security firm White Ops, and referred the case to law enforcement. Today, the U.S. Attorney’s Office for the Eastern District of New York announced criminal charges associated with this fraud operation. This takedown marks a major milestone in the industry’s fight against ad fraud, and we’re proud to have been a key contributor.

In partnership with White Ops, we have published a white paper about how we identified this ad fraud operation, the steps we took to protect our clients from being impacted, and the technical work we did to detect patterns across systems in the industry. Below are some of the highlights from the white paper, which you can download here.

All about 3ve: A creative and sophisticated threat

Referred to as 3ve (pronounced “Eve”), this ad fraud operation evolved over the course of 2017 from a modest, low-level botnet into a large and sophisticated operation that used a broad set of tactics to commit ad fraud. 3ve operated on a significant scale: At its peak, it controlled over 1 million IPs from both residential malware infections and corporate IP spaces primarily in North America and Europe.

Through our investigation, we discovered that 3ve was comprised of three unique sub-operations that evolved rapidly, using sophisticated tactics aimed at exploiting data centers, computers infected with malware, spoofed fraudulent domains, and fake websites. Through its varied and complex machinery, 3ve generated billions of fraudulent ad bid requests (i.e., ad spaces on web pages that advertisers can bid to purchase in an automated way), and it also created thousands of spoofed fraudulent domains. It should be noted that our analysis of ad bid requests indicated growth in activity, but not necessarily growth in transactions that would result in charges to advertisers. It’s also worth noting that 3+ billion daily ad bid requests made 3ve an extremely large ad fraud operation, but its bid request volume was only a small percentage of overall bid request volume across the industry.
Our objective

Trust and integrity are critical to the digital advertising ecosystem. Investments in our ad traffic quality systems made it possible for us to tackle this ad fraud operation and to limit the impact it had on our clients as quickly as possible, including crediting advertisers.

3ve’s focus, like many ad fraud schemes, was not a single player or system, but rather the whole advertising ecosystem. As we worked to protect our ad systems against traffic from this threat, we identified that others also had observed this traffic, and we partnered with them to help remove the threat from the ecosystem. The working group, which included nearly 20 partners, was a key component that shaped our broader investigation into 3ve, enabling us to engage directly with each other and to work towards a mutually beneficial outcome.
Industry collaboration helps bring 3ve down

While ad fraud traditionally has been seen as a faceless crime in which bad actors don’t face much risk of being identified or consequences for their actions, 3ve’s takedown demonstrates that there are risks and consequences to committing ad fraud. We’re confident that our collective efforts are building momentum and moving us closer to finding a resolution to this challenge.

For example, industry initiatives such as the Interactive Advertising Bureau (IAB) Tech Lab’s ads.txt standard, which has experienced and continues to see very rapid adoption (over 620,000 domains have an ads.txt), as well as the increasing number of buy-side platforms and exchanges offering refunds for invalid traffic, are valuable steps towards cutting off the money flow to fraudsters. As we announced last year, we’ve made, and will continue to make investments in our automated refunds for invalid traffic, including our work with supply partners to provide advertisers with refunds for invalid traffic detected up to 30 days after monthly billing.

Industry bodies such as the IAB, Trustworthy Accountability Group (TAG), Media Rating Council, and the Joint Industry Committee for Web Standards, who are serving as agents of change and collaboration across our industry, are instrumental in the fight against ad fraud. We have a long history of working with these bodies, including ongoing participation in TAG and IAB leadership and working groups, as well as our inclusion in the TAG Certified Against Fraud program. That program’s value was reinforced with the IAB’s requirement that all members need to be TAG certified by the middle of this year.


Successful disruption

A coordinated takedown of infrastructure related to 3ve’s operations occurred recently. The takedown involved disrupting as much of the related infrastructure as possible to make it hard to rebuild any of 3ve’s operations. As the graph below demonstrates, declining volumes in invalid traffic indicate that the disruption thus far has been successful, bringing the bid request traffic close to zero within 18 hours of starting the coordinated takedown.
Looking ahead

We’ll continue to be vigilant, working to protect marketers, publishers, and users, while continuing to collaborate with the broader industry to safeguard the integrity of the digital advertising ecosystem that powers the open web. Our work to take down 3ve is another example of our collaboration with the broader ecosystem to improve trust in digital advertising. We are committed to helping to create a better digital advertising ecosystem — one that is more valuable, transparent, and trusted for everyone.

Introducing the Android Ecosystem Security Transparency Report

Posted by Jason Woloz and Eugene Liderman, Android Security & Privacy Team

As shared during the What's new in Android security session at Google I/O 2018, transparency and openness are important parts of Android's ethos. We regularly blog about new features and enhancements and publish an annual Android Security Year in Review, which highlights Android ecosystem trends. To provide more frequent insights, we're introducing a quarterly Android Ecosystem Security Transparency Report. This report is the latest addition to our Transparency Report site, which began in 2010 to show how the policies and actions of governments and corporations affect privacy, security, and access to information online.

This Android Ecosystem Security Transparency Report covers how often a routine, full-device scan by Google Play Protect detects a device with PHAs installed. Google Play Protect is built-in protection on Android devices that scans over 50 billion apps daily from inside and outside of Google Play. These scans look for evidence of Potentially Harmful Applications (PHAs). If the scans find a PHA, Google Play Protect warns the user and can disable or remove PHAs. In Android's first annual Android Security Year in Review from 2014, fewer than 1% of devices had PHAs installed. The percentage has declined steadily over time and this downward trend continues through 2018. The transparency report covers PHA rates in three areas: market segment (whether a PHA came from Google Play or outside of Google Play), Android version, and country.

Devices with Potentially Harmful Applications installed by market segment

Google works hard to protect your Android device: no matter where your apps come from. Continuing the trend from previous years, Android devices that only download apps from Google Play are 9 times less likely to get a PHA than devices that download apps from other sources. Before applications become available in Google Play they undergo an application review to confirm they comply with Google Play policies. Google uses a risk scorer to analyze apps to detect potentially harmful behavior. When Google’s application risk analyzer discovers something suspicious, it flags the app and refers the PHA to a security analyst for manual review if needed. We also scan apps that users download to their device from outside of Google Play. If we find a suspicious app, we also protect users from that—even if it didn't come from Google Play.

In the Android Ecosystem Security Transparency Report, the Devices with Potentially Harmful Applications installed by market segment chart shows the percentage of Android devices that have one or more PHAs installed over time. The chart has two lines: PHA rate for devices that exclusively install from Google Play and PHA rate for devices that also install from outside of Google Play. In 2017, on average 0.09% of devices that exclusively used Google Play had one or more PHAs installed. The first three quarters in 2018 averaged a lower PHA rate of 0.08%.

The security of devices that installed apps from outside of Google Play also improved. In 2017, ~0.82% of devices that installed apps from outside of Google Play were affected by PHA; in the first three quarters of 2018, ~0.76% were affected. Since 2017, we've reduced this number by expanding the auto-disable feature which we covered on page 10 in the 2017 Year in Review. While malware rates fluctuate from quarter to quarter, our metrics continue to show a consistent downward trend over time. We'll share more details in our 2018 Android Security Year in Review in early 2019.

Devices with Potentially Harmful Applications installed by Android version

Newer versions of Android are less affected by PHAs. We attribute this to many factors, such as continued platform and API hardening, ongoing security updates and app security and developer training to reduce apps' access to sensitive data. In particular, newer Android versions—such as Nougat, Oreo, and Pie—are more resilient to privilege escalation attacks that had previously allowed PHAs to gain persistence on devices and protect themselves against removal attempts. The Devices with Potentially Harmful Applications installed by Android version chart shows the percentage of devices with a PHA installed, sorted by the Android version that the device is running.

Devices with Potentially Harmful Applications rate by top 10 countries

Overall, PHA rates in the ten largest Android markets have remained steady. While these numbers fluctuate on a quarterly basis due to the fluidity of the marketplace, we intend to provide more in depth coverage of what drove these changes in our annual Year in Review in Q1, 2019.

The Devices with Potentially Harmful Applications rate by top 10 countries chart shows the percentage of devices with at least one PHA in the ten countries with the highest volume of Android devices. India saw the most significant decline in PHAs present on devices, with the average rate of infection dropping by 32 percent. Indonesia, Mexico, and Turkey also saw a decline in the likelihood of PHAs being present on devices in the region. South Korea saw the lowest number of devices containing PHA, with only 0.12%.

Check out the report

Over time, we'll add more insights into the health of the ecosystem to the Android Ecosystem Security Transparency Report. If you have any questions about terminology or the products referred to in this report please review the FAQs section of the Transparency Report. In the meantime, check out our new blog post and video outlining Android’s performance in Gartner’s Mobile OSs and Device Security: A Comparison of Platforms report.

A New Chapter for OSS-Fuzz

Posted by Matt Ruhstaller, TPM and Oliver Chang, Software Engineer, Google Security Team

Open Source Software (OSS) is extremely important to Google, and we rely on OSS in a variety of customer-facing and internal projects. We also understand the difficulty and importance of securing the open source ecosystem, and are continuously looking for ways to simplify it.

For the OSS community, we currently provide OSS-Fuzz, a free continuous fuzzing infrastructure hosted on the Google Cloud Platform. OSS-Fuzz uncovers security vulnerabilities and stability issues, and reports them directly to developers. Since launching in December 2016, OSS-Fuzz has reported over 9,000 bugs directly to open source developers.

In addition to OSS-Fuzz, Google's security team maintains several internal tools for identifying bugs in both Google internal and Open Source code. Until recently, these issues were manually reported to various public bug trackers by our security team and then monitored until they were resolved. Unresolved bugs were eligible for the Patch Rewards Program. While this reporting process had some success, it was overly complex. Now, by unifying and automating our fuzzing tools, we have been able to consolidate our processes into a single workflow, based on OSS-Fuzz. Projects integrated with OSS-Fuzz will benefit from being reviewed by both our internal and external fuzzing tools, thereby increasing code coverage and discovering bugs faster.

We are committed to helping open source projects benefit from integrating with our OSS-Fuzz fuzzing infrastructure. In the coming weeks, we will reach out via email to critical projects that we believe would be a good fit and support the community at large. Projects that integrate are eligible for rewards ranging from $1,000 (initial integration) up to $20,000 (ideal integration); more details are available here. These rewards are intended to help offset the cost and effort required to properly configure fuzzing for OSS projects. If you would like to integrate your project with OSS-Fuzz, please submit your project for review. Our goal is to admit as many OSS projects as possible and ensure that they are continuously fuzzed.

Once contacted, we might provide a sample fuzz target to you for easy integration. Many of these fuzz targets are generated with new technology that understands how library APIs are used appropriately. Watch this space for more details on how Google plans to further automate fuzz target creation, so that even more open source projects can benefit from continuous fuzzing.

Thank you for your continued contributions to the Open Source community. Let’s work together on a more secure and stable future for Open Source Software.

Announcing some security treats to protect you from attackers’ tricks

Posted by Jonathan Skelker, Product Manager

It’s Halloween ? and the last day of Cybersecurity Awareness Month ?, so we’re celebrating these occasions with security improvements across your account journey: before you sign in, as soon as you’ve entered your account, when you share information with other apps and sites, and the rare event in which your account is compromised.

We’re constantly protecting your information from attackers’ tricks, and with these new protections and tools, we hope you can spend your Halloween worrying about zombies, witches, and your candy loot—not the security of your account.

Protecting you before you even sign in
Everyone does their best to keep their username and password safe, but sometimes bad actors may still get them through phishing or other tricks. Even when this happens, we will still protect you with safeguards that kick-in before you are signed into your account.

When your username and password are entered on Google’s sign-in page, we’ll run a risk assessment and only allow the sign-in if nothing looks suspicious. We’re always working to improve this analysis, and we’ll now require that JavaScript is enabled on the Google sign-in page, without which we can’t run this assessment.

Chances are, JavaScript is already enabled in your browser; it helps power lots of the websites people use everyday. But, because it may save bandwidth or help pages load more quickly, a tiny minority of our users (0.1%) choose to keep it off. This might make sense if you are reading static content, but we recommend that you keep Javascript on while signing into your Google Account so we can better protect you. You can read more about how to enable JavaScript here.

Keeping your Google Account secure while you’re signed in

Last year, we launched a major update to the Security Checkup that upgraded it from the same checklist for everyone, to a smarter tool that automatically provides personalized guidance for improving the security of your Google Account.

We’re adding to this advice all the time. Most recently, we introduced better protection against harmful apps based on recommendations from Google Play Protect, as well as the ability to remove your account from any devices you no longer use.

More notifications when you share your account data with apps and sites

It’s really important that you understand the information that has been shared with apps or sites so that we can keep you safe. We already notify you when you’ve granted access to sensitive information — like Gmail data or your Google Contacts — to third-party sites or apps, and in the next few weeks, we’ll expand this to notify you whenever you share any data from your Google Account. You can always see which apps have access to your data in the Security Checkup.

Helping you get back to the beginning if you run into trouble

In the rare event that your account is compromised, our priority is to help get you back to safety as quickly as possible. We’ve introduced a new, step-by-step process within your Google Account that we will automatically trigger if we detect potential unauthorized activity.

We'll help you:
  • Verify critical security settings to help ensure your account isn’t vulnerable to additional attacks and that someone can’t access it via other means, like a recovery phone number or email address.
  • Secure your other accounts because your Google Account might be a gateway to accounts on other services and a hijacking can leave those vulnerable as well.
  • Check financial activity to see if any payment methods connected to your account, like a credit card or Google Pay, were abused.
  • Review content and files to see if any of your Gmail or Drive data was accessed or mis-used.
Online security can sometimes feel like walking through a haunted house—scary, and you aren't quite sure what may pop up. We are constantly working to strengthen our automatic protections to stop attackers and keep you safe you from the many tricks you may encounter. During Cybersecurity Month, and beyond, we've got your back.