Today’s smartphones and wearable devices collect overwhelming amounts of data about the user’s health. Health information including the user’s daily activities, workouts, medical conditions, body measurements and many other types of information is undoubtedly one of the most sensitive types of data. Yet, smartphone users are lenient to trust this highly sensitive information to other parties. In this research, we’ll figure out how Apple and Google as two major mobile OS manufacturers collect, store, process and secure health data. We’ll analyze Apple Health and Google Fit, research what information they store in the cloud, learn how to extract the data. We’ll also analyze how both companies secure health information and how much of that data is available to third parties.

Apple Health: the All-in-One Health App

The Apple Health app made its appearance in 2014 with the release of iOS 8. Since then, Apple Health is pre-installed on all iPhones.

Apple Health keeps working in background, collecting information about the user’s activities using the phone’s low-energy sensors.

In addition to low-energy sensors built into modern iPhone devices, Apple offers a range of companion devices that can collect additional information about the user’s health and activities. This information may include heart rate measurements, frequent and precise samples of location information (GPS), as well as specific data (fall detection, ECG).

Apple Health users are greeted with the following four data categories:

• Activity shows much the user moves. Walks, workouts etc. can be shown here. Fed with iPhone low-energy sensors, Apple Watch, third-party fitness trackers and apps.
• Nutrition helps counting carbs, calories, caffeine and other important nutritional metrics. Fed via third-party apps (e.g. logs and diaries).
• Sleep analyzes the user’s sleep routine. Fed via Bedtime feature in the Clock app, third-party sleep apps and accessories.
• Mindfulness is fed via the Breathe app on Apple Watch as well as third-party apps. As mobile specialists specializing in mobile forensics, we fail to fully understand the meaning of this category. It does not appear that iOS 11 and iOS 12 developers are fully utilizing this feature.

As one can see, the data is collected from multiple sources ranging from third-party apps and energy-efficient sensors of the iPhone itself to various companion devices such as the Apple Watch and third-party fitness trackers through HealthKit. Users must give their explicit permission to allow third-party apps providing and/or reading information through HealthKit, which carries its own implications.

The Apple Health app recommends one or more third-party app for each data category, including the Strava app (more on that later).

There are also several extended categories including:

• Body Measurements – the user’s height and weight
• Health Records – medical records and CDA documents
• Heart – blood pressure and heartbeat measurements
• Reproductive Health – data about menstrual cycles and the work of the user’s reproductive system
• Results – lab test results (e.g. sugar level)
• Vitals – vital parameters such as blood pressure, body temperature, breathing, heartbeat etc.
• Medical ID – the user’s medical data (e.g. blood type)

Obviously, almost none of the data can be provided by the iPhone alone, or a combination of the iPhone and Apple Watch (or third-party health tracker). The rest of the data is sourced from third-party apps (e.g. menstrual cycle diaries) or received from participating medical facilities in Clinical Document Architecture (CDA) format.

The CDA architecture is based on the XML standard. CDA documents can be imported into the Apple Health app and stored as Health Records. The CDA architecture is supported by participating medical facilities in the USA, UK and Australia.

Data protection laws in most countries treat users’ medical data as highly sensitive information. The collection, processing and use of the data (including storage, alteration, transmission, blockage and deletion) is only permitted within the framework of the law – or if the user consented otherwise after being given the relevant prior information. Apple obtains the users’ consent to collect, store and share information, including iCloud sync and sharing with select third parties. The user must give their explicit permission to enable third party apps access parts of Health data. By default, no access is permitted.

Starting with iOS 11, Apple implemented health data sync with iCloud. In iOS 11, Health Records could only contain CDA records, which were not synced with iCloud. Other types of data (including activities, sleep, nutrition, mindfulness etc.) would sync with iCloud in exactly the same manner as other types of synchronized data such as pictures or contacts. There were no additional protection.

Protection of Health data in iCloud: iOS 11

1. To access synced Health data, one only needs the user’s Apple ID, password and 2FA code.
2. Apple has technical ability to access Health data in iCloud.
3. Health data is provided when serving government requests.
4. Health data is provided when serving GDPR requests.
5. Finally, third-party apps such as Elcomsoft Phone Breaker can extract Health data.

Protection of Health data in iCloud: iOS 12

iOS 12 implements a different approach to protecting Health data in iCloud, employing secure encryption with a key stored in iCloud Keychain. The actual data is now stored in a different (encrypted) container compared to iOS 11. Interestingly, the old (unencrypted) container could remain available for quite a while even after the user updates to iOS 12.

The encryption key is protected with the user’s passcode (screen lock password or system password) of a device already participating in Health sync. This means Apple cannot decrypt Health data (or the iCloud Keychain if that matters) stored in the cloud. We consider this protection mechanism to deliver sufficient security.

