Feature Interactions and Data Privacy
Rick Kuhn
National Institute of Standards and Technology
kuhn@nist.gov
The feature interaction problem is well known in telecommunications,
but it can appear in any system that includes a variety of complex,
interacting functions, particularly those where components are distributed
and independently programmed. Briefly, feature interaction refers
to system functions influencing the behavior of other functions so
that the system behaves in unanticipated ways. Current trends such
as internet telephony and “web 2.0” services will expand,
rather than reduce, the potential for some classes of unanticipated
interactions because they involve greater distribution and more independence
among implementers. Unintended feature interactions can result in
a variety of privacy and security violations.
For a simple, privacy-relevant example from telecommunications, consider
the caller-ID blocking feature. Users may have a variety of legitimate
reasons to block caller ID, but feature interaction might make it
problematic as a means of protecting privacy. One published method
of defeating caller-ID blocking is described in [1]: “Forward
your phone line to a friend who lives in another LATA. When he receives
the anonymous phone call, have him use *69 Call Return to dial to
offending party back. As he is now placing a long distance phone call,
the telephone number of the anonymous caller will show up on your
friend’s phone bill at the end of the month.” The fundamental
problem in this example is that user-desired features (number blocking
vs. long-distance billing accuracy) conflict with one another, and
the resolution of this conflict fails to meet the user’s expectation
of privacy. Note that other means of resolving this conflict also
result in violating a user’s expectation. With most telephone
service today, the technique described above cannot be used because
call return will not work in this situation, thus subjecting the recipient
to annoying or harassing anonymous calls, which is also a privacy
concern.
Although originally arising in the context of traditional circuit-switched
telephony, feature interactions have been identified in web services,
internet telephony, and in the more general case of privacy and security
policies. Resolving interactions in all of these domains can be complicated
by the internet’s trust model. Continuing with our example above,
a traditional centrally-managed switch could allow the called party
to screen calls from the harassing caller using CID blocking, yet
allow other CID-blocked calls through. However, this is no longer
possible with internet telephony, because there is no trusted third
party switch.
As web services handle more privacy-relevant transactions, the problems
that lead to feature interactions in telephony can have consequences
involving much larger volumes of data. Signals/requests have different
meanings on each end of a transaction, hierarchies of rules may have
conflicts among a chain of rules, user roles may have different meanings
among different organizations with consequent variations in privileges,
and functionality developed by may different organizations may have
subtle interoperability problems and may change across time. Adding
complex regulations such as Gramm-Leach-Bliley and HIPAA to varying
corporate privacy policies makes the potential for unexpected interactions
even greater.
Research questions:
Can feature interaction analysis and control methods developed for
telecommunications be applied successfully to web services and policies?
What are the limits to controlling feature interactions with the current
internet trust model? Can interactions between web applications be
controlled sufficiently to prevent unwanted feature interactions while
still allowing necessary functions? Do privacy violations from feature
interactions really matter? (This is just a particular instantiation
of Ross Anderson’s question, “Why do people say they value
privacy but act as if they don’t?”)
[1] alt-2600 FAQ. http://www.usenet.com/newsgroups/news.answers/msg03904.html