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