In order to access Health data synced with iCloud by devices running iOS 12 and newer, one needs all of the following:

1. The user’s Apple ID and password
2. One-time 2FA code (there will be no iCloud sync without 2FA)
3. Passcode or system password to a device already enrolled in Health iCloud sync

Consecutively, the following access restrictions apply:

1. A typical user will have no problems syncing Health with iCloud. When initializing a new iPhone to receive synced Health data, they just need to provide their screen lock password code to their old iPhone (or any device that has iCloud Keychain enabled including Mac computers).
2. Apple does not have access to synced Health data. Even if the data is stored on Apple servers, Apple cannot decrypt it.
3. Apple will not provide Health data when serving government requests or GDPR requests.
4. Extraction with third-party apps is restricted yet still possible (Elcomsoft Phone Breaker).

Where Apple Health Stores Information

iOS devices have Apple Health stored at /private/var/mobile/Library/Health/. In iTunes backups, the data is available at /HealthDomain/Health/.

The folder contains two SQLite databases: healthdb.sqlite and healthdb_secure.sqlite. The two databases contain all information collected or received by the Health app with one exception. There is also a separate encrypted database healthdb_secure.hfd. We are not sure about its exact content, but believe it might be storing the user’s GPS coordinates collected during workouts.

The healthdb.sqlite database contains information about the data sources. The healthdb_secure.sqlite database stores the majority of data with frequent references to the first database.

Apple Health can synchronize information with other devices through iCloud. It synchronizes information collected by the Apple Health app, including data received from HealthKit compliant devices and third-party apps. As far as we know, CDA records are not synchronized with the cloud. The device-specific Medial ID is also not synchronized.

If the user permitted third party apps to access Apple Health, those apps may upload the data into their own cloud services (e.g. Strava, Endomondo and many other apps).

Apple enabled Health cloud sync in iOS 11, while earlier versions of iOS store Health data exclusively on devices. We mentioned earlier that iOS 11 does not offer any additional protection to Health data over other types of synchronized information such as the user’s call logs or contacts. This, however, does not mean that the data is completely unprotected. Apple iCloud uses a number of servers from several different companies including Amazon, Microsoft, and AT&T. For Chinese customers, Apple utilizes servers managed by a government-owned Chinese company. This, however, does not mean that Amazon, Microsoft or the Chinese government have access to the data. All information stored in iCloud is encrypted. While the data might be stored on third-party servers, all encryption keys are stored on Apple premises in Cupertino. Consecutively, Apple has physical access to the encryption key, and can therefore decrypt (most) data. This is fully applicable to any Health information synchronized by iOS 11.

When working on iOS 12, Apple recognized the importance and sensitivity of Health data, and added an extra protection layer. To ensure backwards compatibility with iOS 12, previously synced Healt information is kept in iCloud in its original container. Any data collected by Apple Health on iOS 12 devices is sent to a new container. The new container is securely encrypted (in addition to regular iCloud data encryption). The encryption key is stored in the user’s iCloud Keychain, which, in turn, is protected with an encryption key derived from the user’s lock screen password or system password of a device that already participates in iCloud sync. Apple does not know that password, and cannot decrypt the user’s iCloud Keychain or Health data. The company cannot provide this data to law enforcement or fulfilling GDPR requests.

What about the “old”, unencrypted container created by iOS 11 devices? We witnessed this container disappear in several days after the last device on the Apple account in question was updated to iOS 12. We watched several accounts, and we could not figure out exactly when the unencrypted container was removed.

Extracting Apple Health Data

One can easily extract Apple Health data is one has access to the user’s iPhone and you can unlock the phone (with passcode, Touch ID or Face ID). In order to export data from the Apple Health app, one must open the Health app and use the Export command. The app will create a ZIP archive that can be saved or sent to another device.

In order to be able to export Apple Health data, you must have all of the following:

1. The user’s iPhone in a bootable, working condition
2. The ability to unlock the iPhone (screen lock password or an acceptable form of biometric identification such as Touch ID or Face ID)

iTunes Backups

If you do have the user’s iPhone but are unable to unlock it, or if you have an existing iTunes backup, there is another way to extract Health data. The Health data can be extracted by making the iPhone create a password-protected iTunes backup. In order to be able to create a backup of a locked iPhone, the iPhone being analyzed must have been unlocked at least once after it was powered on, and you must have access to a valid lockdown file (extracted from the user’s computer).

Note: Health information is only included in password-protected backups. Backups with an empty password will not contain any Health information (not even in encrypted form). If you don’t know the backup password, you may be able to recover it with Elcomsoft Phone Breaker or, if you know the phone’s passcode, you can reset the backup password (iOS 11 and 12). Screen Time password, if configured, will disable the ability to reset backup passwords. If this is the case, you may attempt extraction via a jailbreak or use Elcomsoft Phone Breaker to attack the original password.

