Categories: location • notice • mobile • inform • notify

Asynchronous notice

Contents

Context

Many sensor related or other recurring forms of data collection are important for improving service (or product) quality, but occur in a manner which is not apparent to the user. Even where the user is informed of such processing, the nature of that processing may cause it to occur within contexts the user would not consent to. Users are also subject to forgetfulness. The controller processing this information therefore seeks to ensure that consent is retained. Some interfaces necessitate more restrictive use of screen real estate, however, and as such can not accommodate extensive information or persistent elements.

Problem

Users being tracked and monitored may not consent to processing they had previously consented to, as the context surrounding that processing is subject to change.

Also, initial consent may have been forged by an attacker or have been provided by another user of a shared device -- if synchronous notice is only provided at the time of consent, a user may inadvertently distribute personal information over a long period of time after having lost control of their device only momentarily.

Forces and Concerns

  • Users may change their minds or forget about consent they have given
  • Users may not realize the processing they consented to is currently in effect, potentially allowing collection of information they would not want collected
  • Controllers do not want to collect data for which consent is uncertain, where users may feel violated or otherwise let down
  • Controllers cannot remind users of their consent all the time

Providing an asynchronous notice requires a reliable mechanism to contact the user (a verified email address or telephone number, for example). Care should be taken to ensure that the mechanism can actually reach the person using the device being tracked. (For example, notifying the owner of the billing credit card may not help the spouse whose location is being surreptitiously tracked.)

In contrast to the common privacy practice of providing consistent and reliable systems, you may wish to provide random asynchronous notice. If there is a concern that a malicious user may have opted-in the user without their knowledge, a notice that is sent once a week at the same time each week may allow the attacker to borrow the device at the appointed time and clear the notice.

Many repeated notices may annoy users and eventually inure them to the practice altogether. Take measures to avoid unnecessary notices and some level of configuration for frequency of notices. This must be balanced against the concerns of an attacker's opting the user in without their knowledge.

Solution

Whenever there is a context switch, sufficient duration, or random spot check, provide users with a simple reminder that they have consented to specific processing. The triggers and means for contacting the user may be chosen by the user themselves, who should be able to review and if necessary retract their consent.

[Implementation]

Implementation depends on the medium chosen for conveying the notification, and also on the service facilitating collection. For mediums with less space, shorter messages should be provided, but even in more traditionally long-winded options such as email, brevity should be favored. The user should be able to obtain more information by a linking mechanism, also dependent on the medium. The most important information to provide is the fact that they have consented to specific data for specified purposes, and that a context change, spot check, or specified duration has triggered the reminder. Context changes are most notable, as these are most likely to affect the consent. Note that changes to purposes and means instead require new consent, not merely notification.

Asynchronous notices may also include a summary of the data recently collected (since the last notice, say) in order to provide clarity (and reminders) to the user about the extent of collection. By ensuring that users aren't surprised, asynchronous notice may increase trust in the service and comfort with continued disclosure of information.

Examples

  1. Google Latitude reminder email

Google Latitude users can configure a reminder email (see below) when their location is being shared with any application, including internal applications like the Location History service.

This is a reminder that you are sharing your Latitude location with the following application(s):

Google Location History You may disable these applications at any time by going to https://www.google.com/latitude/apps?hl=en]

Do more with Latitude Go to https://www.google.com/latitude/apps on your computer and try the following:

Google Location History lets you store your history and see a dashboard of interesting information such as frequently visited places and recent trips. Google Talk Location Status lets you post your location in your chat status. Google Public Location Badge lets you publish your location on your blog or site.

You are receiving this reminder once a week. To change your reminder settings, go to: https://www.google.com/latitude/apps?hl=en&tab=privacyreminders

  1. Fire Eagle My Alerts

Fire Eagle My Alerts configuration by npdoty, on Flickr Fire Eagle My Alerts configuration by npdoty, on Flickr

This pattern refines Preventing Mistakes or Reducing Their Impact. As it provides notice of noteworthy processing when in context, a user is prevented from mistakenly producing data. As the notification is obtrusive, they are given every chance to cease doing so before it has an impact. As an implicit relationship through Preventing Mistakes or Reducing Their Impact, this pattern also complements Impactful Information and Feedback.

This pattern is an alternative to Ambient Notice. While this pattern provides contextually justified notice whenever necessary, the Ambient variant does so persistently and without contextual justification. Unlike this pattern, Ambient Notice is unobtrusive.

This pattern complements Single Point of Contact. A SPoC is an authority which validates requests and ensures secure and private communication, a usage of data which can be contextually displayed to remind the user of its (de)activation.

[Sources]

N. Doty, M. Gupta, and J. Zych, “privacypatterns.org - Privacy Patterns,” privacypatterns.org, 2017. [Online]. Available: http://privacypatterns.org/. [Accessed: 26-Feb-2015].

C. Bier and E. Krempel, “Common Privacy Patterns in Video Surveillance and Smart Energy,” in ICCCT-2012, 2012, pp. 610–615.

E. S. Chung, J. I. Hong, J. Lin, M. K. Prabaker, J. a. Landay, and A. L. Liu, “Development and Evaluation of Emerging Design Patterns for Ubiquitous Computing,” DIS ’04 Proceedings of the 5th conference on Designing interactive systems: processes, practices, methods, and techniques, pp. 233–242, 2004.

J. Siljee, “Privacy transparency patterns,” in EuroPLoP ’15, 2015, pp. 1–11.