[MUSIC PLAYING]
SARAH HATHIRAMANI: My name is Sarah Hathiramani,
and I work on one of the counter-abuse technology
product teams at Google.
As you heard Jen Fitzpatrick talk about earlier right here
at I/O, we keep more people safe online
than anyone else in the world with products
that are secure by default, are private by design,
and put you in control.
Today, I'm excited to share a bit more about how our teams do
this work at scale.
I'll spend some time talking about our team's recent work
to keep people safe, in some cases
by introducing new technologies across all our platforms.
You might be asking, what do counter-abuse teams at Google
do?
We develop detection systems that identify and respond
to both existing and novel forms of abuse.
We also collaborate with product teams
to build safety into our products
from their inception to help prevent abuse
before it takes place.
We build infrastructure that helps
us protect our users at internet scale,
and we provide transparency into our work,
including transparency reports about our user protection
efforts.
Many of you are probably already familiar with forms
of online abuse like scams, fraud, malware, and phishing.
These are some, but not all of the types of abuse
we spend time identifying and then building scaled systems
to detect and prevent.
But abuse can appear in many different ways.
One way to think about it is to consider
that any time an individual is exploiting a product
feature to harm another user or the underlying system,
that's abuse of our products, features, or systems.
Before we can even start to work on technology to stop abuse,
we have to consider what forms abuse can take
and how people might seek to misuse or exploit our systems.
This is especially challenging because Google is constantly
working on new products, and the technology industry as a whole
is always evolving.
As we develop new products and we
think about how they can be helpful to people,
we also think about how these new technologies might
be exploited or misused.
This means that we have to work hard to ensure
that our counter-abuse capabilities meet
the needs of an ever-evolving abuse landscape.
One example of such a technology is end-to-end encryption
as well as other privacy-preserving technologies
that are becoming more popular as a way
to protect individual's data.
We are committed to building safe systems that
maintain these privacy protections,
prevent abuse, and ensure the integrity of our user's
devices.
The privacy protection offered by end-to-end encryption
is one important precursor to building safe systems.
Being able to verify device and data integrity is another.
For example, if we can verify that an Android device is
running unaltered operating system software and similarly
unaltered apps, we can draw reasonable conclusions
about the integrity of the device.
This allows us to more holistically understand
the extent to which we trust the device
and deliver safer product experiences accordingly.
Our goal is to build systems and devices that
have defense in-depth, that is, multiple layers of defense
built into them.
Things like privacy protections and verifiable device and data
integrity deliver multiple layers
of defense against abuse.
Another example of our approach to defense in depth
is the Pixel 6 and Pixel 6 Pro.
When we introduced these devices,
we also introduced Binary Transparency
for Pixel factory images.
Binary Transparency is a core technology
that counter-abuse systems can be built upon.
It increases the opportunity for third-party organizations
and individuals to verify the integrity
and the provenance of a binary.
Binary Transparency can trace its origins
to certificate transparency.
Certificate transparency, which some of you
will be familiar with from TLS certificates on the web,
provides the ability to verify correct issuance
of certificates.
While a signed certificate by itself
includes one layer of verifiable integrity
via its digital signature, certificate transparency
adds broader public verifiability.
By putting a signed hash of the certificate
in an append-only publicly visible transparency log when
the certificate is issued, it's quickly
verifiable both which organization
issued a certificate and when.
This capability provides the opportunity for everyone
to be on the lookout for misissued certificates
so they can be detected quickly.
Signatures alone don't allow for such rapid detection.
Certificate Transparency, or CT, has
been so effective and successful that no modern browser accepts
TLS certificates that aren't in a CT log.
The idea behind Binary Transparency is similar to CT,
except that we apply these same transparency principles
to other binaries rather than just certificates.
Instead of putting hashes of certificates
into a transparency log, with Binary Transparency,
we put hashes of a binary, in this case, the factory system
images for Pixel 6.
Last October, we released additional detail
along with developer tools to allow the technically inclined
to verify that the system images of the OS installed on Pixel 6
are in the log.
With the ability to verify that the system images are
in the log, people are able to ensure that their phone has
the same bits that Google released
and that the bits haven't been altered
at some point along the way.
If you search for Google Binary Transparency,
you can find both the introduction page as well as
the page specific to Pixel factory images.
If you want to learn more about the core concepts
and infrastructure behind this system,
you can also check out binary.transparency.dev.
In addition to launching Binary Transparency for Pixel factory
images last October, we also launched
and are discussing here for the first time
a second implementation of Binary Transparency
within Pixel 6.
This second Binary Transparency system
enables a new approach to help prevent scams and phishing.
Starting last summer, Messages by Google
has been able to protect messages
with end-to-end encryption when sent via Rich Communication
Services, or RCS.
When messages are end-to-end encrypted,
the servers handling the transmission of the messages
can't check the actual messages.
To protect our users from scams and phishing,
we integrated on-device protections
for this form of abuse.
If users have these protections enabled,
the protections apply to the users' messages
once they're received on the device
regardless of whether the messages are encrypted.
These on-device protections work on users' devices
without sharing information like the message content
back to Google or breaking the end-to-end encryption
of the messages.
This is a privacy-preserving way of providing
the best consistent level of protection
for our users and their messages.
To further preserve privacy, we believe
that adding verifiability to deployed
on-device anti-abuse technologies
is an important first step in this space.
Adding more verifiability to on-device counter-abuse systems
provides more assurance about their integrity.
For example, if an anti-abuse model
fails to verify on device, perhaps due to a network issue,
it won't be used, and the system will
wait until it can receive a verifiable one.
This approach ensures that on-device detection
is based on sound data that is bit-for-bit
what the back-end system sent.
To that end, we added Binary Transparency
to the infrastructure that delivers abuse prevention
updates to devices.
This means that we can verify both the integrity
and the provenance of the update before it's applied.
We're pleased with the privacy properties of this innovation
and are continuing our research in this realm.
In the future, we hope that others in the industry
will operate Binary Transparency logs
as well, just like how certificate transparency works
today.
We also expect some organizations, commercial
and research alike, to operate so-called witnesses, which
are systems that keep an eye on the correct operation
of the logs and verify their consistency.
As the evolution of Certificate Transparency taught us,
transparency ecosystems are successful
only if there are multiple logs, which
means no single point of failure and multiple witnesses
to ensure rapid detection of a log
becoming unavailable or otherwise
misbehaving, for example, in the event
of a connectivity problem.
Thank you for taking the time to learn more about our commitment
to keeping people safe in an ever-changing environment.
As the industry evolves and new technologies emerge,
we remain committed to developing and inventing
privacy-preserving technologies that prevent abuse.
We look forward to ongoing conversation and innovation
in this area, and we thank you for being on this journey
with us.
Thank you.
[MUSIC PLAYING]