Design patterns have been proposed as a method to improve the consistent application of proven solutions across designs. Privacy in operational IoT blockchains today is mostly an attestation from the operator of the service based on IoT. Privacy testing in operational systems an opportunity for further improvement. Privacy risks, threat model and requirements are continuing to evolve and IoT systems will need to evolve with them. [Alqassam 2014]. Privacy threats need to be managed throughout the operational life cycle of the IoT blockchain including changing sensors, upgrading software, etc. Privacy patterns can help maintain consistency across these disruptions; though testing and attestations will also have a role to play.
Privacy patterns for
IoT Blockchain Design
Developers often use the vocabulary of data security to approach privacy challenges, and software architectural patterns frame privacy solutions that are used throughout the development process [Hadar 2018]. There are over 100 IoT design patterns in the literature, but very little explicit identification of IoT design pattern reuse [Washizaki 2019]. As a “step” toward solving security and privacy concerns, [Bloom 2018] identified common input-output (I/O) design patterns that exist in Industrial IoT applications, but these design patterns don’t address the full scope of privacy threats, nor the blockchain aspects. [Xu 2018] collects blockchain design patterns, but these mainly identify privacy as an area for further improvement. [Wirth 2018] provides an initial blockchain and smart contracts architectural blueprint claiming GDPR compliance. [Pape 2018] considers privacy patterns in the IoT architecture, assuming a three-layer service delivery model based on fog computing, and does not consider blockchain aspects, nor an explicit data controller role. The privacy patterns [Pape 2018] identified included: personal data store, data isolation at different entities, decoupling content and location visibility, added noise measurement obfuscation, aggregation of data, data aggregation gateways, and single point of contact. A more comprehensive list of privacy patterns, though not targeted at IoT, is online at https://privacypatterns.org/patterns/. Privacy patterns abstract away from the detailed solution of specific PETs. At best, privacy design patterns align with specific privacy threat models, and the suite of patterns covers the full scope of privacy threats. Privacy design patterns can provide a useful common abstraction for communication between the designers and operators of IoT blockchain during its design and operational lifecycle.
Privacy Testing
Modern software development practices like devops, CI/CD,
etc. have an emphasis on the availability of system tests to ensure key use
cases remain valid during development. Some methodologies (e.g. Design for
Testability) go further and require the development of tests before the development
of the code. It would be helpful if
privacy design patterns had industry consensus methods to verify correct
implementation and operation.
Testing in the context of distributed architectures like IoT and blockchains adds additional complexity. [Pontes 2018] formalizes the notion of a pattern-based IoT testing method for systematizing and automating the testing of IoT ecosystems. It consists of a set of test strategies for recurring behaviors of the IoT system, which can be defined as IoT test patterns. Unfortunately, these did not address the scope of privacy concerns. Similarly, the blockchain literature has few examples of automated test suites (see e.g., [Gao 2019]). Neither of these test patterns is specific to privacy. [Muntes-Molero 2019] proposes an approach towards continuous monitoring for privacy risk control in trustworthy IoT systems. The assumption of trustworthy systems requires additional justification. Blockchains can be designed to achieve secure consensus results despite running on untrusted nodes in a peer-peer network. With little in the literature beyond penetration testing (e.g., [Probst 2012]), testing of assertions that privacy threats have been resolved seems an area for further research.
Given the scope of privacy concerns, privacy testing is unlikely to be accomplished by a single test. While many traditional notions of privacy focus on disclosure, recent regulatory initiatives have created new requirements for user controls. While those controls may be implemented with manual procedures in the short term, IoT blockchain architectures can be expected to evolve to provide automated support for these features, and that will need to be tested. An IoT blockchain may be assembled from different components, and will likely evolve over its operational life as new components are added, software updated, etc. Privacy testing will need to apply both at the component level and cumulatively across the larger architecture, and during run time operations.
Privacy Attestation
Some [Wirth 2018], [Bansal 2008] have noted that trademarks and certification seals may be useful for consumers to identify and trust products and services that provide privacy assertions (e.g., conformance to privacy regulations such as the GDPR). Certification schemes usually require independent verification/ testing to assure the quality of certified goods/services. While privacy testing regimes are still in early stages of development, attestations by entities operating services based on IoT blockchains may provide some interim assurance. This may require similar assurances and indemnification through the component supply chain.
The scope of the attestations that consumers may require to protect their privacy and build trust needs further consideration. Solove’s taxonomy is now incomplete as it does not include the more recent regulatory initiatives like GDPR that mandate some degree of control of the data by the data subject. Traditional data access controls (Create/Read/Update/Delete) are helpful, but more nuanced controls may be required to constrain privacy threats from information processing and secondary uses. GDPR takes a step in this direction by identifying the data controller role and imposing privacy-related obligations on data controllers. IoT blockchain architectures could support a limited set of more nuanced operations on private data through SMC. The SMC code could be open-sourced and inspectable to provide assurances of correct operation. Moving the computing algorithms to the data like this may reduce the amount of attestation required to build trust.
Privacy is an ongoing operational concern, not just a design-time objective. The IoT blockchain architecture, though, it will need adequate capabilities to be designed in so that operators of services based on them will be able to make adequate assurances to their customers, and perhaps their regulators as well. While attestations may provide assurances in the short term, ultimately adequate privacy testing regimes will be required to demonstrate the integrity of the solutions.
[Bloom 2018] G. Bloom, et al. “Design patterns
for the industrial Internet of Things.” 2018 14th IEEE
International Workshop on Factory Communication Systems (WFCS). IEEE, 2018.
[Gao 2019] J. Gao, et al., “Towards automated
testing of blockchain-based decentralized applications.” Proc. of
the 27th Int’l Conf. on Program Comprehension. IEEE, 2019.
[Hadar 2018] I. Hadar, et al. “Privacy by
designers: software developers’ privacy mindset.” Empirical
Software Engineering 23.1 (2018): 259-289.
[Pontes 2018] P. Pontes, et. al., “Test
patterns for IoT.” Proceedings of the 9th ACM SIGSOFT
International Workshop on Automating TEST Case Design, Selection, and Evaluation.
ACM, 2018.
More concise privacy threat models are emerging as awareness grows that privacy concepts expect beyond the scope of traditional security threat models. The Data Controller role has received more interest after GDPR but rarely appears in IoT blockchain architectures. To resolve human privacy concerns requires establishing trust in both the IoT systems and in the entities operating them. Legal innovations (e.g., BBLLCs) enable the possibility of new entities that may help manage privacy threats. Technology innovations (e.g., SMC) enable new privacy patterns by changing the data flow requirements to bring the computation to the data, rather than the reverse.
Privacy Threat Models
Developers often use the vocabulary of data security to approach privacy challenges, and this vocabulary limits their perceptions of privacy mainly to third-party threats coming from outside of the organization [Hadar 2018]. Security by design has achieved wider adoption through the use of methodologies based around threat modeling to build common design patterns around data flows in system architectures. [Deng 2011] applies this approach to privacy threat modelling, distinguishing between hard privacy (based on data minimization) and soft privacy (based on trust in the operations of some external data controller), and identifying a number of privacy properties (unlinkability, anonymity, pseudonymity, plausible deniability, undetectability / unobservability, confidentiality, content awareness, policy and consent compliance). [Muntes-Molero 2019] provides a mapping of the connection between security threat models (STRIDE) and Privacy threat models (LINDDUN).
[Feng 2018] identifies blockchain privacy requirements as only either (1) identity privacy or (2) transaction privacy, and also identifies several attacks for deanonymization of identities in blockchain systems are known including: network analysis, address clustering, transaction fingerprinting, Denial of Service attacks against anonymizing networks, Sybil attacks against the P2P network reputation system. Transaction privacy can also be threatened by transaction pattern exposure through, for example, transaction graph analysis. Identity preservation methods mixing services (which obfuscate transaction relationships with other traffic), ring signatures (which obfuscate the real signer amongst a group of signatories), and non-interactive zero-knowledge proofs (which prove a given statement without leaking additional information). Transaction privacy-preserving mechanisms identified include non-interactive zero-knowledge proofs, and homomorphic cryptosystems (which preserve arithmetic operations carried out on ciphertexts).
The privacy threat models, and traditional IoT architectures, generally assume a data flow pattern where data moves and aggregates for centralized analysis by some other party. IoT blockchains supporting SMC offer a potential alternative architecture of moving the computation rather than the data – exposing only the result of the computation rather than the original private data. This would enable the computations to be trusted rather than some other party. This would also limit the secondary use threat to privacy from Solove’s taxonomy when the data is transferred directly, which otherwise does not seem to be addressed effectively in the privacy principles, or threat models.
Data Controller Entities and business models
Ownership provides a legal basis for data controllers to exercise control over “their” data. In the context of cross border data flows, [Unctad 2019] considered four data ownership policies as options for capturing value for data: personal data markets, data trusts (between members of a group, or digital platform), collective data ownership (nationalization as a public resource), and digital data commons (placing data in the public domain). Assertions of collective ownership or digital commons likely require changes in public policy. While individuals could theoretically build their own IoT systems to control their own data, this is not a scalable approach for IoT deployments as not everyone has the skills, capital or motivation, and the lack of uniformity in approach would reduce the aggregate value. If the data collected has commercial value, then some entity is likely to be claiming ownership of that data. For most IoT architectures this entity is not the humans that may be subjects of IoT surveillance. Many existing IoT architectures require people to trade otherwise private data about themselves for access to some monitoring service. The role of a data controller was identified in [OECD 1980] and reinforced with the GDPR; data controllers have not typically been an element in IoT architectures. A data controller may typically be a data owner, but this is not required – it could be operating under some contract or other license arrangements.
Hence humans subject to surveillance by services based on IoT architectures must trust the entity operating those services for any privacy assurances. For commercial entities operating a service based on IoT, there most likely is terms and conditions (T&C) agreement between the IoT operator and the user. Ideally, this would include some attestations or promises regarding the user’s privacy (e.g. not to resell the data to others for secondary uses). It is difficult for the user to detect violations of such privacy attestations. Other data controllers may collect IoT data implicating privacy without T&C agreements in place. Regulations, such as GDPR, may still apply in such cases. In the event of a change of control at the entity operating the IoT service (e.g., a bankruptcy), the data within its control could be repurposed without notice to the user.
Blockchain technology offers a new entity for consideration as the data controller: an IOT blockchain could be structured as a DAO and incorporated as a BBLLC [Vermont 2018]. In this case, the user would have to trust the BBLLC (and its developers) rather than a commercial platform operator. The BBLLC replaces the human with a computational machine as the data controller. The data controls could be implemented with smart contracts. The smart contracts could be publicly inspectable to build trust in the logic. Several blockchains and smart contracts are already inspectable as open source. The BBLLC could also have preplanned smart contracts for the data to be returned or destroyed in the event of foreseeable disruptions of the BBLLC (e.g., forking, dissolution). While blockchains and smart contracts hold a lot of promise, current implementations do not exhibit all these features, and it may take some time for a consensus to emerge on the detailed scope of the features required in IoT blockchains to support the full scope of privacy threats.
If you are looking for a book that provides a detailed overview of the legal implications of blockchain technology and smart contracts, then “Blockchains, Smart Contracts, and the Law” is the perfect choice for you. This book is written clearly and concisely, making it easy to understand even for those who are new to the topic.
Legal principles and regulations are generally concerned with the technology-independent classification of events. Privacy principles have been proposed as a step beyond legal classifications of privacy violations, but these still remain difficult for many IoT blockchain developers to apply. Privacy Impact Assessments (PIAs) have also been proposed to expose privacy issues, but these have not been widely adopted.
Privacy Principles and Frameworks for IoT Blockchains
Principles have been proposed as implementation and operation guidance on privacy. The OECD guidelines [OECD 1980], are perhaps the most widely known privacy principles. These eight principles, intended for nations to apply to trans-border data flows, are: (1) collection limitation principle, (2) data quality principle, (3) purpose specification principle, (4) use limitation principle, (5) security safeguards principle, (6) openness principle, (7) individual participation principle, and (8) accountability principle. More recently the GDPR has endorsed Privacy by Design (PbD). PbD [Cavoukian 2010] builds on seven foundational principles: (1) proactive not reactive; (2) privacy as the default; (3) privacy embedded in the design; (4) full functionality- positive-sum, not zero-sum; (5) end-to-end life cycle protection; (6) visibility and transparency; (7) respect for user privacy. While OECD principles apply in the context of nations managing data flows, PbD principles are intended in the context of IT systems; as such these two sets of principles are complementary.
While the privacy principles are helpful in moving beyond classifying privacy violations they are not necessarily easily applicable to specific architectural contexts (e.g. IoT blockchains), or software development methodologies [Omoronyia 2019], [Perera 2019], and further refinement may be required for practical adoption. Principles present too abstract a framework to inform design; and are often applied after many critical design decisions have been made in defining the business opportunity. [Edwards 2016]. Both the OECD principles and the Policy by design principles provide a step forward from Solove’s privacy threat taxonomy to provide guidance to the developers and operators of information systems. There is no simple mapping between the privacy threat taxonomy and the privacy policies to validate their completeness. The privacy threat taxonomy provides a static view, classifying events after they have happened, while the policies are intended to be more proactive and preventative, applying to ongoing operations and data flows.
There is a lack of comprehensive, widely adopted frameworks to address privacy issues for IoT applications [Thorburn 2019] (for example, [Panagiotou 2018] only considers some cryptography aspects, [Cha 2018] focused only on informed consent). For privacy engineering, the availability and usage of standards, analysis methodologies, and software tools are relatively weaker than for safety and security, reflecting the fact that privacy engineering is an emerging concern for practitioners [Shan 2019]. If detailed technical standards existed, they could provide a framework for IoT Blockchain developers to work from. [ISO 2009] defines information security in terms of preservation of confidentiality, integrity, and availability of information, but notes that other properties, such as authenticity, accountability, non-repudiation, and reliability can also be involved, but other principles like privacy and non-repudiation don’t fit cleanly into this famous triad. [ISO 2011] added a privacy framework, [ISO 2014] added a code of practice for handling Personally Identifiable Information, [ISO 2017] added guidelines for privacy impact assessments and [ISO 2019] provided guidelines and requirements for privacy information management. While providing some guidance, these ISO standards are neither complete nor customized for an IoT blockchain architectural context. There are a number of more specific IoT standards [Miloslavskaya 2019], but they do not address privacy in detail. [NIST 2019] starts to separate IoT privacy concerns from other security concerns; but, does not provide detailed guidance. Blockchain standards, today, seem to be evolving in open source (see e.g., Ethereum RFCs) at the level of APIs, but do not provide a larger view of the privacy impacts. ISO TC/307 is still developing formal specifications on blockchain technologies. While more comprehensive standards may exist in the future, the standards available at present do not provide a comprehensive framework for privacy in IoT blockchains.
IoT Blockchain is by its nature a distributed architecture; this implies that privacy threats can attack multiple points (in motion and at rest) within the architecture. Understanding the data flows, becomes a prerequisite to analyzing privacy across the IoT blockchain architecture. Recall the OECD principles were developed in the context of data flows between nations; data flows in IoT blockchains, however, are not technically restricted by national borders. Data flows for business processes are often modelled to capture stakeholder collaboration in business processes supported by technology/ automation. [Pullonen 2019] proposed Privacy Enhanced Business Process Modelling Notation (PE-BPMN) to capture the use of PETs along the flow of private information. Such notations may be helpful in discussing the end-end privacy management processes of IoT blockchain architectures.
Identifying privacy Impacts
When analyzing IoT privacy requirements, it can be challenging to identify what information should be protected, when it should be protected, and to whom access should be granted.
IoT consists of diverse technologies and the integration of these technologies can lead to unknown risks. Not all the data collected by IoT architectures is necessarily implicated by privacy concerns; data related to legal entities (e.g. data about people and their possessions), however, may be implicated. For example, IoT sensor data from personal fitness devices, or personal vehicles may be used to infer a person’s location which they may wish to keep private. [Ni 2017] identifies four categories of privacy relevant IoT data: (1) identity, (2) usage, (3) location, and (4) other miscellaneous data (e.g., user preferences, sensor data). It is not only the data collected by IoT architectures that may be problematic for privacy; privacy threats may arise from the linkages [Madaan 2018] between IoT data streams (ie. the information processing aggregation privacy threats in Solove’s taxonomy).
PIAs have been proposed for information systems generally (see e.g., [ISO 2017]. If required, these are typically developed manually at an early[1] stage of the project to scope and shape the development of the solution architecture. Conducting a PIA remains a complicated and bewildering task, mainly due to the lack of detailed, practical guidance on how to carry out such an assessment. The available guidance is mainly at the level of legal, policy, or academic proposals [Vemou 2018] rather than targeted for software developers of other technologists designing and implementing IoT blockchain systems. Even for the ISO standard in PIAs, there are proposals (e.g., [Vemou 2019] for extensions to make the PIA process more tractable for practitioners, but these are still not specialized for the IoT Blockchain context. There are not many published examples of PIAs for IoT architectures in the literature. The EU at one stage had required the development of PIAs for RFID applications [EU 2011]. [Pribadi 2017] provides an example PIA for a smart health care services IoT.
Developers of IoT blockchains need more detailed guidance on how to apply privacy principles in their context. Privacy frameworks and standards are emerging, but still incomplete. PIAs are not guidance for IoT blockchain developers, rather these are created by the IoT blockchain developers for external audiences to understand the scope of privacy threats, and the mitigations supported within their architectures. While not trivial to implement, PIAs may be actionable by IoT blockchain developers to provide more insight for regulators, and the operators and users of services built on IoT blockchains, about potential exposures to privacy threats.
If you are looking for a book that provides a detailed overview of the legal implications of blockchain technology and smart contracts, then “Blockchains, Smart Contracts, and the Law” is the perfect choice for you. This book is written clearly and concisely, making it easy to understand even for those who are new to the topic.
References
[Cavoukian 2010] A.Cavoukian, “Privacy by design: the definitive workshop. A foreword by Ann Cavoukian, Ph. D.” Identity in the Information Society 3.2 (2010): 247-251.
[Madaan 2018] N. Madaan, et.al., “Data integration in IoT ecosystem: Information linkage as a privacy threat.” Computer law & security review 34.1 (2018): 125-133.
[Miloslavskaya 2019] N. Miloslavskaya, et al. “Standardization Issues for the Internet of Things.” World Conference on Information Systems and Technologies. Springer, Cham, 2019.
[Pribadi 2017] I. Pribadi, et. al., “Regulatory recommendations for IoT smart-health care services by using privacy impact assessment (PIA).” 2017 15th Int’l Conf. on Quality in Research (QiR): International Symposium on Electrical and Computer Engineering. IEEE, 2017
[Pullonen 2019] P. Pullonen, et. al., “Privacy-enhanced BPMN: enabling data privacy analysis in business processes models.” Software & Systems Modeling (2019): 1-30.
Much of the existing IoT Blockchain literature considering privacy is ad hoc and not comprehensive in scope [Yan 2014]. Integrating blockchains into IoT architectures can provide additional security-related features, but simply integrating IoT and blockchain without a more comprehensive approach does not assure privacy. A number of useful Privacy Enhancing Techniques (PETs) have been identified, but without a comprehensive, systematic approach the resulting IoT architecture would remain subject to various privacy threats. While some progress has been made in quantifying privacy, end to end privacy metrics for consumers to evaluate services based on IoT blockchain offerings have not been defined. PETs provide a toolkit enabling IoT blockchain architects to improve privacy in specific dimensions. Technical privacy metrics enable measurements of the improvements in privacy in that specific dimension. Individual PETs do not address the scope of privacy threats, and so care must be taken in designing the IoT blockchain architecture to select a set of PETs that address the scope of threats expected. Methods to aggregate privacy metrics to provide adequate comparisons between IoT blockchain architectures on an end to end basis across the scope of privacy threats remain are needed.
Privacy Enhancing
Technologies
[Sen 2018] separates the fundamental concerns of IoT privacy compare to security and then identified and grouped previous IoT PETs into classes: anonymity; working with data; access control and users’ requests; awareness; policy and laws. [Hassan 2019] identified the basic privacy preservation strategies in blockchain-based IoT systems as anonymization, encryption, private contract, mixing and differential privacy. In the context of smart cities, [Curzon 2019] identified 28 PETs: association rule protection, attribute-based credentials, blockchain, encryption, homomorphic encryption, generalization, coding, hashing, micro-aggregation, k-anonymity, J-diversity, t-closeness, mix networks, oblivious transfer, blind signatures, secure multiparty computation (SMC), zero-knowledge proofs, onion routing, private data warehouse queries, private information retrieval, sampling, substitution, masking, nulling out, shuffling, variance, synthetic data and differential privacy. [Yan 2014] –identifies and categorizes a number of PETs from a trust perspective: identity trust and privacy preservation, transmission and communication trust, SMC (privacy-preserving database query, privacy-preserving scientific computations, privacy-preserving intrusion detection, privacy-preserving data mining). [Heurix 2015] proposes a different taxonomy for PETs, classifying them based on the scenario, aspect, aim, foundation, data, trusted third party, and reversibility. While [Yan 2014], [Curzon 2019], and [Heurix 2015] provide views of the PET toolkit that moved beyond notions of privacy as confidentiality, none of them mapped the scope of the PETs they considered against the breadth of privacy threats considered in Solove’s taxonomy. The challenge for IoT architects lies in selecting the appropriate PETs. Technical privacy metrics can provide an indication of privacy improvement, but these are often very specific to the PET and may not be easy to compare across different techniques. The challenge for users lies in understanding the scope of privacy threats that are protected against by the whole IoT architecture – IoT blockchain architectures emphasizing the inclusion of a specific PET, may give the impression that privacy has been protected, when the scope of the PET is narrower than the range of privacy threats.
Privacy Measurement
What can’t be measured, can’t be controlled or improved. [Wagner 2018] provided a systematic survey, identifying more than 80 technical privacy metrics from the literature and classifying them based on the adversary model assumptions, data sources, metric inputs, and metric outputs. These metrics were identified from PETs used in six domains – communication systems, databases, location-based services, smart metering, social networks and genome privacy; many of these dimensions are associated with IoT blockchain applications. The adversary model assumptions were broken into adversary capabilities and adversary goals; the adversary goal was assumed to be compromise of the users’ privacy by learning sensitive information, but this only addresses a portion of the privacy threats scope. The data sources to be protected were categorized as published data, observable data, repurposed data and all other data. IoT blockchain architectures may include data from all four categories. The inputs to calculate the privacy metrics were classified as configuration parameters (e.g., threshold values), prior knowledge (e.g., statistical averages on some population), the estimate of the adversary’s resources, the adversary’s estimate of the true data and the true data itself. The value of metrics based on largely estimated inputs may be questionable. The outputs calculated by the metric were classified as uncertainty, information gain or loss, data similarity, indistinguishability, adversary’s success probability, error, time, or accuracy/precision. With so many metrics to choose from [Wagner 2018] proposes a set of nine questions to select suitable metrics based on the output measured required, adversary characteristics expected, data sources identified for protection, input data available, target audience for the metric, availability of related work (e.g., metrics from a different domain), quality of the metric, metric implementation aspects, and metric parameter considerations.
One important use for privacy metrics would be in comparing alternative IoT blockchain architecture proposals. If the metric inputs are driven by estimates, it would be helpful to have common estimates to enable comparisons across the architectures. Industry-standard benchmarks for the thresholds used in configuring privacy metrics would also help improve comparability in privacy measurements. Similarly, it would be useful to develop some consensus around which of the output metrics are most appropriate for architecture comparisons in the context of IoT blockchains.[Wagner 2018] provides a significant step forward to help IoT blockchain architects select the appropriate PETs from the available toolkit, but more remains to be done to enable effective comparisons of the privacy performance of IoT blockchain architecture proposals.
While valuable within their application niches, most of these technical privacy metrics on PETs don’t address the breadth of IoT privacy concerns from a consumer perspective. Solove’s taxonomy provides a broader perspective; this taxonomy, however, is at a very high level and, like privacy principles, may be difficult to apply in the context of IoT architectures. In [Gemalto 2018] 62% of consumers have increased concerns over privacy as a result of increasing IoT. While 95% of consumers through security was important, lack of privacy was the biggest fear identified. “Silent Authentication” (where a human is authenticated by multiple passive IoT systems) was seen as key feature enabling personalization in smart environments with pervasive IoT. Passive silent authentication clearly implicates several notions of privacy. Given the level of consumer concern, and the emergence of features implicating privacy, there is a need for better privacy metrics for use at the consumer level. One approach could be to construct a privacy metric using a reasonably comprehensive list of privacy threats that have been addressed/assured in the design of the IoT blockchain architecture. Consumers of IoT blockchain services could then look for attestation by the designers or operators regarding the scope of privacy assertions available.
There are increasing concerns about data privacy and online security around the world; this is somewhat of a paradox, as users continue to give away personal data (and thus their privacy) in exchange for different services. A recent survey [CIGI-Ipsos 2019] on Internet security and trust found that 78 percent of Internet users in 25 economies were at least somewhat concerned about their privacy online. Internet scams of various types have also been demonstrated to raise internet users’ sensitivity to privacy issues [Chen 2017]. While economic development theory has long grappled with the consequences of cross-border flows of goods, services, ideas, and people, the most significant growth in cross-border flows now comes in the form of data. Some of these flows represent ‘raw’ data while others represent high-value-added data; this can make a difference in the trajectory of national economic development [Weber 2017]. Public awareness about privacy risks on the Internet is increasing; with the evolution of the Internet to the Internet of Things, these privacy risks are likely to become even more significant due to the large amount of data collected and processed by IoT architectures [Baldini 2018]. The Sony pictures hack[1] illustrates that privacy is not just an individual concern; unease over privacy expectations has emerged at the individual, governmental and international levels. Conceptually and methodologically, privacy is often confounded with security. [Spiekerman-Hoff 2012]. Gartner expressed a concern that the biggest inhibitor to IoT growth will be the absence of security by design[Gartner 2018] (which would include some aspects of privacy). While there has been considerable attention placed on some aspects of security, privacy has received less attention from the IoT community. Privacy was identified this year by Deloitte[2] to be the factor driving regulatory uncertainties over data management. This regulatory uncertainty challenges enterprises’ adoption of new technologies (like blockchain, or IoT). Social expectations for privacy are evolving, particularly in regard to aggregate representations of personal data in cyberspace. IoT devices and architectures are emerging as a major new data source for capturing representations of human activity. Rising cyberspace privacy concerns are moving beyond isolated activities like web browsing or social networks to consideration of the privacy impacts of the aggregate representation of personal data, including foreseeable data generation capabilities of IoT architectures. At a minimum, this creates a public relations problem for the deployment and operation of IoT Architectures.
IoT networks, like many other networks, are not technically constrained within geographical or political boundaries, but these political constructs may imply legal obligations for participants. Many of these legal notions of privacy evolved prior to the availability of the internet. International treaties like the UNDHR [UN 1948] and ICCPR [UN 1976] provide some definitional guidance on privacy rights, and [ALI 1977] identifies US common law privacy torts related to intrusion upon seclusion, appropriation of name or likeness, and publicity given to private life. These legal concepts, however, were all in place before the deployment of the Internet and the emergence of IoT. US legal requirements on privacy also come from a variety of other sources including constitutional limits, legislation, regulation, common law, and contract law; while litigation processes like discovery also implicate privacy. The Federal Trade Commission provides some cross-industry-sector privacy enforcement, but other industry-specific agencies in the health, finance, education, telecommunications, and marketing enforce industry-specific privacy regulations. States have also promulgated their own laws (e.g., on data breach notification and reporting obligations). [Solove 2006] proposed a privacy taxonomy with four main groups of activities that threated privacy (1) information collection (including surveillance and interrogation); (2) information processing (including aggregation, identification, insecurity, secondary use and exclusion); (3) information dissemination (including breach of confidentiality, disclosure, exposure, increased accessibility, blackmail, appropriation, and distortion); and (4) invasions (including intrusions and decisional interference). More recently, the General Data Protection Regulation [EU 2016] (GDPR) applies extraterritorially to protect EU citizens and has also been influential in other national privacy efforts. In particular, GDPR identifies roles in managing data (e.g., Data Protection Officers); rights for data subjects (including breach notification, access to their personal information, data erasure (the right to be forgotten), and data portability); and requires privacy to be incorporated into the design of systems (Privacy by Design). Globally, privacy laws are continuing to evolve towards bringing greater rights to data subjects [Greenleaf 2019]. Legal considerations on privacy generally revolve around the rights and obligations of legal entities; the IoT, however, is generally considered from the perspective of “things” and the data they generate or consume. The “things” in IoT are not usually considered legal entities, but many recent proposals for IoT architectures have been based on blockchains, and some have argued that blockchains could be implemented as Digital Autonomous Organizations (DAOs) structured to be recognized as independent legal entities (e.g., zero-member LLCs [Bayern 2014] or BBLLCs [Vermont 2018]). Manufacturers of IoT systems often seek the scale of global markets, and so cannot avoid these international trends in privacy regulation. IoT architectures have historically not emphasized privacy features, or considered IoTs operating as independent legal entities. The threats of increased regulation and the opportunities of new legal options will challenge existing IoT deployments and create opportunities for new IoT architectures.
The data we collectively create and copy each year is growing at 40% annually is estimated[3] to be around 44ZB/yr in 2020 (that’s around 6TB/yr for every person on earth), with much of this data expected (in future) to come from IoT devices sensing the world around them. Today, while people may choose to consume their portion of all their data as internet cat videos, many are not mindful of the digital footprints they leave in cyberspace [Camacho 2012]. An entirely new value chain has evolved around firms that support the production of insights from data. Individual data are worth very little on their own; the real value of data comes from the data being pooled together. [Beauvisage, 2017]. IoT provides a major new source of data for the big data value chain. Beyond intentional internet interactions, IoT sensor networks can also passively collect data on human activities. At the earlier stages of the data value chain, information content is limited, and therefore the scope for value generation is also low; at the same time, the data is more personalized and hence more susceptible to privacy threats. Some types of data should not be extracted, for instance, if it impinges on fundamental privacy rights. Some data, such as health data, may be usefully extracted under highly regulated circumstances. For many IoT architectures, the privacy threat arising from information processing (e.g., aggregated data) may be more severe than individual data samples. IoT data does not have to be as bandwidth-intensive and focused as video surveillance to threaten privacy. Patterns of private human activity can be discerned from aggregating data from disparate IoT architectures. The ownership and control options for IoT architecture generated data (as relating to human privacy) may be more complex than previous IoT architectures had considered – perhaps rather than centralizing data from IoT sensors in the cloud, IoT data may need to remain distributed, but responding to a limited set of authorized queries. Some actors may also have access across multiple IoT architectures providing a further degree of information aggregation and processing. Even IoT architectures intended for other purposes (e.g. environmental monitoring) may have the data they generate repurposed in ways that violate human privacy. For IoT architectures to succeed in large scale commercial deployments, they must be prepared to address evolving privacy concerns. This will require IoT architecture to identify which of the data they generate can implicate human privacy concerns.
Humans are interacting with vast amounts of data in new and unusual ways. Sensor density in consumer products is also increasing. Cyberspace historically was just an environment in which computer communication occurred; now it is already defined more by users’ social interactions rather than technical implementation concerns [Morningstar 2003]. Cyberspace computation today is often an augmentation of the communication channel between real people. People seek richness, complexity, and depth within a virtual world; and at the same time require increasing annotation of real-world entities with virtualized data in augmented reality. Humans increasingly use cyberspace for social interaction merging cyberspace and social spaces into social computing. The environments, however, are not the same; humans’ expectations and intuitions from the physical world do not always carry over into cyberspace. For example, real-world experiences are ephemeral; thanks to data storage, however, representations of personal data do not naturally decay; applying this to privacy violations, a transient real-world peeping incident equivalent in cyberspace could result in an ongoing data peeping threat. Legal notions of privacy are typically sensitive to the context (e.g., public spaces vs homes) and actors (e.g., people, organizations, governments). If IoT deployment scale projections are correct, then cyberspace in the near future will be dominated by data flows from IoT architectures. Cyberspace may create notions of new types of entities that may implicate privacy [Kerr 2019], and DAOs are one example of this. Devices are evolving to provide more “human-like” interfaces (e.g. voice assistants (e.g. Alexa, Siri) AI chatbots [Luo 2019]) and autonomous activity (e.g. UAV drones, Level 5 self-driving cars). The Apple iPhone 11 sensors include[4] faceID, barometer, three-axis gyro, accelerometer, proximity sensor, ambient light sensor, audio, and multiple cameras. The Tesla Model 3 includes[5] rear side and forward cameras, forward-facing radar and 12 ultrasonic sensors. The increasing data intensity in human experience is affecting human behavior and perceptions. While data generically is a very abstract concept, IoT sensor data is very much concerned with creating and aligning various linkages between physical reality and its cyberspace counterpart. Many actors may have an interest in the data about humans created by IoT devices and architectures. Beyond data ownership considerations, recent privacy legal initiatives have created new roles and additional obligations for operators of IoT architectures – e.g. GDPR’s rights to correct data or to be forgotten. The scope, scale, and serendipity of individual human interactions with cyberspace are reaching a qualitative change as IoT architectures become more pervasive.
The human-computer interaction (HCI) with the IoT blockchain is also an important factor affecting whether privacy enhancements are successful. Click through licenses can easily permit users to contract away their privacy rights (unless otherwise limited by regulation). There have been some efforts[6] to provide better exemplars of legal patterns for privacy information; adoption, however, is voluntary unless there is some superseding regulation (e.g., requiring specific notices to “opt-in” for certain types of information disclosures). Given the evolving nature of privacy concepts, HCI approaches may be helpful [Wong 2019] to better define users’ perceptions of the privacy problem space. Trademarks and certification seals may be useful [Wirth 2018], [Bansal 2008] for consumers to identify and trust products and services that provide privacy assertions (e.g., conformance to privacy regulations such as the GDPR). Beyond disclosures, new privacy rights create functions (e.g., for authorized modification or deletion of data) that need to be supported in IoT architectures. The effectiveness of such functions in providing humans with more advanced controls of their personal data will depend in large part on their ease of use. The usability/ operability of such user controls of their data will also be impacted by the visibility and accessibility of the privacy controls. IoT use cases need to evolve to consider these new roles and functions within IoT architectures and how humans can effectively use them to maintain control of their privacy.
Two fundamental technology trends are driving the Internet of Things (IoT). Firstly, the continued miniaturization of devices through Moore’s law, nanotechnology, new materials, etc., is providing an increased density of functionality in devices, and a consequent increase in the variety and volume of the data these devices can generate and consume. Secondly, the number and quality of connections are increasing. Gartner estimated[7] there would be 8.4 billion connected Internet-of-Things (IoT) devices in use worldwide in 2017 and projects an increase to 50 billion by 2020. IoT use cases are one driver for 5G deployments and these deployments are also expected to increase connectivity density towards ubiquity in many areas. Ericsson estimates[8] there will be 1.5 billion IoT devices with cellular connections by 2022 with cumulative annual growth rates on the order to 20%-30%. This is significantly faster growth than the US GDP growth (estimated[9]in the range 2-3% 2018-2019) or world population growth rates (estimated[10]at 1-2%). Even the job outlook for software developers is only expected[11] to improve by ~21% (2018-2018). The number of IoT devices and their connectivity is evolving the Internet to be primarily an Internet of Things, where the IoT devices, and the data they communicate, forms the dominant usage pattern. This massive IoT investment comprises multiple information infrastructures; forming a cyberspace data environment within which people will interact for an increasing portion of their lives. With massive IoT deployments expected within the next 5 years, to avoid stranded investments, it is important to get the appropriate IoT architecture requirements in place to address common human concerns, particularly around privacy. Existing IoT deployments will also be impacted by privacy as public relations headwinds, evolving regulatory requirements on management of IoT data, changing human attitudes due to the qualitative changes in cyberspace experiences from pervasive IoT environments, and increased user control of IoT data. Retrofitting privacy (or security) into an existing distributed architecture is unlikely to be simple cheap or complete. New IoT architectures must consider privacy impacts.
[CIGI-Ipsos 2019]
CIGI-Ipsos, UNCTAD and Internet Society (2019). 2019 CIGI-Ipsos Global Survey
on Internet Security and Trust. Centre for International Governance Innovation,
UNCTAD and the Internet Society. Available at: https://www.cigionline.org/internet-survey-2019.
[EU 2016]
European Union: Regulation (EU) 2016/679 of the European Parliament and of the
Council of 27 April 2016 on the protection of natural persons with regard to
the processing of personal data and on the free movement of such data, and
repealing Directive 95/46/EC (General Data Protection Regulation)
[Morningstar 2003]
C.Morningstar, et. al., The Lessons of Lucasfilm’s Habitat. The New Media Reader.
Ed. Wardrip-Fruin and N. Montfort: The MIT Press, 2003. 664-667.
[Solove 2006] Daniel
J. Solove “A Taxonomy of Privacy”. U. Pa. L. Rev., 154:477–560, 2006.
“Things” have been around much longer than the Internet or Blockchain. The term “Internet of Things”, however, seems to have emerged around 1999 [1], [2], and gained more widespread recognition with the 2005 ITU report [3] (which seemed largely concerned with RFID technologies). In 2010, the IoT application domains included transportation and logistics, healthcare, smart environments, personal and social, and robot taxis, smart cities, and virtual reality were considered “futuristic”; while data authentication, data integrity, privacy, and data forgetting were considered open research issues [4]. IoT was added to the 2011 Gartner Hype Cycle, and hit the peak of inflated expectations in 2014, based on embedded sensors, image recognition, and near-field payment technologies. Early standardization efforts on IoT were primarily focused on optimized communication technologies (e.g. [5]). Google Glass was released in 2013 triggering popular interest in Augmented Reality and Virtual Reality, and Amazon released the Echo voice assistant in 2014. Around this time trust management aspects of IoT started to receive more attention [6] as did the intersection between IoT and social networks [7]. IoT Architectures in 2015 were mainly layer-oriented, separating sensing/ perception from communication and (centralized) processing [8], and security threats were also categorized by these layers[9]. By 2016, IoT device deployments we sufficiently large to form an attractive target for malware attacks (e.g., Mirai malware) and Blockchain started to come into the IoT conversation [10]. Blockchain capabilities like immutability, transparency, auditability, data encryption, and operational resilience have been proposed to solve many architectural shortcomings of early IoT systems [11].
IoT Blockchains
IoT architectures seem to be adopting blockchains to leverage advantages from decentralization, security/ trust models and enablement of new business models providing greater user control of the IoT data [12], [13]. Centralized IoT architectures have enabled users to surrender their data to others in exchange for IoT services; blockchain technologies enable more nuanced controls on data usage and offer possibilities of commercial microtransactions thus enabling new business models. Existing IoT business models have been analyzed across multiple dimensions (e.g. [14]), but the impact of additional blockchain capabilities was not considered. With blockchains’ roots in cryptocurrencies, they can also be used to facilitate microtransactions and other trading activities in the IoT applications (e.g., smart-grid energy trading & settlement [15]). IoT architectures relying on centralized servers are vulnerable to failures and Denial of service attacks on a single point. IoT architectures are characterized by massive quantities of nodes, with the law of large numbers ensuring that some portion of the nodes is impacted by limited or intermittent connectivity, power or other faults. Blockchains based on redundant peer-peer infrastructure provide some degree of resiliency in the face of failure. Centralized IoT architectures rely on trusting a third party to handle the data, and typically do not support assurances against the life cycle of data integrity (e.g. data tampering, deletion or provenance). Blockchains can provide some assurances regarding data integrity, and blockchain consensus mechanisms can provide assurances of data provenance even amongst untrusting parties, and by distributing data over a peer-peer network provide alternate mechanisms for establishing trust in the IoT ecosystem [16]. Historically, centralized IoT architectures have provided users with only limited knowledge or control over how their data may be used and by whom. Blockchains and smart contracts can provide constraints on operations permitted on the data in the blockchain. Massive IoT deployments in centralized architectures imply substantial costs for centralized infrastructure support; in contrast, distributed peer-peer blockchain IoT architectures have no centralized servers. An IoT ecosystem has numerous vulnerabilities concerning confidentiality, privacy, and data integrity. With its cryptographic characteristics, blockchain can help in addressing security requirements in IoT [17] ([18] provides a SWOT analysis of blockchain as a mechanism to improve the security of IoTs). [19] proposed a blockchain architecture for IoT for improved privacy by distributing the data and placing it under the control of the user. [20] proposed a design for the tamper-resistant gathering, processing, and exchange of IoT sensor data (car mileage) that was intended to be scalable, efficient, and privacy-preserving. [21] prototyped a blockchain IoT leveraging the immutability properties of blockchains to preserve evidence for use in law enforcement and insurance cases. Whether viewed from the perspective of adding blockchain features to IoT, or including IoT data flows in blockchains, the integration trend of these technologies is expected to continue.
The IoT encompasses a broad range of sensors, systems, and services that tend to be optimized for (or fragmented into) specific applications. [22] provides an overview of the scope of IoT across the perspectives of multiple taxonomies to identify the main dimensions used to characterize IoT systems. Most of the literature focused on the IoT “things”, their communication patterns and to a lesser extent, the data made available by the IoT system; complete treatments of all the potential elements of IoT systems or all the quality dimensions of IoT systems have typically not been provided. Given the breadth of IoT, not every IoT deployment requires a blockchain – IoT applications with multiple independent, interacting entities that do not have a shared trusted authority are more suitable for blockchains [23]. The scale, connectivity and transaction patterns of IoT architectures are not the same as cryptocurrency applications that blockchains were initially deployed in. Blockchains designed for other purposes may not have the inherent characteristics required for IoT [24]. IoT devices are typically resource-constrained (e.g. RFIDs have no computational elements), and blockchains involve computation heavy cryptographic functions; blockchains have, however, been demonstrated in the context resource-limited computing nodes such as the Raspberry Pi [25]. Blockchain also appears to be adopting IoT as a key use case, with increasing numbers of publications focused on the topic [26]. While blockchains and smart contracts can provide interesting features to IoT architectures, they may need optimization for the IoT context, and don’t necessarily address all of the emerging IoT requirements in areas such as privacy. With billions of IoT devices already deployed, existing IoT architectures may need to be adapted to support blockchain capabilities. Developers of new IoT architectures should consider whether to include blockchain capabilities. While new blockchain technologies optimized for IoT are emerging, existing blockchain deployments may also need to consider the impacts of IoT data flows on their infrastructure (e.g., address space consumption, transaction performance, etc.). Smart contracts may provide a path to ease the integration of IoT data on blockchains while enabling new capabilities (e.g. control loops or transactions triggered by IoT sensor data).
If you are looking for a book that provides a detailed overview of the legal implications of blockchain technology and smart contracts, then “Blockchains, Smart Contracts, and the Law” is the perfect choice for you. This book is written clearly and concisely, making it easy to understand even for those who are new to the topic.
[14] D. Hodapp, et. al., “Business Models for Internet of Things Platforms: Empirical Development of a Taxonomy and Archetypes.” AIS: 14th Int’l Conf. on Wirtschaftsinformatik, Feb. 24-27, 2019, Siegen, Germany
[18] S. Moin, et. al. “Securing IoTs in distributed blockchain: Analysis, requirements and open issues.” Future Generation Computer Systems 100 (2019): 325-343.
[20] M. Chanson, et al. ,”Blockchain for the IoT: privacy-preserving protection of sensor data.” Journal of the Association for Information Systems 20.9 (2019): 10.
[21] D. Billard, et. al., “Digital Forensics and Privacy-by-Design: Example in a Blockchain-Based Dynamic Navigation System.” Annual Privacy Forum. Springer, Cham, 2019.
[22] F. Alkhabbas, et. al., “Characterizing Internet of Things Systems through Taxonomies: A Systematic Mapping Study.” Internet of Things7 (2019): 100084.
[24] R. Han, et.al., “Evaluating blockchains for iot.” 2018 9th IFIP International Conference on New Technologies, Mobility and Security (NTMS). IEEE, 2018.
