WWDC2018 Session 204

Transcript

[ Music ]
[ Applause ]
>> Good morning.
Welcome to Session 204,
Automatic Strong Passwords and
Security Code Autofill.
My name is Chelsea.
You may have seen Automatic
Strong Passwords and Security
Code Autofill in the State of
the Union, yesterday.
I'm really excited to tell you
more about these features,
today.
These new features and other
features in iOS 12 will help
users log into and create
accounts with ease in your app.
If you have a login screen or an
account creation screen in your
app, this session is for you.
A major pain point for users is
dealing with passwords.
They can be a pain point, even
for people that use the best
practice, which is to use a
password manager to create and
fill passwords for them.
For everyone else it can be
tempting to do something easy
but insecure, like reuse a
password they're already using
on another service or use an
easy to guess password that they
can memorize.
We know that the most private
secure thing for your users is
to use strong unique passwords
for each service that they use.
We've all heard of breaches in
services that result in users'
passwords being exposed.
Users then need to go and change
their password on every service
where they were using it.
The features that we'll discuss
today will help users choose
strong unique passwords for your
apps.
This way, you both help users
that are trying to consciously
use best password practices, as
well as your users that would
rather not think about
passwords.
Many of your users use the
iCloud Keychain.
The features that we're going to
talk about today are built on
top of the Keychain.
It has best in class security
and it protects users' passwords
behind biometric authentication.
Apple does not have access to
the credentials stored in
Keychain, so users' privacy is
preserved, as well.
The iCloud Password Keychain
Manager can help users log into
and create accounts in your app.
We've added some new features on
iOS 12 to help make account
creation and login even easier.
I'm really excited to show you
these features with a demo.
So, I'm going to go to the Shiny
app.
This is my favorite demo app for
creating an account and logging
back into it.
So, I'm going to go ahead and
create-- and tap create account.
I'll focus the email field and
you'll see that I've been given
a suggested username.
This is a new feature on iOS 12.
These suggested usernames are
based on credentials that the
user already has stored in the
Keychain.
Since I always use
Chelsea@example.com, I'm going
to select that as my username.
Without another tap, the
password field is focused for me
and a strong unique password has
been provided.
I'm also told that I can go and
look up this password in
Settings at any time.
So, if I need to go and type it
onto another device where iCloud
Keychain is available, it's
available to me.
So, I'm going to go ahead and
use this strong password and
sign up.
So, with just a couple of taps
I'm logged back into the Shiny,
or I'm signed up for the Shine
app.
Now, let's fast forward through
all of the other account setup.
I've turned on second factor
authentication.
And let's look at what logging
back into Shiny looks like.
So, I'm going to go ahead and
tap the email field.
As you can see, the credential I
just created is suggested right
on the QuickType bar.
Going to select that.
And then, after Face ID, my
password and username are filled
and I can log in.
Now, I've set up second factor
authentication.
Normally, I'd need to try to
memorize this code or go back to
Messages.
But as you can see, the code
that I just received for second
factor authentication is right
on the QuickType bar.
So, with one tap I can fill the
code.
Yeah. It's really awesome.
[ Applause ]
So, I can fill that code,
submit, and again, with a
minimal number of taps I'm
logged back into Shiny.
Back to the slides.
So, as you saw, creating an
account with Automatic Strong
Passwords is quick and easy.
I didn't think about the
password, since one was provided
for me and inserted into the
password field.
I also didn't think about the
password when logging back into
Shiny.
Passwords have truly become an
implementation detail to logging
into my app with Automatic
Strong Passwords and Password
Autofill.
Here's today's agenda.
First, we're going to do a quick
recap of Password Autofill,
since many of the features that
we'll talk about today are built
upon that feature.
Next, we'll talk about how to
ensure that Automatic Strong
Passwords works in your app.
Then, we'll talk about Security
Code Autofill.
Next, we'll talk about federated
authentication with a
third-party service.
And finally, we'll discuss some
new password management features
that the iCloud Password
Keychain Manager provides.
In iOS 11, we introduced
Password Autofill for apps.
Some of the new features that
we're going to discuss today are
built upon the same adoption you
may have done for that feature.
Password Autofill helps users
log into your app by surfacing
credentials right on the
QuickType bar.
Here's a quick recap of how to
ensure that it works in your
app.
Passwords in the iCloud Keychain
Password Manager are stored
based on domains on the Web.
Like Apple.com.
Thus, it's important to have an
association between your app and
the domain on the Web.
This way, we're able to
confidently surface credentials
on the QuickType bar.
You already have this
association if you've adopted
Universal Links or Handoff.
The process of adding this
association is pretty simple.
You'll have a small change to
your apps Entitlements file and
you'll serve a file from your
domain on the Web.
If you'd like to see an in-depth
look at how to set this up, see
Introducing Password Autofill
for Apps from WWDC 2017.
It's important to always tag
your fields with text content
type, so that Autofill can be
offered at the right place.
Tag your username fields with
the username content type.
Tag fields where users are going
to be filling, or passwords for
existing accounts with a
password content type.
If you've chosen not to use
Secure Text Entry for your
password fields, it's
particularly important that you
tag your fields with the
password content type.
This way, we know we're in a
password context.
Now, that we've discussed how to
get Password Autofill working in
your app, let's talk about some
improvements that it has.
Since, iOS 11.3, WKWebView
supports Password Autofill.
This helps your users if your
login screen is implemented
using Web technologies.
New to iOS 12, password managers
from the app store can provide
information to Autofill.
This means that any work you do
to support the iCloud Keychain
Password Manager filling
credentials in your app, also,
helps users of these other
password managers, as well.
If you're a developer of a
password manager, see
Implementing Autofill Credential
Provider Extensions.
On iOS 12, we now offer to save
credentials when a user logs
into your app with a new
account.
This way, users can then use
these credentials in your app
and website on all of their
devices.
Let's talk about how to ensure
users are prompted to save and
update passwords in your app.
Here's how saving works.
First, Autofill infers that
we're in a login scenario.
Then, Autofill checks the
eligibility of your app based on
if there's an association
between your app and the domain
on the Web.
Without this association saving
passwords will not be offered.
Next, it finds the username and
password fields so that it knows
which data to save in the new
credential.
Then, it detects that a sign in
action has occurred.
And finally, Autofill decided
whether to prompt to save or
update the password based on if
this is as brand new credential
that's not yet in the Keychain.
Or if the user is updating an
existing credential.
Now, this may work with no
changes to your app on iOS12.
But let's talk about some steps
you can take to ensure that it
works.
First, make sure to tag your
fields with the username and
password content types, like,
with filling passwords.
Make sure to remove your
username and password fields
from the view hierarchy when a
sign in occurs.
This way, Autofill can detect
that a sign in is occurring.
You could do this by dismissing
the view controller that your
sign in fields are in.
Make sure to only clear the
username and password fields
after they've been removed from
the view hierarchy.
This way, we can read out the
data and save it into
credential.
Make sure the Autofill saves the
credential to the correct
domain.
You can do this by saving a
password in your app, and then
going to Settings to check where
the credential is saved.
If you notice that Autofill is
not saving to the correct
domain, you can override where
it's saving using the Web
credentials associated domain
service.
Finally, you may have previously
been using
SecAddSharedWebCredential to
manually save credentials when a
user logs into your app.
However, now that Autofill
automatically prompts users to
save passwords you may no longer
need this.
You will still want to use this
if your app has a web view for
its login screen because saving
is not supported there.
So, here are some of the key
steps that we've discussed so
far to make sure that filling
and saving passwords in your app
works.
Make sure to associate your app
with the domain on the Web.
Tag your fields with the
username and password content
type.
And for saving passwords, ensure
that login is detected by making
sure that the saving prompt
appears when you sign into your
app.
By ensuring that Password
Autofill works in your app, you
help your users log in with
ease.
For new users, one of the first
encounters they'll have with
your app is creating an account.
In my demo you saw how Automatic
Strong Passwords made this
process super easy.
I'd like to invite Reza to the
stage to discuss how to ensure
Automatic Strong Passwords works
in your app.
Thank you.
[ Applause ]
>> Thank you, Chelsea.
Hi, everyone.
This is Reza and I'm really
excited to tell you all about
Automatic Strong Passwords.
Account creation is a point of
frustration for many users.
They might even leave your app
and never come back, or as many
of them do, decide to use a weak
password or keep reusing the
same one.
This significantly reduces their
security.
Although, it might be an
alternative to account creation,
some of you might have concerns
about allowing social media to
be used to sign into your apps.
Automatic Strong Passwords makes
account creation just as easy.
It brings convenience and
security to the signup process.
Users no longer need to think
about or worry about passwords.
Autofill even suggests usernames
to ease the signup process.
With Automatic Strong Passwords,
account creation is only a few
taps away.
So, users are more likely to
sign up and user your services.
Now, I'd like to talk about how
Automatic Strong Passwords
works.
Similar to what Chelsea
explained in a login scenario,
when your app presents a view
controller Autofill infers its
type.
In this case, it's a signup view
controller.
It will then check the
eligibility of your-- it will
then check the eligibility of
your app based on the associated
domains to figure out if it can
save passwords.
If that's the case, Autofill
will then detect relevant signup
form elements; the username and
the password.
Once the username field become
first responder Autofill
suggests usernames.
This is a new feature we're
adding in iOS 12.
The user proceeds with the
suggested username.
And eventually, the password
field becomes first responder.
Autofill automatically inserts a
strong password into the
password field.
At this point, the user only
needs to proceed with the
suggested password and sign up.
Autofill takes care of saving
the password.
In many cases, this happens
automatically without any
adoption requirements in your
apps.
However, in order to ensure your
app's compatibility with
Automatic Strong Passwords there
are a certain number of steps
you should take.
Many of these steps are
identical to those Chelsea
explained to make your apps
compatible with saving.
Make sure to tag your username
field with UI textContentType
username.
New in iOS 12, make sure to tag
your new password and confirm
new password fields with UI
textContentType newPassword.
If you're using a UI table view
to represent your signup form
make sure to use unique
instances of UITextField for the
username and the password field.
This is important, because once
Autofill detects username and
password fields, it expects to
be able to reliably read their
values later on.
Some of you might have changed
password forms in your apps.
Automatic Strong Passwords is
compatible with change password
forms if Autofill is able to
detect username and password
fields on the same screen.
Note that the username field can
be Read Only.
Best practices that we discussed
for signup forms, also, apply to
change password forms.
Now, let's take a moment and
talk about the format of these
generated passwords.
The generated passwords are 20
characters long.
They contain uppercase, digits,
hyphen, and lowercase
characters.
This gives you a strong password
with more than 71 bits of
entropy.
We designed this to be a strong,
yet compatible with most
services.
It is, of course, possible for
your apps to define their own
custom password rules.
As I mentioned before, in most
cases, you don't need to do this
because the default format of
Automatic Strong Passwords
should be compatible.
However, if your app's backend
requires a separate set of rules
that are not compatible with the
default format of Automatic
Strong Passwords, you could
define your own rules.
To do so, use the new password
rules language in iOS 12.
Following the format of the
password rules language, create
a rulesDescriptor.
Using the rulesDescriptor create
an instance of
UITextInputPasswordRules and
assign it to the password rules
property of UITextField.
Once you do this, Automatic
Strong Passwords will generate
passwords based on these rules.
We have also created a new
web-based Password Rules
Validation Tool.
Use this tool to ensure the
rules that you specify are
correct and produce the type of
passwords that you expect.
I'll talk more about this,
shortly.
Now, that we talked about the
steps it would take to make your
apps compatible with Automatic
Strong Passwords, I'd like to
show you a demo.
I'm the developer of the Shiny
app and I want to make sure that
Shiny is compatible with
Automatic Strong Passwords in
iOS 12.
So, the first thing to do is to
run Shiny using the iOS 12 SDK
and try it out.
So, in Xcode I'll click on Run.
And here is Shiny.
I'll tap on Create Account.
Tap on Email.
And I don't see any suggested
username.
When I tap on the Password field
I don't see any Automatic Strong
Passwords suggestion, either.
So, let's go back to Xcode and
investigate this, further.
The first thing to make sure of
is associated domains for your
apps.
In this case, I've already
ensure that Shiny has an
associated domain.
In fact, earlier today I was
able to get Autofill suggestions
when I wanted to logging into
Shiny.
Next, you should take a look.
You should take a closer look at
your signup view controller.
I'll click on the Email field.
And here, under Text Input
Traits, Content Type, I see that
I'm correctly setting the
content type to username.
And because I want the format of
this username to be of type
email address, I'm also
correctly setting the Keyboard
Type to Email Address.
So, this is good.
Let's take a closer look at the
Password field.
I see that the Content Type is
set to Unspecified.
This should, actually, be set to
New Password.
So, I'll select New Password,
here.
And because this is a password
field, I'm going to mark it as
Secure Text Entry.
All right.
Let's run Shiny again and try it
out.
:15
Okay. Tap on Create Account.
Tap on Email.
Here, I see I'm getting
suggested username, now.
I'm going to go ahead and
proceed with the suggested
username.
I also, see Automatic Strong
Passwords.
So, in most cases, this should
be enough and you should be
done.
Let's proceed with the signup
process.
For the purpose of this demo,
I'm requiring Shiny passwords to
contain a dollar sign.
This means that we need to
specify our own custom password
rules for Automatic Strong
Passwords.
And actually, the best way to do
so is using the new Password
Rules Validation Tool.
Using the tool, I will be able
to specify correct password
rules, and also, ensure the rule
will produce the type of
password that I expect.
So, let's jump right in.
This is the new Password Rules
Validation Tool that you can
have access from
developer.apple.com.
For the purpose of this demo,
I'm allowing uppercase,
lowercase, digit, and requiring
at least a dollar sign to be
present in my password.
At the bottom of the page I see
some examples of the password
generated.
I also, have the option to
download a number of these
passwords in case I need to run
some tests in my app's backend.
Once I'm happy with the
formatting of the passwords I
have two options.
If I'm making a native app for
UIKit, I can go ahead and copy
the rules formatter for UIKit.
Or if I'm making a webpage I can
copy the HTML formatted rules.
For this demo, since we are
making a native app for UIKit,
I'm going to go ahead and copy
the UIKit version.
And once I've copied it, all I
need to do is go back in Xcode,
select the password, and paste
in the rule-- in the Password
Rule text field.
Now, let's run Shiny, again.
Okay. I'll tap on Create
Account.
Tap on. I'm going to go ahead
and proceed with the suggested
username.
And at this point, the password
should be compatible with the
rules that I just specified.
Let's proceed with the signup.
And just like that, I'm in.
[ Applause ]
Thank you.
We just saw how easy it is to
make your apps compatible with
Automatic Strong Passwords.
>> Than you, Reza.
As Reza showed you, these are
some steps you can take to
ensure that Automatic Strong
Passwords works in your app.
Make sure to associate your app
with the domain on the Web, just
like filling and saving
passwords.
Make sure to tag your fields
with the username and new
password content types.
Ensure that signup is detected
by checking that when you sign
up for your app the password is
saved.
Most of you will be done after
doing these three things.
However, if your service is not
compatible with Apple's password
generation format you may want
to use some password rules on
your password text field.
To ensure that Automatic Strong
Passwords generates a compatible
password.
By ensuring that Automatic
Strong Passwords works well in
your app, you're setting your
users up for success by
encouraging them to use a strong
unique password in your app.
Some of your apps and services
may use SMS, or security code
sent via SMS to your users.
I'd like to invite Harris to the
stage to discuss how you can
service these codes right in
your app.
[ Applause ]
>> Awesome.
Thank you, very much, Chelsea.
Hello, everyone.
My name is Harris and I am super
stoked to talk to you about
Security Code Autofill.
But first, this section needs a
little bit of audience
participation.
So, show of hands, how many of
you have ever gotten a text
message that looks something
like this?
All right.
I think it's fair to say that
most of us have to deal with
these codes on a fairly regular
basis, these days.
All right.
Question of the second, after
getting one of these text
messages how many of you go
through a process like this?
Where you think you have the
code memorized, you type it in,
you switch the last two digits
around, and then you have to do
it all over, again.
Let me see those hands.
All right.
Final question.
After going through this
process, how many of you feel
something like this?
All right.
So, let me tell you it doesn't
have to be this way.
Because starting in iOS 12 and
macOS Mojave, we're introducing
Security Code Autofill.
A brand new feature which takes
all the pain and frustration out
of message based second factor
flows.
Now, it is important to note
that Security Code Autofill does
not alter the calculus around
the security of second factor
methods.
What it merely does is remove
the indignity out of having to
type the code in yourselves in
the age of computers.
Nothing more, nothing less.
[ Applause ]
So, starting in the new iOS and
macOS, instead of exercising
your memorizing skills you get
to do something like this.
Just one tap, right on the
QuickType bar, and you're signed
in.
And hopefully, at the end of
this process, you feel a little
bit more like this.
All right.
So, let's talk about some
technical details.
As with other Autofill features,
Security Code Autofill will work
in your apps right out of the
box, most of the time.
Still, you can do just a tiny
bit of work to ensure that
Security Code Autofill works
every single time.
We've told you this before but
tag your fields.
In iOS 12 we're introducing a
new UITextContentType with the
value oneTimeCode.
Tag your security code fields
with this and Security Code
Autofill will work every time.
Additionally, it is very
important that you allow usage
of the system keyboard for
inputting these codes.
Tempting as it may be, you
should refrain from building
Bespoke keyboard UI's within
your view hierarchy or setting
custom input views in your
controls.
Because if you do so you are
preventing iOS from surfacing
the necessary UI or injecting
the appropriate events to type
the code in on behalf of your
users.
And additionally, you may be
hampering the experience of
folks that leverage
accessibility technologies like
voiceover.
So, bottom line is let the
system keyboard do the heavy
lifting for you and Security
Code Autofill will work every
time.
Another step that you can take
to ensure that Security Code
Autofill works great with your
service is to craft your text
message, accordingly.
iOS and macOS use data detector
heuristics to infer that an
incoming message carries a
security code.
Specifically, our heuristics are
looking for words like code or
passcode in proximity to the
actual code string.
And you can see a few sample
text messages in different
languages in the slide behind
me.
Now, verifying that your
specially crafted message
properly triggers the iOS and
macOS heuristics is super
simple.
You can be your own best friends
and simply text yourselves.
Then, when you go into the
message transcript and you see
the code being underlined and
tapping the code offers you a
Copy Code option, you know you
have it right.
Security Code Autofill is
available in all supported
locales of iOS and macOS.
And if after following these
best practices you find that you
cannot get Security Code
Autofill to trigger
appropriately inside of your app
or website, please let us know
by filing a bug report.
We'll be looking out for them.
So, so far, we've talked about
getting Security Code Autofill
to work within your native iOS
apps.
Security Code Autofill is also
available in iOS Safari on
websites and, and this is pretty
cool, if your users are signing
into your service in Safari on
their Mac, text message
forwarding securely pushes
incoming messages from their
iPhone to their Mac.
Now, what this means is that
they can fill in a security code
with a single click in Safari's
completion UI.
You no longer have to switch
back to Messages to copy the
code out or, you know, go find
your iPhone all the way across
your home.
It's really cool.
[ Applause ]
To support Security Code
Autofill in Safari, we are
introducing a new input
autocomplete attribute value
one-time-code.
In fact, all of the UI Text
Content Types that you heard
about today have web platform
equivalents that you can
leverage to ensure a smooth
seamless autofill experience in
your websites, just as well as
in your apps.
You've heard this before but tag
your form fields this time and
Autofill will work great every
time.
So, this was a brief
introduction to Security Code
Autofill, a brand new addition
to iOS 12 and macOS Mojave that
takes all the pain and all the
frustration out of message based
second factor flows.
Now, with the Autofill features
that we've introduced today, it
becomes super simple for you to
build a relationship with your
users while safeguarding their
security and respecting their
privacy.
Still, some of you may find that
you have to support federated
authentication flows with third
party providers, such as popular
social networks.
For those of you among the
audience, we are introducing in
iOS 12 a new API to support such
flows.
We call it
ASWebAuthenticationSession and I
would like to show you how it
works.
Now, here I am back in the Shiny
app.
And this time I will choose to
log in with example.com, a super
popular social network.
Now, as soon as I tap the button
the app under the hood calls in
to the new
ASWebAuthenticationSession API.
Now, one of the ways in which
ASWebAuthenticationSession makes
logins faster is by sharing its
underlying cookie storage with
Safari.
Now, of course, before we do any
of this, iOS asks for explicit
user consent.
Upon consenting, the user is
presented with a secure view
controller and guided through
the third party's federated
authentication flow.
In this case, I'm already signed
into example.com in Safari on my
iPhone, so all I have to do is
tap Allow.
There we go.
And with just two taps I've gone
through a full federated
authentication flow with a
third-party service.
So, in the past you may have
used one of the other iOS
platform technologies to
implement federated
authentication inside of your
apps.
Starting with iOS 12,
ASWebAuthenticationSession is
the go-to way to implement such
flows.
As we mentioned, already,
ASWebAuthenticationSession makes
login flows faster by sharing
its underlying cookie storage
with Safari upon explicit user
consent.
Now, what this means is that
depending on the implementation
of the federated authentication
flow by the third party.
If your user is already signed
into that service in Safari on
their device, they may not even
have to see a login form, at
all.
If they do have to see a login
form ASWebAuthenticationSession
supports Password Autofill and
Security Code Autofill to make
the experience as painless as
possible.
And for you developers,
ASWebAuthenticationSession
offers a straightforward
block-based API that makes
adoption super simple.
So, let's take a look at it.
Now, let's see how simple it is
to implement federated
authentication using
ASWebAuthenticationSession.
You're going to start off by
importing the brand new
AuthenticationServices
framework.
And then, you simply define the
oauthURL as it's described to
you by your third-party
authentication provider.
Now, following this you will
create an
ASWebAuthenticationSession
object.
You're passing the oauthURL and
a callback handler that gets
involved at the end of the
authentication session.
Now, it is crucial that you hold
onto a strong reference to the
authentication session object
while the session is in flight.
And by doing so, you also have
the ability to cancel an ongoing
session should you choose to do
so.
Finally, you call the
nonblocking start method.
Upon doing so, first iOS will
ask for user consent to share
the underlying Safari, the
underlying cookie storage that
Safari has with your session.
And then, the user is presented
with a secure view controller
and guided through the
authentication flow.
When the user completes the
authentication flow or if they
cancel out of the authentication
session, your completion handler
gets involved and you can handle
the result.
And that's how simple it is to
implement federated
authentication in iOS 12, using
ASWebAuthenticationSession.
It only takes a few lines of
code.
Starting with iOS 12 this new
API is the go-to way to
implement federated
authentication and it replaces
SFAuthenticationSession.
If you find that you have to
support federated authentication
inside of your apps, we strongly
encourage you to adopt this new
API.
And with that, I'll turn things
over back to Chelsea, to talk to
you about a number of super cool
new password management features
that we built right into iOS 12
and macOS Mojave.
Thank you, very much.
[ Applause ]
>> Thanks, Harris.
I'm really excited to tell you
about some of the new features
that the iCloud Keychain
Password Manager gives you in
iOS 12 and macOS Mojave.
You may have seen some of these
in the State of the Union,
yesterday.
What we've talked about, so far,
is how you can help users log
into and create accounts in your
app.
However, there are some cases
when users will be interacting
with accounts for your app when
they're outside of the context
of your app.
For these cases we've added some
features to the iCloud Keychain
Password Manager to make
managing and interacting with
these accounts a breeze.
If a user needs to look up a
password, they can now simply
ask Siri.
They'll be taken right to their
password after authentication.
This way, they can read off
their password to type into
another device that doesn't have
iCloud Keychain.
Some users may share account
information for services like
utilities.
In order to share this
information, users can now
AirDrop passwords to their
contacts.
On iOS 12 the password list UI
is redesigned so it's more
scannable and delightful to
interact with.
The password list UI in macOS
has been redesigned, as well.
And it looks great.
Another new feature of the
iCloud Keychain Password Manager
is it now warns users if they're
reusing passwords across
multiple websites.
When the user taps on one of
these passwords they'll be given
the option to change their
password on the website.
Automatic Strong Passwords on
the web can help them update to
using a strong unique password
for that service.
The Password Reuse Auditing
feature is built right into the
Safari Passwords List on macOS,
as well.
Last but not least, your tvOS
apps can now offer to autofill
from a nearby iOS device.
[ Applause ]
In order, to learn more about
this incredibly convenient
feature see the Password
Autofill section of the What's
New in tvOS 12 session.
In summary, Autofill is a
powerful platform feature that
helps users interact with
accounts in your apps.
As we discussed, the features
that we talked about today may
work with no changes to your
app, however, it's important
that you test your app with
these new features.
Apply the recommendations that
we discussed today.
If after applying these
recommendations, Autofill is not
working as you'd expect, please
file a bug report.
We'd love to hear from you.
To use the Password Rules
Validation Tool that Reza showed
you during his demo, you can
visit the URL listed here.
Here are some related sessions
you might be interested in.
If you're a developer of a
password manager, see
Implementing Autofill Credential
Provider Extensions.
If you'd like to learn more
about Password Autofill for
apps, see Introducing Password
Autofill for Apps from WWDC
2017.
And if you'd like to talk to us
or you have questions about any
of the content we've covered
today, come to the Safari,
WebKit, and Password Autofill
Lab after this session.
We've also got a couple more,
later in the week.
Thank you, so much, for
attending and have a great WWDC
2018.
[ Applause ]