=Paper=
{{Paper
|id=None
|storemode=property
|title=A Framework for Transforming Abstract Privacy Models into Implementable UbiComp System Requirements
|pdfUrl=https://ceur-ws.org/Vol-787/paper4.pdf
|volume=Vol-787
}}
==A Framework for Transforming Abstract Privacy Models into Implementable UbiComp System Requirements==
https://ceur-ws.org/Vol-787/paper4.pdf
Modiquitous 2011 Proceedings
A Framework for Transforming Abstract Privacy Models
into Implementable UbiComp System Requirements
Ivan Gudymenko Katrin Borcea-Pfitzmann
Faculty of Computer Science Faculty of Computer Science
Dresden University of Technology Dresden University of Technology
ivan.gudymenko@gmail.com katrin.borcea@tu-dresden.de
ABSTRACT Whereas UbiComp introduces a set of tangible benefits for
During the development of UbiComp systems, privacy and the user1 , it also raises serious privacy concerns. The reason
security issues often come into play only after the design for this is that the advances of sensing technology and mem-
process is complete. The main development effort is typi- ory amplification have provided UbiComp systems with
cally concentrated on the direct functionality of the system, qualitatively new opportunities of covert surveillance. Marc
which too often results in immaturity of privacy compliance Langheinrich claimed in [11] that ”ubiquitous devices will
of the end product. This is one of the main burdens on the per definition be ideally suited for covert operation and il-
way to acceptance of such systems among potential users legal surveillance, no matter how much disclosure protocols
and to commercial success thereof as a consequence. are being developed”.
We claim that ensuring privacy and security in any UbiComp Privacy concerns of the users can impede the development
system should be taken into account already at the system and especially the deployment of UbiComp systems. To give
design stage and should continue throughout all steps of the an example, alongside its intended purpose, Smart Grid sys-
development of a UbiComp system. In this paper, we focus tems may pave the way to privacy violation scenarios (see
on privacy issues of UbiComp, namely we consider a frame- [8, 13] for more details.)
work which enables for consistent transformation of abstract
privacy models into a set of implementable system require- That means, that deploying a UbiComp system in a privacy-
ments. A general approach to creating an abstract privacy preserving manner will increase the likelihood of its accep-
model, which takes into account social, legal, and functional tance among potential users and broaden the target audience.
issues, is outlined. The further transformation of the model Moreover, having created the infrastructure of a UbiComp
into a set of system-specific and platform-independent re- system, it is relatively easy to deliver the end product to cus-
quirements is described. tomers (to deploy the system, e.g. accompany individuals
with respective sensors) since ”individual investments pay
off immediately” [14]. Due to this fact and because of the
Author Keywords
higher acceptance among customers, a system with decent
Ubiquitous Computing, Privacy, Privacy Model privacy management mechanisms is more likely to be com-
mercially successful.
ACM Classification Keywords
K.6.5 MANAGEMENT OF COMPUTING AND INFOR- In this paper, we outline how a UbiComp system can be
MATION SYSTEMS: Security and Protection—Privacy designed in a privacy-preserving way. Namely, a concept,
which describes how privacy requirements can be elaborated
and how respective privacy mechanisms can be ”woven” into
General Terms UbiComp system’s functionality, is considered. This ap-
Design proach enables for privacy to be inherently built into the
UbiComp system under development, which should facili-
INTRODUCTION tate privacy management in the deployed system and make
Marc Weiser, one of the pioneers in the area of Ubiqui- it more efficient.
tous Computing (UbiComp), outlined this concept as ”The
idea of integrating computers seamlessly into the world at USED TERMINOLOGY
large [...]” [21]. Frank Stajano in his book [18] described Privacy is a broad notion and defining it is a difficult task
UbiComp as ”[...] a scenario in which computing is om- due to the substantial difference of privacy perception among
nipresent, and particularly in which devices that do not look individuals. However, in order to avoid ambiguity and not to
like computers are endowed with computing capabilities.” confuse the reader, we present our own understanding of this
According to him, UbiComp does not imply ”the computer notion.
on every desk” but rather embodying the computational 1
For example, unobtrusiveness of the devices with respect to their
power into different parts of the surrounding environment size and operation mode, ability of the user to concentrate on the
(clothes, household appliances, etc.), that normally are not specific (business) tasks without having to pay much attention to
considered to be equipped with it thus making them ”smart”. the management of the underlying technical system, etc.
I. Gudymenko, K. Borcea-Pfitzmann: A Framework for Transforming Abstract Privacy Models into 27
Implementable UbiComp System Requirements. Proc. of 1st International Workshop on Model-based
Interactive Ubiquitous System 2011, Pisa, Italy, June 13, 2011, http://ceur-ws.org/Vol-787
Modiquitous 2011 Proceedings
The widespread ways of understanding privacy are ”the right privacy and security requirements are considered. In or-
to be let alone” [20] and also ”the right to be forgotten” [19, der to provide for flexibility in future, a concept of exten-
5]. One of the common delusions is that the ”more” pri- sion/variation hooks with respect to privacy and security
vacy the individual has, the better his identity is protected. requirements is used.
However, privacy does not have a monotonic behavior. The
optimum is situated in the vicinity of the ”golden middle” 2. At initialization time, an instantiation of generic require-
because individuals live in society and therefore experience ments considered during the first step is carried out. Also,
the need for social interaction. This implies exchanging of the so-called binding3 of extension/variation hooks is per-
certain pieces of private information between communicat- formed.
ing entities. We claim, however, that individuals, without 3. At run-time, the previously implemented privacy and se-
fully realizing it, need adequate and appropriate privacy. curity management mechanisms are used. In order to
Managing privacy implies constant processes of negotiation provide for dynamic adaptation (e.g in response to con-
between the parties involved and also with the person2 con- text changes), the concept of dynamic extension/variation
cerned of which personal information of that individual is hooks may be exploited.
given out in which situation and enforcing that his/her pri-
vacy policy is being followed. Thus, in order to take the
aforementioned issues into account, we adhere to the fol- System
Initialization Run-time
Design Stage
lowing definition of privacy, elaborated in [3]:
D EFINITION. Privacy of an entity is the result of negotiat- ● considering generic ●instantiation of generic ●active use of previously
security/privacy privacy and security implemented requirements
ing and enforcing when, how, to what extent, and in which requirements requirements
context which data of this entity is disclosed to whom. ●dynamic adaptation
● security and privacy ● implementing mechanisms should
extensibility/variability security and privacy be considered
hooks (allows for extensions/variations (e.g. via dynamic privacy/
This definition takes into account the communication part- flexibility in future) (via the corresponding security extension/variation
ner, the context, in which the communication takes place, hooks binding) hooks)
and the negotiation processes, which are needed to flexi- ●adding all the extensions
and variations to the list of
bly manage privacy. This is necessary to reason which per- generic privacy and security
sonal information an individual is willing to disclose to get mechanisms
which kind of service and to solve possible conflicts, which
might arise due to the contradiction of privacy goals of dif- Figure 1. The process of making privacy requirements inherently built
ferent individuals. The concept of multilateral security [1, into the UbiComp system’s functionality.
15] provides for a flexible and effective way of negotiating
such conflicts in a privacy-respecting environment. More- PRIVACY IN UBICOMP: PECULIARITIES
over, which personal data is disclosed, its granularity, and In order to provide for effective privacy management in Ubi-
the enforcement of an individual’s privacy requirements are Comp systems, it is sensible to explore which peculiarities
also considered in the definition above. privacy issues have in this domain.
MAKING PRIVACY INHERENTLY BUILT INTO THE UBI- The pervasive nature of UbiComp may impose certain con-
straints on the users of the system in that it might be hard for
COMP SYSTEM’S FUNCTIONALITY
them to actually refuse to use it. This problem raises privacy
In order to provide for a privacy-respecting and secure Ubi- concerns and is called ”the disability to opt-out” [7], where
Comp system, the process of ensuring privacy and security the following example was stated: it would be extremely dif-
should begin already at the system design stage, the concept ficult if not impossible to refuse to use the Ubiquitous RFID
of which is known as ”privacy by design”, and it should con- system in case ”such devices [RFID tags] get affixed to bank
tinue throughout all the other steps of system development. notes, ID cards, and every item that one can buy in a store”.
If opt-out is nevertheless made possible, the following prob-
It is clearly impossible to predict the security and privacy
lems might arise:
requirements of all potential users and also their variations
in response to future context changes during the system de- • much inconvenience caused by opt-out (e.g. postal mail
sign stage. In order to provide for flexibility and extensi- of a check instead of a credit card payment);
bility, a concept of special extension/variation points (so-
called hooks) for unforeseeable extensions/variations of pri- • opt-out can look suspicious (a denial to give away cer-
vacy and security requirements can be utilized. tain data in particular situations may look suspicious, e.g.
switching the location sensor off during the time when a
Thus, the process of ”weaving” privacy and security mech- crime was committed, etc.)
anisms into the UbiComp system’s functionality can be di-
vided into the following steps, depicted in Figure 1: Another privacy problem specific to UbiComp is a constantly
rising likelihood that intimate conversations might become
1. During the system design stage, generic (i.e. foreseeable) 3
The term is adopted from programing. It basically means that
2
In each situation an individual is constantly performing reasoning the corresponding hooks are being directly used, i.e. exten-
about what he/she is willing to disclose to get which kind of service. sion/variation has taken place via the hook.
28
Modiquitous 2011 Proceedings
publicly available. The authors of [7] call this problem ”the
Negotiation, team work
loss of ephemeral communication”. Similarly, Schneider
states: ”The moral is clear: If you type it and send it, pre-
SE PE FE
pare to explain it in public later”. In this case, the problem
of violation of contextual integrity arises. It was described in
[4] as ”falsifying the context in which information has been
communicated” by ”putting it into a wrong context”. For in- Mechanism of Merging
stance, consider an example of a debating club: a person re- ●
the Requirements:
Merging the Requirements
Conflict Resolution
ceives a topic ”Should foreigners be allowed to work in Ger- ●
●Consistency check
many?” and should state arguments against it. If his speech Mechanism of Merging
is put into another context later on (e.g. shown at the TV) ●
the Requirements:
Merging the Requirements
A Set of Security and Privacy Requirements
without specifying the original context, the speaker’s reputa- ●
●
Conflict Resolution
Consistency check
tion might be dramatically spoiled (i.e. the ”decontextualiza-
tion of communicated information” has turned ”innocuous”
A Set of Direct Functionality System Requirements
information into the ”mortifying” one [4]). with Privacy and Security Requirements woven into it
In [14], it was outlined that the privacy of an individual in
UbiComp could be enhanced by changing the main direc- Figure 2. A process of joint development of privacy and security re-
tion of information flow to ”infrastructure → user” and ap- quirements for a UbiComp system.
plying filtering in order to avoid overload or annoyance of SE = Security Engineer.
PE = Privacy Engineer.
the user. This change of information flow ”enables a quan- FE = Direct Functionality System Engineer.
tum leap in privacy by avoiding the possibility to gather huge
amounts of personal data”. In this case, the infrastructure
might also broadcast security and privacy advices (e.g. pos- DESIGNING PRIVACY AND SECURITY REQUIREMENTS
sible options, etc.) to the user if it appears to be of mutual IN A JOINT FASHION
interest to both, the provider(s) of the infrastructure and the Privacy and security are closely connected to each other. Im-
users. portant is to understand that neither of them is a byproduct
of the other one. Only if having considered both, privacy and
Thus, in order to provide for a privacy-respecting UbiComp
security, can the developed UbiComp system be regarded as
system, the following issues have to be taken into account:
privacy-respecting and secure.
1. Provide for support of opt-in/opt-out according to the in-
For this reason, we suggest that privacy and security require-
dividual’s choice. At the same time, mechanisms against
ments are elaborated in a joint fashion by two cooperative
irresponsible behavior should be taken into account (i.e.
entities: the Privacy Engineer (PE) and the Security Engi-
non-repudiation of performed actions)4 .
neer (SE) (see Figure 2). These entities are responsible for
2. Anonymization and encryption techniques for resource- the whole design process of privacy and security policies re-
constrained devices should be carefully considered in or- spectively as well as for administrating and managing pri-
der to mitigate the problem of disclosure of the content of vacy and security in the deployed system. The process of
intimate conversations to public. designing policies for a privacy-respecting and secure Ubi-
Comp system should be carried out in the presence of col-
3. Mechanisms for protecting contextual integrity of data laboration between the PE and the SE. Further negotiation
should be provided (especially in case of voice/video with the Functionality Engineer (FE), who is responsible for
recording services, personal communication services, the design of the direct functionality of the system, should be
etc.) For example, attaching a special protected tag to considered as well. The reason for this is that it is expected
data, which will specify the original context and protect that the requirements elaborated by the PE and the SE along
the information from decontextualization, should be con- with the ones of the FE may not be free of conflicts. That
sidered. The tag itself can be authenticated by the indi- is why conflict resolution mechanisms should be considered
vidual who owns the information or by the group of in- during the process of merging the requirements. In order to
dividuals to whom the data is relevant (using multi-party ensure that the requirements are consolidated in a consistent
authentication, for instance). way (i.e. specific requirements of each area after the merg-
4. It is also highly advisable to design a UbiComp system ing conform to the ones before the merging), consistency
adhering to the concept of reverse information flow (”in- checks should also be performed after the merging.
frastructure → user”) where possible.
4
Consider an example of an ”Ambient Coffee Machine” service PRIVACY MODELING
in the organization, where users are able to drink coffee without In order to provide for privacy requirements, which are go-
being obliged to pay for it at the spot but required to do so at the ing to enable for efficient privacy management in the de-
end of the month. An irresponsible user might want to be using ployed system, we suggest that a corresponding model of
such a service for several weeks and then decide to opt-out ”due to
privacy reasons” without paying. In this case, authentication and privacy for the target domain of UbiComp is created. The
legal enforcement, for instance, can be used to prevent such case respective requirements can be inferred from the model later
from happening. on. Here, with the term ”abstract privacy model” we refer
29
Modiquitous 2011 Proceedings
to a high-level model, which takes into account social, legal, meta-metamodel → metamodel → model, see [2] for more
and functional issues and enables the developer to perform a details). The task of providing for a consistent privacy model
combination of privacy issues from different fields in an in- and transforming it into a set of implementable system re-
terdisciplinary manner. Having an abstract privacy model in quirements is within the competence of the Privacy Engineer
the first step will facilitate the process of taking various and (cf. Figure 2).
often illusive privacy issues and considerations of the Ubi-
Comp area into account and make the approximation to the This approach implies several steps, which are depicted in
real world scenario more accurate. Figure 3.
Modeling privacy is not a trivial task. Existing privacy mod- 1. The Privacy Engineer entity (that might be a group of pri-
els are often abstract and difficult to transform into a set of vacy experts in practice) creates an abstract privacy model.
system requirements. For instance, the model introduced in This implies the following steps:
[12] deals with the concept of ”crossing personal borders”,
i.e. privacy violation occurs when ”personal borders” of an • investigating the privacy area of the future UbiComp
individual are crossed. The author provides for a classifi- system deployment, i.e. determining individuals’ pri-
cation of privacy-violation scenarios, analyzes the privacy vacy concerns, possible privacy threats, taking into
concerns of the individuals and also considers the impact account various cultural differences in perception of
of technological advance on privacy. However, the model privacy, etc.;
is described in a loose and nontechnical way, which might • reviewing the current status of legal basis in the area
impede its adoption for the process of inference of privacy of interest (i.e. finding out which privacy-related laws
requirements. apply to the future UbiComp system deployment, how
the situation is legally regulated and determining the
Another model was introduced in [17], which focuses on the weak sides of it);
activities that invade privacy: information collection, infor- • creating the joint picture of privacy-related issues in
mation processing, information dissemination, and invasion. the field;
The model consists of the data subject (the individual) and • on the aforementioned basis, an abstract pri-
the data holders (who collect, process and disseminate pri- vacy model is created (system- and platform-
vate information). Similarly to the above mentioned model, independent).
it provides for a rather notional description of privacy issues
and does not specify how the respective requirements can be 2. Next, a consistent transformation of the abstract privacy
inferred and further implemented. model created during the first step into a set of system-
specific requirements is carried out. If some of the model
Moreover, new approaches to modeling of privacy should preferences can not be transformed, a possible refinement
also be considered because of the rapid evolution of technol- of the abstract model should be considered. The result of
ogy. For instance, Shapiro in [16] gives an example of Fair the second step is a set of implementable system require-
Information Practices that have been commonly used for un- ments.
derstanding informational privacy. However, he claims that
”As more things become digitized, informational privacy in- 3. The last step is the actual implementation (”weaving” of
creasingly covers areas for which Fair Information Practices privacy mechanisms into the UbiComp system’s function-
were never envisioned” (e.g. genetics, biometrics, etc.). ality).
UbiComp definitely introduces a serious challenge regarding
An abstract Privacy Model
privacy modeling, translating a model into a set of system re- (System- and Platform- independent)
quirements and implementing it. It is of little help just hav-
ing a good model of privacy if it can not be adopted into tech- Transformation
nical schemes of privacy regulation and thus be used within a
UbiComp system. Provided that a decent and implementable System Privacy Requirements
model of privacy is available, respective privacy mechanisms (System-specific, Platform-independent)
should be woven into the UbiComp system functionality at
the system design stage to allow for designing inherently Transformation
privacy-respecting systems.
Implementation
(System- and Platform- specific)
Therefore, it would be helpful to consider a framework which
will enable for consistent transformation of an abstract pri-
vacy model into functional requirements of a UbiComp sys- Figure 3. A general structure of a framework for transforming abstract
tem, which in turn can be implemented. privacy models into implementable requirements.
The above mentioned approach introduces a set of challenges:
Privacy Modeling Framework
The concept of the Privacy Modeling Framework is similar 1. Merging the individual privacy requirements with legal is-
to the meta-modeling approach used in programming (e.g. sues in the area of interest (step one) is a difficult task.
30
Modiquitous 2011 Proceedings
The reason for this is that the former is elusive and not it is not possible to provide for a full-fledged support of pri-
easy to specify. The latter is well specified but coarse- vacy management, having considered this issue after design-
grained and hence inflexible. For example, suppose it is ing the direct functionality of a UbiComp system, i.e. build-
written in the privacy law that location of the individual is ing privacy on top of the system. That is why the process
private information and any exposure of this information of ensuring privacy and security has to begin at the system
to a third party is subject to law violation. The situation design stage and it should continue throughout all the other
when the individual is willing for his location to be known steps of system development.
to some of his friends at certain times, is not considered,
however. Moreover, the legal part strongly depends on the Thus, an approach to making privacy inherently built into the
region, which raises the question of international interop- UbiComp system’s functionality was considered. In order to
erability and aggravates the outsourcing problem, i.e. the provide for dynamic privacy management (e.g. to enable
privacy-sensitive data that is governed by law in one coun- the consideration of unforeseeable extensions towards pri-
try, might be under threat of violation in the other one. vacy requirements), a concept of special extension/variation
This happens due to the absence of a unified international points can be utilized while designing a system.
law protection system of privacy-sensitive data.
Providing for efficient privacy management requires the ex-
Having managed to specify privacy requirements of the ploration of the peculiarities of privacy in the target domain.
individual and taken the legal prospective into account, Also, respective recommendations for developing appropri-
the consistency of the joint abstract model should be con- ate privacy policies should be formulated. Having consid-
sidered. ered this issue, we presented our concept of designing pri-
vacy and security requirements in a joint fashion. The reason
2. The second step (transformation of abstract privacy model for this is that privacy and security are closely connected and
into a set of requirements) implies the existence (or cre- mutually affect each other. According to this concept, pri-
ation) of a mature language that will enable to express vacy and security requirements should be considered by two
the abstract model in a standardized, ready-to-implement cooperative entities: the Privacy Engineer (PE) and the Se-
format. To the best of our knowledge, only a few ef- curity Engineer (SE). Moreover, further negotiation with the
forts have been made in this direction by now. The au- designer of the direct functionality of the system (Function-
thors of [9] described their privacy model using a pri- ality Engineer) is considered along with conflict resolution
vacy control language that ”includes user consent, obli- mechanisms.
gations, and distributed authorization”. In [10], a privacy-
specific access control language was used to manage pri- The creation of an abstract privacy model was suggested to
vacy in the environment of so-called ”Platform for En- enable effective development of privacy requirements, which
terprise Privacy Practices (E-P3P)”, which defines tech- take various privacy issues and considerations of the Ubi-
nology for privacy-enabled management and exchange of Comp area into account and provide for a better approxima-
customer data. The authors in [6] showed how a privacy tion to the real world scenario. Respective privacy require-
policy can ”be specified and implemented according to ments can be further inferred from the model. This can be
the Generalized Framework for Access Control (GFAC)- done within our Privacy Modeling Framework, which con-
approach”. In order to successfully complete the second siders the creation of an abstract, domain-specific privacy
step, it should be decided by which means the abstract model by the PE entity, further inferring respective require-
model should be specified in the most comprehensive and ments from it, and, lastly, implementing them into the Ubi-
consistent way (e.g. which language to choose or even to Comp system’s functionality.
introduce a new one).
Having described our conceptual view on ensuring privacy
3. Along with privacy-specific questions, general framework- in a UbiComp system, more concrete ways of creating an ab-
related issues arise: stract privacy model, means of specifying the requirements
and necessary recommendations towards their implementa-
• The framework is described in an abstract way. That tion are to be elaborated. Finally, applying the concept to a
is why the ways of its implementation should be out- particular real use case scenario is to be realized.
lined. Moreover, it should also be considered, which
degree of automation of the transformation process
can be achieved.
ACKNOWLEDGEMENT
• Next, the consistency of the performed transforma-
tion should be carefully considered. Surely, certain The authors would like to express their gratitude to a great
trade-offs are going to arise. Their impact on the ac- researcher and friend Andreas Pfitzmann who passed away
curacy of the implemented privacy model should be in September 2010. He was not only a highly qualified pro-
assessed. fessional but also a very kind and responsive person who
inspired the people around him on their way to scientific ex-
cellence.
CONCLUSION AND FUTURE WORK
The paper has presented an approach to designing an inher- This paper is to a large extent influenced by discussions with
ently privacy-respecting UbiComp system. We claim that Andreas and is written in commemoration of him.
31
Modiquitous 2011 Proceedings
REFERENCES 14. Pfitzmann, A. Accompanying Ambient Intelligence
1. Andreas Pfitzmann. Multilateral Security in (AAmI) – Why You should take your Sensors with
Communications. Addison-Wesley-Longman, 1999, You. A Sketch on the Future of privacy-aware, secure
ch. Technologies for Multilateral Security, 85–91. Ambient Intelligence., Apr. 2010.
2. Assmann, U., Zschaler, S., and Wagner, G. Ontologies, 15. Rannenberg, K. Multilateral security: A concept and
Meta-models, and the Model-Driven Paradigm. examples for balanced security, 2000.
Ontologies for Software Engineering and Software
Technology (2006), 249–273. 16. Shapiro, S. S. Privacy by design: moving from art to
practice. Commun. ACM 53 (June 2009), 27–29.
3. Berg, M., and Borcea-Pfitzmann, K. Implementability
of the Identity Management Part in Pfitzmann/Hansen’s 17. Solove, D. J. A taxonomy of privacy. University of
Terminology for a Complex Digital World. In Pennsylvania Law Review 154, 3 (Jan. 2006), 477 pp.
Proceedings of PrimeLife / IFIP Summerschool on GWU Law School Public Law Research Paper No. 129.
Privacy and Identity Management for Life,
18. Stajano, F. Security for Ubiquitous Computing. John
S. Fischer-Hübner, M. Hansen, P. Duquenoy, and
Wiley & Sons, LTD, 2002.
R. Leenes, Eds., IFIP Advances in Information and
Communication Technology, Springer (2011). 19. Warman, M. EU proposes online right ’to be forgotten’,
4. Borcea-Pfitzmann, K., Pfitzmann, A., and Berg, M. Nov. 2010. Accessed online on 05.04.2011. The
Privacy 3.0 : = Data Minimization + User Control + Telegraph.
Contextual Integrity (Privatheit 3.0 : = http://www.telegraph.co.uk/technology/internet/8112702/EU-
Datenminimierung + Nutzerkontrolle + Kontextuelle proposes-online-right-to-be-forgotten.html.
Integrität). IT - Information Technology 53, 1 (2011), 20. Warren, S. D., and Brandeis, L. D. The right to privacy.
34–40. Harward Law Review 4, 5 (Dec. 1890), 193–220.
5. Dou, E. EU proposes online right ’to be forgotten’, 21. Weiser, M. The Computer for the 21st Century.
Nov. 2010. Accessed online on 05.04.2011. Reuters. Scientific American (Feb. 1991).
http://www.reuters.com/article/2011/03/17/us-eu-
internet-privacy-idUSTRE72G48Z20110317.
6. Fischer-Hübner, S., and Ott, A. From a formal privacy
model to its implementation. In National Infromation
Systems Security Conference (Oct. 1998).
7. Henrici, D. RFID Security and Privacy. Springer, 2008.
8. Herold, R. SmartGrid Privacy Concerns, Sept. 2009.
Accessed online on 03.04.2011.
http://www.privacyguidance.com/files/SmartGridPrivacy
ConcernsTableHeroldSept 2009.pdf.
9. Karjoth, G., and Schunter, M. A privacy policy model
for enterprises. In Computer Security Foundations
Workshop, 2002. Proceedings. 15th IEEE (2002),
271–281.
10. Karjoth, G., Schunter, M., and Waidner, M. Platform
for enterprise privacy practices: Privacy-enabled
management of customer data. Springer (2002), 69–84.
11. Langheinrich, M. Privacy by Design – Principles of
Privacy-Aware Ubiquitous Systems. In Ubicomp 2001:
Ubiquitous Computing, G. Abowd, B. Brumitt, and
S. Shafer, Eds., vol. 2201 of Lecture Notes in Computer
Science. Springer Berlin / Heidelberg, 2001, 273–291.
12. Marx, G. T. Murky conceptual waters: The public and
the private. Ethics and Inf. Technol. 3 (Sept. 2001),
157–169.
13. Pentland, W. Why Smart People Are Suspicious of
Smart Me-
ters, Dec. 2010. Accessed online on 01.04.2011. Forbes.
http://blogs.forbes.com/williampentland/2010/12/10/why-
smart-people-are-suspicious-of-smart-meters.
32