Since iCloud backups cannot be protected with a password, they contain no Health data at all (even in encrypted form).

To decrypt the backup and convert folders and file names to readable form, Elcomsoft Phone Breaker must be used.

Jailbreak/GrayKey Extraction

If the iPhone is jailbroken, you can extract the physical Health databases from the file system. If you are using GrayKey (a specialized appliance available to select law enforcement and government agencies), you can make and analyze a file system image.

Going after a jailbreak for Health data analysis has little practical sense as Health information included in a password-protected backup is essentially the same as can be obtained via jailbreak. The only practical reason for pursuing the jailbreak would be if the backup is protected with an unknown password and that password cannot be reset because of Screen Time/Restrictions password.

Extracting Health Data from iCloud

The ability to access Apple Health information from iCloud depends largely on whether or not some of the user’s devices are still running iOS 11, and on whether or not you know the user’s screen lock password (passcode or system password to one of the user’s devices participating in Health sync). Notably, a correctly executed cloud extraction can return more information than can be obtained from a single iPhone. The ability to extract Apple Health data is unique to Elcomsoft Phone Breaker.

If  one of the user’s devices is still running iOS 11 (and the original unencrypted container is still present in the cloud):

1. Launch Elcomsoft Phone Breaker
2. Click Apple – Synced Data
3. Select Health
4. Enter the user’s Apple ID and password
5. If the user’s account is protected with two-factor authentication, you will be prompted for a one-time code.
6. Skip the passcode. Only data collected by devices running iOS 11 will be extracted.
7. If you know the user’s screen lock password, you may extract significantly more data. However, even if you don’t, you may be able to access Health data stored in the original unencrypted container.

If all of the user’s devices run iOS 12, the first (unencrypted) container may be missing. If this is the case, you will need to supply the correct screen lock password (iPhone passcode or system password of the user’s Mac) to one of the devices already participating in Health data sync. If this is the case, use the following steps.

1. Launch Elcomsoft Phone Breaker
2. Click Apple – Synced Data
3. Select Health
4. Enter Apple ID, password, and one-time 2FA code.
5. Select the device enrolled in iCloud sync from the list below. Choose the device to which you known the screen lock password.
6. Enter the passcode or system password for that device.
7. Elcomsoft Phone Breaker will download and decrypt Health data from both containers.

The screen lock password is required to gain access to iCloud Keychain that stores the encryption key required to decrypt the second Health container. Without that key, the data can be downloaded but cannot be decrypted; this is the reason why Apple does not provide Health data to law enforcement or as part of GDPR archives.

The downloaded Health data can be analyzed using Elcomsoft Phone Viewer:

Google Fit: the Android’s Stock Health App

Android does not offer a health subsystem that comes anywhere close to Apple Health. The closest one can get is the Google Fit app that users can download from the Play Store. Compared to Apple Health, Google Fit is a completely different beast doing many things backwards.

The amount of data collected and displayed

The Apple Health app collects a large number of data categories from an overwhelming amount of sources. Apple Health will only accept those types of data that are already defined in the HealthKit protocol. Once it accepts a certain data category, the app can correctly display and analyze the data.

The ugly side of this approach is exactly the overwhelming abundance of data displayed on the app’s main screen. For the sake of curiosity, what exactly is Mindfullness? (I can read English, yet I still fail to understand what exactly this is.) What is the point of displaying the entire Reproductive Health category (complete with menstrual cycles) to male users? Where does it source information about the amount of copper or iron I ate during the day, and why is it even displayed if I don’t log this data? The app is unnecessarily bloated and can easily confuse new users, literally begging to start ignoring large portions of the app.

Google Fit is exactly the opposite of Apple Health. Google’s app aggregates the bare minimum of data such as the step count and distance walking, Move Points representing time the user was moving, and Heart Points representing the time spent on active workouts. That’s about it if your phone is the only source of information.

Google Fit and third-party apps

Third-party apps may or may not share some of the data they collect with Google Fit. Google did not set any specific requirements, so many manufacturers of fitness tracking devices (e.g. Samsung, Garmin) don’t share any data with Google at all. Other manufacturers (e.g. the Vector Watch app) do share information with Google Fit if the user enables the corresponding option.

If any data is shared with Google Fit, the app may or may be able to display it. If the data exceeds the limited analytic abilities of the Google Fit app, it won’t be shown to the user at all. However, it will still be synced with the cloud through the user’s Google Account.

Apple requires manufacturers of HealthKit compliant apps and companion devices to share the complete data set with Apple Health. It does not mean that any fitness tracker or watch will share the data. For example, Samsung Gear smart watches and fitness trackers don’t share any data to Apple Health at all. However, if the app or device is advertised as HealthKit compliant, it will have to share all or most of the data with Apple Health. This requirement is missing in Android.

