Privacy and Security of our data is something that’s increasingly valuable to us.

While we cannot forget Apple is a large corporation with its legal requirements and was indeed part of the companies supplying the Government Agencies with customer data — just like Google, Microsoft, and many others.

The latest updates to iOS 8 and OS X Yosemite introduce some very welcomed changes to the way Security and Privacy is dealt with on these platforms and may serve as an inspiration for others.

I’ve gathered this information by watching over 17 hours of WWDC 2014 sessions and carefully reviewing, analyzing what was said, and writing a huge number of notes on Security, Privacy, UX and other areas which I will be publishing here in the coming weeks.

As a Designer this post will help you understand how you must deal with topics such as Permissions from now on. I’ve included some technical information for Developers. Entrepreneurs will hopefully understand how Privacy and Security are important to build trust with your consumers, something that’s incredibly hard to regain once lost.

Apple takes advantage of its unique control over hardware, software and services to provide the best security offer in the consumer market as detailedly described in their iOS Security Paper.

But aside from that, they know, and want you to know, their business model isn’t reading and selling your personal information.

These Security and Privacy changes didn’t happen “because it’s a nice thing to do”.

Apple wants to grow their user base to include kids under 13 — this requires them to introduce Family Sharing in order to better comply with the Children’s Online Privacy Protection Act.

They also want to keep growing in Enterprise — that’s where the Secure Enclave, Device Management, Offline-first and a slew of other security measures come in.

Table of Contents

1. Location
2. Camera
3. Contacts
4. Kids
5. Safari
6. Keychain and Authentication
7. HomeKit
8. HealthKit
9. CloudKit
10. Handoff
11. iTunes Connect
12. Advertising Identifier
13. Wi-Fi MAC Address
14. Notifications
15. Extensions
16. Changes to Settings
17. Privacy Best Practices

Location

The location APIs on iOS 8 — provided by Core Location, have been significantly updated in ways that impact both developers and end users.

Summary

1. New “While In Use” Permission Type
2. Location Access Monitoring
3. Mandatory Access Purpose Explanation
4. Technical Details

New “While In Use” Permission Type

Applications should now request a new “While [app is] In Use” permission type when accessing the user’s Location.

An app may upgrade or downgrade the permission type when updated and will display a confirmation prompt as long as the user hasn’t previously denied access.

As a side note: you can now direct the user directly to the applications’s privacy controls in iOS Settings from your app without having to display step-by-step instructions for the user to follow. See “Technical “Details” for this section.

Location Access Monitoring

Apps using “While In Use” permission that continue to access Location when not in the foreground will cause iOS to display a message in a double-height status bar just like when you’re in a call, using Navigation, Personal Hotspot or recording Audio.

Legacy apps running on iOS 8 will automatically be given the “Always” permission type.

iOS will attempt to keep the User informed and in control of apps using the “Always” permission type by displaying an alert when the app isn’t in the foreground. This alert allows the User to either continue allowing or easily revoke Location access.

Mandatory Access Purpose Explanation

Applications must have a very good reason to access Location and make that clear to the user through the provided purpose description text or they will be rejected by the App Store team.

The best thing to do here is to respect the User’s privacy — something that’s mentioned in many WWDC sessions. Rebuilding trust is very hard to do and will negatively impact your business if nothing else.

Technical Details

As mentioned above, adding the (localizable) purpose description string to Info.plist for the permission type you want to use is mandatory for Core Location (and other APIs).

The relevant Info.plist keys:

• NSLocationAlwaysUsageDescription
• NSLocationWhenInUseUsageDescription

Core Location Manager now has 2 new blocking methods that should be called before the monitoring methods (startUpdatingLocation, etc):

• requestAlwaysAuthorization
• requestWhenInUseAuthorization

The “When Is Use” permission does not provide access to:

• Region Monitoring
• Significant Location Change
• Visits API (new)
• Start accessing Location in background
• Background App Refresh

You can link to the new application Privacy screen in iOS Settings app by opening the URL provided by the UIApplicationOpenSettingsURLString constant.

Camera

