[MUSIC PLAYING]
SPEAKER 1: In
theory, the URL bar
that's shown at the
top of a web browser
is your unambiguous clue
to website identity.
If the URL bar says Google.com,
you're at the real Google.
But in practice, it's not always
so easy to tell site identity
from a domain.
In a study that we did with
over 1,000 participants,
we showed users a browser
window where the website looks
like a Google login
page, but the address bar
said tinyurl.com.
When asked to identify
this website, over 85%
of participants said
the website was Google.
We're approaching this
problem from a few angles.
First, we're actively combating
sophisticated spoofing
techniques that
abuse URLs to create
unusually deceptive attacks.
Second, we're trying to
draw people's attention
to the information in URLs
that's most relevant for making
security decisions.
And finally, we're
building specialized tools
to support expert use cases
so that we can help make URLs
better security tools
without interfering
with experts' workflows.
SPEAKER 2: People
should be able to browse
the web without worrying
that someone is collecting
a dossier on them for
what they're doing,
and developers should
be able to build sites
without worrying that their
infrastructure is compromising
their users' interests.
Third parties may want to
answer some very natural
and non-personal questions--
things like, how many
different people saw my ad?
Or how often do the people
who click on these ads
actually buy something?
Answering all these
questions today
relies on a really
powerful capability--
global cross site identity.
This is what can also be used
to knit your browsing behavior
together into a user profile.
So once we've invented new
ways for the web to flourish--
ways that don't
rely on tracking--
recognizing users across
sites has historically
been based on third
party cookies.
But as browsers have restricted
access to those cookies,
we've seen them replaced
with other mechanisms--
covert browser storage,
device fingerprinting.
Those covert tracking
techniques are a real problem.
If the web platform
forces you to use
high entropy
fingerprinting surfaces
to perform mundane tasks like
checking for emoji support,
that's a problem
that we need to fix.
And then, we want Chrome
to notice it and stop it
when a website is
abusing a bunch
of unrelated, high entropy
content APIs as a way
to fingerprint you.
Our privacy budget
explainer describes
the multi-step process
that we're working on.
Starting in Chrome M80--
that's three months from now--
if you set a cookie the way
you've probably been doing it
since the dawn of
the web, that cookie
will be available only
in a first party context.
If you want that cookie
when you're a third party,
you need to do something new.
If you want a cookie available
when you're a third party,
you will need to explicitly
set it with the attributes
SameSite=None and Secure.
SPEAKER 3: And there are
a lot of online services
that heavily rely
on phone numbers,
especially as a way to
send SMS text messages.
These services are using
SMS to let users sign up,
help users recover
their accounts,
increase user security
with two step verification,
or confirm payments.
That's why we are proposing
a new API called SMS Receiver
API.
Web developers can
use the SMS Receiver
API to let the browser
receive the SMS message,
extract the OTP, and enter
the OTP on behalf of the user.
Before the website
can receive an SMS,
you have to know the
user's phone number
so that you can send a message.
If you are using an input tag,
my recommendation is to use
autocomplete="tel".
That way, the browser can help
the user auto fill their phone
number.
When an SMS is received and
meets all the conditions,
a bottom sheet
appears in the browser
and the user can grant
the browser permission
to access the text message.
This permission is required for
every receipt of a new message.
This means the browser
won't be able to read
SMS messages without the
use of explicit permission.
To learn more about the
SMS Receiver API, please
go to Google/smsreceiverAPI.
In the previous session,
Emily showed you
how Chrome tries to ensure the
user is on the genuine side.
Web often allows you to provide
an extra layer of safety
for users because
the key pair is
bound to the website's origin.
Even if a user ends up
on the phishing website,
that phishing
website will not be
able to make the user
generate a valid signature.
Now, I would like to talk
about two primary user
experiences using WebAuthn.
They are two-factor
authentication and re
reauthentification.
So how effective
are second factors?
Here's a comparison
between SMS OTP
as the second
factor and security
key as a second factor.
As you can see, SMS
OPS is not perfect
against targeted attacks, while
security key protect users
completely.
Platform authenticators are more
consumer-friendly than roaming
authenticator or security
keys because you don't have
to purchase a separate device.
You don't have to worry
about carrying it around,
and they are a part of
device you use every day.
[MUSIC PLAYING]