These differences lead to the following consequences.

1. In many cases, a fitness tracker or smart watch device that supports both Android and iOS platforms will provide significantly more data to the Apple Health app compared to Google Fit.
2. Apple Health standardizes data. HealthKit compliant apps cannot supply types of data that are not defined by Apple.
3. Google Fit will accept data of any type including unknown. Unknown types of data will not be displayed but will be synced in the cloud.

Additional information: Google Fit Explained and Google Fit compatible apps and devices.

Google Fit vs. Apple Health

Unlike the Apple Health app running on a recent iPhone model, Google Fit does not appear to be constantly polling the phone’s built-in pedometer sensor. Apparently, the Google Fit app makes use of Google Location Services and possibly data provided by Significant Motion sensors. The number of steps is not counted but is calculated based on the distance walked and the user’s body measurements (height). Of course, using a fitness tracker or companion device could supply information about the user’s step count; however, location data will still be collected by the Google Fit app. The following forum post of a Google Fit engineer seems to confirm our findings:

Battery is one of our top most concerns and we work hard to optimize Google Fit’s battery usage and provide a magical experience. Google Fit uses a mix of sensors (Accelerometer, Step counter, Significant Motion counter), Machine Learning and heuristics to get the data right. Our algorithm is pretty similar to your 1st option (*) plus a little bit of magic.

We periodically poll accelerometer and use Machine Learning and heuristics to correctly identify the activity and duration. For devices with hardware step counters, we use these step counters to monitor step counts. For older devices, we use the activity detected to predict the right number of steps. Our algorithms merge these activities, steps and sometimes location to correlate and further increase accuracy.

We do not poll GPS to estimate steps or detect activities.

— Engineer on Google Fit Team.

Source: Stack Overflow, How is it possible that Google Fit app measures number of steps all the time without draining battery?

(*) Wakes up the phone every minute or so, then analyses the sensors for a few seconds and then sleeps again. However it seems that the records are pretty accurate to the minute, so the waking up must be frequent.

Google Fit uses AI algorithms to try to learn the user’s personal walking patterns and their clusters. According to Google Fit engineer, this eliminates the need of constantly polling the hardware pedometer sensor while allowing Google Fit to be used on devices not equipped with step counter sensors at all. In addition, the algorithms eliminate the need of performing CPU-intensive calculations on sensor data every time the app takes a measurement. This makes Google Fit more power efficient compared to generic software pedometer apps on Android, at expense of the accuracy compared to solutions using a built-in hardware pedometer sensor. Considering the huge fragmentation of the Android platform in both hardware and software, Google’s approach appears to reach a trade-off between power consumption and accuracy while leaning towards the power factor.

Apple Health, on the other hand, does not use location data at all unless the user is wearing the Apple Watch and the watch detects a workout. If a workout is detected, location information will be collected continuously. Notably, such location data is then stored in a separate database and is encrypted. Instead, Apple Health is polling the low-energy motion coprocessors introduced with the iPhone 5s.

The Apple M-series motion coprocessors collect, process, and store sensor data even if the device is asleep without waking the main CPU. The use of motion coprocessors in Apple iPhones reduces power draw of the device and saves battery life while supplying apps with a constant (but not necessarily real-time) flow of relevant information. Applications can retrieve the data through the Core Motion framework without constantly engaging the main CPU. The Core Motion framework enables applications to be aware of what type of movement the user is experiencing, such as driving, walking, running, or sleeping.

The Core Motion framework enables applications to access hardware-generated data. In particular, the following step counting functions are available:

Pedometer: Provide step-counting data from the built-in motion processor.

• CMPedometer: An object for fetching the system-generated live walking data.
• CMPedometerData: Information about the distance traveled by a user on foot.
• CMPedometerEvent: A change in the user’s pedestrian activity.
• CMStepCounter (deprecated; use CMPedometer instead): The number of steps the user has taken with the device.

How does AI-powered Google Fit fare against Apple’s energy-efficient hardware and dedicated pedometer API? We made a quick non-scientific test in an attempt to compare information collected by the two apps by carrying the iPhone (with Apple Watch) and Google Pixel 3 XL (no separate fitness tracker) for one day. Both phones were equipped with SIM cards. We then analyzed the data collected by the two systems.

Apple Health

This is how Apple Health represents the data (1:20 in a car; a short walk; lunch; short car trip; walk; return trip):

Apple Health reports 3287 steps and 2.6 km walking distance; 222+1342=1564 calories burned; amount of physical activities unknown; reports 9 minutes “workout” and 5 “stand hours” (which does not seem right).

The data was exported from the Apple Health app. The exported data is available as a set if XML files in a ZIP archive. Below is a sample record:

