| Literature DB >> 30348623 |
Luke Hutton1, Blaine A Price1, Ryan Kelly1,2, Ciaran McCormick1, Arosha K Bandara1, Tally Hatzakis3, Maureen Meadows4, Bashar Nuseibeh1,5.
Abstract
BACKGROUND: The recent proliferation of self-tracking technologies has allowed individuals to generate significant quantities of data about their lifestyle. These data can be used to support health interventions and monitor outcomes. However, these data are often stored and processed by vendors who have commercial motivations, and thus, they may not be treated with the sensitivity with which other medical data are treated. As sensors and apps that enable self-tracking continue to become more sophisticated, the privacy implications become more severe in turn. However, methods for systematically identifying privacy issues in such apps are currently lacking.Entities:
Keywords: mHealth apps; mobile phone; privacy; usable security and privacy
Year: 2018 PMID: 30348623 PMCID: PMC6231850 DOI: 10.2196/mhealth.9217
Source DB: PubMed Journal: JMIR Mhealth Uhealth ISSN: 2291-5222 Impact factor: 4.773
Figure 1How the regulatory and market landscape was fed into the design of the heuristics and the choice of apps to study. GDPR: General Data Protection Regulation; FIPS: Fair Information Practices; QS: quantified self.
The 26 heuristics (H) present in our evaluation technique.
| Category description and numbera | Heuristic | |
| H1 | Before data are shared with a remote actor, the entity collecting the data is explicitly identified. | |
| H2 | Before data are shared with a remote actor, the uses of the data are explicitly identified. | |
| H3 | Before data are shared with a remote actor, the potential recipients are explicitly identified. | |
| H4 | The nature and means of the data collected are explicitly identified. | |
| H5 | Steps taken to ensure confidentiality, integrity, and quality of data are explained. | |
| H6 | For those of above satisfied, notice is sufficiently explicit. | |
| H7 | Can control when data are used for nonoperational secondary use, such as marketing or research. | |
| H8 | Consent acquired before data shared with remote actor. | |
| H9 | Consent is explicitly opt-in: no preticked checkboxes, etc. | |
| H10 | Can choose which data types are automatically collected from sensors or other sources, for example, connect a finance app to a single bank account or track steps but not heart rate. | |
| H11 | Data collection consent is dynamic: if new types of data are being collected, consent is renewed | |
| H12 | Data processing consent is dynamic: if the purpose of processing changes, consent is renewed. | |
| H13 | Data distribution consent is dynamic: if the actors’ data are distributed to changes, consent is renewed. | |
| H14 | Consent to store and process data can be revoked at any time: with the service and any other actors. | |
| H15 | Can control where data are stored. | |
| H16 | All raw collected data can be extracted from the service (in-app or via vendor’s website). | |
| H17 | All data are available in standard text formats (CSVb, XML, JSONc, GPXd, etc). | |
| H18 | Data extraction is available from within the service, for example, without raising a request with support. | |
| H19 | Programmatic access to data is possible, for example, app programming interfaces are exposed. | |
| H20 | Privacy controls are per-disclosure, for example, individual workouts can be published to a social networking site, not relying solely on global defaults. | |
| H21 | Privacy controls allow granular sharing of data types, for example, when sharing a workout, the distance can be shared but not the pace. | |
| H22 | Error prevention: is explicit confirmation acquired before a disclosure? | |
| H23 | Minimize user memory load: Effects of a disclosure are visible throughout the disclosure flow (ie, memory of earlier decisions not required). | |
| H24 | Minimalist: During the disclosure flow no extraneous information (such as adverts or irrelevant user interface elements) is displayed. | |
| H25 | Consistency: Information shown during the disclosure flow is consistent with the effect of the disclosure. | |
| H26 | Help and documentation: Contextual help with making privacy decisions is available. | |
aSee Multimedia Appendix 1 for the scoring criteria.
bCSV: comma-separated values.
cJSON: JavaScript Object Notation.
dGPX: GPS eXchange Format.
The categories of apps used in our evaluation and the constituent search keywords for each group.
| Purpose and app category | Keywords | |
| Cycling | Cycling | |
| Diet | Diet, eating | |
| Exercise | Exercise, workouts | |
| Apps with wearable hardware | N/Aa | |
| Heart | Heartrate, heart rate | |
| Mood | Mood, happiness | |
| Running | Walking, running | |
| Sleep | Sleep | |
| Step count | Steps | |
| Weight | Weight, body fat | |
| Spending | Spending, income | |
| Time | Time keeping | |
aN/A: not applicable.
Figure 2Screenshot of initial login screen of the Bliss app.
Figure 3Boxplot showing how performance on the privacy heuristics varies across different types of apps.
Figure 4Boxplot showing the differences in performance among the 4 groups of heuristics.
Figure 5Boxplot showing differences in performance among the 4 groups of heuristics.
Figure 6Partial screenshot of the Fitbit Android app account creation page.