Camera now requires user consent to be accessed. From a Design perspective, this means we now need to think about when to display the permission alert and provide a mandatory purpose string to go along with the prompt.

Technical Details

The new Camera access purpose string isNSCameraUseDescription.

Current applications will trigger a consent dialog when the camera is accessed and will receive no data until the user grants access.

Contacts

Access to contacts has changed (see Technical Details) and is now optional for situations where you need to pick a single contact such as sharing with or inviting a friend.

This is a great change because it means there’s one or two less reasons to give an app access to your contact list.

Also good to know is that apps will only get a static copy of the contact and won’t have access to future changes as apps with full access do.

The Contacts API now supports filtering the contact list. This is useful to filter out contacts without an email address or any other desired condition.

On the Privacy side, it’s also possible to request only a subset of the contact’s properties as it doesn’t make sense to access phone numbers and addresses when only an email address is required.

Properties can also be filtered by value, allowing you to display people with @apple.com emails.

These filtering methods are good for limiting the amount of information that reaches the app but also to reduce visual clutter of irrelevant properties.

Technical Details

Some methods will be deprecated in future seeds of iOS 8, specifically ABPeoplePickerNavigationControllerDelegate methods:

• peoplePickerNavigationController:shouldContinueAfterSelectingPerson:
• peoplePickerNavigationController:shouldContinueAfterSelectingPerson:property:identifier:

Those methods are being replaced with new ones in ABPeoplePickerNavigationController:

• peoplePickerNavigationController:didSelectPerson:
• peoplePickerNavigationController:didSelectPerson:property:identifier:

Also three new properties for setting NSPredicates and filter the contacts to pick from on:

• predicateForEnablingPerson - determines if a person can be selected or not.
• predicateForSelectionOfPerson - select the whole person or just a property
• predicateForSelectionOfProperty - determines which properties to display

Kids

Apple already provides kids under 13 with special Game Center accounts that only allow canned chat messages, generic screen names, no image sharing, and no ad targeting whatsoever.

Parental Controls are also available, and certain schools can provide Apple IDs to their students that come with sensible defaults such as limited ad tracking.

Now with iOS 8, parents worldwide can create Apple IDs for their kids under 13 as part of Family Sharing.

Family Sharing has UX and Privacy implications and here’s the gist of it:

• Create a Family of Apple IDs
• Share all your Purchases (apps, books, more)
• Ask to Buy — if the children tap buy, the parents will confirm and purchase for them

User Experience Implications

With Ask to Buy, In-App Purchases may take an undetermined amount of time to complete as the parents need to approve the purchase.

This can happen on any app so you need to design for it and either present the purchase status or perhaps only prevent the item being purchased to be used after certain negative balance.

Pickers such as the Contact Picker will display a padlock when restrictions are in place — this can happen because of Enterprise or Parental restrictions.

Remember to handle situations where access is ‘restricted’, in addition to just ‘denied’. This would mean not displaying instructions for enabling access to a feature because the user might not even have permission to do so.

Privacy Implications

On the Privacy side, you’ll get a lot more kids using your apps — wether they’re made for kids or not.

Apps made for Kids need to have a privacy policy, and as a general rule do not collect any kind of Personally Identifiable Information.

The Children’s Online Privacy Protection Act (COPPA) is incredibly strict with what it considers to be Personally Identifiable Information (PII) and you need to have that in mind as even Bluetooth usage is restricted.

The COPPA law applies only to apps where you have actual knowledge the user is under 13. While this is an US law, other countries will soon implement laws modeled after it so if you comply with COPPA it’s likely you’ll comply with others as well.

As a side note: the newly introduced app bundles cannot have mixed general-purpose and Apps for Kids. Also: Ask to Buy or Game Center do not make apps COPPA compliant.

Apps for Kids Best Practices

1. Don’t collect any PII data, avoid:
   • Logins
   • Advertising Identifier and behavioral ads
   • Location, Contacts, Photos, Bluetooth, Microphone, Camera, HealthKit, Social
   • Push Notifications
2. Disable sensitive features based on age.
   • Recording the age and storing it securely (even in iCloud) is okay
   • App must still be usable by under 13 or it will be rejected