<Record type="HKQuantityTypeIdentifierHeartRate" sourceName="Oleg’s Apple Watch" sourceVersion="5.1.2" device="&lt;&lt;HKDevice: 0x2832ab610&gt;, name:Apple Watch, manufacturer:Apple, model:Watch, hardware:Watch4,2, software:5.1.2&gt;" unit="count/min" creationDate="2019-01-06 14:35:47 +0100" startDate="2019-01-06 14:23:53 +0100" endDate="2019-01-06 14:23:53 +0100" value="96">

Interestingly, the app appears to collect data from two pedometer sensors: one on the iPhone, and another in the Apple Watch.

<Record type="HKQuantityTypeIdentifierStepCount" sourceName="iPhone" sourceVersion="12.1.2" device="&lt;&lt;HKDevice: 0x2832ad680&gt;, name:iPhone, manufacturer:Apple, model:iPhone, hardware:iPhone11,6, software:12.1.2&gt;" unit="count" creationDate="2019-01-06 14:51:45 +0100" startDate="2019-01-06 14:40:37 +0100" endDate="2019-01-06 14:48:11 +0100" value="198"/>
<Record type="HKQuantityTypeIdentifierStepCount" sourceName="Oleg’s Apple Watch" sourceVersion="5.1.2" device="&lt;&lt;HKDevice: 0x2832ad5e0&gt;, name:Apple Watch, manufacturer:Apple, model:Watch, hardware:Watch4,2, software:5.1.2&gt;" unit="count" creationDate="2019-01-06 14:50:55 +0100" startDate="2019-01-06 14:37:08 +0100" endDate="2019-01-06 14:43:07 +0100" value="150"/>

As far as we know, when more than one source of information is available, Apple Health prioritizes the data collected from the iPhone before Apple Watch.

Heart rate variability:

<Record type="HKQuantityTypeIdentifierHeartRateVariabilitySDNN" sourceName="Oleg’s Apple Watch" sourceVersion="5.1.2" device="&lt;&lt;HKDevice: 0x2832a2800&gt;, name:Apple Watch, manufacturer:Apple, model:Watch, hardware:Watch4,2, software:5.1.2&gt;" unit="ms" creationDate="2019-01-07 14:31:58 +0100" startDate="2019-01-07 14:30:56 +0100" endDate="2019-01-07 14:31:58 +0100" value="16.5784">
  <HeartRateVariabilityMetadataList>
   <InstantaneousBeatsPerMinute bpm="101" time="14:30:57,56"/>
   <InstantaneousBeatsPerMinute bpm="100" time="14:30:58,16"/>
   <InstantaneousBeatsPerMinute bpm="101" time="14:30:58,75"/>
   <InstantaneousBeatsPerMinute bpm="100" time="14:30:59,35"/>
   <InstantaneousBeatsPerMinute bpm="100" time="14:30:59,96"/>
   <InstantaneousBeatsPerMinute bpm="100" time="14:31:00,56"/>
   <InstantaneousBeatsPerMinute bpm="102" time="14:31:01,14"/>
   <InstantaneousBeatsPerMinute bpm="97" time="14:31:01,76"/>
   <InstantaneousBeatsPerMinute bpm="95" time="14:31:02,39"/>
   <InstantaneousBeatsPerMinute bpm="99" time="14:31:02,99"/>
   <InstantaneousBeatsPerMinute bpm="97" time="14:31:03,62"/>
   <InstantaneousBeatsPerMinute bpm="98" time="14:31:04,23"/>
   <InstantaneousBeatsPerMinute bpm="100" time="14:31:04,83"/>
   <InstantaneousBeatsPerMinute bpm="101" time="14:31:05,42"/>
   <InstantaneousBeatsPerMinute bpm="101" time="14:31:06,01"/>
   <InstantaneousBeatsPerMinute bpm="100" time="14:31:06,62"/>
   <InstantaneousBeatsPerMinute bpm="97" time="14:31:07,23"/>
   <InstantaneousBeatsPerMinute bpm="100" time="14:31:42,76"/>
   <InstantaneousBeatsPerMinute bpm="100" time="14:31:43,36"/>
   <InstantaneousBeatsPerMinute bpm="101" time="14:31:43,96"/>
   <InstantaneousBeatsPerMinute bpm="98" time="14:31:44,57"/>
   <InstantaneousBeatsPerMinute bpm="98" time="14:31:45,18"/>
   <InstantaneousBeatsPerMinute bpm="100" time="14:31:45,78"/>
   <InstantaneousBeatsPerMinute bpm="96" time="14:31:46,40"/>
   <InstantaneousBeatsPerMinute bpm="97" time="14:31:47,02"/>
   <InstantaneousBeatsPerMinute bpm="97" time="14:31:47,64"/>
   <InstantaneousBeatsPerMinute bpm="102" time="14:31:48,23"/>
   <InstantaneousBeatsPerMinute bpm="103" time="14:31:48,81"/>
   <InstantaneousBeatsPerMinute bpm="107" time="14:31:49,37"/>
   <InstantaneousBeatsPerMinute bpm="106" time="14:31:51,06"/>
   <InstantaneousBeatsPerMinute bpm="104" time="14:31:51,64"/>
   <InstantaneousBeatsPerMinute bpm="104" time="14:31:52,21"/>
   <InstantaneousBeatsPerMinute bpm="103" time="14:31:52,80"/>
   <InstantaneousBeatsPerMinute bpm="97" time="14:31:53,41"/>
  </HeartRateVariabilityMetadataList>

 </Record>

