Transcript
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
>> Good morning.
[ Applause ]
Good very early morning.
My name is Katie Skinner
and I work with teams all
across Apple on user privacy.
This includes iOS, OS X,
iCloud, iWork, iTunes,
and along with David
Stites, David give a wave.
We're going be to talking
about protecting your user's
privacy for the next hour.
I'm going to start out talking
about the part privacy
plays in your reputation.
Then we're going to do an
update on changes coming
to identifiers in iOS 7.
David will talk about
new data types
for data isolation this year,
and for the new developers
in the room, walk
through an example on how
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to take advantage
of data isolation.
Then, I'll finish off talking
about some privacy best
practices, both policies
and some techniques
that you can apply.
So reputation, your users
are your be-all, end-all.
They're your most
important thing.
They're the people
who download your app,
launch your app 2
o'clock in the afternoon
when they're bored at work.
Or alternately stop
launching your app,
even delete it of their device.
So maintaining a good
relationship with them is key,
and privacy is a
big part of that.
In the next hour, we're
going to talking about ways
that you can maintain that
reputation and keep it strong.
So last year WWDC, we talked
about long-lived identifiers.
We talked about the UDID,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and then we introduced
purpose-scoped [phonetic]
replacement APIs.
Now, I will go over the
replacement APIs again,
but first I want
to make a point.
iOS as a platform has
continued to grow.
Apps can and are doing
amazing new things.
They're filling new purposes
that maybe even last year,
we hadn't even thought of.
It's really thanks to
all of you here today
that we really have that.
And as the platform grows,
we feel like a single long-lived
identifier should not be
absorbing all of that growth.
That's why we think
that purpose-scoped
identifiers are the future.
So now, I'm going to go through
the UDID replacement APIs.
There are three, the first one
is the Application Identifier
and it is scoped
per application.
The second is the
Vendor Identifier
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and it scoped per developer.
The third is the Advertising
identifier used for advertising.
Now before we go any further, I
want to clarify the difference
between the UDID and a UUID.
They sound very, very similar.
So a UDID stands for
Unique Device Identifier
and is unique hardware-based
identifier.
Now, the UUID stands for
Universally Unique Identifier
and is unique random identifier.
So, the key takeaway here is
for single device,
there is one UDID.
But on that same device,
there are more UUIDs
on that device than
apps installed.
As I'm sure as many of
you know, as of May 1st,
apps and app updates
that reference
to UDID are no longer being
accepted to the App Store.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
In iOS 7, the API is removed.
If you have an existing
app in the Apps Store
that still references UDID,
it will now be returned
the Vendor Identifier.
So, let's go through
this change to behavior.
Up top, we have what you
would recognize as the UDID.
So in iOS 7, now your old
app will receive a series
of Fs [phonetic] followed
by the Vendor Identifier
with the dashes removed.
So, let's build one.
Here we have the Fs then
the Vendor identifier
without the spaces.
Now, you can see the top value
and the bottom value
are very different.
So, if you have an old app
that references the UDID,
you must test on iOS 7.
Understand the impact
that this has to your app
and insure this will not have
any impact on your users.
If you required changes, once
you test, you can find out
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and then update your app
before iOS 7 hits wide release.
Now, you may have tried
updating your app but it failed
and was rejected from the App
Store due to UDID references.
If this has happened to you,
this slide is are
great reference.
It goes through steps explaining
how you can find the references
within your code.
Now, the most common place
that references are found is
in a third-party library.
So, if this happened to you, go
through these steps, find it,
take it out and then
resubmit to the Apps Store.
Now, the Vendor Identifier
is one
of the purpose-scoped
replacements.
We introduced it in
iOS 6 and it is a UUID.
It provides a device,
unique mapping per team ID.
Now, your team ID, that's
the same as developer
and you can find what your
team ID is on iTunes Connect.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
This mapping is stored
and managed by iOS.
The value will be maintained,
it will stay around as long
as at least one app for
your team ID is installed
on the device.
If all apps are deleted,
this value is also erased.
Now this mapping
table is backed up
but it will not be
restored across devices.
Now, what is restore
across devices mean?
If a user takes the backup on
device one and then installs it
on device two, that's
restoring it across devices.
The most common case of this is
when users purchase a new device
and they want to take their
existing data with them.
Now, I'm going to walk
through an example
that shows a little bit more
clearly what the lifetime
of the Vendor Identifier is.
So, in this case we
have two apps, app one
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and app two for developer foo.
As you can see, they're
currently mapped
to the same value for
identifier for vendor.
So let's delete app one.
There is no change to
the mapping for app two.
But let's say the user
decides to delete app two.
Now, the value for vendor
identifier is also erased.
If the user decides they
want to reinstall app two,
they like it now, then
a new value is created.
And any further apps for that
developer will now be mapped
to the new value.
The advertising identifier is a
second one of the replacements.
It's used for advertising.
Note, you may not handle the
advertising identifier yourself.
It may be handled by a
third party ad library.
But if you do any advertising
yourself within your app,
you must check the value
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of limit ad tracking
before using the
Advertising Identifier.
If the value is set no, you
can only use the Advertising
Identifier for the
reasons outlined
in the Program License
Agreement.
Now, these include things
like frequency capping,
estimating the total
number of unique users.
This value is backed up,
but it will not be
restored across devices.
New in iOS 7, Limit
Ad Tracking is moving
under Settings Privacy.
It can also now be
controlled by restrictions.
And David will talk more
later more about restrictions.
Remember do not cache the
Advertising Identifier
as it can be reset by users
using the Reset button
in advertising.
Now this slide is
a good reference.
If you're trying to understand
what are the differences
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
between the identifiers, maybe
compare scope or lifetime.
This is a great tool, a
great slide to look at later
to understand more clearly.
So now, I'm going through
a couple other changes
in iOS coming to identifiers.
The first one is
the MAC address.
Access the MAC, the device's MAC
address will now be restricted.
The API is not being
deprecated but sysclt
and ioclt will now
return a consistent value
across all devices.
And this applies
to existing apps.
If you use the MAC address
today, make sure to test
on iOS 7 and understand
the impact to your users.
gethostuuid() is
removed in iOS 7.
Existing apps will receive
the Vendor Identifier.
In iOS 7, push tokens are
now scoped per application.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The Push token was never
guaranteed to be a stable value.
So please, do never,
never cache it.
Always use the value provided
application:didRegisterFor
RemoteNotifications
WithDeviceToken:.
So, the Pasteboard in iOS 7 is
also being scoped per team ID.
There's no change to
existing system Pasteboards.
But also note in iOS
7 any data stored
on the Pasteboard
will be inaccessible
when users upgrades to iOS 7.
Now, I've gone through a
whole bunch different updates
to identifiers and new changes.
But what I want to leave you
with in this section is
make sure to test your apps
on iOS 7 especially
your older apps.
You want to understand the
impact and insure that none
of that impact affects
your users.
Now, I'm going to
pass it over to David
to talk more about
data isolation.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
David? [Applause]
>> Okay. Thanks Katie.
So I'm going to take you
guys through data isolation,
what it is and how you
can take advantage of it?
So, just like any
successful peanut butter
and jelly sandwich, there
are two key ingredients,
peanut butter and jelly.
And similarly in any successful
data isolation scheme,
there are two key elements,
consent and transparency.
So, what do I mean by that?
Well, consent is something
that the user is going
to give to your application.
It's usually permission
to do something
such as accessing their
user data classes.
In this particular example,
we see that Camera would
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
like to access your location
so that it can geotag
photos and videos.
Transparency is the
other key ingredient.
It makes it clear to
the user what is going
to happen with their data.
It helps create clear
mental models for the user
to understand and also
sets expectations.
Here, we can see that there's
a purpose string that explains
that photos and videos will
be tagged with the location
that they were taken,
potentially,
so that we can display
them on a map perhaps.
So you should be thinking
about both these concepts--
transparency and consent
when you're designing
your applications.
Now, we've made this easy
and consistent for you
by building it in to
the operating system.
So, those of you who are not
familiar with data isolation,
it's a technical design where by
the operating system intervenes
between an application
and the user's data
on behalf of the user.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
While this intervention
happens completely outside
of the address space
of your process,
it's completely transparent
to your application.
So, if the user decides to allow
you access their user data then
you will receive data back.
And if a user declines
to allow you access,
then you won't receive
any data back.
So, this screen should look
somewhat familiar to you.
This is how you manage your data
isolation on both iOS and OS X.
And you get there on iOS by
going to Settings Privacy
and then choosing the category
that you want to manage
and on OS X on System
Preferences and going
to Security and Privacy.
So, there's a number of classes
that we support already on OS X
and we're adding some new
support in OS X Mavericks.
In Mountain Lion we supported
Contacts and Location
and in Mavericks we're adding
Calendars and Reminders.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
On the social side of things
for OS X, we're adding support
for LinkedIn and Tencent Weibo.
And for those of you who are
not familiar with Tencent Weibo,
it's a microblogging
service in China.
We support all of the same
data classes that we do on OS X
with the addition of some such
as Photos and Bluetooth on iOS.
And in iOS 7 we're going to be
adding two new data classes,
Microphone and Camera
in some regions only.
And for the social
side of things in iOS,
we support all the same classes
as OS X, Facebook, Twitter,
Sina Weibo, and we're adding
support for Tencent Weibo.
So, you're already shipping on
either Mountain Lion or iOS 6,
that's great, congratulations.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You're already taking
advantage of data isolation.
So, as before on iOS 6, this
data isolation will apply
to all existing applications,
there's absolutely no need
to recompile or resubmit your
application to the App Store.
You're going to be ready
from a data isolation
perspective on day one.
However, there are certain
changes you can make
to improve the user experience.
For example, you can add purpose
strings to your application
which we'll talk about
later to make it clear
to the user why you want
to access their user data.
Also, you can design a robust
fallback behavior in the case
that the user declines
to give you access
to their personal data.
So, let's talk about
privacy support in OS X.
It's really easy to get consent
from the user and all you have
to do is call the
purpose-specific APIs
that have been provided to you.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, as I said before you should
already been getting consent
from your user.
We've just made this easier and
consistent for you as an aid
to you by building it
into the operating system.
Now, note that calls on
OS X are synchronous.
So, you're going to
want to wrap them
in a dispatch block using GCD
or put them in NSOperation
to keep UI responsive so
that you can update the user.
Note that after the user
makes their initial choice,
all of the calls will
return immediately
because there's no
reason to block.
The user's already made
their decision as far
as what they want to
allow you to access.
As I said before, if the user
wants to grant you access
to the particular data
category, then you're going
to receive a populated
object back.
If the user decides
to not allow access
to a particular data category,
then you're either going
to get a nil value back
or an empty object.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And for applications that
access systems services
such as AppleScript or
Spotlight to get to user data,
then the operating system will
prompt on behalf of the user
when your application
uses those services.
[ Pause ]
On OS X, applications can
participate in the App Sandbox.
And if you're shipping on the
Mac App Store, you're required
to participate in
the Apps Sandbox.
So, for those of you
who are unfamiliar
with what the App Sandbox
is, is a security design
that isolates your process
from other processes
and the operating system.
Typically, this Sandbox
processes have a tight set
of restrictions on the set of
resources that they can access.
For example, if the address book
is initially outside the Sandbox
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for your process then you
won't be able to access it.
So, if you're going to
ship on the Mac App Store,
there's an additional set of
things that you're going to have
to do to get these
consent dialogs to show up.
And we'll talk about that in
a second that all you have
to do is add entitlements
to your application.
Now, if the permission set ever
changes for your application,
you'll be notified and the
OS may kill your application.
Now, the reason I say, "May", is
because it's the user's choice.
They can either decide to kill
the application immediately
or they can wait
until a later point.
This is to keep the
App Sandbox consistent
with the user's desires for
what in-application can access
as far as their user data.
So, the last point
I want to make is
that you should only build
with the entitlements
that you absolutely need.
This goes to least privilege.
You shouldn't be collecting
data or accessing data
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that you don't truly need.
So, as I said before,
it's very easy
to add entitlements on OS X.
All you have to do is select
the target, go to capabilities,
and turn the App Sandbox on.
And then from there, you
can add the categories
that you want to access.
This particular example is
accessing Contacts and Calendar.
Now really, the UI for
this is simply a front-end
for editing the
entitlements.plist.
So, if you want to not use
the UI, you can always choose
to edit the plist
manually if you desire.
You can find more
information about this
on the Developer Center.
So now that we've talked about
OS X, let's talk about iOS.
So there are numbers
of similarities
and a few differences
on iOS from OS X.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
On iOS, applications are built
on top of the App Sandbox.
So therefore, participation
in it is obligatory
and you do not need to add
entitlements as you did on OS X.
However, unlike OS X, if the
permission set ever changes,
then the OS will immediately
kill your application,
there is no choice.
Also access to these APIs
are asynchronous on iOS
so the consent dialog will
be presented to the user,
and then synchronously return
and the permission
will come later
and data is usually returned
to either a delegate
or a block method.
On iOS, you can register for
Background Change Notifications.
And before the OS
kills your application,
it will call these
change notifications
and you can handle the
change appropriately.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And honestly, this
was a good idea anyway
because when you're working with
user data that sync with iCloud
such as Contacts,
Calendars, Remainders,
that data can be shifting
out from underneath you
as the user could potentially
change them on other devices.
So, it's always good to register
for those change notifications.
So, there are number
of different ways you can
present these consent dialogs
to the user.
Both of these are
applicable on iOS and OS X.
For CLLocationManager, we can
simply trigger the Consent Alert
by calling
startUpdatingLocation.
Differently, we can trigger
Consent Alert for EKEventStore
by calling requestAccessTo
EntityType:completion.
I've highlighted
these APIs in yellow
because they represent
the difference
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
between iOS 6 and iOS 7.
You can find this
later on either
on the Dev Center
or on the slide.
So, now that we've talked
about all the different APIs,
let's actually take
you through some codes
since that's what you guys
build your business off of.
So we can see that access to
AVAudioSession is now managed
by the OS and all we have
to do is alloc init a
particular AV audio session.
And when we set the
category of the audio session
that is what's going to
present the dialog to the user.
The two categories
they're going to present,
the dialog to the user, are
AVAudioSessionCategoryRecord
and AVAudioSession
CategoryPlayAndRecord.
Now, if the user declines
to give you access to this,
then your audio stream is going
to be filled with all zeros
or essentially silence.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Another way to trigger the
consent dialog is calling
requestRecordPermission:.
This will allow you
to request consent
from the user ahead of time.
Now, I've shown you two very
different ways attributed
in a consent dialog.
What's the difference?
Well, consider VoIP application.
The wrong time to be
prompting the user
for consent is the first time
that application is
making an outgoing call
or having an incoming call.
The user doesn't want to have to
deal with consent at that point
so you may wish to request
permission from the user ahead
of time using
requestRecordPermission:.
Some apps may like the Set
Category Method better.
I wanted to make a quick
point about routing
because all routes lead to the
microphone and consent dialogs.
So, for those of you
who are interfacing
with external hardware, then
all of the different routes
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that you can interface with
such as the headphones,
the internal mic, and
the lightning connector
and even Bluetooth are going
to trigger that consent dialog.
[ Pause ]
In addition, we've added
support for Tencent Weibo.
So, all we're going to have
to do is alloc init
in account store.
And then we're going
to request access
to the Tencent Weibo account
by calling requestAccessTo
AccountWithType:.
And then the access level will
be returned in a block and the--
we will grant it and even you
can handle either accessing the
account or displaying
a failure to the user.
Note that all ACAccountType's
support the accessGranted:
selector so that you can
test your access levels
and display UI to the user
before you request access.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So how do we test all this?
It's a lot of information.
Well, it's really
easy to test it.
All you have to do is run
your app, pretty easy, huh?
Note that there's no data
isolation currently supported
on the simulator,
however, it is coming
in a future seed of iOS 7.
So, until then, you need
to test on your device.
Note that you can only trigger
the Consent Prompt one time
so if you need to go back and
test this again, you either need
to go to-- on iOS, you need to
go to Settings, General Reset,
Reset Location in Privacy
or in OS X use tccutil
from the command line to reset
that particular data class.
You can also toggle
the switches yourself
to test how your application
will respond in Settings,
Privacy on iOS and
System Preferences,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Security and Privacy.
That you should consider all
of the possible test cases
maybe even build them
into your test suite so you
don't ship any regressions.
There are four different
test cases.
The first one is Permission
Being Sought and Denied.
The second is Permission
Being Sought and Granted.
Third is Permission
Previously Denied.
And the last one is
Permission Restricted.
Now, Permission Restricted
is unique and we'll talk
about that in a second.
So up until this point,
we've been fairly optimistic
and assumed that user will grant
you access to their user data.
That's not always the case and
you should be prepared for that.
So, in some cases such as
when you're using the
UIImagePickerController
or the AddressBook Picker, the
OS will actually help you out
and display a lock page
to the user to remind them
that they have previous
revoked access
to that particular data class.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
However, just because
the OS can help you out,
it doesn't mean you
should rely on it
for all the different cases.
You should design a
rich fallback behavior.
Try and keep the user
engaged as much as possible.
Your code should be resilient
to the lack of data returned.
One note I want to
make about this is
that restrictions can
actually prevent users
from changing their
Privacy Settings.
They may actually be
unable to give you access.
So, your fallback behavior
should not be a dialog
that says, "Go flip the switch"
because they won't be able to.
An example of these
restrictions includes enterprise
configuration profiles, as
well as on-device restrictions.
So, it's really easy to test
your code with restrictions.
All you have to do is go to
Settings, General Restrictions
on iOS and from there you
can set up the restrictions
and whatever you'd like to test.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So now that we've talked about
what data isolation, what it is?
How to take advantage of it?
And what's new on iOS and OS X?
Let's talk about how we
convey purpose to the user.
[ Pause ]
So, there are two points
that I want to make.
The first is that we
call these dialogs,
these consent alerts
just-in-time alerts.
This is a key differentiating
feature of our platform
and we believe that
we're truly better
at this than other platforms.
These consent alerts are
only shown to the user
at the exact time when the data
access is occurring not before.
This helps to clarify the
"when" in the user's mind.
It's the least intrusive.
I'm sure we've all
used the applications
that presented a
conga line of alerts
when you start up
the application.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So consider your user interface
and you should delay asking
for the user's permission,
as long as, possible.
The second point that I
want to make about this is
that you should only be
asking the user for permission
to access the data classes
that you truly need.
If the user is confused
about why a particular
application needs to access
to a particular data class, then
they're more likely to question,
"Well, why does this
application need that,"
and potentially disengaged with
your applications as Katie said.
So to help you answer the, "Why
an application needs access
to a particular data class?"
We've given you a dedicated
space to tell the users.
Consider this your value
proposition of telling the user,
how allowing you access
to the particular data category
will enhance their experience.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
For example, in this particular
slide, we see that Camera would
like to access location so that
we can geotag photos and videos
with the current location,
perhaps to display
it on the map.
Also, for Aperture, we
can see that it wants
to access our Contacts so that
as we're using the Faces feature
in Aperture, it can suggest
contacts that we know.
So, each consent dialog
supports purpose strings.
However, you can only have one
purpose string per data class.
Now, you guys are
going to be coming
up with the purpose
strings and they're optional
but they're highly recommended
because it makes it
extremely transparent
to the user why you want to
access a particular data class.
For those of you who are
shipping internationally,
you can localize your purpose
strings for your native users
by simply putting the purpose
string in localizable.strings.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And to add this purpose
strings, it couldn't be easier.
All you have to do is use Xcode
and edit the Info.plist and look
for the "Privacy -" whatever
data class you want to access.
So, we can see here,
I have an application,
Restaurant application,
and we're telling the user
that we want to access
their Calendars
so that we can put their
restaurant reservations
on there.
We want to access
their contacts.
We can automatically add
their name to the reservation.
We want to access their photos
so they can upload all
those great pictures of food
that they ate after they
complete the reservation.
And note that just like
before with the Entitlements,
the Xcode UI is simply a
front-end for the info.plist.
So, you could always edit
that info.plist manually
if you so choose.
Here are all the different
purpose string keys
that we support.
Some of these are iOS only.
So, make sure you pay
attention to that.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You can always find this
information again in the slides
or on the Dev Center
after this talk.
We have some great sample
code out there for iOS.
It's available today and you can
find it on the Developer Center,
just search for PrivacyPrompts
Project
or you could find the link
in the related materials
at the end of this talk.
Use it in your app, go ahead,
or just experiment see with--
to see what it happens and
how you use data isolation.
So, there are some key points
that I want to live you
at before Katie comes back.
The first thing is, build
privacy into your application.
Spend as much time
thinking about privacy
as you do other aspects of
your application such as colors
or what animations you're going
to be presenting to the user.
Start today.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
After this talk, spend one
hour adjusting your application
to use purpose strings.
In fact, we're having a lab.
Right after this talk at 10:15,
down in Core OS,
Lab A, come to it.
We'll help you out.
We'll answer your questions.
There are three new data
categories for data isolation
on iOS on OS X, Microphone,
Tencent Weibo,
and Camera in some reasons only.
Note that data isolation
applies to all
of Apple's platforms
both iOS in OS X.
have you-- if you're shipping
in the Mac App Store for OS X,
there's additional work that
you're going to have to do
to get those consent
dialogs to show up.
And remember that purpose
strings are your friends.
They help explain
the value proposition
to the user making them
more likely to engage
with your application.
And then lastly, make sure you
understand all the implications
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of data isolation
on iOS 7, OS X.
So, test your app thoroughly.
So, with that, I'm going to give
it back to Katie to take you
through some privacy
best practices.
[Applause]
>> Thanks David.
So, now we're going
to finish off talking
about some privacy best
practices that you can apply
to help maintain
trust with your users.
We're going to touch on
transparency, control,
talk about and walkthrough
examples
for applying data
collection techniques.
Talk about fingerprinting and
the built-in tools you can use
to apply data protection.
So, we're going to
start with transparency.
What is that?
Transparency is being clear
to your users what is actually
going on, what's happening.
One way that you can do this is
if you collect data then
show that to your users.
Allow them a way to
examine what the data is.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Your privacy policy is another
great way to be transparent
and privacy policies
are very important.
Your privacy policy should
include what data you plan
to collect, what you plan to do
with that data, and if you plan
to share with any third parties.
We make it easy to make your
privacy policy available
for users.
You can submit your
link in iTunes Connect
and then it will
automatically show up across all
of the App Store clients.
So, here is iTunes Connect
and you can enter your
URL right underneath the
description section.
Then, automatically it'll show
up across all App Store
clients on the Details pane.
So, David talked a lot about
control and there's two pieces
that I just want to
quickly highlight.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
When you're asking for
permission do it in context
and do it at the
time you need it.
This is the best way to drive
engagement with your users,
when they clearly
understand what's happening
and they feel in control.
So, data collection is a great
tool to improve your app.
It's very powerful.
Understand what your usage
pattern is for users.
What are your popular features.
Where users running into
issues, errors, crashing.
But all data collection
should be decision driven.
You should have an engineering
or business decision that made
from the data you collect.
As soon as the data
flows in, you'll be able
to make that decision.
I really feel like
data collection,
all data collection impacts
privacy to a certain extent.
Now, this doesn't mean
that I think all data
collection is bad.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But you should weigh the
positives and the risks
and make sure that
they balance out.
So, we've all heard about
data breaches in our industry
and you want to make sure
that the data that you collect
if released you have a solid
explanation of what you're going
to do with that data and
how it improves your app
for your users.
If not, that will only
further impact your reputation.
So now, the first
technique we're going
to apply, its anonymization.
This is removing traces
that will tie this log
back to the originator.
So, here we have a log
for an illegal token
and you can see we
have a path in it.
Now, paths are very,
very sensitive.
We've have a proposed user
name, Johnny Appleseed a neat --
code name, Project Zanzibar.
And we know that
something is happening
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for Project Zanzibar probably
in this financial year.
So, what's the first
thing we should do?
Remove the path.
But file names can still
contain a lot of user data.
People put their names in
it and even code names.
So, what's much better is to
eliminate all user strings.
Only log the type of file that
this error happened within.
It gives you enough information
to be able to track down
and start debugging without
deanonymizing the log.
The second one is aggregation,
and this is grouping together
different logs over time.
You can do this over different
time periods 24 hours a week.
So, let's start out with the
same log that we had last time.
Now, we have grouped it together
under keynote file
errors and others.
So here we still have the
ability to see trends,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
understand the frequency,
but without having
all of the raw events.
Sampling is another technique.
This is only gathering, logging
a portion of either the events
or gathering data from only
a portion of your users.
So, let's start out with
the log that we deanonymize.
What would be better,
log from only 1 in 10,
1 in 100, 1 in 10,000 machines.
Now here, we still
have the distribution
so we can still make
conclusions.
But we don't need to collect
data from every single user.
So, depending on the
decision that is driving you
to collect this data, you
also may be able to collect 1
in 10, 1 in 100 events.
This makes it so you don't
have a complete picture
for a single user.
You still have the
same amount of data,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you'll still have
your distribution
but you eliminate
the full picture.
Deresolution is a technique
that eliminates the number
of significant figures you can
apply it mostly to time, size,
and a duration metrics.
So, here we have a full
timestamp and a size
and it looks pretty anonymous.
If I look at this I think,
pretty good, but the things
to think about is if I have
logged this type of information
on the client and this type
of information on the server.
By recombining the two we may
be deanonymizing our client logs
that we worked so hard, applied
other techniques to deanonymize.
So, what should we do?
Let's eliminate minutes,
let's eliminate seconds,
and bucket at the size.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But you can do this
in multiple times.
We can go one further.
Let's say the decision
we're trying
to understand is how much
data is being processed
on which day is.
I want to make sure that
our service don't go
down on Fridays versus Sundays.
So, it may not be important to
know this happened to May 4th
but watch the trend of
how much data is processed
on a Friday versus a Sunday.
[ Pause ]
The next technique is decay
and this applying
deresolution over time.
Now, you may have someone
on your team that says, "No,
we can't deres the data.
I need the full timestamp.
I need the full size.
I need to be able to track
down this individual
transaction or event.
Usually, this is because of
security or fraud reasons.
But just because you have a
need for this type of resolution
on day one does not
mean on the day seven
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that you have the same need.
You can apply deresolution
over time.
So, first let's take this
over seven days later.
We're going to eliminate
the timestamp fully.
So, you can do this
more than once.
You can do this after
three months, six months,
a year and you can do it
multiple times on the same file.
So, here after 30 days now we've
eliminated the full date time.
So, I've talked a lot about what
decision is driving the data
and how that helps you choose
what collection technique
to apply.
But if you ask yourself
the question,
why am I collecting this
data and you can think
of a good answer or
maybe you say, "Oh,
I think it'd be really
interesting."
Then the best thing to do is
to not collect the data at all.
[ Pause ]
Now, I've walk through
six different techniques
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that you can apply and you can
apply them all on the same log.
But there are tools in
your tool belt to use
and to apply throughout.
So, this is the things
you should think
about when you're adding
new logging, new features
or take a look back at the
logging you already have
and think which of these can
I use and apply to there.
So, fingerprinting is something
that's coming up more and more
in the news and what is it, what
do they mean by fingerprinting?
This is one of the
large collection
of fairly static
metrics are collected
and then it can form a
unique persistent fingerprint
and this will identify
a specific device.
This doesn't need to contain
any personal information
and it can be done accidentally.
A lot of times, this can
be done when you're trying
to understand, "What
is the configuration
that most users have set up?"
Things like timestamps or what
libraries are in his phone.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But the key thing here is,
you need to apply the
techniques I mentioned to try
and eliminate this risk.
Especially deresolution
is a great one to use
because as the buckets
get bigger,
makes it a smaller chance to
any user will have a unique set
of data across all of
your data collection.
[ Pause ]
So, you're users have trusted
you with a lot of data.
They may have given you their
name or many other things
and it's important to use the
tools that we provide in the OS
to help protect that data.
So, first thing is
application credentials.
You should always be
storing them in the keychain.
Think twice whether you
synchronize the credentials
across devices.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Do you really need to?
Encrypt your traffic.
Use SSL/TLS and really
on this one it's time.
Also, when you're
storing data on disk,
use the built-in
data protection.
There's a great talk
from last year,
Session 706 called
Protecting User's Data
that walks you clearly
through the steps of how
to apply data protection.
[ Pause ]
So, these policies
and techniques
that I mentioned
are all great ways
and great things you can
apply to help maintain
that relationship
with your users.
There are more that we didn't
get today like privacy by design
and there'll be a link in
the more information section
that can point you
to more of these.
But I want to leave you
with one last thing.
It's just an easy trick I use.
I call it "the parent
or grandparent test."
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
If I explain in clear language
to my grandmother, what's going
on and why that behavior
is happening.
If she nods, and has understand?
Then good, we're
on the right road.
But if she doesn't
understand, looks confused,
or gives me a not great look
then that's the time to go back,
look at these policies that I
mentioned and apply them again.
So, since its Friday, all the
related sessions have already
happened so, these are
great talks for you
to go look online and watch.
The first one is Protecting
Secrets with the Keychain.
And the second one
is A Practical Guide
to the App Sandbox.
Also, the one I just mentioned
about data protection.
So, if you think of
a question later,
Paul Danbold is a
great resource.
He'll point you or your
questions to the right place.
Also, David created some great
sample code, go check it out.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Use it. Learn from it.
There's also more documentation
under the programming guide
that you can find to
understand more about privacy
and you can dive-in deeper.
You can always find
great information
on Apple Developer Forums.
Now, I know we talked
about a whole bunch
of different things today.
Identifiers, purpose
strings, data protection.
But I want leave you with a
few clear actions to go do.
Test on iOS 7, especially if
you have an app in the App Store
that is several years old.
You want to understand and sure
that you do not have
the user impact.
Test all cases.
Also add purpose strings.
And if you've have not
already added a link
to your privacy policy,
please go add it.
All of your collection should
be driven by decisions.
And lastly, maintain
your relationship
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and strengthen your relationship
with your users by thinking
through privacy implications
throughout everywhere
in your design.
Now, thank you very much both
on behalf of me and David
and have a great rest of WWDC.
[ Applause ]