So as he said, I'm
Adrienne, and I'm
from the Chrome security team.
And today, I'm going to be
talking to you about how
to ask for superpowers,
meaning all these cool new APIs
that we've been talking
about throughout the day.
So I travel a lot,
too, just like Alex.
Last week, I was in
the Sydney office
talking to the Chrome Apps team.
A few weeks before
that, I was in London.
And because I travel
so much, I like
to try to stay in touch
with my family back at home.
And I usually do that
with Hangouts in Chrome.
So when I want to video chat
with my husband or maybe
my dog, who doesn't really
know what's going on,
I use Hangouts.
And Hangouts relies on
getUserMedia in Chrome
in order to get access
to camera and microphone.
And as Alex was
talking about, it
would be great to be able to
get things like flight updates
and gate change notifications
from a website using things
like ServiceWorker
and Push Messaging.
And so all of this cool
new user experiences
are being enabled by
all the new APIs that
are coming to the web.
So we've talked about
a few of these today,
and even more will
be coming out.
We've got Notifications,
and Bluetooth
is in the works, things
about persistent storage
and background sync, et cetera.
And all of these
are really awesome,
and I hope to see them used
in all of your websites.
But we've also got
to deal with the fact
that there are possible
negative user experiences that
could come along with
these APIs as well.
So for example, I'm one of
those people who doesn't always
plug in my phone.
And sometimes, on day three,
I'm like going around my office
mates' computers looking for
USB cables looking for power.
So I don't really want websites
to be draining my battery more
than they really need to.
So something like
Push Messaging,
while really awesome, could
also end up draining battery
faster than you like.
Or Notifications
are great when you
want to find out about an
email or a tweet or something
like that but not so great
when you're getting 15 of them
in a minute to tell you all
about some new product you
should buy.
And of course, no one
really wants their camera
turning on at a surprising time.
So as a community, we
face a challenge here.
So on one hand, we have these
new superpowers, these new APIs
that we want to be able to use
to build great experiences.
But on the other hand, we
have responsibility to users
to make sure that
we're respecting
their privacy, their security,
and in general their desire
to have control
over their devices.
And also, one of the things
that I really love about the web
is that I can go to
just about any website
and feel pretty confident that
at the end of the session,
I'm not going to have
any problems with privacy
and security.
I can go to little
known websites,
I can try new things
out, and I don't really
have to be worrying about
privacy and security,
because Chrome is
doing it for me.
And I feel that's our
job as developers,
to take users'
concerns into account,
so that users don't
have to become security
experts to use the internet.
So our answer to this is
by putting more effort
into Chrome's permission model.
So when I say a permission,
what I'm talking about
is you go to use
a notification API
and a thing pops
up to ask the user,
hey, do you want to let a
website use the Notification
API.
And there are two
main goals we have
with this permission system.
The first goal is, of course,
to respect user choices and user
control over their devices.
And on the other
hand, we also want
to make it easy for
developers to be
able to use this permission
system so that it flows well
and works well
with your websites.
And so I'm going
to be talking today
about some of the things that
are coming now, or coming soon
in Chrome with respect
to the permission model.
And then after
that, I'm also going
to be discussing a
set of different tips
that you can use to make
your websites work better
with this permission model.
I'd also like to
clarify that everything
that I'm talking about
today pretty much
is stuff that Chrome is doing.
It's not a standards track or
a specifications type work.
Those are the APIs.
I'm talking about the UI
and the user experience that
surrounds the APIs as
part of the browser.
So as Alex briefly
alluded to earlier,
the foundation of this
model is that HTTPS
is going to be required
for most new APIs,
if they touch on things that
are security related, privacy
related, or if they
could be abused.
And not only will this
apply to new APIs,
as if they come into
existence, but we're also
trying to figure out how to
backport this to older APIs.
So for example, getUserMedia
is shipping today.
As I mentioned earlier,
Hangouts uses it.
And right now, you can use
it over both HTTP and HTTPS.
We're working to figure
out a transition plan
to make it HTTPS
only in the future.
Now, let me explain why we
think this is important.
Let's say that
I'm using Twitter,
and I give Twitter the
ability to take photos
with my computer, to post a
picture of myself or my dog
or something.
I want Twitter to be
able to use that ability.
I don't want my ISP and
the people around me
at the coffee shop to also gain
that ability at the same time.
And HTTPS gives
you the guarantee
that Twitter will be the
only one getting access
to this privilege.
And the flip side of
that is integrity.
Say you have something
like Notifications.
Some Wi-Fi provider
might get into their head
that a great way to monetize is
to send lots of notifications,
advertising things to people.
That's going to hurt
your website too,
because people are
going to associate
these low-quality notifications
with your website, which
isn't what you want.
So I want to acknowledge
that some people have found
in the path to adopting HTTPS
a little rocky, so don't panic.
It's probably easier and faster
and cheaper than you think.
And later this afternoon,
my colleague, Chris Palmer,
is going to talk all about
all the great things that
have happened over the
recent year and coming to us.
All right, so now you've
got your HTTPS website.
So the first thing you're
going to need to do
is to request permission
to get access to the API.
So in the past, and in
fact currently on stable,
what this looks like is an info
bar at the top of the screen
that is asking the user
whether to grant or deny
a certain privilege
for that website.
As you can see, it also
pushes the content area down.
So we got feedback
from developers
that that info bar was
being missed by users.
They weren't really seeing it.
So we're working on a new thing
called a permission bubble.
And this hopefully will
get more user attention
and the users will
notice it more easily.
So you can play with it
if you turn on that flag.
Or we're also going to be
starting to roll it out
experimentally soon
in the coming months.
We're still playing
around with things,
like how to get focus right.
Another problem that we
had with the info bar model
was that if people ask
for multiple permissions,
they would end up getting
stacked on top of each other
like this, which is pretty ugly.
And if you get a few
of them, it starts
taking up a lot of space.
So the permission bubbles
will coalesce permissions
that are asked for very
close together in time.
Users can still say yes or no
to each of these individually.
Another thing we're doing is
looking at completely new ways
to ask for permission,
instead of just
the binary yes or no answer.
So this is an example
from Chrome 40
for the Chrome Apps USB API.
So instead of just asking the
user yes or no, like can this
access USB devices,
it lets the user
choose which USB devices
should be available to the app.
Now my colleagues
are also working
on prototypes of similar
types of things for things
like the web
Bluetooth API, so you
should expect to be seeing
this for web permissions too.
All right, so let's say that the
user has made their decision,
they've either granted
or denied the ability
to use a permission.
People might want to
change their minds later.
We ran through some
scenarios with a group
of users a few weeks
ago, asking people
whether they would say
yes or no to permissions
in certain circumstances.
And some people
expressed hesitation,
because they didn't know how
to control these privileges.
For example, this
person said, "And that's
why I wanted to decline,
I don't know how to undo.
If I knew how to undo,
I would say yes."
So to address
this, we're working
on better in-page controls.
I'm going to show a demo here.
By the way, I'm using
the same extremely--
if I could switch to
the projector, that'd
be great-- the same extremely
fresh version of Chrome
that Alex was using, so please
cross your fingers for me.
All right, so here
I've got a website
that's asking for
access to geolocation.
Thanks, it's reminding me
that I'm at my own talk.
Useful, right?
OK, so I'm going to go
ahead and allow this.
Now if you click on the
lock, it opens this up,
the in-page controls.
So this lets the user
check on the security
and the privacy
of the connection.
So you can see at the
top, it's using HTTPS.
So it says your connection
to this site is private.
And it also gives
you the ability
to see any of the non-default
permission settings.
So this one has location,
because I just granted that.
And from right here, you can
toggle between Allow and Block
if you want.
So now I block that.
Back to the slides, please.
Now, another thing
that comes up is usage.
I mentioned earlier
that I'm really
paranoid about battery life.
Other people are
concerned about things
like how much disk space a
website or app is taking up.
Or some people are
worried, they don't
want to use any
websites that are going
to be constantly
tracking their location.
So our answer to
that is building
some of this information
into site settings.
I'm going to show you some mocks
of our vision in this space.
But just so you
know, you can see
some of what I'm about to
talk about in Chrome 40,
although it's not
feature complete yet,
which is why I'm
showing mocks today.
So if you go into site settings,
you can search for a page
or pick a specific permission.
Here, I'll do Notifications
as an example.
And it'll show you
all the websites that
have been granted access to
this or have been blocked.
And for the ones
that have access,
it'll show you when
it was last used.
So you can see, for
example, who's recently
been sending notifications
on your device.
And if you search for or
click on a specific website,
you can see that
the history of how
it's been using its privileges.
You can see here
in this example,
it's been using geolocation.
You'll also be able
to see information
about battery usage
and data storage.
And you can do things
like Stop or Delete
the data, if you
think that's important
and you're trying to
reclaim some space.
So I recognize that those
features that I was just
talking about in Site
Settings are not things
that people are going
to use every day.
On an everyday basis, people
want things to just work.
So let me give you two examples.
The first is Virgin America.
You're traveling, you've got
10 gate changes in 10 minutes.
You probably want all 10
notifications in 10 minutes
telling you all about
this, because this
is important to you.
On the other hand,
let's say someone
wanted to send you 15
advertisements in 15 minutes.
You probably don't want that.
So how do you distinguish
between these two cases?
Well, in the positive
user engagement case,
the user really
likes that website.
Examples of a user indicating
they like a website
might include something like it
shows up in their history a lot
because they visited often.
Maybe they've bookmarked it.
Maybe they've added it
to their home screen.
Or maybe they have
a login for it.
So what we're
thinking about doing
is tying these signs of
positive user engagement
to thresholds for permissions
that aren't privacy sensitive
but are more just annoying.
So you might be able to
send more notifications,
have a higher quota for storage,
or if they're a vibration API,
vibrate more times in
a short period of time.
So we want to be able to
sort of reward this good user
experience.
This is still
experimental by the way.
This isn't something that
we've nailed down precisely
and something that we
haven't launched yet.
I'm mentioning it
really early now,
because I would love to get
feedback from you on what
you think about these ideas.
And if you could come
talk to me at the booth
or come to the panel
with questions about it.
I would love to hear
your thoughts on it.
We also be recognizing
user discontents.
By this I mean, I mentioned that
there are two cases, the Virgin
America case,
which I like a lot,
and the case of the
sort of spammy website.
And we want to be
able to recognize
these negative cases as well.
So for example, users might
consistently-- say 99% of users
say no when a website
asks for our permission.
Or people are
saying, yes, but then
they're going and
turning it off later.
These are signs
that users aren't
very happy with that experience.
And so in these cases,
we're thinking about things
like lowering thresholds or
maybe not even prompting users.
So again, this is an idea
that we haven't exactly
fully decided on
the mechanics of it.
But I'm giving you
an early heads up.
All right, so now
I'm going to talk
about what you can do
to build a good user
experience around our
permission system.
First, I want to motivate
that users don't just click,
yes, yes, yes when you
ask them for things.
People do think about
and make real decisions
when asked permission questions.
So here are some quotes
from users about things
that they've
considered when they're
trying to decide whether
to grant a permission.
So what type of information
is it going to show?
Are you interested in it?
Do you trust the trust source?
So some researchers
at UC Berkeley
asked a group of iOS users
to share the settings
in their phones so they could
see what apps they had granted
or not granted geolocation
information to them.
And they found that
it differed a lot
depending on the specific app.
So you can see that for some
apps, like Maps, almost 100%
of users were willing
to grant a geolocation.
But on the other end of the
spectrum, fewer than half
of users were willing to
grant it to some apps,
like SoundHound and Shazam.
So the point I'm
trying to make here
is that the benefit
that users feel
they're going to get from
a specific permission
depends on what you tell them
the value proposition is.
So the first tip that we have
is to provide clear value
by timing the permission
requested in such a way
that the user can
connect the permission
request with the feature.
All right, so I'm going
to do another demo here.
Can I get on the
camera again, please?
So yes, you may recognize it.
This is the same demo that
Alex was using earlier.
So let's see how this goes.
OK, so let's say that I'm
travelling and my flight is
canceled.
And now, I'm trying to
book another flight.
So OK, I click on the button
to bring up the page to book
a flight.
Now it immediately
pops up the question
of whether I'd like Polyair to
be able to send notifications.
This isn't really a great
time to ask about that.
I don't really know what's
going to happen if I say yes.
So I'm going to swat it away.
So let's say I'm trying
to go from SFO to LAX.
All right, we're going to
take the Millennium Falcon.
All right, here again, it pops
up another permission request.
And this one is a
little bit better.
You can see that
it's at least tied
to some feature on the
page, but in my opinion,
it's still not the
best version yet.
So let's say no to that.
Now here, I'm going to click on
the Notify about flight delays
button.
Now here, it's very
clear that you've just
turned on notifications
for flight delays.
So the user is going to be
persuaded to click on Allow
here to say yes,
because they understand
what they're going to get.
Back to the slides, please.
So for some permissions,
like Notifications,
it's pretty easy to do this
well today, in my opinion.
For other types of permissions,
it's maybe a little bit harder.
So for example, for
Geolocation, you
can't tell whether
your website already
has the permission
before you try to use it.
So some people on
my team are working
on something called
the Permissions API.
Don't copy this code, because
it's currently a spec.
It hasn't been implemented yet.
But it's coming.
You'll start seeing an
implementation probably in 41.
But the idea here is
that it'll let you query
to find out whether
your website has a given
permission or a
set of permissions
so that you know whether trying
to use it is going to pop up
a permission request
or not to allow
you to time your
permission request better.
So for example, if you knew
this about your location,
you could do different behavior.
You could show very
localized stores.
You could show all
stores in California.
If you don't have
the permission,
just use the IP Geo instead.
So it'll give you more options.
All right, so the next
thing you need to note
is that you need to
ask with a document.
And this pertains specifically
to service workers.
If you try to request a
permission when there's
no document open,
there's nowhere
to show the permission request.
So don't do this.
So I'm going to show with
a good and a bad example.
A good example is in the
main document in response
to some event, like toggling,
request the permission there.
A bad example would be when
a background sync event fires
from within your service a recur
trying to request permission.
But the page might be closed.
There's no where to show
a permission request.
So you will not have a good
time; do not do it this way.
All right, the third
thing I want to talk about
is handling user rejection.
So what I mean is when a user
says no to your permission
request, please don't
break your whole website.
The user might see that
it breaks the feature
and then at a later time go
back and enable the permission.
So I'm going to show an example
of what that looks like.
So here this imaginary
store is going
to give you three options
of ways to give you
information about
store openings.
So if you click on the
toggle for the first one,
that opens up a
Notifications prompt asking
about desktop notifications.
So let's say I have,
for whatever reason,
changed my mind in this
intervening second and click
Block.
The thing you can do
as a website developer
here is gray out
Disable the feature.
So here, the rest of
the website still works.
You can still do email
alerts or Facebook alerts
or however you want.
But Notification part
specifically has been disabled.
Now, here's how you can check
the states, particularly
for notifications.
There are two ways to check the
states, the permission state.
The first is on
load, you can check
the value of
Notification.permission
and then update the
state of the toggle
based on whether it's,
for example, already
disabled for your domain.
The other is, let's say you
want to trigger the request.
You do
Notification.requestPermission,
and the callback will
take as an argument
a permission parameter.
And either way, you're
able to then check
the value of the
permission, either the value
onload or the value
after you requested it
and update your UI accordingly.
And last but not
least, you also have
to remember that you need
to handle revocation.
So let's say the user
grants a permission
but then, for whatever
reason, disables it later.
This might mean--
or even could just
be that their device
breaks, you don't know.
So make sure that
when available,
take advantage of both
your success callbacks
and your error callbacks.
So here's another
example of that.
Here, this is currently in the
middle of recording audio using
getUserMedia.
So I previously
granted the permission.
But now I'm going
to take it back.
And the next time the user goes
to click the Record button,
the error callback
is going to fire.
And you can see in the
console at the bottom
say that it's a
permission denied error.
So this is an example
of showing how
you can pass in both a success
callback followed by an error
callback.
And in the error callback, you
could say Disable the feature
and Update the UI setting.
So hopefully, we're
able to help you
as developers build good
permissions user experiences.
Because I want you all to
be able to use these really
awesome APIs that
are coming out.
And as part of that,
you need to make sure
that you're justifying
to users both
why you should be able
to get the permission
and also why you should keep it.
And as I said before, we
want to help you do this,
so we love feedback.
And also, these will
be posted later.
All of the demos and the code
examples are on my GitHub.
Thank you.
[APPLAUSE]