3. Verifiable Parental Consent
   • Consult a lawyer
   • tip: use an Age Gate to ask for the parent’s email so they can fill in the required paperwork
   • Parents must be able to review, delete Personally Identifiable Information (PII)
   • Parents must be able to stop PII collection
   • PII must be deleted when no longer in use

Final words on this topic: it might be a good idea to have your Made for Kids app reviewed by a lawyer and remember the legal age changes between countries, a good technique would be to adjust ages based on the current App Store country (which can easily be read using StoreKit).

Safari

Safari for iOS and OS X have received some Privacy updates as well.

Note: it also now blocks ads from automatically redirecting to the App Store without user interaction!

Block Cookies not from Current Website

This means that if you visit foo.com, only that website will have access to read and save cookies. Any other website — inserted via iframe or linked to, won’t have access to even its own Cookies.

Keychain Improvements

Safari now supports the new autocomplete values username, current-password and new-password to better understand the intent of a form.

By better understanding signup, login and password change forms, Safari knows when to provide strong password suggestions, and when to update the stored credentials so they’re available on all of the user’s devices.

It’s a nice balance of both security and convenience.

On iOS 8, native apps can access website credentials stored in the Keychain. So an app like Vimeo could completely bypass the Login form if it detects the user has logged in to Vimeo on a browser that supports Keychain (all except Firefox).

For an app to be able to prompt the user for access to the credentials stored in Keychain, “Domain Pairing” is required and described in Technical Details below.

This obviously works both ways: if a user starts by installing and signing up on the app and them visits the website, the Browser will be able to Autofill the credentials.

Technical Details

Here are some guidelines for declaring the purpose of your forms:

• Signup — username & new-password;
• Login — username & current-password;
• Password change — username (read-only), current-password & new-password.

Domain Pairing

An app can only access Keychain credentials for websites it’s been authorized to access. To sum it up:

1. App Vimeo declares it has access to vimeo.com
2. iOS will attempt to fetch and validate an encrypted file from vimeo.com
3. The file should contain the Vimeo application id

For information on how to encrypt the file, request credentials from your app, and details of how different http status codes might impact this feature watch WWDC 2014 Session 506 titled “Your App, Your Website, and Safari”.

Keychain and Authentication

Keychain is a specialized key-value database for storing and retrieving sensitive data on iOS and OS X.

Apple has made it especially secure on iOS by integrating it with the Secure Enclave — a tamper-proof cryptographic coprocessor that contains encryption keys unique per-device, that are immutable and unknown even to Apple, available on the iPhone 5S/iPad Air/Mini (more details here).

This means that security-wise, you will want to use Keychain to store any kind of sensitive information on both iOS and OS X.

Keychain

Keychain makes it really easy to synchronize items across devices for convenience. Here’s what changed in regards to sharing:

• App Groups allow more flexible sharing between apps from the same developer;
• Share between Apps and Extensions — a Social Sharing widget does not require a separate login from the main app it’s bundled with.

But security is sometimes more important than convenience. Keychain already allows you to prevent items from ever leaving the device or be included in backups, in addition to that:

• Items can be made to require user consent when accessed;
• That consent can be set to Touch ID with the device password as fallback;
• Items can be made inaccessible if passcode is removed.

The safest scenario would require flagging items as device-only, requiring Touch ID for access, and invalidated if passcode is ever removed.

Remember: you can also store any piece of text in Keychain, not just username + password credentials. Apple uses this to synchronize wi-fi credentials between devices so that when you connect your laptop to a network, your phone will be able to as well a few seconds later when synchronization finishes, saving you from entering those long passwords on your phone.

Touch ID

You can now use Touch ID to allow access only to the device owner.

This doesn’t require you to use Keychain, it could be used to replace pin codes in Banking Apps and more. It’s just an extremely quick, simple and secure way to authenticate the owner of the device.

You’re given the freedom to come up with a fallback mechanism for Touch ID if required. You can implement a password, sms code or any other 2-Factor Authentication mechanism.

HomeKit

