Difference between revisions of "Mobile Privacy Experience"

Revision as of 07:21, 22 June 2023

Full Title or Meme

As more of our interactions with networked applications and data increases, the need for user's to understand the impact of the choices they make during their interactions.

Context

Current User Experiences with privacy notifications is demonstrably inadequate to the problems created.^[1] Mobile Phones began a campaign to label apps with consumer-friendly labels. The result was panned in papers like the New York Times and Washington Post. Which called the labels confusing and had to identify as to their purpose.

Problems

1. User's requests for more privacy and seldom followed up by any significant change in user behavior. This makes it easy from companies to claim that they offer privacy options that the user can enable but not ensuring that the user has any real choice.
2. Generally attempts to legislate privacy attract lawyers who encourage the legislature to give the lawyers a means to extract settlements from offending companies, without otherwise making any effort to actually improve the user's experience. For one example see the wiki page on GDPR is a scam. This leads to mitigations that are not at all related to user privacy concerns.
3. Tracking of user's or their devices either in physical space or digital space can expose the full identity is a short time.
4. Aggregation of user's attributes or behaviors will expose a user's full identity in an amazingly short time online.
5. Developers that create privacy notices are typically unaware (or unconcerned) about privacy threats.

Taxonomy

1. mobile credential = this can be called many things beside credential including: certificate, registration, membership, access ticket, etc. but it must be included in a network enabled portable device.
2. subject = the entity associated with a credential. Typically the holder is the subject or a guardian of the subject.
3. holder = the entity to which the wallet is issued.
4. holder wallet (a holder agent from a provider) includes all of the components: the mobile device, operating system, key storage facility, network accessibility, wallet software, wallet network support infrastructure, etc.
5. issuer = an entity that can bind a credential to a subject
6. issuer provider = the entity that creates the issuer code or service.
7. verifier = the entity that requires some proof about a subject (the verifier acquires validation of subject claims.)
8. verifier provider= the entity that creates or supplies the verifier code, device or service.

Modes of operation:

1. Issuer on-line = can or must the verifier check the current status of the credential.
2. Digital Presence = in spite of the apparent meaning of user or device presence, this actually describes the wireless protocol to be used (eg BLE indicates presence).
3. Physical Presence = a biometric check which can be made on the any device in the hand of the user or the verifier.
4. Proof of Presence = a trusted device can create an assurance statement that include information about presence of the holder (or subject??)

Wallet Consideration

1. The wallet here means all of the components that contribute to the mobile experience.
2. Since this page describes the Mobile Privacy Experience the web-only wallet is not considered.
3. The mobile device must, at a minimum, give the user experience for the user choice.
4. Assurance statement = a credential signed by the wallet and possible by a remote attestation service (RAS). see MAAS
5. What features are required of the device to meet the security and privacy needs of the credential and the presentation of that credential.
6. Where hardware protection is required, how can a holder reacquire credentials that are no longer available if the device is lost? (Note that this covers both hardware protection on the device and also in removable "keys" that contain the secrets.)
7. If user secret data is stored in the cloud, evidence of the protection provided to those secrets must be generally accessible for expert review.
8. The "wallet app" may be preinstalled on the device or available by download.

Solutions

1. Focus on the single consent page where a user has a choice about release of data.
   1. The only interesting test is to ask users in the field to evaluate what that page meant to them.
   2. The subject needs to understand what is requested and why. In many cases that means that the list will often be abbreviated. For example, if a prescribing physician needs to know current medicines and allergies, etc. the statement might be sufficient to say "information needed in prescribing medications."
   3. Legibility and clarity for the vast majority of subject who might not be well educated in the language used for prescribing or have a physical limitation in what they can see.
   4. Privacy labels should be standardized similar to food nutrition labels.
2. Legal requirements are seldom helpful in establishing the user consent page, but are critical in what data is available to subject that is one of the very few that chose to followup on their concerns by drilling into the details.
   1. Apps need to be scrupulously careful about stating what data is collected and what is retained.
   2. Apps must make it easy to retract consent to use or store data where that is legally permissible.
3. Support services available to the Holder (and potentially to the Subject.)
   1. Assurance that holder (Subject) secrets are not released.
   2. Notification to the Holder of any unexpected release of Subject information is typically required by government regulations.
   3. Method to recover access to mobile credentials.

References

1. ↑ Lorrie Faith Cranor, Mobile-App Privacy Nutrition Labels Missing Key Ingredients for Success CACM 65 No. 11 (2022-11)