Internet Architecture Board (IAB) A. Cooper
Request for Comments: 6973 CDT
Category: Informational H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
B. Aboba
Skype
J. Peterson
NeuStar, Inc.
J. Morris
M. Hansen
ULD
R. Smith
Janet
July 2013
Privacy Considerations for Internet Protocols
Abstract
This document offers guidance for developing privacy considerations
for inclusion in protocol specifications. It aims to make designers,
implementers, and users of Internet protocols aware of privacy-
related design choices. It suggests that whether any individual RFC
warrants a specific privacy considerations section will depend on the
document's content.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Architecture Board (IAB)
and represents information that the IAB has deemed valuable to
provide for permanent record. It represents the consensus of the
Internet Architecture Board (IAB). Documents approved for
publication by the IAB are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6973.
Cooper, et al. Informational [Page 1]
RFC 6973 Privacy Considerations July 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. This document is subject to
BCP 78 and the IETF Trust's Legal Provisions Relating to IETF
Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Cooper, et al. Informational [Page 2]
RFC 6973 Privacy Considerations July 2013
Table of Contents
1. Introduction ....................................................4
2. Scope of Privacy Implications of Internet Protocols .............5
3. Terminology .....................................................6
3.1. Entities ...................................................7
3.2. Data and Analysis ..........................................8
3.3. Identifiability ............................................9
4. Communications Model ...........................................10
5. Privacy Threats ................................................12
5.1. Combined Security-Privacy Threats .........................13
5.1.1. Surveillance .......................................13
5.1.2. Stored Data Compromise .............................14
5.1.3. Intrusion ..........................................14
5.1.4. Misattribution .....................................14
5.2. Privacy-Specific Threats ..................................15
5.2.1. Correlation ........................................15
5.2.2. Identification .....................................16
5.2.3. Secondary Use ......................................16
5.2.4. Disclosure .........................................17
5.2.5. Exclusion ..........................................17
6. Threat Mitigations .............................................18
6.1. Data Minimization .........................................18
6.1.1. Anonymity ..........................................19
6.1.2. Pseudonymity .......................................20
6.1.3. Identity Confidentiality ...........................20
6.1.4. Data Minimization within Identity Management .......21
6.2. User Participation ........................................21
6.3. Security ..................................................22
7. Guidelines .....................................................23
7.1. Data Minimization .........................................24
7.2. User Participation ........................................25
7.3. Security ..................................................25
7.4. General ...................................................26
8. Example ........................................................26
9. Security Considerations ........................................31
10. Acknowledgements ..............................................31
11. IAB Members at the Time of Approval ...........................32
12. Informative References ........................................32
Cooper, et al. Informational [Page 3]
RFC 6973 Privacy Considerations July 2013
1. Introduction
[RFC3552] provides detailed guidance to protocol designers about both
how to consider security as part of protocol design and how to inform
readers of protocol specifications about security issues. This
document intends to provide a similar set of guidelines for
considering privacy in protocol design.
Privacy is a complicated concept with a rich history that spans many
disciplines. With regard to data, often it is a concept applied to
"personal data", commonly defined as information relating to an
identified or identifiable individual. Many sets of privacy
principles and privacy design frameworks have been developed in
different forums over the years. These include the Fair Information
Practices [FIPs], a baseline set of privacy protections pertaining to
the collection and use of personal data (often based on the
principles established in [OECD], for example), and the Privacy by
Design concept, which provides high-level privacy guidance for
systems design (see [PbD] for one example). The guidance provided in
this document is inspired by this prior work, but it aims to be more
concrete, pointing protocol designers to specific engineering choices
that can impact the privacy of the individuals that make use of
Internet protocols.
Different people have radically different conceptions of what privacy
means, both in general and as it relates to them personally [Westin].
Furthermore, privacy as a legal concept is understood differently in
different jurisdictions. The guidance provided in this document is
generic and can be used to inform the design of any protocol to be
used anywhere in the world, without reference to specific legal
frameworks.
Whether any individual document warrants a specific privacy
considerations section will depend on the document's content.
Documents whose entire focus is privacy may not merit a separate
section (for example, "Private Extensions to the Session Initiation
Protocol (SIP) for Asserted Identity within Trusted Networks"
[RFC3325]). For certain specifications, privacy considerations are a
subset of security considerations and can be discussed explicitly in
the security considerations section. Some documents will not require
discussion of privacy considerations (for example, "Definition of the
Opus Audio Codec" [RFC6716]). The guidance provided here can and
should be used to assess the privacy considerations of protocol,
architectural, and operational specifications and to decide whether
those considerations are to be documented in a stand-alone section,
within the security considerations section, or throughout the
Cooper, et al. Informational [Page 4]
RFC 6973 Privacy Considerations July 2013
document. The guidance provided here is meant to help the thought
process of privacy analysis; it does not provide specific directions
for how to write a privacy considerations section.
This document is organized as follows. Section 2 describes the
extent to which the guidance offered here is applicable within the
IETF and within the larger Internet community. Section 3 explains
the terminology used in this document. Section 4 reviews typical
communications architectures to understand at which points there may
be privacy threats. Section 5 discusses threats to privacy as they
apply to Internet protocols. Section 6 outlines mitigations of those
threats. Section 7 provides the guidelines for analyzing and
documenting privacy considerations within IETF specifications.
Section 8 examines the privacy characteristics of an IETF protocol to
demonstrate the use of the guidance framework.
2. Scope of Privacy Implications of Internet Protocols
Internet protocols are often built flexibly, making them useful in a
variety of architectures, contexts, and deployment scenarios without
requiring significant interdependency between disparately designed
components. Although protocol designers often have a particular
target architecture or set of architectures in mind at design time,
it is not uncommon for architectural frameworks to develop later,
after implementations exist and have been deployed in combination
with other protocols or components to form complete systems.
As a consequence, the extent to which protocol designers can foresee
all of the privacy implications of a particular protocol at design
time is limited. An individual protocol may be relatively benign on
its own, and it may make use of privacy and security features at
lower layers of the protocol stack (Internet Protocol Security,
Transport Layer Security, and so forth) to mitigate the risk of
attack. But when deployed within a larger system or used in a way
not envisioned at design time, its use may create new privacy risks.
Protocols are often implemented and deployed long after design time
by different people than those who did the protocol design. The
guidelines in Section 7 ask protocol designers to consider how their
protocols are expected to interact with systems and information that
exist outside the protocol bounds, but not to imagine every possible
deployment scenario.
Furthermore, in many cases the privacy properties of a system are
dependent upon the complete system design where various protocols are
combined together to form a product solution; the implementation,
which includes the user interface design; and operational deployment
practices, including default privacy settings and security processes
of the company doing the deployment. These details are specific to
Cooper, et al. Informational [Page 5]
RFC 6973 Privacy Considerations July 2013
particular instantiations and generally outside the scope of the work
conducted in the IETF. The guidance provided here may be useful in
making choices about these details, but its primary aim is to assist
with the design, implementation, and operation of protocols.
Transparency of data collection and use -- often effectuated through
user interface design -- is normally relied on (whether rightly or
wrongly) as a key factor in determining the privacy impact of a
system. Although most IETF activities do not involve standardizing
user interfaces or user-facing communications, in some cases,
understanding expected user interactions can be important for
protocol design. Unexpected user behavior may have an adverse impact
on security and/or privacy.
In sum, privacy issues, even those related to protocol development,
go beyond the technical guidance discussed herein. As an example,
consider HTTP [RFC2616], which was designed to allow the exchange of
arbitrary data. A complete analysis of the privacy considerations
for uses of HTTP might include what type of data is exchanged, how
this data is stored, and how it is processed. Hence the analysis for
an individual's static personal web page would be different than the
use of HTTP for exchanging health records. A protocol designer
working on HTTP extensions (such as Web Distributed Authoring and
Versioning (WebDAV) [RFC4918]) is not expected to describe the
privacy risks derived from all possible usage scenarios, but rather
the privacy properties specific to the extensions and any particular
uses of the extensions that are expected and foreseen at design time.
3. Terminology
This section defines basic terms used in this document, with
references to pre-existing definitions as appropriate. As in
[RFC4949], each entry is preceded by a dollar sign ($) and a space
for automated searching. Note that this document does not try to
attempt to define the term 'privacy' with a brief definition.
Instead, privacy is the sum of what is contained in this document.
We therefore follow the approach taken by [RFC3552]. Examples of
several different brief definitions are provided in [RFC4949].
Cooper, et al. Informational [Page 6]
RFC 6973 Privacy Considerations July 2013
3.1. Entities
Several of these terms are further elaborated in Section 4.
$ Attacker: An entity that works against one or more privacy
protection goals. Unlike observers, attackers' behavior is
unauthorized.
$ Eavesdropper: A type of attacker that passively observes an
initiator's communications without the initiator's knowledge or
authorization. See [RFC4949].
$ Enabler: A protocol entity that facilitates communication between
an initiator and a recipient without being directly in the
communications path.
$ Individual: A human being.
$ Initiator: A protocol entity that initiates communications with a
recipient.
$ Intermediary: A protocol entity that sits between the initiator
and the recipient and is necessary for the initiator and recipient
to communicate. Unlike an eavesdropper, an intermediary is an
entity that is part of the communication architecture and
therefore at least tacitly authorized. For example, a SIP
[RFC3261] proxy is an intermediary in the SIP architecture.
$ Observer: An entity that is able to observe and collect
information from communications, potentially posing privacy
threats, depending on the context. As defined in this document,
initiators, recipients, intermediaries, and enablers can all be
observers. Observers are distinguished from eavesdroppers by
being at least tacitly authorized.
$ Recipient: A protocol entity that receives communications from an
initiator.
Cooper, et al. Informational [Page 7]
RFC 6973 Privacy Considerations July 2013
3.2. Data and Analysis
$ Attack: An intentional act by which an entity attempts to violate
an individual's privacy. See [RFC4949].
$ Correlation: The combination of various pieces of information that
relate to an individual or that obtain that characteristic when
combined.
$ Fingerprint: A set of information elements that identifies a
device or application instance.
$ Fingerprinting: The process of an observer or attacker uniquely
identifying (with a sufficiently high probability) a device or
application instance based on multiple information elements
communicated to the observer or attacker. See [EFF].
$ Item of Interest (IOI): Any data item that an observer or attacker
might be interested in. This includes attributes, identifiers,
identities, communications content, and the fact that a
communication interaction has taken place.
$ Personal Data: Any information relating to an individual who can
be identified, directly or indirectly.
$ (Protocol) Interaction: A unit of communication within a
particular protocol. A single interaction may be comprised of a
single message between an initiator and recipient or multiple
messages, depending on the protocol.
$ Traffic Analysis: The inference of information from observation of
traffic flows (presence, absence, amount, direction, timing,
packet size, packet composition, and/or frequency), even if flows
are encrypted. See [RFC4949].
$ Undetectability: The inability of an observer or attacker to
sufficiently distinguish whether an item of interest exists
or not.
$ Unlinkability: Within a particular set of information, the
inability of an observer or attacker to distinguish whether two
items of interest are related or not (with a high enough degree of
probability to be useful to the observer or attacker).
Cooper, et al. Informational [Page 8]
RFC 6973 Privacy Considerations July 2013
3.3. Identifiability
$ Anonymity: The state of being anonymous.
$ Anonymity Set: A set of individuals that have the same attributes,
making them indistinguishable from each other from the perspective
of a particular attacker or observer.
$ Anonymous: A state of an individual in which an observer or
attacker cannot identify the individual within a set of other
individuals (the anonymity set).
$ Attribute: A property of an individual.
$ Identifiability: The extent to which an individual is
identifiable.
$ Identifiable: A property in which an individual's identity is
capable of being known to an observer or attacker.
$ Identification: The linking of information to a particular
individual to infer an individual's identity or to allow the
inference of an individual's identity in some context.
$ Identified: A state in which an individual's identity is known.
$ Identifier: A data object uniquely referring to a specific
identity of a protocol entity or individual in some context. See
[RFC4949]. Identifiers can be based upon natural names --
official names, personal names, and/or nicknames -- or can be
artificial (for example, x9z32vb). However, identifiers are by
definition unique within their context of use, while natural names
are often not unique.
$ Identity: Any subset of an individual's attributes, including
names, that identifies the individual within a given context.
Individuals usually have multiple identities for use in different
contexts.
$ Identity Confidentiality: A property of an individual where only
the recipient can sufficiently identify the individual within a
set of other individuals. This can be a desirable property of
authentication protocols.
$ Identity Provider: An entity (usually an organization) that is
responsible for establishing, maintaining, securing, and vouching
for the identities associated with individuals.
Cooper, et al. Informational [Page 9]
RFC 6973 Privacy Considerations July 2013
$ Official Name: A personal name for an individual that is
registered in some official context (for example, the name on an
individual's birth certificate). Official names are often not
unique.
$ Personal Name: A natural name for an individual. Personal names
are often not unique and often comprise given names in combination
with a family name. An individual may have multiple personal
names at any time and over a lifetime, including official names.
From a technological perspective, it cannot always be determined
whether a given reference to an individual is, or is based upon,
the individual's personal name(s) (see Pseudonym).
$ Pseudonym: A name assumed by an individual in some context,
unrelated to the individual's personal names known by others in
that context, with an intent of not revealing the individual's
identities associated with his or her other names. Pseudonyms are
often not unique.
$ Pseudonymity: The state of being pseudonymous.
$ Pseudonymous: A property of an individual in which the individual
is identified by a pseudonym.
$ Real Name: See Personal Name and Official Name.
$ Relying Party: An entity that relies on assertions of individuals'
identities from identity providers in order to provide services to
individuals. In effect, the relying party delegates aspects of
identity management to the identity provider(s). Such delegation
requires protocol exchanges, trust, and a common understanding of
semantics of information exchanged between the relying party and
the identity provider.
4. Communications Model
To understand attacks in the privacy-harm sense, it is helpful to
consider the overall communication architecture and different actors'
roles within it. Consider a protocol entity, the "initiator", that
initiates communication with some recipient. Privacy analysis is
most relevant for protocols with use cases in which the initiator
acts on behalf of an individual (or different individuals at
different times). It is this individual whose privacy is potentially
threatened (although in some instances an initiator communicates
information about another individual, in which case both of their
privacy interests will be implicated).
Cooper, et al. Informational [Page 10]
RFC 6973 Privacy Considerations July 2013
Communications may be direct between the initiator and the recipient,
or they may involve an application-layer intermediary (such as a
proxy, cache, or relay) that is necessary for the two parties to
communicate. In some cases, this intermediary stays in the
communication path for the entire duration of the communication;
sometimes it is only used for communication establishment, for either
inbound or outbound communication. In some cases, there may be a
series of intermediaries that are traversed. At lower layers,
additional entities involved in packet forwarding may interfere with
privacy protection goals as well.
Some communications tasks require multiple protocol interactions with
different entities. For example, a request to an HTTP server may be
preceded by an interaction between the initiator and an
Authentication, Authorization, and Accounting (AAA) server for
network access and to a Domain Name System (DNS) server for name
resolution. In this case, the HTTP server is the recipient and the
other entities are enablers of the initiator-to-recipient
communication. Similarly, a single communication with the recipient
might generate further protocol interactions between either the
initiator or the recipient and other entities, and the roles of the
entities might change with each interaction. For example, an HTTP
request might trigger interactions with an authentication server or
with other resource servers wherein the recipient becomes an
initiator in those later interactions.
Thus, when conducting privacy analysis of an architecture that
involves multiple communications phases, the entities involved may
take on different -- or opposing -- roles from a privacy
considerations perspective in each phase. Understanding the privacy
implications of the architecture as a whole may require a separate
analysis of each phase.
Protocol design is often predicated on the notion that recipients,
intermediaries, and enablers are assumed to be authorized to receive
and handle data from initiators. As [RFC3552] explains, "we assume
that the end systems engaging in a protocol exchange have not
themselves been compromised". However, privacy analysis requires
questioning this assumption, since systems are often compromised for
the purpose of obtaining personal data.
Although recipients, intermediaries, and enablers may not generally
be considered as attackers, they may all pose privacy threats
(depending on the context) because they are able to observe, collect,
process, and transfer privacy-relevant data. These entities are
collectively described below as "observers" to distinguish them from
traditional attackers. From a privacy perspective, one important
Cooper, et al. Informational [Page 11]
RFC 6973 Privacy Considerations July 2013
type of attacker is an eavesdropper: an entity that passively
observes the initiator's communications without the initiator's
knowledge or authorization.
The threat descriptions in the next section explain how observers and
attackers might act to harm individuals' privacy. Different kinds of
attacks may be feasible at different points in the communications
path. For example, an observer could mount surveillance or
identification attacks between the initiator and intermediary, or
instead could surveil an enabler (e.g., by observing DNS queries from
the initiator).
5. Privacy Threats
Privacy harms come in a number of forms, including harms to financial
standing, reputation, solitude, autonomy, and safety. A victim of
identity theft or blackmail, for example, may suffer a financial loss
as a result. Reputational harm can occur when disclosure of
information about an individual, whether true or false, subjects that
individual to stigma, embarrassment, or loss of personal dignity.
Intrusion or interruption of an individual's life or activities can
harm the individual's ability to be left alone. When individuals or
their activities are monitored, exposed, or at risk of exposure,
those individuals may be stifled from expressing themselves,
associating with others, and generally conducting their lives freely.
They may also feel a general sense of unease, in that it is "creepy"
to be monitored or to have data collected about them. In cases where
such monitoring is for the purpose of stalking or violence (for
example, monitoring communications to or from a domestic abuse
shelter), it can put individuals in physical danger.
This section lists common privacy threats (drawing liberally from
[Solove], as well as [CoE]), showing how each of them may cause
individuals to incur privacy harms and providing examples of how
these threats can exist on the Internet. This threat modeling is
inspired by security threat analysis. Although it is not a perfect
fit for assessing privacy risks in Internet protocols and systems, no
better methodology has been developed to date.
Some privacy threats are already considered in Internet protocols as
a matter of routine security analysis. Others are more pure privacy
threats that existing security considerations do not usually address.
The threats described here are divided into those that may also be
considered security threats and those that are primarily privacy
threats.
Cooper, et al. Informational [Page 12]
RFC 6973 Privacy Considerations July 2013
Note that an individual's awareness of and consent to the practices
described below may change an individual's perception of and concern
for the extent to which they threaten privacy. If an individual
authorizes surveillance of his own activities, for example, the
individual may be able to take actions to mitigate the harms
associated with it or may consider the risk of harm to be tolerable.
5.1. Combined Security-Privacy Threats
5.1.1. Surveillance
Surveillance is the observation or monitoring of an individual's
communications or activities. The effects of surveillance on the
individual can range from anxiety and discomfort to behavioral
changes such as inhibition and self-censorship, and even to the
perpetration of violence against the individual. The individual need
not be aware of the surveillance for it to impact his or her privacy
-- the possibility of surveillance may be enough to harm individual
autonomy.
Surveillance can impact privacy, even if the individuals being
surveilled are not identifiable or if their communications are
encrypted. For example, an observer or eavesdropper that conducts
traffic analysis may be able to determine what type of traffic is
present (real-time communications or bulk file transfers, for
example) or which protocols are in use, even if the observed
communications are encrypted or the communicants are unidentifiable.
This kind of surveillance can adversely impact the individuals
involved by causing them to become targets for further investigation
or enforcement activities. It may also enable attacks that are
specific to the protocol, such as redirection to a specialized
interception point or protocol-specific denials of service.
Protocols that use predictable packet sizes or timing or include
fixed tokens at predictable offsets within a packet can facilitate
this kind of surveillance.
Surveillance can be conducted by observers or eavesdroppers at any
point along the communications path. Confidentiality protections (as
discussed in Section 3 of [RFC3552]) are necessary to prevent
surveillance of the content of communications. To prevent traffic
analysis or other surveillance of communications patterns, other
measures may be necessary, such as [Tor].
Cooper, et al. Informational [Page 13]
RFC 6973 Privacy Considerations July 2013
5.1.2. Stored Data Compromise
End systems that do not take adequate measures to secure stored data
from unauthorized or inappropriate access expose individuals to
potential financial, reputational, or physical harm.
Protecting against stored data compromise is typically outside the
scope of IETF protocols. However, a number of common protocol
functions -- key management, access control, or operational logging,
for example -- require the storage of data about initiators of
communications. When requiring or recommending that information
about initiators or their communications be stored or logged by end
systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize
the potential for that information to be compromised and for that
potential to be weighed against the benefits of data storage. Any
recipient, intermediary, or enabler that stores data may be
vulnerable to compromise. (Note that stored data compromise is
distinct from purposeful disclosure, which is discussed in
Section 5.2.4.)
5.1.3. Intrusion
Intrusion consists of invasive acts that disturb or interrupt one's
life or activities. Intrusion can thwart individuals' desires to be
left alone, sap their time or attention, or interrupt their
activities. This threat is focused on intrusion into one's life
rather than direct intrusion into one's communications. The latter
is captured in Section 5.1.1.
Unsolicited messages and denial-of-service attacks are the most
common types of intrusion on the Internet. Intrusion can be
perpetrated by any attacker that is capable of sending unwanted
traffic to the initiator.
5.1.4. Misattribution
Misattribution occurs when data or communications related to one
individual are attributed to another. Misattribution can result in
adverse reputational, financial, or other consequences for
individuals that are misidentified.
Misattribution in the protocol context comes as a result of using
inadequate or insecure forms of identity or authentication, and is
sometimes related to spoofing. For example, as [RFC6269] notes,
abuse mitigation is often conducted on the basis of the source IP
address, such that connections from individual IP addresses may be
prevented or temporarily blacklisted if abusive activity is
determined to be sourced from those addresses. However, in the case
Cooper, et al. Informational [Page 14]
RFC 6973 Privacy Considerations July 2013
where a single IP address is shared by multiple individuals, those
penalties may be suffered by all individuals sharing the address,
even if they were not involved in the abuse. This threat can be
mitigated by using identity management mechanisms with proper forms
of authentication (ideally with cryptographic properties) so that
actions can be attributed uniquely to an individual to provide the
basis for accountability without generating false positives.
5.2. Privacy-Specific Threats
5.2.1. Correlation
Correlation is the combination of various pieces of information
related to an individual or that obtain that characteristic when
combined. Correlation can defy people's expectations of the limits
of what others know about them. It can increase the power that those
doing the correlating have over individuals as well as correlators'
ability to pass judgment, threatening individual autonomy and
reputation.
Correlation is closely related to identification. Internet protocols
can facilitate correlation by allowing individuals' activities to be
tracked and combined over time. The use of persistent or
infrequently replaced identifiers at any layer of the stack can
facilitate correlation. For example, an initiator's persistent use
of the same device ID, certificate, or email address across multiple
interactions could allow recipients (and observers) to correlate all
of the initiator's communications over time.
As an example, consider Transport Layer Security (TLS) session
resumption [RFC5246] or TLS session resumption without server-side
state [RFC5077]. In RFC 5246 [RFC5246], a server provides the client
with a session_id in the ServerHello message and caches the
master_secret for later exchanges. When the client initiates a new
connection with the server, it re-uses the previously obtained
session_id in its ClientHello message. The server agrees to resume
the session by using the same session_id and the previously stored
master_secret for the generation of the TLS Record Layer security
association. RFC 5077 [RFC5077] borrows from the session resumption
design idea, but the server encapsulates all state information into a
ticket instead of caching it. An attacker who is able to observe the
protocol exchanges between the TLS client and the TLS server is able
to link the initial exchange to subsequently resumed TLS sessions
when the session_id and the ticket are exchanged in the clear (which
is the case with data exchanged in the initial handshake messages).
Cooper, et al. Informational [Page 15]
RFC 6973 Privacy Considerations July 2013
In theory, any observer or attacker that receives an initiator's
communications can engage in correlation. The extent of the
potential for correlation will depend on what data the entity
receives from the initiator and has access to otherwise. Often,
intermediaries only require a small amount of information for message
routing and/or security. In theory, protocol mechanisms could ensure
that end-to-end information is not made accessible to these entities,
but in practice the difficulty of deploying end-to-end security
procedures, additional messaging or computational overhead, and other
business or legal requirements often slow or prevent the deployment
of end-to-end security mechanisms, giving intermediaries greater
exposure to initiators' data than is strictly necessary from a
technical point of view.