HomeKit is new in iOS 8, it brings consistency to the Internet of Things market which in turn allows simpler, better experiences to be enjoyed and created.

The problem we have today is how hard it is for devices from different manufacturers to coordinate amongst themselves because they all speak different languages and require different proprietary apps.

This also puts in more strain into the hardware manufacturer which has to invest not only in the basic software needed to run the hardware, but also in creating and maintaining consumer apps. This might lower costs, increasing sales and offer, as a consumer you won’t need to worry about compatibility either.

HomeKit allows you to simply ask Siri to “enable night mode”, which will control (even if away from home) a number of devices from different manufacturers and make sure the doors are locked, specific lights are turned off while others are turned on, cameras start recording and more.

All with a single voice command, without opening any apps, and regardless of the accessory manufacturer.

”We don’t think it’s good enough to be sort of private with your data stored somewhere else, we think it’s important to take privacy very seriously.” — Kevin McLaughlin, Wireless Software Engineering

When it comes to security and privacy, there are 4 key points:

• Data is stored only on your device
• Controls are issued only by your device
• Advanced end-to-end encryption used in communications
• Mandatory Privacy Policy for HomeKit apps

“We take Security and Privacy very seriously, we have spent a lot of time and effort, attention, reviews after reviews making sure that we have a great solution here.” — Kevin McLaughlin, Wireless Software Engineering

Security and Privacy are of the upmost priority in HomeKit, everything from pairing to communication is done securely.

HomeKit implements Perfect Forward Secrecy which isn’t new but a very good practice, HomeKit APIs can only be used in the foreground to ensure it’s the user who is always in control, not some rogue app.

Apps can be notified of changes in accessories such as a door being unlocked and ensure the user is aware of it.

One interesting fact is that in order to bridge the digital and physical, Apple has made the Identify command mandatory as part of all HomeKit accessories. This allows you ask Siri to identify a light bulb and have it flash for example.

I will focus more on the capabilities and vision for HomeKit in a future post, stay tuned!

Technical Details

The best really is to read the documentation, watch WWDC 2014 Session 213 titled “Introducing HomeKit”, check out the dedicated HomeKit page with information for App and Hardware developers.

But here are a few highlights:

• HomeKit APIs can only be used in the foreground to ensure user control
• Built-in Accessory Browser speeds up development
• Use HomeKit Accessory Simulator for simple testing and development
• HomeKit delegate methods are mandatory to ensure Accessory Database consistency
• Apps can subscribe to events such as a specific lightbulb has being turned on
• Items can be grouped into Rooms: “Kitchen”, Zones: “Downstairs”, Services: “Ceiling Lights”, Actions: “Night Mode”
• Actions can be Triggered manually, scheduled, set to repeat and more
• Non-HomeKit devices can be used through HomeKit Bridges
• HomeKit can be extended but Siri only supports the built-in functionality
• Accessories can be reached either via Wi-Fi or Bluetooth LE
• Accessories have Characteristics:
  • read-only: e.g.: current exterior temperature
  • read-write: e.g.: adjust thermostat temperature
  • write-only: mandatory on all accessories, e.g.: identify device

HealthKit

HealthKit is new in iOS 8, it brings consistency, security, privacy to health and fitness data.

Currently, data is fragmented and insecurely stored across multiple apps. The user has no proper ownership or control over it as once the fitness app is removed, so is the data.

Privacy isn’t a current priority, and granular control over how data can be accessed isn’t a standard practice. This is alarming because it’s highly valuable data that can and is likely to be exploited by insurance companies, banks, advertisers in order to profile customers and measure risk.

Just imagine what Facebook can do with behavioral data captured by Moves — an app which gathers the visited locations and fitness data for thousands of Android and iOS users.

While HealthKit is yet another closed silo, one that’s primarily in your pocket, securely encrypted, and where you have a very high level of visibility and control through the built-in front-end: Apple Health for iOS 8.

Quick UX Tip: have HealthKit in mind as a source for the user’s age, height. It can be used to simplify forms or personalize games.

Privacy First

