Data Confidentiality Workshop
Home Workshop Agenda Participants Travel Information

 

Contact

 


WORKSHOP ON DATA CONFIDENTIALITY

September 6-7, 2007 in Arlington, VA

White Paper & Bio


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

 

Rick Kuhn

NIST

 

 

Biographical Data

 

Rick Kuhn is a computer scientist with the U.S. National Institute of Standards and Technology. His primary technical interests are in information security, software assurance, and empirical studies of software failure, currently focusing on research in combinatorial testing. He co-developed the role based access control model (RBAC) used throughout industry and led the effort to establish RBAC as an ANSI standard. For development and advancement of RBAC he received a gold medal award for scientific/engineering achievement from the U.S. Dept. of Commerce, and the Technology Transfer award from the Federal Laboratory Consortium. He is currently an editor and editorial board member of IEEE Security and Privacy and previously served as Program Manager for the Committee on Applications and Technology of the President's Information Infrastructure Task Force. He received a BA and MBA from William & Mary and an MS in computer science from the University of Maryland, College Park, and is a senior member of IEEE.