Good morning.

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 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, 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 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. 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 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. 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 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 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 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. 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. 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 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.

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. 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. 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. 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. 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.

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 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 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. 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. 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 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.

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 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.

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.

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, 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. 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. 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.

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. 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.

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. 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. 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. 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 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.

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. 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. 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 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, 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, 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. 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.

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 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.

Now, I've walk through six different techniques 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. 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.

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. 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.

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." 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. 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 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.