Walking distance (calculated based on the number of steps walked and user-provided body measurements):

<Record type="HKQuantityTypeIdentifierDistanceWalkingRunning" sourceName="Oleg’s Apple Watch" sourceVersion="5.1.2" device="&lt;&lt;HKDevice: 0x2832f9270&gt;, name:Apple Watch, manufacturer:Apple, model:Watch, hardware:Watch4,2, software:5.1.2&gt;" unit="km" creationDate="2019-01-06 15:08:49 +0100" startDate="2019-01-06 14:58:43 +0100" endDate="2019-01-06 15:06:35 +0100" value="0.178172"/>

There is some additional information reported by the Apple Watch including Basal Energy Burned, Active Energy Burned, Flights Climbed, Apple Exercise Time.

<Record type="HKQuantityTypeIdentifierActiveEnergyBurned" sourceName="Oleg’s Apple Watch" sourceVersion="5.1.2" device="&lt;&lt;HKDevice: 0x28329d0e0&gt;, name:Apple Watch, manufacturer:Apple, model:Watch, hardware:Watch4,2, software:5.1.2&gt;" unit="kcal" creationDate="2019-01-06 15:31:53 +0100" startDate="2019-01-06 15:28:49 +0100" endDate="2019-01-06 15:29:50 +0100" value="0.424"/>

