Mobile Privacy Experience

From MgmtWiki
Jump to: navigation, search

Full Title or Meme

As more of our interactions with networked applications and data increases, the need increases for users to understand the impact of the choices they make during their interactions so they can understand what it is that they are consenting to.

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 hard to identify as to their purpose.

Assumptions

  1. Issuers can be strongly identified such that holder trust decisions are possible.
  2. Verifiers are similarly strongly identified and may be issuers as well.
  3. Wallets are permitted to acquire credentials from issuers based on holder request only.
  4. Wallets may create signed credentials on their own behalf as needed.
    1. For example statements about themselves or the holder presence.
  5. Wallets shall not store information from verifiers that the verifier can later access.
    1. No cookie privacy rule.
    2. It may be that transactions or receipts need more detailed consideration.
  6. Holders are allowed to configure wallets which may include Issuer or Verifier preferences.
  7. Access to any data on a private mobile device by any entity, sovereign or not, without the subject's knowledge is unacceptable.

Principles

  1. The holder is in charge of their own devices, data, settings, limitations, navigation and other behaviors.
  2. The issuers hold subject's data that can be bundled into credentials that the holder can request.
    1. The issuers have a responsibility to the holders (and subjects) to protect access to subject data.
    2. The issuers must issue credentials that allow holder (through their wallets) selective release of any data.
    3. The issuers must not release subject data to wallets that are not trustworthy.
  3. The verifiers need some evidence of the holder (or subject) to release access to goods or services.
    1. The verifiers have a responsibility to present their identity and purpose for requesting access to data.
  4. The wallet is the holder's agent and must represent the holder's intentions.
    1. The wallet must convince both issuers and agents of its trustworthiness by the messages it sends.
    2. The wallet must construct consent screens based on issuer's or verifier's data requests that the holder can understand.
    3. Accessibility and holder preferences are always accommodated.

Problems

  1. The web is a completely open community that accepts anyone that asks to be included with no checking of Identity.
    1. No website can be trusted without some prior knowledge.
    2. The holder can expect to be attacked by unscrupulous providers of wallets, issuers and verifiers.
  2. Most holders are unfamiliar with technology and the implications of the use of that technology.
  3. Subject's requests for more privacy and seldom followed up by any significant change in Subject's behavior. This makes it easy from companies to claim that they offer privacy options that the holder can enable but not ensuring that the holder has any real choice.
  4. 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 Experience. For one example see the wiki page on GDPR is a scam. This leads to mitigations that are not at all related to privacy concerns. The point of the GDPR was to fine multi-nationals and increase the EU revenue.
  5. Tracking of holder's or their devices either in physical space or digital space can expose the full identity is a short time.
  6. Aggregation of Subject's attributes or behaviors will expose a subject's full identity in an amazingly short time online.
  7. Developers that create privacy notices are typically unaware (or unconcerned) about privacy threats.
  8. Session state from one connection to another (cookies) allows tracking of the holder of the wallet.
    1. Wallet IDs cannot be passed to either the issuer or the verifier in identity proofing or attestation.

Taxonomy

  1. mobile credential = this can be called many things beside credential including: certificate, registration, membership, card, license, access ticket, etc. but it must be included in a network enabled portable device.
  2. fallback access = some means to allow holder access when a mobile credential cannot be accessed.
  3. subject = the entity associated with a credential. Typically the holder is the subject or a guardian of the subject.
  4. holder = the entity to which the wallet is issued.
  5. holder wallet (a holder agent from a provider) includes all of the components: the mobile device, operating system, key storage facility, network accessibility, wallet app software, wallet network support infrastructure, etc.
  6. issuer = an entity that can bind a credential to a subject
  7. issuer provider = the entity that creates the issuer code or service.
  8. verifier = the entity that requires some proof about a subject (the verifier acquires validation of subject claims.)
  9. 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 with the issuer.
  2. Digital Presence = in spite of the apparent meaning of subject 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 any device in the hand of the holder 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 Experience

Wallet Consideration

  1. The wallet here means all of the components that contribute to the mobile experience.
  2. The wallet may contain privacy settings that determine how the wallet is to handle requests for proof or data from credentials.
  3. Since this page describes the Mobile Privacy Experience the web-only wallet is not considered.
  4. The mobile device must, at a minimum, give the holder experience for the holder choice.
  5. Assurance statement = a credential signed by the wallet and possible by a remote attestation service (RAS). see MAAS
  6. What features are required of the device to meet the security and privacy needs of the credential and the presentation of that credential.
  7. 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.)
  8. If holder (or subject) secret data is stored in the cloud, evidence of the protection provided to those secrets must be generally accessible for expert review.
  9. The "wallet app" may be preinstalled on the device or available by download.

Fall Back Operation

  1. Where a fully-powered smart phone is not available for use by both the holder and the verifier, the existing fallback is to the ISO 18013-1 card. The only part of that card needed is the bar code on the back of the card which can be scanned by any reader, including a smart phone camera. Typically both the front and back are scanned and stored, which releases ALL of the credential information to the verifier and is probably retained by the verifier. Many holders are reluctant to allow verifiers that level of disclosure.
  2. One option that is available is a QR Code printed on any home computer that directs the verifier to the issuer for on-line verification.

Levels

The wallet must accommodate both holder experience and legal requirements. These are often incompatible and judgement is needed. The following levels are conceptual and are based on the deviation from the norm similar to a normal distribution, so one could be considered (very roughly) within one standard deviation and so on.

  1. In the most common case the holder gets one screen that contains the purpose, a holder understandable identity of the verifier (and other data controllers or providers) and the proposed summary data to be released. A holder gesture is required to release the data.
  2. The wallet or holder decides that more information is required to be evaluated than the one screen can provide.
  3. The holder wants to see the full data (and metadata) that is to be released to the verifier.
  4. The holder wants (or is forced) to view the terms and conditions of the issuer or verifier.
  5. The holder needs to change the wallet (device/app) configuration setting to allow the data access requested.

Solutions

  1. Focus on the single consent page on the holder's device where the holder has a choice about release of data.
    1. The wallet crafts the consent page based on the request for proof and/or data contained in the subject's credentials.
    2. The wallet must not respond to the request without the holder's physical indication of acceptance of the terms on the consent page.
    3. The only interesting test is to ask holders in the field to evaluate what that consent page meant to them.
    4. The subject needs to understand the purpose (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."
    5. Legibility and clarity for the vast majority of holders who might not be well educated in the language used for verifying or have a physical limitation in what they can see.
    6. Privacy labels should be standardized similar to food nutrition labels.
  2. Legal requirements are seldom helpful in establishing the a consent page, but are critical in what data is available to any subject who might be one of the very few holders that chose to follow-up 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. Clear means to understand and modify current privacy settings.
    3. Notification to the Holder of any unexpected release of Subject information is typically required by government regulations.
    4. Method to recover access to mobile credentials.
    5. Consent receipts may be required from verifiers either at, or after, holder consent is granted. Where available, these need to be accessible by the holder, probably as a function of the wallet app.
    6. Revocation of consent will typically be required by governmental agencies. Where required the wallet should facilitate that action.

References

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

Other Material

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Mobile_Privacy_Experience&oldid=18932"