Apple understands consumer trust is a valuable business asset, as a result, its designers and engineers have created HealthKit with privacy as a top priority.

They understand that knowing whether a user has denied access to a particular type of data is valuable information.

HealthKit only lets apps know if the user has been prompted before, it’s not possible to distinguish between a user who has denied access to blood glucose levels and one that has no data of that particular type. This makes fingerprinting of a particular subset of users harder by limiting the amount of information available.

Permissions work on a per-app, per-data type. Apps can be granted write-only, read-only, or read-write and cannot modify or delete data created by other apps. E.g.: a user might use the Health app to see the total calorie count, but use multiple apps to log that data. Individual apps wouldn’t have access to the complete dataset.

As stated above, permissions are very granular, instead of the usual Alert, HealthKit uses an Authorization Sheet that allows control over all of the requested permissions at once, grouped by read and write access types.

A Privacy Policy is mandatory for HealthKit apps and must be visible on the website and App Store page — same with HomeKit, Apps for Kids, Keyboards and more.

Health App

The Health app allows the user to review, manage and control access to every single of the +60 data types, ranging from birthdate to potassium.

This app is also used to manage what information is included in Medical ID.

When configured, Medical ID is accessible from the Emergency Call screen, one swipe away from the Lock Screen Passcode input.

It’s an interesting addition as you can add relevant emergency phone numbers, blood type, organ donor status, allergies and other helpful information accessible to medical personnel without unlocking the device.

Technical Details

Documentation is still very sparse as of Xcode 6 Beta 2, and from what I understood there are no direct implications to privacy, it’s really just about implementation details.

It’s good to note that HealthKit is yet another simple to use API that helps with unit definition, conversion, localization, statistics, storage and retrieval.

Unit Definition and Quantity Conversion

Base and Complex units are defined using the HKUnit class.

Base units are classified into types such as Mass (HKUnit.gramUnit()), Length (KHUnit.meterUnit()), Volume, Energy (HKUnit.jouleUnit()), Temperature (HKUnit.degreeCelsiusUnit()).

Complex units such as grams per deciliter can be defined very easily through a string format such as g/dL.

HKQuantity(unit:HKUnit.meterUnit(), doubleValue: 1.79);

Quantities are created by specifying the Unit and Value as seen above.

Quantity conversion compatibility can be verified using HKQuantity’s meterQuantity.isCompatibleWithUnit(HKUnit.secondUnit()) method.

Localization

The new unit formatters (NSMassFormatter, NSLengthFormatter, NSEnergyFormatter) will handle localization details for you.

E.g. NSMassFormatter.forPersonMassUse = YES will automatically return stones or pounds for United Kingdom and United States respectively, but Kg for the rest of the world.

Storage

All data stored in HealthKit Store (HKHealthStore) is a subclass of an immutable HKObject. The main class offers a way to store a dictionary of metadata and a source, which is inherited by the HKSample and HKCorrelation subclasses.

The correlation (HKCorrelation) object is a set of correlated data samples (HKSample) with shared metadata, and that individually wouldn’t make sense — such as a single heart beat.

Samples can be of Category (immutable, e.g.: birth date) or Quantity type (changes over time, e.g.: steps, potassium, etc).

Data can be made as explicit as “Body Temperature sampled in Fahrenheit using a Braun Ear Thermometer with serial number #1234. Collected value was of 98.8 with sampling starting at 10:00:00 AM and ending at 10:00:10 AM”.

This metadata could enable you to isolate data from defective or less accurate devices based on serial number for example.

Note: HealthKit automatically handles situations where the same data (e.g.: steps) has more than one source. Without de-duplication this scenario would result in a higher step count to be reported.

Retrieval

HealthKit makes it easy to query and subscribe to changes in large datasets. It provides a standard HKQuery, a HKObserverQuery for subscribing to changes, and an HKAnchoredObjectQuery which is essentially a paginated list of results.

The HKObject can be made rich enough to discriminate data sourced from a specific device by filtering, for example, by its serial number.

Statistics

The HKStatistics class helps with gathering basic average, min, max, sums and optionally separate data by source.