The Apple Health app reports comprehensive information about the user’s activities. The data can be used for solving crime (e.g. investigators in http://fortune.com/2018/12/06/apple-iphone-health-app-murderer/ apparently used HKQuantityTypeIdentifierStepCount and HKQuantityTypeIdentifierFlightsClimbed):

<Record type="HKQuantityTypeIdentifierFlightsClimbed" sourceName="iPhone" sourceVersion="10.2.1" device="&lt;&lt;HKDevice: 0x283294320&gt;, name:iPhone, manufacturer:Apple, model:iPhone, hardware:iPhone8,1, software:10.2.1&gt;" unit="count" creationDate="2018-02-24 15:33:19 +0100" startDate="2018-02-24 14:01:57 +0100" endDate="2018-02-24 14:01:57 +0100" value="1"/>

Unlike Google Fit, Apple Health only stores the user’s location data if the app detects a workout. If a workout is detected, the Apple Watch starts collecting information continuously with a period of 1 second; if not, no location data is collected at all.

<Location date="2019-01-05 12:43:54 +0100" latitude="52.5118" longitude="13.3364" altitude="27.6155" horizontalAccuracy="1.31159" verticalAccuracy="1.11272" course="168.053" speed="0.783315"/>
<Location date="2019-01-05 12:43:55 +0100" latitude="52.5118" longitude="13.3364" altitude="27.6987" horizontalAccuracy="1.30859" verticalAccuracy="1.11246" course="168.053" speed="0.75217"/>
<Location date="2019-01-05 12:43:56 +0100" latitude="52.5118" longitude="13.3364" altitude="27.7774" horizontalAccuracy="1.30547" verticalAccuracy="1.11249" course="168.053" speed="0.719109"/>

Google Fit

For the same trip, Google Fit reported the following information:

Google Fit: 3748 steps, 2.41 km distance, 1377 calories burned, physical activity time 50 minutes. The app maps the user’s location data:

We exported Google Fit data through Google Takeout and analyzed the period of 14:30 to 15:30. The Daily Aggregations file contains information in 15-minute intervals in CSV format.

Start time,End time,Calories (kcal),Distance (m),Low latitude (deg),Low longitude (deg),High latitude (deg),High longitude (deg),Average speed (m/s),Max speed (m/s),Min speed (m/s),Step count,Average weight (kg),Max weight (kg),Min weight (kg),Inactive duration (ms),Walking duration (ms)

14:30:00.000+01:00,14:45:00.000+01:00,21.970262804673375,81.47002220153809,52.3498691,14.5603561,52.3498691,14.5603561,1.3560495376586914,1.361162781715393,1.3509362936019897,189,,,,839979,60021
14:45:00.000+01:00,15:00:00.000+01:00,18.642008718815653,11.182665824890137,52.3457901,14.5852002,52.3457901,14.5852002,,,,269,,,,890828,9172
15:00:00.000+01:00,15:15:00.000+01:00,57.92037990980161,234.93591034412384,52.3452287,14.5833228,52.3454651,14.584661,0.6185604934920054,0.7937963008880615,0.4872109591960907,442,,,,290734,609266
15:15:00.000+01:00,15:30:00.000+01:00,38.01473075330071,282.5838632583618,52.3453065,14.5836133,52.3458285,14.5853516,1.0011046724361665,1.2798868417739868,0.3900336027145386,435,,,,519858,305148
15:30:00.000+01:00,15:45:00.000+01:00,18.041664123535156,,52.3145496,14.5510705,52.3170428,14.588051,21.795568063657157,32.099998474121094,9.140000343322754,,,,,,

If the user does not wear a compatible watch or companion device, the phone collects low accuracy information. The data is stored in the Low Accuracy folder. Notably, location data is only included for routes the user was walking or running (as opposed to driving or taking a trip on a bus).

<Activity Sport="Other">
<Id>2019-01-06T14:16:36.976Z</Id>
<Notes>Walking</Notes>
<Lap StartTime="2019-01-06T14:16:36.976Z">
<Track>
<Trackpoint>
<DistanceMeters>0.0</DistanceMeters>
<Time>2019-01-06T14:16:36.976Z</Time>
</Trackpoint>
<Trackpoint>
<DistanceMeters>13.942784309387207</DistanceMeters>
<Time>2019-01-06T14:16:59.061Z</Time>
</Trackpoint>
<Trackpoint>
<DistanceMeters>105.96516132354736</DistanceMeters>
<Time>2019-01-06T14:18:38.996Z</Time>
</Trackpoint>
<Trackpoint>
<DistanceMeters>181.415753364563</DistanceMeters>
<Time>2019-01-06T14:19:39.966Z</Time>
</Trackpoint>
<Trackpoint>
<DistanceMeters>200.01529788970947</DistanceMeters>
<Time>2019-01-06T14:19:55.202Z</Time>
</Trackpoint>
<Trackpoint>
<DistanceMeters>258.8811311721802</DistanceMeters>
<Time>2019-01-06T14:20:41.096Z</Time>
<Position>
<LatitudeDegrees>52.3458285</LatitudeDegrees>
<LongitudeDegrees>14.5853516</LongitudeDegrees>
</Position>
</Trackpoint>
<Trackpoint>
<DistanceMeters>258.8811311721802</DistanceMeters>
<Time>2019-01-06T14:20:41.195Z</Time>
</Trackpoint>
<Trackpoint>
<DistanceMeters>282.5838632583618</DistanceMeters>
<Time>2019-01-06T14:21:42.124Z</Time>
</Trackpoint>
</Track>
<DistanceMeters>282.5838632583618</DistanceMeters>
<TotalTimeSeconds>305.148</TotalTimeSeconds>
<Calories>26.090152740478516</Calories>
<Intensity>Active</Intensity>
<TriggerMethod>Manual</TriggerMethod>
</Lap>
</Activity>

If the user wears a fitness tracker or companion device, the data may be reported with higher accuracy. The data is then stored in a different folder.

<Activity Sport="Other">
<Id>2018-12-11T19:21:55.172Z</Id>
<Notes>Walking</Notes>
<Lap StartTime="2018-12-11T19:21:55.172Z">
<Track>
<Trackpoint>
<DistanceMeters>0.0</DistanceMeters>
<Time>2018-12-11T19:21:55.172Z</Time>
</Trackpoint>
<Trackpoint>
<DistanceMeters>27.18842887878418</DistanceMeters>
<Time>2018-12-11T19:22:23.299Z</Time>
</Trackpoint>
<Trackpoint>
<DistanceMeters>62.03313636779785</DistanceMeters>
<Time>2018-12-11T19:22:54.555Z</Time>
</Trackpoint>
</Track>
<DistanceMeters>62.03313636779785</DistanceMeters>
<TotalTimeSeconds>59.383</TotalTimeSeconds>
<Calories>5.07724666595459</Calories>
<Intensity>Active</Intensity>
<TriggerMethod>Manual</TriggerMethod>
</Lap>
</Activity>

Finally, aggregated data is available in Daily Summaries:

Date,Calories (kcal),Distance (m),Low latitude (deg),Low longitude (deg),High latitude (deg),High longitude (deg),Average speed (m/s),Max speed (m/s),Min speed (m/s),Step count,Average weight (kg),Max weight (kg),Min weight (kg),Inactive duration (ms),Walking duration (ms)
2019-01-06,1893.2533778121408,1692.7585290074348,52.3145496,13.3485443,52.5222746,14.588051,3.7923538250920985,32.099998474121094,0.3485696017742157,3832,,,,48974765,2463627

Conclusions

When comparing information collected by the Apple Health app with information available through Google Fit, we can notice major differences in reported information coming from how these applications source the data. Apple Health counts steps using the built in pedometer sensor (and calculates walking distance), while Google Fit makes use of smart algorithms periodically polling the built-in pedometer and Significant Motion sensors as well as location data (part of Google Location History).

Important: Apple Health does not map the user and does not collect location data unless a workout is detected. Once the app detects a workout, GPS data is collected continuously.

Since Google Fit is not constantly polling the hardware pedometer sensor and relies on smart AI-based algorithms instead, we can see significantly lower accuracy compared with the hardware-based solution by Apple. Using additional sources of information (e.g. from compatible fitness trackers or smart watches) makes for a clearer picture. However, apart of Android Wear/WearOS smart watches, very few devices or OEM apps will readily share such data with Google Fit. Notably, Google Fit collects information about the user’s location regardless of workouts.

Data sync and security

Apple Health and Google Fit differ vastly when it comes to synchronizing and securing the data.

For Apple Health, the amount of data being synced as well as its protection differ between iOS 11 and iOS 12 (earlier versions of iOS did not support Health sync to iCloud). Google Fit, on the other hand, is compatible even with early versions of Android, and synchronizes similar amounts of information regardless of the version of Android it runs on.

In iOS 11, Health data is stored in iCloud a dedicated container. That container, however, does not feature any additional protection compared to other types of synchronized information. As a result, Health information can be extracted via a government request or through GRPD pullout. In order to access the data with Elcomsoft Phone Breaker, one needs the user’s Apple ID and password as well as the one-time code to pass Two-Factor Authentication.

iOS 12 makes use of a new, encrypted Health container (while retaining the old container in iCloud if there are any iOS 11 devices contributing to Health sync). The encryption key is stored in the iCloud Keychain. The encryption key is protected with an encryption key generated based on the user’s passcode (screen lock password or system password) of any device registered on the same Apple account and already participating in the sync. As such, Health data is NOT available to government requests or GDPR pullouts. Any Health data one still receives comes from the original (iOS 11) container, which may not be kept for long once the user updates all of their devices to iOS 12.

Accessing Health data synced by iOS 12 devices requires the user’s Apple ID and password, one-time code to pass 2FA (Health sync will not be enabled on accounts without 2FA), as well as the user’s screen lock password or system password from an already enrolled device.

Apple Health allows sharing data with third-party apps via HealthKit protocol. Third-party apps may use their own cloud services to store and synchronize the data. Data protection and privacy protection policies vary among third-party developers, while real implementation are, without any exceptions, vastly inferior to Apple’s (e.g. Strava Running and Cycling GPS).

Any data exported from the Apple Health app or downloaded from the cloud conforms to strict specifications; it is standardized and easy to analyze.

Google Fit also synchronizes information through Google Drive with the user’s Google Account. There is no additional encryption of Fit data whatsoever. One can easily obtain Google Fit data by using the Google Takeout service. Using Google Takeout requires Google Account login and password; possibly 2FA code for accounts protected with Two-Factor Authentication. The 2FA code could be skipped if a binary authentication token is extracted from the user’s computer or if one uses a Web browser that previously signed in to the user’s Google Account.

Google delivers Fit data via government requests and GDPR pullouts.

Third-party apps can access Google Fit data with just the user’s login and password (and possibly 2FA code, see above).

Google Fit accepts many types of data from third-party apps that are not directly supported. Unsupported types of data are not displayed within the app; however, they are still synced with the cloud and can be extracted. Analyzing these types of data can be difficult.

Data Sourcing

One area where Apple Health and Google Fit differ the most is the source of the data.

Google Fit will not constantly poll the phone’s hardware in order to read step count. Instead, the app uses smart AI-based algorithms to estimate step count based on periodic readings of the pedometer sensor (if available) and a combination of accelerometer data, Significant Motion sensor data, and location data. Steps are calculated based on walking distance and pace as well as the user’s body measurements. Google Location Services appear to play a major role in sourcing the data; location points are always saved to the cloud. Companion devices (fitness trackers, smart watches etc.) may provide additional information.

Google Fit: data sync and data protection. All data is synced with Google Drive without additional encryption. Google serves government and GRPR requests. Data can be obtained via Google Takeout or third-party apps.

Apple Health processes data collected by the energy-efficient motion coprocessor built into all iPhone devices since iPhone 5s. No location data is saved unless a workout is detected. If a workout is detected, Apple Health collects location points every second. These location points are stored locally in a separate database, which is encrypted. Apple Health also prompts for body measurements, yet the use for this data is directly opposite to Google Fit. With Apple Health, the user’s height is used to approximate the distance walked based on the measured number of steps. Apple Watch and other companion devices deliver extra information, while third-party apps can access Health data if explicitly allowed by the user.