The more advanced HKStatisticsCollection and HKStatisticsCollectionQuery allow for defining date ranges, sampling intervals, and other more complex analysis.

CloudKit

CloudKit is Apple’s Backend-as-a-Service, similar to Facebook’s Parse and others, but it provides Accounts and Data Transport, leaving Computing to the device itself, and doesn’t provide Identity.

This is probably the most delicate change to iOS privacy, security and freedom-wise.

Its advantage is how well-integrated it is into Xcode, iTunes Connect, iOS and OS X itself. Like all *Kit frameworks, the objective is allow developers to focus on what makes their apps unique and not think about the groundwork required to even get it running.

That is the selling point, there’s obviously a tradeoff between convenience and lock-in but I’ll focus on Privacy for this post.

Account Privacy

CloudKit does not give Apps access to the real user’s Apple ID or data from other apps, instead, CloudKit creates a Random User ID on a Per-App basis, and there’s no access to private data outside of your app’s CloudKit Drive Container.

Note: CloudKit will create an anonymous, read-only account for users without an Apple ID. These users will only be able to read from the public database, more on that later.

Technically, a malicious publisher can map the CloudKit Random User ID provided to “App A” to a Permanent ID (such as email, Twitter, Facebook, etc) available to “App B” via the Advertising ID — common to all Apps from a single device.

Remember though: the Advertising ID can be reset or disabled by the user, its usage is restricted and needs to be justified as part of the App Store review process.

Having said that, using iAds is justification enough and the existence of Advertising ID isn’t known to everyone — much less that it can be disabled and is on by default for users over 13.

Friend Discovery

Friend discovery is handled by CloudKit. The user can control visibility on a per-app basis, and it avoids the need to share contact details with the App developer.

The only returned information will be the other user’s Random User ID, plus the first and last names.

Discovery works without disclosing any PII (such as email) to the app — CloudKit servers are responsible for user PII and can do the matching internally.

Optionally, CloudKit can perform the discovery via a user-provided email — encrypted by the separate on-device CloudKit process and securely sent over the wire.

Note: iCloud 2-Factor Authentication isn’t mandatory, as a result, most accounts are only secured by regular credentials. People have taken advantage of this before and might do it again as these accounts are increasingly data-rich.

[Update] It seems Apple might enforce 2-Factor Authentication soon as reported by MacRumors.

Data Privacy and Security

Each application has access to one or more CloudKit Containers owned by its publisher.

CloudKit Containers are divided into one Public and one Private database. Database Records may contain structured or bulk data (assets) — without going into detail, this is similar to Core Data.

By default, Public Records can be read by any user, and created by authenticated users, and written to by their creator.

Unauthenticated users — without an iCloud account — can be granted read permissions but they can never create or write to Records to either Public or Private databases.

An app can only access Private Databases owned by the current user.

User records are managed by CloudKit to prevent spoofing. The Private Database will contain a single User Record, while the Public Database will contain many.

Public User Records can be accessed given a known Random User ID but cannot be queried en masse for privacy reasons.

Tech Details

CloudKit is used by Apple to build their new iCloud apps, it’s meant to be a transport technology and not for local storage so Core Data and other solutions are still required.

Quotas

Usage quotas for Public and Private database are handled by the developer and user respectively.

Management

iCloud Dashboard allows developers to manage existing iCloud Containers, new containers and associations are managed in the Developer Dashboard along with App IDs, etc.

Records

CloudKit Records (CKRecords) support all plist property types plusCLLocation which allows for Geo Queries; References (CKReference) and Assets (CKAsset). Their schema is automatically generated during development.

Record Zones

Record Zones allow for custom grouping of records, CKAssets are garbage collected by CloudKit and support for delta uploads, Core Data-like cascade deletes is also included.

Subscriptions

Apps can be notified via APNS of changes to CloudKit Records and Zones. On a related note: apps now have access by default to Content Push Notifications — different from User Push Notifications.

References

Sessions 208 and 231 provide you with all the technical details you need and were used as a source for this section.

Other Sections

Latest update: 2014-06-07 19:02 UTC. I’ll be adding the remaining sections soon.