researching crowdsourcing to extend iot testbed ......researching crowdsourcing to extend iot...

Researching crowdsourcing to extend IoT testbed infrastructure for multidisciplinary experiments, with more

end-user interactions, flexibility, scalability, cost efficiency and societal added value

Grant agreement for: Collaborative project Grant agreement no.: 610477 Start date of project: October 1st, 2013 (36 months duration)

Deliverable D2.3 Identity Management and Reputation Mechanisms Report

Contract Due Date 31/03/2016

Submission Date 20/07/2016

Version 1.0

Use of Resources This deliverable production is the result of Task 2.3 which has benefited from a collective effort of work from the partners of the consortium estimated to be about 16.16 PMs.

Responsible Partner CTI

Author List Sotiris Nikoletseas (CTI), Theofanis Raptis (CTI), Gabriel Filios (CTI), Panagiotis Aleksandrou (CTI), Yiannis Stamatiou (CTI), Karagiannis Marios (UNIGE), Sébastien Ziegler (MI), Cedric Crettaz (MI), Aleksandra Rankov (DNET), Nikolaos Loumis (UNIS), Xenia Ziouvelou (SOTON)

Dissemination level PU

Keywords Internet of Things, Crowd sourcing, Personal data protection, Privacy, Lab, Identity Management, Reputation Mechanisms, Ranking Functions, Risk Analysis, Anonymity, Right to be forgotten.

Project Coordinator: Mandat International (MI) Sébastien Ziegler <[email protected]>

Ref. Ares(2016)6928075 - 13/12/2016

D2.3 Identity Management ad Reputation Mechanisms Report

of 85

Abstract

This deliverable reports on the progress achieved in T2.3 “Identity management and

reputation mechanisms” during the 2nd and 3rd year of the IoT Lab project. During this

period, the focus was on designing and implementing specific identity assignment methods

for the efficient role management of the platform and on establishing effective reputation

mechanisms and relevant ranking functions. Furthermore, specialized privacy issues were

revisited (sliced consent, *right to be forgotten”, data granularity, etc.) and a detailed risk

analysis of the platform was conducted.

Acknowledgements This deliverable is part of the IoT Lab European Research project which has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under Grant Agreement no 610477.


of 85

Contributors

First Name Last Name Partner Email

Sotiris Nikoletseas CTI [email protected]

Theofanis Raptis CTI [email protected]

Gabriel Filios CTI [email protected]

Panagiotis Aleksandrou CTI [email protected]

Yiannis Stamatiou CTI [email protected]

Aleksandra Rankov DNET [email protected]

Sébastien Ziegler MI [email protected]

Cedric Crettaz MI [email protected]

Michael Hazan MI [email protected]

Nikolaos Loumis UNIS [email protected]

Marios Karagiannis UNIGE [email protected]

Marios Angelopoulos UNIGE [email protected]

Xenia Ziouvelou SOTON [email protected]


of 85

Table of Contents

Abstract ........................................................................................................................ 2

Acknowledgements ..................................................................................................... 2

Contributors ................................................................................................................. 3

Table of Contents......................................................................................................... 4

List of Tables ............................................................................................................. 6

List of Figures ............................................................................................................ 6

Executive Summary .................................................................................................... 8

1 Introduction ........................................................................................................... 9

1.1 The IoT Lab project in brief ............................................................................... 9

1.2 Purpose and scope of the WP 2 ..................................................................... 10

1.3 Purpose and scope of the Task T2.3 .............................................................. 11

1.4 Purpose and scope of the current document .................................................. 12

2 Responses to the Reviewers’ Comments ......................................................... 13

3 Identity management .......................................................................................... 21

3.1 The attribute-based credentials concept for identity management ................. 21

3.2 Role Based Authentication and Authorisation System .................................... 24

3.2.1 The distinct roles of platform users and the available functionalities ........ 24

3.3 Protection of identities .................................................................................... 27

4 Reputation Mechanisms ..................................................................................... 29

4.1 Active feedback from Users ............................................................................ 29

4.2 Quality of Service (QoS) guarantees .............................................................. 30

4.3 An incentives model for the crowd participants .............................................. 33

4.4 Ranking functions ........................................................................................... 35

4.4.1 The ratings for the platform ...................................................................... 36

4.4.2 The Rating of the Crowd Participants ...................................................... 38

4.4.3 The Ratings of the Experimenters ............................................................ 40

4.4.4 The ratings of the proposed ideas for new experiments .......................... 41

5 Relevant privacy and personal data protection issues ................................... 43

5.1 Anonymity ....................................................................................................... 44

5.2 The right to be forgotten for users .................................................................. 52

5.3 Sliced informed user consent ......................................................................... 60


of 85

5.4 Decreasing raw data granularity if an experiment can tolerate it .................... 62

5.5 Performing a risk assessment of the IoT infrastructure .................................. 63

6 The risk analysis of IoT Lab platform ................................................................ 65

6.1 The Risk Analysis Framework ........................................................................ 65

6.1.1 The CORAS Risk Analysis Framework .................................................... 66

6.1.2 Scope of the risk analysis ........................................................................ 67

6.1.3 Limits of the Analysis ............................................................................... 67

6.1.4 Identified Security Mechanisms ............................................................... 68

6.1.5 Identified Assets ....................................................................................... 68

6.1.6 Identified Success Factors for the IoT Lab platform ................................. 69

6.1.7 Applicable Standards and Legislation ...................................................... 69

6.2 Security Requirements ................................................................................... 69

6.2.1 Confidentiality .......................................................................................... 70

6.2.2 Integrity .................................................................................................... 71

6.2.3 Availability ................................................................................................ 72

6.2.4 Accountability ........................................................................................... 73

6.3 Risk analysis tables ........................................................................................ 75

6.4 Risk evaluation ............................................................................................... 80

6.5 Risk levels ...................................................................................................... 81

6.6 Recommendations .......................................................................................... 82

6.6.1 Conclusions and recommendations based on the development expert’s assessment .......................................................................................................... 82

7 Conclusion .......................................................................................................... 84

References ................................................................................................................. 85


of 85

List of Tables

Table 1: The parameters that estimate the Quality of Service that the platform provides to

its users. The total rate is the weighted sum of these parameters. ............................... 32

Table 2: The specific scores calculated for the IoTLab platform. .................................. 36

Table 3: The parameters that contribute to the rating of a user and the weights for each

parameter. The total rate is the weighted sum of these parameters. ............................. 39

Table 4: The parameters that contribute to the rating of an experimenter and for each

parameter. The total rate is the weighted sum of these parameters. ............................ 40

Table 5: The parameters used to calculate the rating of a proposed idea, the weights for

each parameter and the functions that calculate the points earned for each parameter. The

total rating is the sum of the functions for each parameter. .......................................... 42

Table 6: Schema for Collecting data from all users ...................................................... 49

Table 7: Identified physical assets. ............................................................................... 68

Table 8: Identified immaterial assets. ........................................................................... 68

Table 9: Template for risk level matrix. ......................................................................... 80

Table 10: Risk level table based on the development team’s estimates. ...................... 81

List of Figures

Figure 1: LimeSurvey activation – settings option ........................................................ 18

Figure 2: Basic functionality of an ABC system. ........................................................... 21

Figure 3: IoT Lab modules overview. ............................................................................ 30

Figure 4: IoT Lab Incentives Model Design Methodology ............................................. 33

Figure 5: IoT Lab Generic Experiment Process “Crowd-driven experiments” ............... 34

Figure 6: Delete account action .................................................................................... 58

Figure 7: Confirmation Dialog ....................................................................................... 59

Figure 8: Initial state of the app .................................................................................... 59

Figure 9: Active location services on Android ............................................................... 61

Figure 10: Service notification ...................................................................................... 61

Figure 11: Service Notification expanded ..................................................................... 61

Figure 12: An example for a decision tree. ................................................................... 64

Figure 13: The CORAS risk analysis and management process. ................................. 65


of 85

Figure 14: Outline of CORAS risk management process ............................................. 66

Abbreviations and acronyms

ABC Attribute Based Credential

AIDE Advanced Intrusion Detection Environment

API Application Programming Interface

CA Consortium Agreement

DNS Domain Name System

EC European Commission

eID Electronic Identity Card

EU European Union

FP7 Seventh Framework Programme

FTP File Transfer Protocol

GA Grand Agreement

GDPR General Data Protection Regulation

GPS Global Positioning System

HTTPS Hypertext Transfer Protocol Secure

ICT Information and Communication Technologies

ID Identifier

IDS Intrusion Detection System

IEEE Institute of Electrical and Electronics Engineers

IIP Istituto Italiano Privacy

IoT Internet of Things

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

IT Information Technology

KPI Key Performance Indicator

LAN Local Area Network

QoS Quality of Service

QoE Quality of Experience

R&D Research & Development

REST Representational State Transfer

SSH Secure Shell

SSL Secure Sockets Layer

URL Uniform Resource Locator

WP Work Package


of 85

Executive Summary

This document reports on the technical progress achieved in the context of Task T2.3 “Identity

management and reputation mechanisms”. In the first part of the document we describe the

identity management process for the platform. Issues, such as role based authentication,

identity assignment and protection as well as authorization are discussed. In addition, a detailed

response to the Reviewers’ comments is also included.

In the second part of the document, the reputation mechanisms in which the ranking functions,

users’ feedback, quality of service are discussed and a brief introduction regarding incentives

modelling is presented. In addition, privacy by design is revisited and some relevant privacy

features that we have implemented are presented (sliced consent, right to be forgotten, and

data granularity etc.). Finally, a detailed risk analysis of the platform is provided along with useful

insights for improvements with respect to the protection of the users’ privacy.


of 85

1 Introduction

1.1 The IoT Lab project in brief

IoT Lab is a European research project exploring the potential of crowdsourcing to extend

European IoT testbed infrastructure for multidisciplinary experiments with more end-user

interactions. It researches and develops:

1. Crowdsourcing mechanisms and tools enabling testbeds to use third parties resources

(such as mobile phones), and to interact with distributed users (the crowd). The

crowdsourcing enablers will address issues such as privacy by design, identity

management, security, reputation mechanisms, and data ownership.

2. Virtualization of crowdsourcing and testbed components by using a meta-layer with an

open interface, facilitating the integration and interaction with heterogeneous components.

It should ease data integration and reduce the cost of deployment in real environment.

3. Ubiquitous Interconnection and Cloudification of the testbeds resources. It will research

the potential of IPv6 and network virtualization to interconnect heterogeneous and

distributed resources through a Virtual IoT Network and will integrate them into the Cloud to

provide an on-line platform of crowdsourcing Testbed as a Service (TBaaS) available to the

research community.

4. End-user and societal value creation by analysing the potential end-users and

crowdsourcing participants to propose an optimized model for end-user adoption and

societal value creation.

5. “Crowdsourcing-driven research” as a new model in which the research can be initiated,

guided and assessed by the crowd. It will compare it to other models.

6. Economic dimension of crowdsourcing testbed, by analysing the potential markets and

business models able to monetize the provided resources with adequate incentives, in order

to optimize the exploitation, costs, profitability and economic sustainability of such testbeds.

It will also develop tools for future experiments.

7. Performing multidisciplinary experiments, including end-user driven experiments through

crowdsourcing, to assess the added value of such approach.

The project will adopt a multidisciplinary approach and address issues such as privacy and

personal data protection. To achieve these ambitious goals, the consortium consists of

seven international academic or research partners and a SME that bring in expertise from

complementary research areas, including Information and Communication Technologies,

End-user interaction, and Economics.


of 85

1.2 Purpose and scope of the WP 2

Crowdsourcing is an emerging paradigm which allows citizen provided resources and

infrastructure to be leveraged for experimentation tasks. Crowdsourcing offers several

advantages compared to traditional dedicated testbed deployments and will play an

important role for future IoT testbeds and experimentation in the following areas: 1)

experiments can be easily scaled up without significant testbed infrastructure investments,

2) the geographic coverage of IoT testbed resources can be greatly extended to different

environments in which the crowdsourced resources are hosted 3) deeper societal

penetration can be achieved as devices close to end-users can be incorporated into

experimentation.

Besides these advantages and potential, providing reliable experimentation on top of

crowdsourced testbed resources remains a challenging task. This is mainly due to the

indeterminism introduced by the infrastructure outside the physical control of the testbed

provider. Owners who have provided IoT resources, e.g. Smart Phones, for experimentation

to IoT Lab may decide to switch off resources at arbitrary moments, or may frequently

change preferences for access and sharing policies. Crowdsourced devices may be used

for the normal purpose during ongoing experimentation affecting available system resources

for experiments or vice versa the user experience can be negatively affected by it. Other

challenges are the handling of system dynamics such as mobility, connectivity availability

and energy resource depletion or changes to the experimentation context during ongoing

experimentation.

Another challenge relates to the preservation of privacy of owners/end-users of crowd

provided resources and the enforcement of end-user preferences for experimentation tasks.

An experimentation framework that encompasses crowdsourced devices must take great

care in ensuring user confidence in the system, as negative experiences can quickly lead to

withdrawal of many users/resources from the system.

All the above challenges render existing IoT experimentation frameworks and

methodologies unsuitable to use without the adaptation of these challenging characteristics.

The main goal of this WP is to tackle the above stated challenges in order to ensure a

successful participation of crowdsourced devices as part of the IoT Lab experimentation

framework and to provide testbed users with an effective and efficient experimentation

experience on top of it.


of 85

1.3 Purpose and scope of the Task T2.3

In our proposed Internet of Things testbed paradigm, the crowd plays a vital role. In order to

guarantee that adequate privacy, trust and quality of service standards are met, several

identity management and reputation management mechanisms are investigated. In

particular, to the contributors and the end-users of the IoT testbed platform, there will be

assigned individual identifiers that will be used for their authentication, authorization and

management of privileges across the platform. The form and range of these identifiers is

investigated in the context of this task. As an example, identifiers could include usernames,

passwords and digital certificates, etc.

We also investigate and try to employ novel concepts in identity management, such as

Attribute-Based Credentials. These credentials allow the authentication of a user towards a

service without requiring the user to reveal his or her identity elements. Other issues to be

investigated include the methods by which identities are assigned to contributors and end-

users, the protection of these identities and the corresponding technologies that support this

protection (e.g. secure network protocols such as SSL).

The role of Reputation Management Mechanisms in guaranteeing an adequate quality of

service by the IoT testbed platform will be investigated as well. For instance, such

mechanisms could be used in order to design ranking functions or to adjust the authorization

and access privileges for both end-users and contributing systems/networks. Also, these

mechanisms could take into consideration active feedback from the end-users of the

platform or network/system related attributes. Reputation Management Mechanisms are

closely related to and enhance trust and could provide incentives to contributors so that they

could adopt architectures with strong trust and privacy related properties.


of 85

1.4 Purpose and scope of the current document

In this document we describe the work carried out within the scope of task T2.3 “Identify

management and reputation mechanism”. This description includes the role-based

authentication and authorization scheme that we have implemented. We also present the

Reputation Mechanisms that we have designed for the IoT Lab which aim at increasing

crowd participation.

The deliverable is aligned with the Reviewers’ request to continuously apply “the privacy by

design mantra”, including full transparency, prior informed consent, the Right to be forgotten,

and anonymity definition, etc. It takes into account specifically the recently adopted

European General Data Protection Regulation.

This report includes a clear and complete privacy and data protection risks assessment of

the IoT Lab infrastructure and data stored (e.g. re-identification, risks of surveillance, risk

that data are to be transmitted to authorities, etc.).

The adaptations on mobile application includes:

Default option for privacy related settings (opt-in vs. opt-out; the default presently is

‘data collection’);

Notification of users when sensors are enabled for experiments and an experiment

starts using sensors;

Consent and settings modification via the application;

Decision as a matter of policy whether the platform will allow and facilitate the

collection of biometric data (face, heart rate, etc.), and evaluation of the risks and the

definition of the strategy to inform and to protect.

The analysis and recommendations on relevant privacy issues, including the Right to be

forgotten and the anonymization of experimental data are documented in this deliverable.

We describe the solutions that we have implemented to address the relevant privacy issues.

Finally, we present a global risk analysis for the IoT Lab platform.


of 85

2 Responses to the Reviewers’ Comments

In this section, we address the Reviewers' report recommendations on issues relevant to

privacy and our strategy and technical approach are presented. In our design, we took into

account all remarks from the Reviewers and revised our strategy in light of the European

norms for personal data protection.

We present our strategy for each comment about ethical and policy issues in the reviewers

report:

1. Partners should keep in mind that the personal data are stored with the Testbed

in distinct places but, as a link with individuals remains possible (e.g. indirectly

via Email address or unique identifier), are not anonymous. Therefore, they

should be careful with the use of this term. If the data were anonymous, no data

protection concerns would rise. This is obviously not the case. Hence, a clear

distinction should be made with the personal data collected and stored on IoT

Lab, which are not anonymous and the data made available (for re-use) to third

party researchers which are aggregated data but not fully anonymous data.

The Reviewers are correct to address this risk. The newly adopted General Data

Protection Regulation provides a clear definition of anonymized data. In its Recital

26, it states: “The principles of data protection should therefore not apply to

anonymous information, namely information which does not relate to an identified or

identifiable natural person or to personal data rendered anonymous in such a manner

that the data subject is not or no longer identifiable. This Regulation does not

therefore concern the processing of such anonymous information, including for

statistical or research purposes.”

One of the challenges of the IoT Lab project is to provide data from the crowd to

researchers, in a manner compliant with the personal data protection norms adopted

by the legislator, and with the researchers’ needs and requirements. In this context,

anonymization of data collected from the crowd is challenging but required. The

alternative would be to collect data qualified as personal, which could be accessed,

changed and deleted by their data subject at any time. This would imply for instance

that the experiment results could be changed a posteriori, after the researcher would

have published its results. Such an alternative would make the platform inadequate

with research principles.

This context convinced us that we had to adopt a dual approach:

Ensure full and effective anonymity of all data provided by crowd participants,

in line with the Recital 26 of the GDPR;

Apply personal data obligations to the researchers or any other stakeholder

who would provide personal data to the platform. While respecting the principle

of data minimization, the IoT Lab platform considers that the crowd participants


of 85

have the right to get clear and transparent information on who is leading the

researches.

Our first precaution right from the start was to render the stored data from the crowd

participants effectively anonymous and not allow the participant to enter any

identifying information about him or herself. To this end, the participant by design is

not required to enter his/her email or name/surname, phone number and home

address in order to participate in an experiment through the platform (the interfaces

accepting input from the user do not ask for such information). Moreover, we included

new provisions in the IoT Lab application and platform’s Terms Of References that

forbid the collection of personal data (such as email address, name, phone number,

etc.) through indirect means, such as surveys, and we invite the community to inform

the Platform Administrator of any breach of this obligation.

The participant’s smart phone is differentiated with an anonymous ID, with no data

stored that could enable the direct identification of the user. Thus, the data (i.e. sensor

values) to support an experiment and submitted by the participant later, cannot be

directly linked to the identity of the natural person who supplied it.

However, there is a risk of indirect participant identity exposure. This can be possible

after subjecting the participant data (i.e. sensor data) to a special analysis based on

spatial and temporal correlations as well as information about the place where the

data was collected (e.g. city, city area, country). For instance, GPS sensor data can

result in user identification under certain circumstances and in combination with other

information. This is especially true in the context of the new Web 3.0 where machine

analysis of Internet data is easier and at a more massive scale, giving rise to serious

inferencing attacks on the participant’s privacy. Since such risks cannot possibly be

foreseen nor anticipated, our consortium has taken special care to implement a

number of techniques (mostly based on randomization and generalization) that alter

the participants’ data so as to prevent inferencing/indirect privacy risks but still retains

their usefulness in experiments.

Other privacy risks such as identification through the IP has been properly considered

and resulted in the conclusion that the platform does not access nor store user

personal IP addresses, as smartphones do not have static IP addresses. We access

only the “NATed” IP addresses provided by the telco operator. We discuss our risk

minimization strategy and specific measures to ensure proper anonymization of data

in Section 5 Relevant Privacy and Personal Data Protection Issues.

Another important dimension of our strategy has been to adopt a clear and explicit

prior informed consent mechanism that is always controlled and can be modified and

blocked at any time by the participants.


of 85

Finally, we followed the principle of “proportionality” and the consistent interpretation

and reference of Working Party 29 and the European Court of Justice to the notion

of possible identification through “reasonable means”. As stated in the GDPR Recital

26: “To determine whether a natural person is identifiable, account should be taken

of all the means reasonably likely to be used, such as singling out, either by the

controller or by another person to identify the natural person directly or indirectly. To

ascertain whether means are reasonably likely to be used to identify the natural

person, account should be taken of all objective factors, such as the costs of and

the amount of time required for identification, taking into consideration the

available technology at the time of the processing and technological developments.”

The European norms has voluntarily chosen a certain dose of pragmatism and

balance of interests. IoT Lab did its best to comply with the form and spirit of the

European Personal Data Protection Regulation.

2. Partners should make sure that crowd participants can at all times easily

withdraw consent and ask to erase all their data (not only email address and

phone numbers) and make sure that this is also respected by third parties, and

contemplate technical measures to accomplish this.

As mentioned above, IoT Lab adapted its platform to ensure that data collected from

crowd participants are fully and effectively anonymized. According to the GDPR,

anonymized data are not subject to access, modification and deletion rights.

Moreover, as previously explained, researchers cannot take the risk that their

experiment results are modified a posteriori. We also included a very clear clause in

the prior informed consent in which the participants formally accept to give away their

anonymized data or their researches.

However, in order to anticipate a potential evolution of the normative framework, or a

technological evolution, we have considered and implemented several

complementary mechanisms:

A mechanism enabling participants at any time to block any data sharing and

to erase their socioeconomic profile from the IoT Lab system.

A mechanism that enables the Platform Administrator, on a case by case basis

to access, modify and/or delete all data sets linked to an anonymous identifier.

These mechanisms enable further advancement than what is formally required by the

GDPR. Participants explicitly accept to give away experiment data, provided that they

are anonymized.

For further details, please refer to Section 5.


of 85

3. Full transparency to crowd participants about the use of their mobile resources

and data is required. It includes clear information about the different types of

use of their personal data (e.g. research oriented versus use for policy

decisions). A ‘slice-based’ (granular) consent for different types of use is

advised and technical tools to label personal data collected from these users

accordingly. In addition, this could be reflected in the architecture by different

groups of personal data available with the individual testbed resources and

selective access by the IoT lab.

We have implemented, fully, the concept of “sliced-based consent” in all operations

that involve the dispatch of sensor data to the IoT platform. Special messages appear

on the user’s screen which describe which type of data is going to be dispatched.

Also, there exists full information about the usage of the users’ data as well as the

experiment which uses it. We have also Role-Based Access Control Mechanisms for

the access of different types of data, restricting their use to the consigned operators

or experimenters. Please refer to Section 5.3 for further details.

4. In view of further persistence of the work done, guidance to future users of the

testbed/platform in for example appropriate terms of use, including for

appropriate privacy and data protection, should be contemplated in the third

year of the project. Roles of users, also in terms of data protection, should be

clearly mapped.

We have provided relevant documentation and guidelines as we have implemented

full role-based data access controls. Please refer to Section 3.2 for more details and

Section 5 for a clear view on our adopted privacy policy.

5. In case of use of existing survey tools for collection of crowd input (by

questionnaires), partners should make sure that the terms of use of such

survey tools do not conflict with the data protection guarantees given to the

crowd participants/end-users (e.g. use of LimeSurvey tool, see D7.2, p. 18)

which allows potential collection of IP addresses). A short description of

available (privacy friendly) different (web) survey tools for future users in D7.2

would be helpful in this regard.

General statement

The IoT Lab platform should ensure that any personal identifier of the participants such as: participant individual IP address, MAC address, email address, phone number, name, postal address, i.e. should be effectively and completely anonymous.

This is established as a shared obligation NOT to request any personal identification of the participants, as stated above and to inform the IoT Lab


of 85

platform immediately of any breach of this obligation.

This also applies to any 3rd party tools, such as LimeSurvey, that is hosted by IoT Lab platform and used by IoT Lab researchers for the surveys’ creation.

On IP address

Working Party 29 and the European Court of Justice highlighted the potential risk to

identify a natural person through IP addresses. IP addresses can be useful, for

instance, to get an approximate geographic location with a low level of granularity.

The core IoT Lab platform does not collect IP addresses. However, LimeSurvey can

collect such IP addresses, as indicated below:

On IP address collection in Lime Survey

“Saving the IP address of a participant is quite easy with LimeSurvey: this is just a general

setting for your survey. Go to General settings -> Notification & data management and

set the ‘Save IP address’ setting to ‘Yes’.

When you activate your survey, your responses will have an extra column stating the IP

address of the participant. You can export this data and use one of the many available

APIs to retrieve location data for an IP (contact lab support if you’re interested in a script).

Do note that the IP address does not always give a representative account of the location

of your participant: the participant might connect via a proxy, his ISP might have rerouted

his connection, or the IP address might be spoofed. Also, participants might fill in the

survey from a different address than their home address, so if you’re really interested in

their location (or their place of birth), you might want them to pinpoint that on a map. How

that work is explained in the next chapter.”

Our approach to the IP address:

In the case of IoT Lab, the participants have to provide their data through a mobile phone, which doesn’t have a static IP address, nor a direct access to the Internet. The Internet access is provided by a telco operator, who serves as proxy for accessing the Internet, and uses network address translation. It means that the IP addresses received by the IoT Lab platform are not linked to any specific user. Of course, IoT Lab has no possibility to access the logs of telco operators in order to identify the user behind a volatile NATed IP address. This can be compared to the case mentioned by Working Party 29 regarding cyber cafés, where IP addresses can be used by various users and are considered in this case as non-personal data.

Moreover, with respect to the user’s IP address which can be collected by the LimeSurvey through the settings specified by the researcher before activating the survey (Figure 1), the IoT Lab platform can prevent its collection by running a script that deletes all IP addresses from the corresponding column when a survey is posted. As mentioned, the collected IP address refers to the IP address

https://uilots-labs.wp.hum.uu.nl/glossary/limesurvey/

http://en.wikipedia.org/wiki/Internet_service_provider

http://en.wikipedia.org/wiki/IP_address_spoofing


of 85

of the provider.

Figure 1: LimeSurvey activation – settings option


of 85

On location

On location collection in Lime Survey

“LimeSurvey has a specific question type available to pinpoint a location on a map. You

can e.g. ask someone to select his location of birth on a Google Map overlay. The

question will return the selected longitude and latitude as well as basic address

information: the country, region, city and ZIP code.

To add this type of question, select “Short free text” as the question type and open the

Advanced settings. Select “Google Maps” for “Use mapping service” to convert this

question into a map selection question. It’s advisable to use the IP address as default

location, otherwise you’ll end up with [0, 0], which is somewhere south off the coast of

Ghana. You can set additional settings on what you want to have saved, and also on the

layout of the map.

Note for external users: the setting to use the IP address as a location requires an API

key from http://www.ipinfodb.com/ which you’ll have to set in your general settings. Also,

note that pre 2.0-versions of LimeSurvey use a deprecated version of that API (v2 instead

of v3) and will thus break. For a quick fix, go to qanda.php, function getLatLongFromIp,

and compare/repair this function with the latest and greatest

in/application/helpers/qanda_helper.php (link to GitHub).”

Our approach for location:

Collection of GPS location of participants is very important for one of the planned

use cases (D8.3.2 – ekoNET Solutions on Air pollution) that collects the

subjective view of the participants at a given time and place (through the survey)

and compares it with the factual environmental data at the same place and time

(through IoT data collection). It is one of the cases where we can combine the

two halves of IoT Lab TBaaS.

In order to comply with the privacy protection requirements, it is important to

ensure collection of geo-location information with a level of granularity that is on

one hand high enough for reliable correlation with other data, but is low enough

to prevent any identification of the participant.

Collection of the GPS location through the platform is fine since the platform

applies a random parameter and limited granularity, which will prevent

identifying the users’ precise location. The accessed data is rounded. A

researcher or administrator can only access the rounded data and cannot

access the detailed GPS.

https://uilots-labs.wp.hum.uu.nl/glossary/limesurvey/

http://www.ipinfodb.com/

https://github.com/LimeSurvey/LimeSurvey/blob/master/application/helpers/qanda_helper.php#L3663


of 85

6. The implementation of the mobile application shall be revised considering the

default option for privacy related settings (opt-in vs. opt-out; the default

presently is ‘data collection’).

All default options are set to “opted-out”. As long as resources are enabled, they can

be used for experimentation.

7. By default, users of the application should be clearly notified in the following

cases:

- sensors are enabled for experiments

- an experiment starts using sensors

The application should allow the user to change consent and the settings via

the application.

We have implemented Sliced-Based Consent, where users are always asked before

their sensor data is dispatched. Please refer to Section 5.3 Sliced Informed Consent.

8. The project further needs to decide as a matter of policy whether the platform

will allow and facilitate the collection of biometric data (face, heart rate, etc.),

and if so, evaluate the risks and define the strategy to inform and to protect.

As a strategic decision, the IoT platform has not been designed to handle biometric

data, neither now nor will it do so in the future.


of 85

3 Identity management

3.1 The attribute-based credentials concept for identity management

Almost all applications and services based on computer systems require some form of

authentication of participants in order to establish trust relations, either for only one endpoint

of communication or for both. One widely used mechanism for this is a password based

authentication. Given the weaknesses of such a simple authentication method, multiple

alternative techniques have been developed to provide a higher degree of access control of

which Cryptographic certificates is one. Although such certificates can offer sufficient

security for many purposes, they do not typically cater to privacy because they are bound to

the identity of a real person. Any usage of such a certificate exposes the holder’s identity to

the party requesting authentication. There are many scenarios where the use of such

certificates unnecessarily reveals the identity of their holder, for instance scenarios where a

service platform only needs to verify the age of a user but not his/her actual identity.

Revealing more information than is necessary not only harms the users’ privacy but also

increases the risk of abuse of information resulting in for example, identify theft when

information falls in the wrong hands.

Figure 2: Basic functionality of an ABC system.

Over the past 10-15 years, a number of technologies have been developed in order to build

ABC systems in a way that they can be trusted, like normal cryptographic certificates, while

at the same time protecting the privacy of the holder (e.g., hiding the real holder’s identity).

Such Attribute-based credentials (ABCs) are issued just like ordinary cryptographic

credentials (e.g., X.509 credentials) using a digital (secret) signature key. However, ABCs

allow their holder to transform them into a new credential that contains only a subset of the

attributes contained in the original credential. Still, these transformed credentials verify just


of 85

like ordinary cryptographic credentials (by using the public verification key of the issuer) and

offering the same strong security (Figure 2).

Based on Figure 2, a credential is a certified container of attributes issued by an issuer to a

user (i.e. an entity possibly collecting credentials from various issuers and controlling which

information from which credentials are presented to which verifiers). An attribute is described

by the attribute type, determining the semantics of the attribute (e.g., first name), and the

attribute value, determining its contents (e.g., John). By issuing a credential, the issuer

vouches for the correctness of the contained attributes with respect to the user.

The user can then later use his or her credentials to provide certified information to a verifier

(for authentication or an access decision), by deriving presentation tokens that reveal partial

information (in fact the minimum required information needed for the transaction) about the

encoded attributes. Apart from revealing information about credential attributes, the

presentation token can optionally sign an application-specific message and/or a random

nonce to guarantee freshness. Moreover, presentation tokens support a number of

advanced features such as pseudonyms, device binding, inspection, and revocation.

Presentation tokens based on Privacy-ABCs are in principle cryptographically unlinkable

(although naturally, they are only as unlinkable as the information they intentionally reveal)

and untraceable, meaning that verifiers cannot tell whether two presentation tokens were

derived from the same or from different credentials and that issuers cannot trace a

presentation token back to the issuance of the underlying credentials. However,

pseudonyms and inspection can be used to purposely create “linkability” across presentation

tokens (e.g., to maintain a state across sessions by the same user) and create traceability

of presentation tokens (e.g., for accountability reasons in case of abuse).

There are a handful of proposals about how to realize an ABC system in the literature.

Notable is the appearance of two technologies: IBM’s Identity Mixer and Microsoft’s U-prove

and Privacy-ABCs which actually integrate in an interoperable way, the two technologies.

However, the complexity of ABC technologies and the client-server interactions have so far

overwhelmed potential users and consequently hindered their effective large scale

deployment. Overcoming these hurdles requires an in-depth comparative study of the

functionalities of the different ABC technologies and an analysis of their security and

efficiency properties for a common understanding of their applicability to diverse application

fields and scenarios.

With a comparative understanding of these technologies, it is quite likely that different user

communities and different application scenarios are able to decide how they are best served

by these technologies. Also further advances in ABC technologies will undoubtedly occur

over time. Yet the same users may want to access applications requiring different ABC

technologies, and the same applications may want to cater to user communities preferring

different ABC technologies. Hence, it is essential that different ABC technologies coexist or

be interchanged by the same user and application platforms. It may also be sometimes

desirable to convert ABCs from one technology into another so as to federate across


of 85

different ABC domains, as is done today between different authentication domains using

standards such as SAML, Kerberos, or OpenID. There are no commonly agreed sets of

functions, features, formats, protocols, and metrics to gauge and compare ABC

technologies, so it is hard to judge their respective pros and cons. There is also currently no

established practice or standard to allow for the interchangeability and federation of ABC

technologies.

With respect to applicability, a number of countries have already introduced or are about to

introduce electronic identity cards (eID) and drivers licenses. Electronic ticketing and toll

systems are also widely used all over the world. As such electronic devices become

widespread for identification, authentication, and payment (which links them to people

through credit card systems) in a broad range of scenarios, the users’ privacy and

traceability will be increasingly threatened in the future Internet society. If and when eIDs

are rolled out, societies and countries are well advised to build privacy protection techniques

into them, such as ABCs. We note that employing ABC technologies requires a number of

surrounding infrastructure components due to the need to be integrated into authorization

and access control systems. Thereby, policy languages play a particularly important role.

In summary, as electronic personal identification cards (eID) and electronic driving licenses

are becoming more widespread, maintaining the users’ privacy will become an even greater

challenge. Privacy technologies, such as the ones mentioned above, will be necessary to

build sustainable privacy solutions into these systems and realize their benefits for

tomorrow’s information society.

As a final remark for our project, using ABCs is not advisable, given the project’s goals, since

users are anonymous from the beginning. However, in a future version of the IoT Lab

platform, users may register their full identity and then use ABCs to only prove their eligibility

to participate or prove some other elements important to an ongoing experiment, such as

their age or occupation.


of 85

3.2 Role Based Authentication and Authorisation System

For the purposes of the IoT Lab project, an Identity Management Scheme is implemented

with a Role-Based Authentication and Authorisation Policy. In this scheme, individual

identifiers are assigned to all the types of platform users for their authentication,

authorization and management of privileges across the platform. For all types of users,

individual identifiers (username and password) for accessing the platform are used. The

access rights differ from user to user, depending on the user’s role (e.g. Administrator,

Researcher, Participant, Sponsor, Charity, etc.).

3.2.1 The distinct roles of platform users and the available functionalities

The distinct roles that a user can have ultimately determines the functionalities and access

rights on the system. Each user is assigned a role during registration and this defines the

user’s platform access rights for the lifetime of the account. Multiple roles cannot be

assigned to a single user account therefore, when necessary, multiple registrations to the

platform one for each role are required.

The foreseen roles for the IoT Lab platform are as follows:

Crowd participants

Crowd participant refers to any user of the IoT Lab Smartphone application who has installed

the app on his/her smartphone. This role is extended, by default, to any user that is using

the mobile app. The crowd participants can get involved in improving the platform in a

number of ways including:

Proposing research ideas by stating their opinions regarding the ideas of others;

Providing mobile device’s sensor data to the platform on a voluntary basis;

Providing data/knowledge/information through their participation in surveys performed by the researchers.

Crowd participants can provide anonymously and as an option, their socioeconomic profiles

which are then made available to the researchers. This is to target their surveys and

questionnaires to specific end-user profiles, as well as to analyse correlations between

results and socioeconomic dimensions. However, the data collected are limited to large

categories to avoid data that is too granular and could be combined to identify an individual.

It also avoids collecting identifying information, such as email addresses.

The database does not store the phone number or IP address of the participant. For all

communications originating from the platform to the participant's mobile device, an

anonymous token is stored in the database to enable this communication. Communications

originating from the participant's mobile device use standard HTTP APIs that only store data

provided as arguments from the device (e.g. data the user is implicitly sending and none of

the communication itself i.e. IP address, MAC address etc.) Other personal data entered by

the user as part of their socioeconomic profile are stored in the database but can be deleted

at any time from within the mobile application or using the "forget me" functionality.


of 85

Depending on their contributions (e.g. quality and quantity of provided

data/information/ideas) to the platform, crowd participants also receive points and achieve

badges which can be exchanged for donations to their favorite charities selected from an

offered list. This is part of the incentives scheme that aims to foster their participation.

Each mobile phone connected to the platform is identified through a unique identifier which

cannot be reversed. The system has been designed to ensure that the database identifier

cannot be linked to a physical user through “reasonable means” as stated by the European

GDPR (Recital 26) and in line with Working Party 29’s interpretation in Opinion 5/2014 on

anonymization techniques1.

All data/information provided by the users are anonymised by default and cannot be in the

future linked to them.

Researcher

The researchers’ category refers to any user of the IoT Lab Testbed as a Service who

performs research or experiments. Each researcher must be registered to the platform

before he/she is able to use its resources. This is required in order to guard against

overloading the system with open access while at the same time protects against malicious

misuse since researchers are not anonymous. In order to comply with transparency

requirements with the participants, the researchers must register their full identities.

A researcher can initiate experiments and execute them either through IoT interactions or

through crowd interactions.

Research based on IoT interactions include experiments that use sensor data, either from fixed/portable testbeds (allowed to reserve them for the purpose of their experiments) or from the mobile app sensors.

Research based on crowd interactions refers to compiling and distributing surveys to end-users of targeted socioeconomic groups who provide the required information/opinion/knowledge back to the platform.

Researchers have access to all the data collected to support their experiment and research

in order to conduct analysis and report the results.

Researchers can also be recipients of sponsorship funds and be able to allocate the funds

in order to support their experiments and research goals.

Platform Administrator

The Platform Administrator is an internal role corresponding to the person responsible for

the supervision of all activities related to the platform and the management of user accounts.

The Platform Administrator manages the following tasks:

Validation/approval, suspension or rejection of researchers’ or other platform users’

1http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf


of 85

access to the platform (e.g. a researcher’s access to the platform can be declined in case of registering/conducting a non-ethical research);

Carrying out a global data deletion request in order to realize the Right to be forgotten functionality requirement.

In addition to this, The Platform Administration’s role assumes access to the following:

All data produced by the experiments;

Current, past and future experiment resource reservations;

Surveys from all participating mobile phones and researchers.

Testbed Owner

This role is assigned to users that belong to the entities that make physical testbeds

available (universities, companies, foundations, etc.) and have been given the right to use

the IoT Lab platform. They are responsible for maintaining their testbed resources in a

coherent way including inserting/updating new resources and specifying the resource

accessibility using related database APIs. Through this role, they have access to all the data

and resource reservations that belong to their specific testbed.

Sponsor

The Sponsor role is given to users who wish to make donations (sponsorships) to specific

researchers or directly to researches. When a sponsorship is given to a researcher instead

of a research, the researcher can then choose the manner in which the donation will be

distributed to their researches.

Sponsors, when logged in to the platform can have access to:

A list of all researchers that applied for donations (with all the relevant data about that researcher and its research);

A list of all researches that opted for donations (with access to the research description, objectives, timescale, etc.).

They can select a specific research or researcher from the list and donate the money directly

via PayPal.

Each Sponsor also has access to the list of all of his or her sponsored researchers and

researches.

Charity

This role is given to users that represent registered charities. Charities have to provide all

the information necessary to prove their legal status (formal paperwork, banking information

etc.) since they are the intended recipients of sponsorship funds donated to the platform.

They also need to provide detailed descriptions of their activities and goals. The charity role

has no real interaction with the IoT Lab platform but appears in a list provided to the end-

users who then choose a charity that will receive the sponsorship funds. This is done after

their registration is approved and they have participated in a sponsored experiment.


of 85

3.3 Protection of identities

The user identities are protected against various privacy risks by means of specific

measures we have taken, within the context of the overall security of the platform. The risks

are presented in depth in Section 5, where a Systematic Risk Analysis is presented for the

most common identified threats. In order to reduce the risk effects on the users and the

platform, a number of security measures have been taken. These measures are taken at

different levels across the IoT Lab system.

Security of Servers

Beyond activating the network firewalls in routers, the firewalls in all servers of the crowd

sourcing platform are enabled. In the servers’ firewalls, only the ports that are used by

services are open while all other services, such as email, FTP, and DNS are disabled.

Furthermore, for some services (e.g. SSH connections) access is allowed only from specific,

trusted client computers for remote administration purposes.

The system settings are very important within this context. A very strong password for a

System Administrator is mandatory while processes run in non-privileged mode to avoid

causing system instability or malfunction. Also, daemon processes that run for specific

purposes (e.g. socket services) are not run with administrator privilege (root).

A backup policy is also enforced that schedules a system-wide backup at least once a week

on a removable storage media. Organisational and technical guidelines are also issued with

regard to protecting and using the removable media on which the data is stored in order to

prevent unauthorised access and processing as well as accidental damage.

In addition, the system is always kept up to date. Periodically, operating system kernel

patches are installed while the latest releases of installed applications are downloaded as

soon as they become available.

Penetration testing tools (e.g. Nessus, Backtrack) run periodically to detect possible security

issues in the system.

Data Storage Security

Data storage is protected against any illegitimate access by external parties. We enforce

database access control policies through a username/password based authentication

mechanism, as well as by assigning distinct roles and access rights to different user groups.

Access to the database in production mode for obtaining user data is restricted to computers

only residing in the same local area network (LAN) in which the database resides, for

security reasons. Thus, only services that run on computers in the same LAN as the

computer hosting the database are able to submit and execute database queries.

It is also important to create several user classes with different database access privileges.

For example, an Administrator has full access rights, a User of the crowdsourcing tool can

only insert sensor data and Experimenters can access anonymized sensor data.

Special attention is paid to installing the appropriate database management tools. As it is


of 85

recommended, we avoid using the phpMyAdmin tool for security reasons in production

mode. It is preferable to connect to the MySQL database using secure tunnelling over SSH.

Network Security

Sensitive data is protected against unauthorised access by implementing suitable data

protection mechanisms. For instance, all the ports of a firewall are closed for all unused

services such as mail, FTP, DNS, etc.

For stronger security, in cases where remote access to a server is required (e.g. remote

access by an Administrator), we have employed a DMZ (Demilitarized Zone) network

configuration. The purpose of a DMZ is to add an additional layer of security to an

organization's local area network (LAN). An external attacker has only direct access to

equipment in the DMZ, rather than any other part of the local network. To create a DMZ, a

two firewall configuration or a VPN server can be used.

Personal data is protected against the risk of intrusion into the system’s infrastructure. The

potential effects of viruses and other malicious programmes are minimized through the

implementation of suitable Anti-Malware techniques. These techniques are regularly

reviewed and modified, at least once every six months. For proactive security, there are

several IDS (Intrusion Detection System) tool systems in the market. The System

Administrator uses the most appropriate one.

Some IDS with which our team is familiar with are:

Snort, which is one of the most widely adopted IDS. It is open source software and it is included in the Debian Linux distribution;

Advanced Intrusion Detection Environment (AIDE) which is open source and compatible with the Debian server;

Tiger, a UNIX security auditing and intrusion detection tool which is freely available under a GPL license.

Security at the Application Level

Our project’s development teams follow all the customary, important security guidelines

recommended by experts for the development of the IoT platform applications and services.

For the Android application of the crowdsourcing tool, the official Android webpage [1]

provides recommendations for handling several security issues. For the Web applications,

our developers refer to the official security pages of the development tools they use and

follow the provided guidelines.

There are several programming languages and development tools for Web services and

applications. A list of such tools, along with their security documentations are as follows:

PHP: http://php.net/manual/en/security.php

Perl : http://perldoc.perl.org/perlsec.html


of 85

Python: https://docs.python.org/

Finally, we always install updates and patches for all the tools on a regular basis or as soon

as they are made available by the tool providers.

4 Reputation Mechanisms

In accordance to the goals of the project, one of our main priorities is to encourage users to

participate in research experiments. Such a participation from an end-user could be either

passive by providing his or her smartphone resources (sensors) for experiments, or active

by proposing ideas for new experiments, by evaluating the experiments he or she has

participated in and by giving feedback on their experiences in using the platform.

4.1 Active feedback from Users

It will be a major project success if we manage to mobilise a large number of crowd

participants. A vital factor of this success is the satisfaction level of the participants while

using the platform. For this reason, we implemented a mechanism that collects the

participants’ opinion about several crucial aspects of the platform.

The main feedback collection mechanism is to periodically send questionnaires to the

crowdsourcing tool users, asking them to evaluate the IoT Lab platform. The questionnaire

is designed so that the users can give an overall score regarding their experience with the

platform as well as individual scores regarding aspects of the system. For example, the

users are asked to provide a score for the following:

The overall platform

The protection of their privacy

The quality of service that is provided to them

How interesting is the research that is done via the IoT Lab platform

The process by which the charities are chosen and sponsored over the IoT Lab platform

These scores are used to calculate a total evaluation score for the platform. This evaluation

score is made public through the IoT Lab Website and it is updated periodically, taking into

account new user feedback results. This evaluation process which includes the creation of

the questionnaire and the processing of its results is within the scope of work conducted in

WP5.


of 85

4.2 Quality of Service (QoS) guarantees

In order to ensure high levels of Quality of Service (QoS) and Quality of Experience (QoE)

for all end-users participating in crowdsourcing and accessing the platform through a portal

for data perusal, a set of system tests needs to be carried out. To identify the crucial modules

of the platform that require monitoring and testing, we must first define the Quality of Service

aspects of the IoT Lab platform. Then we must check which modules of our system are

related to these aspects. This analysis will help us define a set of Key Performance

Indicators (KPIs) and help us to develop relevant monitoring and testing procedures.

Figure 3: IoT Lab modules overview.

Our platform offers a Web portal for the experimenters to implement their research

experiments. The platform also offers a mobile application for the crowd users enabling them

to contribute to the experiments with their mobile phones and its sensor data. The crowd

users can give their opinion on current experiments as well as give their ideas for new

experiments. An experimenter can design and implement a research experiment which can

involve a survey addressed towards a specific group of crowd users, or a scenario involving

data coming from sensors placed at testbeds or the users’ mobile devices or both. From the

crowd user side, a research experiment may ask the user to get involved in answering a

questionnaire, enabling his or her phone sensors or proposing and rating experimental

ideas. Figure 3 depicts the aspects involved in a research experiment.


of 85

From this Figure, we have defined a set of KPIs related to QoS and have addressed them

as follows:

Service uptime and correct operation (upt): To ensure the uninterrupted and correct

operation of the Web portal, the APIs and databases run a service self-check on their own

status. In case of malfunction, they notify automatically the responsible party to investigate

the problem and take corrective measures.

Service responsiveness (resp): Most of the actions in our platform are asynchronous.

Thus, latency will not be noticeable by the users, the researchers and the participants. Such

asynchronous actions for instance, are uploading and answering a questionnaire. For

synchronous actions some latency may be experienced, especially on the testbeds side. In

order to measure and reduce this latency, a daemon process is continuously running and

measures the latency incurred by each platform module. Upon the detection of extreme or

intolerable latencies, the responsible party is notified to investigate the causes and

implement measures to reduce them.

Correct operation of the experimentation resources (cor): In order to ensure the

availability and correct operation of the IoT resources, three demon services are

continuously running to discover new resources, check the availability of existing ones and

update their status indicators if necessary.

Mobile phone resource conservation (cons): To avoid depletion of mobile phone

resources (i.e. exhaustion of battery or data sensors) a cache algorithm has been

implemented. It checks the measurements database for the existence of recent

measurements before requesting new data directly from a mobile phone.

To each of the four metrics defined above, a value is assigned (see Table 1 below) which

reflects how well the IoT platform performs. Based on these four metrics, we can evaluate

the overall quality of IoT platform service as a weighted average of the values assigned to

the individual metrics. This function is evaluated at the end of each week in order to be as

up to date as possible and to reflect the quality of the service frequently enough to allow for

monitoring and corrective measures.

More specifically, this weighted average function has the following form:

𝑄𝑜𝑆 = 25 ∗ 𝑢𝑝𝑡 + 25 ∗ 𝑟𝑒𝑠𝑝 + 25 ∗ 𝑐𝑜𝑟 + 25 ∗ 𝑐𝑜𝑛𝑠,

where 𝑢𝑝𝑡 is the service uptime and correct operation, 𝑟𝑒𝑠𝑝 is the service responsiveness,

𝑐𝑜𝑟 is the correct operation of the experimentation resources and 𝑐𝑜𝑛𝑠 is the mobile phone

resources conservation.

For both the service uptime and correct operation (𝑢𝑝𝑡) as well as the service

responsiveness (𝑟𝑒𝑠𝑝), we use a Binary Value Scheme, i.e. 0 or 1. If the services work as

intended, 𝑢𝑝𝑡 and 𝑟𝑒𝑠𝑝 will be assigned the Value 1, otherwise they will be assigned the

Value 0. For the correct operation of the experimentation resources (𝑐𝑜𝑟) we consider each

offline or outdated resource as a negative point to the quality of the provided service.

Therefore, 𝑐𝑜𝑟 can be defined as the ratio of the active resources to the total number of


of 85

resources. Lastly, mobile phone resource conservation (𝑐𝑜𝑛𝑠) is calculated by comparing

the current week's ratio of cached measurements with the average value over all the past

weeks. If the current week cached requests are less than the average over the past weeks,

then 𝑐𝑜𝑛𝑠 is set equal to their ratio otherwise it is set by default to 1. A detailed analysis

focused on IoT Lab scalability and its requirements can be found in Deliverable D1.3

Updated IoT Lab Architecture and Components Specification.

In Table 1, we illustrate the use of the 𝑄𝑜𝑆 function by means of an example:

Table 1: The parameters that estimate the Quality of Service that the platform provides

Parameter Weight Value range

Meaning of value

Example computation in the end of the current week

Value Weighted

value

Services uptime and correct operation (upt)

25% Discrete, either 0

or 1

1 means that we had no down time and 0 means the opposite

1 25.00

Service responsiveness (resp)

25% Discrete, either 0

or 1

1 means that if we had no noticeable latency and 0 means the opposite

1 25.00

Correct operation of the experimentation resources (cor)

25% Continuous, from 0 to 1

𝑐𝑜𝑟 = 𝑜𝑛𝑙𝑖𝑛𝑒 𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒𝑠

total resources 0.89 22.25

Mobile phone resources conservation (cons) 25%

Continuous, from 0 to 1

If (

𝑐𝑎𝑐ℎ𝑒𝑤𝑒𝑒𝑘 > 𝑐𝑎𝑐ℎ𝑒𝑎𝑣𝑔)

then 𝑐𝑜𝑛𝑠 = 1

otherwise

𝑐𝑜𝑛𝑠 = 𝑐𝑎𝑐ℎ𝑒𝑤𝑒𝑒𝑘

𝑐𝑎𝑐ℎ𝑒𝑎𝑣𝑔

𝑐𝑎𝑐ℎ𝑒𝑤𝑒𝑒𝑘 = 3%

𝑐𝑎𝑐ℎ𝑒𝑎𝑣𝑔 = 4%

⇒ 𝑐𝑜𝑛𝑠 = 0.75

18.75

QoS Rate: 90.00


of 85

4.3 An incentives model for the crowd participants

In order to better motivate people to participate in submitting new ideas, performing

experiments or participating in them, we have conducted an extensive analysis of potential

motivators and incentives, as part of WP5 and WP6.

In the context of WP6 (Task 6.3), that aims to propose an incentives model for the IoT Lab

crowdsourcing participants and researchers, a detailed analysis has been conducted that is

based on a Holistic Incentive Model Design Methodology. This design methodology is shown

in Figure 4.

Figure 4: IoT Lab Incentives Model Design Methodology

The design of the “IoT Lab Incentive Model” (see Figure 4) is based upon two analytical

processes:

(a) Theoretical background analysis (input from WP5): Understanding what motivates

people to get involved in the IoT Lab experimentation process, the analysis is highly critical

in the identification of the incentive types that can be utilised in order to maximize user

participation.


of 85

(b) “IoT Lab experimentation process” analysis: Having identified the incentive types, it

is equally important to analyse the IoT Lab experimentation process, which involves both

(i) the analysis of the IoT Lab generic experimentation process (see Figure 5) including the

different types of experiments such as lifecycle and the crowd-driven

research/experimentation process, and (ii) the analysis of the different data sources in the

IoT Lab and its experimentation process (i.e., types of data sources and the involved

stakeholders).

Figure 5: IoT Lab Generic Experiment Process “Crowd-driven experiments”

The IoT Lab Incentives model (WP6, T6.3)

The proposed incentives model for the IoT Lab is a “hybrid gamified incentive model” that

combines two key types of incentives: (i) intrinsic and (ii) extrinsic incentives, in accordance

with the WP5 analysis. In addition, it also includes innovative approaches that aim to

enhance both the extrinsic, intrinsic and social motives such as the “gamified approach”.

Gamification Mechanisms (Gamification by design): The IoT Lab incentives model is a

“gamified” one, which will integrate gamification [2] elements aiming to enhance the user

experience and engagement in the IoT Lab activities. These elements are:

Award points: These will be awarded for the different user actions across the IoT

Lab platform. In the context of WP 6 (T6.3) a point-based reward system has been

designed taking into account the specificities of the IoT Lab experimentation process


of 85

for the crowd participants and the researchers.

Leader boards: These will allow users to track their performance over time and

display them to other users of the IoT Lab ecosystem. Leader boards will graphically

display the overall status of a user with respect to the points they have earned and

their earned badges as well as badges that potentially can be received (unlock) with

a small additional effort.

Reputation Scoring (R-Score): In order to further enhance user involvement in the

platform, while evaluating user behaviour in a qualitative and quantitative manner, an

innovative scoring mechanism has been designed. The proposed Reputation Scoring (R-

Score) will characterize users’ overall activity (crowd-driven, value-added, research) from

different perspectives and associated KPIs:

Incentive-based KPI (i.e., points, badges earned);

Crowd-driven research KPI (i.e., proportion of proposed ideas provided by a single

user, frequency of experimental ideas proposals, evolution of ideas into experiment);

Behaviour KPI (i.e., activity history, experiment contribution score, market

assessment contribution score).

Maintaining the R-scores of users facilitates a different reward scheme that encourages

frequent user participation and contribution. The R-score based rewards will be provided to

the top 5% of the users achieving the highest R-Scores. These awards include the following:

Social awards: Top Contributor Award (Electronic badge);

“Good-cause” award: A distinctive badge and the opportunity to select the charity

which will receive part of the IoT Lab donations that will be allocated to the user.

Triangular approach: IoT Lab will also utilise a "Triangular Award Model" which essentially

allows crowd-participants to allocate points/credits collected through their participation

experiments to a charity of their choice, from a list provided by the platform operators. This

approach is based on the working assumption that a research sponsor provides a budget

for an experiment, out of which a small amount (say, 10-20%) will be used for the

maintenance of the platform while the rest will be allocated to the users so that they can, in

turn donate it to the charities in proportion with their earned points.

4.4 Ranking functions

In this section, we present the mechanisms that are implemented for the IoT Lab platform

for rating its different entities and functionalities. These mechanisms, which are comprised

of a set of ranking functions, automatically calculate the values for several metrics of the

platform, such as the Experimenters themselves, the platform users and the proposed users’

ideas for new research experiments.

These metrics are utilized and publicized in different ways to the IoT Lab platform users’

community. Some of these metrics are used in order to increase the efficiency and usability


of 85

of the platform, others are used for providing aggregate information to the community about

the participation of experimenters, users, charities, sponsors, etc. Other metrics are used to

motivate the users to be more active by proposing, for instance, new ideas for research

experiments by participating in more experiments and by providing feedback about their

platform experiences. These metrics are used also in the evaluation of the platform, the

experiments, the proposals for new experiments, etc.

In the next subsections, we present in more detail all the ratings that are used for evaluating

the platform, the experimenters, the end-users and the proposed ideas for new research

experiments.

4.4.1 The ratings for the platform

In order to maintain the highest possible reputation level of the IoT Lab platform, it is

important to provide metrics that quantify some important parameters to the user community

and to the public. One idea is to calculate only one generic rating (this score could be defined

in a scale of, e.g., 5 stars) for the overall platform that will take into account all the

parameters. Although this is a simple and comprehensive way to evaluate the platform, it is

not sufficient enough to understand its main quantitative and qualitative characteristics. For

this reason, we decided to calculate individual scores for the different platform aspects. In

Table 2, the functions that are used to calculate the individual scores are listed.

Table 2: The specific scores calculated for the IoT Lab platform.

Specific score for the

platform

Description

Participants This is the total number of participants of the IoT Lab

platform including:

Crowdsourcing tool users

Researchers

Testbed owners

Charities

Sponsors

Platform donations This is the total amount of donations to charities which

has already been given by the IoT Lab platform.

IoT Research projects This is the total number of all the research projects

that have been completed or are still in progress using

the IoT Lab platform.

Crowd-driven research

projects

This is the total number of research projects that are

based on the interaction with crowd participants,

including:

Number of ideas proposed by the crowd

Number of experiments that use crowd-


of 85

sourced sensors

Number of surveys answered by users

Crowd-sourced sensors This is the total number of resources (e.g.

accelerometers, GPS devices, gyroscopes, etc.) that

are provided by the crowd participants through the

crowdsourcing tool which is installed in their mobile

devices and are made available for experiments.

Testbed resources This is the total number of resources (sensors,

actuators, etc.) which are provided by all the testbeds

that participate in the IoT Lab platform and are

available for experiments.

User evaluation score This is the average score from all ratings gathered

through surveys from the crowdsourcing tool users.

This is described in more detail in Section 4.1 (Active

feedback from users).

Platform efficiency This is a weighted function of some metrics related to

the Quality of Service of the platform. The way in

which it is calculated is presented in more depth in

Section 0 by an example. This score is periodically

calculated and publicised to the community of IoT Lab

platform.

This information can be presented on the Website as an infographic providing an overview

of the quality and effectiveness of the IoT Lab. This infographic can act as a marketing tool

that can be disseminated through social networks and other communications channels in

which the IoT Lab participates. Also, this infographic or parts of it, could be diffused to users

through the crowdsourcing tool.


of 85

4.4.2 The Rating of the Crowd Participants

Except for the IoT Lab platform ratings, there is also a mechanism that calculates ratings for

the crowd participants. The rating of each end-user is automatically calculated by means of

a weighted function that takes into account: the smartphone resources provided to the

experiments, participation in experiments and activity through actions such as stating

opinions in surveys, providing feedback and proposing ideas for new research projects.

The end-users can see their ratings on the crowdsourcing tool installed on their device with

respect to his or her ranking among all other IoT Lab users (e.g. “Your score is higher than

70% of the IoT Lab community users” etc.).

From the server’s side, an API is implemented that calculates the rating of the user and rank

by a ranking function. This ranking function is a weighted sum of the following factors:

The number of sensors provided in experiments: For each sensor the user provides to

the experiments, 100 points are earned. For example, if the accelerometer, the GPS and the

gyroscope are used on the user’s smartphone, 300 points in total are awarded.

The number of experiments participated in: For each experiment, 50 points are earned.

For example, if the user has participated in 25 experiments, 1250 points in total are awarded.

The number of surveys responded to: For each survey in which the user has participated

in, 200 points are. For example, if the user has responded to surveys publicised by the IoT

Lab, 600points are awarded.

The ratings earned for proposing ideas for new experiments: For each new idea, the

user earns as many points as the rating of the idea itself. An idea can obtain a rating between

0 and 100, which is then converted to a 5-star scale to be displayed to the user. For example,

if he or she has proposed 4 ideas receiving the ratings of 65, 79, 24 and 97 respectively,

then 265 points in total are awarded.

The number of times ideas are rated for proposed experiments offered by other users:

For each time the user rates an experiment, 50 points are earned. For example, if he or she

has rated 8 experiments (regardless of the ratings given to them) 400 points in total are

awarded.

The research points gathered from the application of the incentives model: For each

research point that the user has gathered from the incentives model, 10 points are earned.

For example, if he or she has earned 137 research points than 685 points in total in this

rating are awarded.

In Table 3, the weights of all contributing parameters as well as the points and total scores

for two user example are shown.

The rating and rank of all other IoT Lab users can be seen only by the user through the

crowdsourcing tool installed on his or her device. The crowdsourcing tool using the

appropriate API displays the user ratings and ranking, obtained periodically from the server

and is updated accordingly.


of 85

Table 3: The parameters that contribute to the rating of a user and the weights for each parameter. The total rate is the weighted sum of these parameters.

Parameter Weight

Example User A Example User B

Value Points

gathered Value

Points gathered

Number of sensors provided to experiments

100 3 300 2 200

Experiments she has participated in

50 25 1250 37 1850

Surveys she has responded to

200 3 600 3 400

Ratings of her ideas

1

4 ideas with ratings:

65+79+24+97 = 265

265 6 ideas with ratings:

23+92+54+86+93+48 = 396

396

Number of times she has rated other ideas

50 8 400 13 650

Research points 5 137 685 189 945

User's total Rating

4270 5025


of 85

4.4.3 The Ratings of the Experimenters

In this section we present the mechanism that calculate the rating for an experimenter. This

rating is automatically calculated with a weighted function that takes into account the

research projects the experimenter has created using the IoT Lab platform and the

evaluation he or she has received from the users of these experiments.

An experimenter can view his or her ratings on the IoT Lab platform Website in the area that

in which they have access to after logging in. There is also a list with the rankings of the 20

top-rated experimenters.

From the server side, an API is implemented that calculates the rating of an experimenter

as well as his or her rank among all other IoT Lab experimenters based on the ranking

function. The ranking function that calculates the Experimenter’s rating is a weighted sum

of the following:

The number of days the platform is used for running experiments: For each day, the

experimenter earns 1 point. For example, if he or she has been active in the platform since

28/07/2014 and today is 15/03/2016, then the points awarded are 596.

The number of research projects created using the IoT Lab platform: For each research

project created, he or she earns 200 points. For example, if the experimenter has created 5

research projects (e.g. 2 experiments with sensors from testbeds, 1 with crowd sensor

resources and 2 based on crowdsourced surveys) 1000 points in total are awarded.

The number of IoT Interactions researches created using IoT Lab platform:

For each IoT interaction created, he or she earns 50 points. For example, if the experimenter

has created 5 IoT interactions researches 100 points in total are awarded.

In Table 4, the weights of all contributing parameters as well as the points and total scores

for two examples are shown.

Table 4: The parameters that contribute to the rating of an experimenter and for each parameter. The total rate is the weighted sum of these parameters.

Parameter Weight

Example Experimenter A Example Experimenter B

Number Points

gathered Number

Points gathered

Number of days of active participation in the IoT Lab

1 From: 28/07/2014

To: 15/03/2016 = 596 days

596 From: 14/11/2015

To: 15/03/2016 = 122 days

122

Number of created research projects

200 5 1000 6 1200

Number of IoT interactions created

50 5 250 2 100


of 85

Experimenter's total Rating:

1846 1422

4.4.4 The ratings of the proposed ideas for new experiments

One of the functionalities which are provided to end-users through the crowdsourcing tool is

the ability to propose ideas for new experiments. The users can also rate the ideas of other

users and the top rated ideas can be selected by experimenters for actual implementation.

In order to support this process, a mechanism is active that calculates the ratings of

proposed ideas.

The rating of an idea is automatically calculated by a weighted sum that takes into account

the average value of the evaluations for this idea provided by other users, the number of

users that have provided evaluations as well as when this idea was proposed.

The end-users can rate the ideas with a 5-star scale, using a special menu in their

crowdsourcing tool. From the server side, an API is implemented that calculates the rating

of each proposed idea based on a ranking function, which is a weighted sum of the following:

The average rating given to the idea by other users: When an end-user rates an idea of

another user, he or she is able to rate it with a 5-star scale (which is converted into a value

between 0 and 100). The average of these ratings given by all the users to the idea is then

calculated. The weight for this parameter is 70% and this idea takes as many points as the

ratings average for this idea multiplied by 70%. For example, if the average rating of an idea

is 85, (as the rating of an idea is a value between 0 and 100) then this idea earns for this

parameter, 85*70%=59.5 points (this parameter takes values between 0 and 70).

The number of users that have rated the idea: Another parameter is the number of ratings

it received from users. The weight for this parameter is 20%. According to this parameter,

the ideas that were most popular (that is, those which attracted the ratings of most users,

regardless of the actual ratings they received), receive more points. This parameter value is

calculated as follows:

20 ∙10

3(1−1

𝑉𝑜𝑡𝑒𝑠)−1

103−1,

where 𝑉𝑜𝑡𝑒𝑠 is the number of users that rated this idea. For example, if an idea has been

rated by 150 users, then it earns 19.1 points for this parameter (this parameter, when

weighted, takes values between 0 and 20).

When the idea was proposed by a user: The last parameter that contributes to the total

rating of an idea is number of days that have passed since it was proposed by the user. The

weight for this parameter is 10%. For this parameter, the ideas that are more recent receive

more points than the older ones. This parameter is calculated as follows:

10 ∙ 10

−31

𝐴𝑔𝑒−1

10−3−1,


of 85

where 𝐴𝑔𝑒 is the number of days that have passed since the idea was proposed by the user.

For example, if an idea was proposed on 10/03/2016 and today is 15/03/2016 (that is, 5

days have passed), the idea earns 7.5 points (this parameter, when weighted, takes values

between 0 and 10).

Table 5 summarises the points that a proposed idea for a new experiment earns for each

parameter. There are different weights (70%, 20% and 10%) with which each parameter

contributes to the total rating of the idea. The table also shows the function that calculates

the points earned, separately, for each parameter. The total rating for the idea is the sum of

these three functions. Finally, the same Table shows two examples with the calculation of

the rating.

Table 5: The parameters used to calculate the rating of a proposed idea, the weights for each parameter and the functions that calculate the points earned for each parameter. The

total rating is the sum of the functions for each parameter.

Parameter Weigh

t Function

Example Idea A Example Idea B

Value Points

gathered Value

Points gathered

The average rating from users (Ratings)

70 % Ratings * 70% 85 59.5 85 59.5

The number of ratings received by users (Votes)

20 % 20 ∙10

3(1−1

𝑉𝑜𝑡𝑒𝑠)

− 1

103 − 1 150 19.1 10 10.0

Idea’s “freshness” in days (Age)

10 % 10 ∙

10−3

1𝐴𝑔𝑒 − 1

10−3 − 1

5 7.5 25 2.4

Idea's total Rating:

86.1 71.9


of 85

5 Relevant privacy and personal data protection issues

Personal data protection is a fundamental IoT Lab requirement and objective. The project is

committed to align and fully abide by the European personal data protection norms. It

voluntarily agreed to align with the newly adopted General Data Protection Regulation

(GDPR),

According to the GDPR, article 4, "‘personal data’ means any information relating to an

identified or identifiable natural person (‘data subject’); an identifiable natural person is one

who can be identified, directly or indirectly, in particular by reference to an identifier such as

a name, an identification number, location data, an online identifier or to one or more factors

specific to the physical, physiological, genetic, mental, economic, cultural or social identity

of that natural person;"

In its recital 26, the GDPR states that: "The principles of data protection should apply to any

information concerning an identified or identifiable natural person. Personal data which have

undergone pseudonymisation, which could be attributed to a natural person by the use of

additional information should be considered to be information on an identifiable natural

person. To determine whether a natural person is identifiable, account should be taken of all

the means reasonably likely to be used, such as singling out, either by the controller or by

another person to identify the natural person directly or indirectly. To ascertain whether

means are reasonably likely to be used to identify the natural person, account should be

taken of all objective factors, such as the costs of and the amount of time required for

identification, taking into consideration the available technology at the time of the processing

and technological developments."

The same recital highlights that: "The principles of data protection should therefore not apply

to anonymous information, namely information which does not relate to an identified or

identifiable natural person or to personal data rendered anonymous in such a manner that

the data subject is not or no longer identifiable. This Regulation does not therefore concern

the processing of such anonymous information, including for statistical or research

purposes."

IoT Lab’s main purpose is to support the research community by providing a tool enabling

researchers to perform experiments, collect data and publish their results, without any risk

that their results may be compromised by later modifications or manipulations. The capacity

of IoT Lab to anonymize the collected data is hence of upmost importance and by failing to

do so, the platform would enable the participants to access, modify and delete their data at

any time. This would translate in modifying research results a posteriori. It would be a major

problem for researchers, as their published results could be later changed by the

participants’ posterior interaction.

In order to address this complex situation, IoT Lab has adopted a dual strategy:

IoT Lab has researched and aimed at ensuring systematic, complete and effective

anonymity of participants and anonymization of data collected in line with Recital 26


of 85

of the GDPR. The IoT Lab platform voluntarily intends not to know who the natural

persons are taking part in its experiments.

In parallel, IoT Lab has developed mechanisms that enable, in case of technology or

jurisprudence evolution, to access and delete specific data sets provided by the

participants.

IoT Lab is committed to fully respect the European Personal Data Protection norms, and is

treating other specific data sets, such as information related to the researchers, as personal

data, by enabling the non-anonymized data subjects to access, modify, and delete their

personal data, as well as to benefit from the “right to be forgotten”. Moreover, the platform

has adopted a very clear and explicit prior informed consent mechanism, as well as the

possibility for the participants to control and modify at any time the data they share and

provide to experiments.

In this section, we address some important privacy issues which parallel our integrated

privacy strategy defined in D2.1 Privacy and Data Ownership Report. Here, we present our

approach on these issues from three different views:

A. The legal definition and scope provided by Istituto Italiano Privacy (IIP);

B. The mechanisms identified and implemented to address it;

C. A brief risk analysis for this issue

5.1 Anonymity

A. The legal definition and scope

In this section we examine in some detail the essential characteristics, fundamental

concepts and notions of anonymity, personal and anonymized data, and privacy protection.

In the legal terminology the following definitions apply:

Personal Data: Data that can be linked “through reasonable means” to an individual;

Anonymized Data: Data which cannot lead to the discovery of an individual’s identity

directly or indirectly even though it is related to them;

Privacy Protection: The prevention of the disclosure of one’s personal data (one way

of achieving this is data anonymization).

Data anonymization is one of the principal means of achieving privacy protection. Contrary

to superficial intuition, anonymization is not a milestone, i.e. an event that just occurs but is

an ongoing process throughout the information system life cycle which handles personal

data. As a continuous process, involving the deployment of technical measures,

organizational policies and incorporation of (possibly complex) data handling laws,

anonymization can leave the possibility of residual privacy risks. Thus, any implementation

of the data anonymization process should be protected against any possible remaining risks

to private data.

Two general techniques for anonymization is randomization and generalization, which are


of 85

briefly described below:

Randomization: Randomization refers to a family of techniques which modify the

accuracy of personal data in order to obfuscate any link which can lead to the

identification of the individual to whom the data pertains. In essence, the data

becomes sufficiently fuzzy in order to preclude identification. Randomization does not

destroy the uniqueness of each data item as it still forms a unified attribute set derived

from an individual. It is only the link which actually becomes fuzzy, not the data item

itself. Random permutations and differential privacy are two other common

randomization techniques. Randomization is frequently complemented by other

anonymization techniques, such as generalization, which we examine below.

Generalization: Generalization refers to the increase of the granularity (i.e.

coarseness) of the collected data. For instance, instead of providing the exact GPS

coordinates of the user’s location, the GPS coordinates are replaced by sufficiently

large location intervals which point to a wider area containing the true GPS

coordinates of the user. One should be wary, however, of advanced inferencing

attacks which can deduce the exact personal data out of the coarser data.

Generalization is based on techniques such as aggregation and K-anonymity, L-

diversity and T-closeness.

Some good practices which are recommended by the EU Data Protection Supervisors

include the following:

1. General guidelines:

a. Do not rely on the “release and forget” approach. Given the residual risk of

identification, data controllers should have in mind the following:

i. Identify new risks and re-evaluate the residual risk(s) on a regular basis.

ii. Assess whether the controls for identified risks suffice and adjust

accordingly.

iii. Monitor and control the privacy risks.

b. As part of such residual risks analysis, one should take into account the

identification potential of the non-anonymised portion of a dataset (if any – which

is the case with the IoT platform and the project’s work), especially when

combined with the anonymised part of the personal data together with possible

correlations among data attributes (e.g. correlations that exist between

geographical location and wealth level of the individual).

2. Contextual elements:

a. The goals to be achieved through an anonymised dataset should be clearly

defined and documented as they play a pivotal role in determining the person’s

identification risk.

b. This element should be considered in combination with all relevant contextual

elements – e.g. nature of the original data, adopted control mechanisms

(including security measures to restrict access to the personal datasets), sample

size (quantitative features), availability of public information resources (to be


of 85

relied upon by the data recipients), envisaged release of data to third parties

(limited, unlimited e.g. over the Internet or through personal data brokers etc.).

c. Consideration should be given to potential attackers by taking into account the

appeal of the data and their susceptibility to targeted attacks (sensitivity of the

information and nature of the data will be key factors in this respect).

3. Technical elements:

a. Data controllers should publicize the anonymization technique or the mix of

techniques that have been implemented, especially if they plan to release the

anonymised dataset.

b. Obvious (e.g. rare) attributes and quasi-identifiers should be removed from the

dataset.

c. If noise addition techniques are employed (e.g. as part of applying the

Randomization technique), the noise level added to the original data should be a

function of the domain attribute (for instance, the addition of noise should not lead

to an attribute having an illegal value), the impact for data subjects of the

attributes to which noise has been added, and/or the sparseness of the dataset.

d. When relying on differential privacy (in randomization), attention should be paid

to keeping track of queries in order to detect privacy-intrusive queries, since the

intrusiveness of queries is cumulative.

e. If generalization techniques are implemented, it is fundamental for the data

controllers not to limit themselves to one generalization criterion even for the

same attribute. This means, for instance, that different location granularities or

different time intervals should be employed. The selection of the criterion to be

applied must be driven by the distribution of the attribute values in the given

population. Not all distributions are amenable to generalization – i.e., no single

approach can cover all cases for generalization. Variability within equivalent

classes should be ensured. For instance, a specific threshold should be selected

depending on the “contextual elements” mentioned above (sample size, etc.) and

if that threshold is not reached, then the specific sample should be discarded (or

a different generalization criterion should be chosen).

The following legal checklist is an anonymity test related to a specific data-set:

Is it still possible to single out an identifiable individual?

Is it still possible to link records relating to an identifiable individual?

Can information be inferred concerning an identifiable individual?

If at least one answer to the above questions is YES, data is still “personal” and can lead to

the individual’s identity.

To determine whether a person is identifiable, consideration should be given to all the “likely

reasonably” identification means that can be used either by the controller or by any other

person who can identify an individual.

With respect to the "likely reasonably" identifiability criteria, EU DPS has stated the following:


of 85

First, it can be argued that data controllers should focus on the concrete means that would

be necessary to reverse the employed anonymization technique, notably with respect to the

cost and the know-how which are necessary to implement those means performing, also,

an assessment of their likelihood and severity. For instance, the data controllers should

balance their anonymization effort and costs (in terms of both time and required resources)

against the increasing, low-cost, availability of technical means that can be employed in

order to identify individuals in datasets, the increasing public availability of other datasets

(such as those made available in connection with “Open Data” policies), and the numerous

examples of incomplete or faulty anonymization applications entailing subsequent adverse,

sometimes irreversible, effects on the data subjects. It should be noted that the identification

risk may increase over time and, also, depends on the developments and advances in

Information and Communication Technologies (ICTs). Legal regulations, if any, must

therefore be formulated in a technologically neutral manner and ideally take into account the

changes and the development potential of ICTs.

Second, “the means likely reasonably to be used to determine whether a person is

identifiable” are those to be used “by the controller or by any other person”. Thus, it is critical

to understand that when a data controller does not delete the original (identifiable) data at

event-level, and the data controller hands over part of this dataset (for example after removal

or masking of identifiable data), the resulting dataset is still considered as personal data.

Only if the data controller would aggregate the data to a level where the individual events

are no longer identifiable, the resulting dataset can be qualified as anonymous. For instance,

if an organisation collects data about individuals’ mobility patterns, the individual patterns at

event level would still qualify as personal data for any person, as long as the data controller

(or any other party) still has access to the original raw mobility data, even if direct identifiers

have been removed from the set provided to third parties. However, if the data controller

deleted the raw data, providing only aggregate statistics to third parties on a high level, such

as “on Mondays on trajectory X there are 160% more passengers than on Tuesdays”, that

would qualify as anonymous data.

An effective anonymization solution prevents all parties from identifying an individual in a

dataset by linking two records within the dataset (or between two separate datasets) or by

inferring any information from within the dataset. Generally speaking, therefore, removing

directly identifying elements in themselves is not sufficient to ensure that identification of the

data subject is no longer possible. It will often be necessary to take additional measures to

prevent identification, once again depending on the context and purposes of the processing

for which the anonymised data are intended.

Moreover, even in presence of personal data, the “right to object” and the “right to be

forgotten” shall not apply always and unconditionally, but only in certain circumstances. For

instance, the “right to object” is fully exercisable only in cases where data processing was

legitimated by one of these conditions:

Direct marketing.

Processing is necessary for carrying out a task of public interest or exercising official


of 85

authority vested in the controller or in a third party to whom the data is disclosed.

Processing is necessary for the purposes of the legitimate interests pursued by the

controller or by the third party or parties to whom the data is disclosed, except where

such interests are overridden by the interests for fundamental rights and freedoms of

the data subject.

In the context of the IoT Lab project, in the event that the data subject’s consent is requested

and given, the data subject participating in an experiment or research, cannot exercise the

“right to object”, until data processing is necessary accordingly. If the “right to object” could

be exercised unconditionally and indiscreetly by the data subject, then a risk of jeopardising

the experiment’s results exists.

Moreover, the following is stated in the new General Data Protection Regulation (which is

still not an applicable law but could be referred to towards interpretation of situations in hand)

concerning the “rights to erasure and to be forgotten”: “the further retention of the personal

data should be lawful where it is necessary, for exercising the right of freedom of expression

and information, for compliance with a legal obligation, for the performance of a task carried

out in the public interest or in the exercise of official authority vested in the controller, on the

grounds of public interest in the area of public health, for archiving purposes in the public

interest, scientific or historical research purposes or statistical purposes, or for the

establishment, exercise or defence of legal claims.”

B. The status of the collecting data

IoT Lab platform intends to ensure effective and complete anonymity of participants. It is

established as a shared obligation NOT to request any personal identification from the

participants, such as email address, name, phone number or postal address, and to inform

the IoT Lab platform immediately of any breach of this obligation.

The database table responsible for collecting data from all users, including smart phone

participants, has the following schema:


of 85

Table 6: Schema for Collecting data from all users

The fields that comprise Table 6 cover all kinds of user roles and no user role uses all of

them. More specifically, for crowd participants the system is using only a small subset such

as:

id, roles_id, providers_id (connected to a special generic provider) for all crowd users

gender, age, hometown, country, employment_status, employment_sector,

education_level for users who voluntarily choose to disclose this information. These

users are able to change and delete this information at any given time. These fields

comprise the user's socio economic profile.

wifi_only, commercial_participation, offloading_always for all users to store configuration

preferences.

reputation_points, activity_points, budget for incentives purposes.

last_updated, status, deletion_request for maintenance purposes.

From the above model it is apparent that no personal data is collected from any crowd

participants, apart from socioeconomic data which are revocable and can be deleted at any

time and are not granular enough to identify individuals.

Mobile phones are stored in the system in the same way that all sensor nodes are stored.


of 85

The only difference is that there is a liaison between phones and their users while there is

no such connection in dedicated sensors. This connection is not exposed in the UI of the

platform and is only used internally and does not provide any additional information that

would help a third party identify individuals. The only information that could be used is the

location data and it is filtered by default in the measurements database to a much lower

resolution than needed to be of any use for location tracking of individuals. But even in that

case, the design of the data collection described above would not enable any individual

identification through reasonable means. IoT Lab application offers the ability to display all

the available resources on a map. In order to preserve the user’s anonymity and privacy, no

resources are flagged as the property of individuals. Since our platforms treats all kind of

resources equally, no sensitive information is showcased inside the application. On the

contrary, the details presented are what type of sensor is accompanied with the estimated

location inside the range of 110m.

Finally, the communication of the platform with the mobile devices only uses anonymous

random tokens that cannot be used to identify individuals.

C. The dilemma between complete end-user controlled process and the scope of the

platform to serve and support researches

The project intends to maximize personal data protection however, if users can

modify/delete the provided data, this will impact and change a posteriori the results of the

research resulting in a significant problem for the researchers that are using the platform.

This can be considered as a trade-off between a complete end-user controlled process and

the purpose of the platform to serve and support researches. IoT Lab is a research oriented

platform and therefore assigns the priority to the researcher. The adopted policy will be

based on clear prior informed consent mechanisms. Participants will explicitly accept to give

away experiment data, provided that they are fully anonymized. Below are some examples

on why this policy is followed.

Example 1. Researcher A has designed a novel algorithm and in order to validate its

performance conducts an experiment using smartphones sensor data from a dataset D

through the IoT Lab platform. Researcher A then draws the results in a comprehensive plot.

Researcher B after 6 months, designs a second algorithm that solves the same problem and

thinks that it can outperform the algorithm proposed by Researcher A. In order to prove this

algorithm experimentally works, Researcher B uses the same dataset D to conduct the

experiments. The results are then drawn using the same plot together with the results of

algorithm A, and can now be comprehensively compared. However, if the end-users had the

ability to modify/delete/change the original data over time, then this comparison would not

work and the two algorithms would not be able to provide a solid experimental comparison

using dataset D.

Example 2. Researcher A conducts a research using smartphones sensor data from a

dataset D through the IoT Lab platform. The outcome of the research is a thorough

examination and creation of structural conclusions about the dataset entries. The


of 85

conclusions are correlated with the specific dataset attributes like patterns, structural

properties, element relations, etc. If the end-users that provided the data had the ability to

modify/delete/change those over time, then the attributes of dataset D would change

resulting in an unstable and unreliable conclusions about dataset D.

D. Our proposing strategy

Based on the considerations stated in the previous subsections, our consortium has taken

full measures to implement applicable EU policies and good practices in order to ensure the

privacy of the data subjects who participate in the IoT Lab platform experiments.

Our consortium has decided to adopt a Privacy Protection Strategy based on the following

anchor points:

Full compliance with European personal data protection norms. We have followed the

guidelines given by the EU privacy protection legislation (e.g. EU Data Protection

Supervisors, Opinion 05/2014 on Anonymisation Techniques- ARTICLE 29 DATA

PROTECTION WORKING PARTY etc.) so as to be fully compliant with existing EU

legislation with regard to protecting the privacy of the IoT platform participants.

Leverage on effective participants’ data anonymity as specified in Recital 26 of the

GDPR.

Principle of proportionality. The IoT platform will never ask a participant any information

that is not directly linked to an experiment or research conducted through the platform.

This precludes the collection of any personal information leading to the identification of

the participant since it is not directly linked with the types of experiments allowed by the

platform.

Clear Prior informed consent mechanism. We have implemented a User Consent

Mechanism which is ubiquitous throughout the participant’s interactions with the

platform. During any step of the interactions where any kind of information is send by

the participant to the platform (e.g. sensor data), a specially designed interface informs

the participant and asks for his/her explicit consent to perform the sending operation.

Actively ensuring that collected data from the participants are effectively anonymized

and cannot be linked to an individual. This is, perhaps, the most important measure

taken since the collected data is treated as non-personal data from the start. However,

in order to give full flexibility and generality to the platform, we have developed

complementary mechanisms that will enable the participants to delete their data on

request (or automatically if they wished so).


of 85

E. Our implementation that enable participants to control their data

In order to anticipate any evolution of the technology or jurisprudence of the European Court

of Justice, as well as evolving Working Party 29 interpretation, the consortium has developed

a set of tools and enablers to access and delete specific data sets.

In the following section, we expand on the above anchor points and demonstrate how the

necessary privacy protection requirements are met.

5.2 The right to be forgotten for users

A. The legal definition and scope

Definition in literature

In the literature, the “right to be forgotten” “reflects the claim of an individual to have certain

data deleted so that third persons can no longer trace them”[3]. It has been defined as "the

right to silence on past events in life that are no longer occurring"[4]. The “right to be

forgotten” leads, in certain cases, the individuals to have information, videos or photographs

about themselves deleted from certain Internet records [3]; in other cases, such as in the

famous Google v. Spain [11] case, “the right to be forgotten” does not affect the sources of

data (i.e. Internet records, web pages) while it concerns the mere de-indexing of data from

search engines.

Legal Framework in EU

After the mentioned ruling of the Court of Justice on Google v. Spain [11], “the right to be

forgotten” is part and parcel of the right to data protection. Following the ruling, individuals

have the right - under certain conditions - to ask search engines to remove links with

personal information. This applies when the information is inaccurate, inadequate, irrelevant

or excessive for the purposes of data processing (para 93 of the ruling). The court found that

in that particular case the interference with a person’s right to data protection could not be

justified merely by the economic interest of the search engine. At the same time, the Court

explicitly clarified that the “right to be forgotten” is not absolute but will always need to be

balanced against other fundamental rights, such as the freedom of expression and of the

media (para 85 of the ruling). A case-by-case assessment is needed considering the type of

information in question, its sensitivity for the individual’s private life and the interest of the

public in having access to that information. The role the person requesting the deletion plays

in public life might also be relevant.

According to the recital no. 65 of the new General Data Protection Regulation (UE)

679/2016, "a data subject should have the right to have personal data concerning him or her

rectified and a ‘right to be forgotten’ where the retention of such data infringes this Regulation

or Union or Member State law to which the controller is subject. In particular, a data subject

should have the right to have his or her personal data erased and no longer processed

where the personal data are no longer necessary in relation to the purposes for which they

are collected or otherwise processed, where a data subject has withdrawn his or her consent


of 85

or objects to the processing of personal data concerning him or her, or where the processing

of his or her personal data does not otherwise comply with this Regulation. That right is

relevant in particular where the data subject has given his or her consent as a child and is

not fully aware of the risks involved by the processing, and later wants to remove such

personal data, especially on the internet. The data subject should be able to exercise that

right notwithstanding the fact that he or she is no longer a child. However, the further

retention of the personal data should be lawful where it is necessary, for exercising

the right of freedom of expression and information, for compliance with a legal

obligation, for the performance of a task carried out in the public interest or in the

exercise of official authority vested in the controller, on the grounds of public interest

in the area of public health, for archiving purposes in the public interest, scientific or

historical research purposes or statistical purposes, or for the establishment,

exercise or defence of legal claims."

The EU defines "data controllers" as "the natural or legal person, public authority, agency or

other body which, alone or jointly with others, determines the purposes and means of the

processing of personal data"[7][8]. The EU General Data Protection Regulation requires

data controllers who have been informed that an individual has requested the deletion of

any links to or copies of information, taking account of available technology and the cost of

implementation, shall take reasonable steps, including technical measures, to inform

controllers which are processing the personal data that the data subject has requested the

erasure by such controllers of any links to, or copy or replication of, those personal data."[5].

In the situation that a data controller does not take all reasonable steps then they will be

fined heavily [6].

Common Practice in Industry

To exercise the “right to be forgotten” and request removal from a search engine, one must

complete a form through the search engine’s website. Google’s removal request process

requires the applicant to identify their country of residence, personal information, a list of the

URL’s to be removed along with a short description of each one, and attachment of legal

identification [8]. The applicant receives an email from Google confirming the request but

the request must be assessed before it is approved for removal. If the request is approved,

the link is removed from search results but the content, however, remains online and is not

completely erased [10].

The “right to be forgotten”, as applied by the European Court of Justice, imposes the

possibility to stop accessing information related to a natural person through online searches,

but not the destruction of the information itself. In other words, according to this specific

interpretation, the “right to be forgotten” refers to individuals who have the right to repudiate

past information collected about them through search processes and search results, but not

to the source information itself.

After a request is filled, a panel reviews the request, weighing “the individual's right to privacy

against the public's right to know,” deciding if the Website is “inadequate, irrelevant or no


of 85

longer relevant, or excessive in relation to the purposes for which they were processed”.

Google has formed an Advisory Council comprised of various professors, lawyers, and

government officials from around Europe to carry out the decisions.

Notwithstanding the above, the interpretation of “right to be forgotten” as provided by the

new General Data Protection Regulation (UE) 679/2016 is deemed adequate for the IoT Lab

case.

Proposal for the IoT Lab

In the context of IoT Lab, the “right to be forgotten” for users shall be understood as much

as possible in line with the definition provided by Article 17 of the General Data Protection

Regulation (hereinafter “GDPR”).

The user shall therefore have the right to obtain from the controller the erasure of personal

data concerning him or her without undue delay and the controller shall have the obligation

to erase personal data without undue delay where one of the following grounds applies:

a) Data are no longer necessary in relation to the purposes for which they were collected

or otherwise processed;

b) User withdraws consent on which the processing is based and where there is no

other legal ground for the processing of the data;

c) User objects to the processing of personal data on grounds relating to his or her

particular situation and there are no overriding legitimate grounds for the processing,

or the user objects to the processing of personal data for direct marketing purposes;

d) Data have been unlawfully processed;

e) Data have to be erased for compliance under a legal obligation in Union or Member

State law to which the controller is subject;

f) Data have been collected in relation to the offering of information society services.

This obligation is related to information and data linked to an identified or identifiable person,

which implicitly excludes anonymized data from its scope.

When the controller has made the personal data public and is obliged to erase the data,

reasonable steps must be taken including taking into account available technology and the

cost of implementation including technical measures. This is done in order to inform

controllers who are processing the data, that the data subject has requested the erasure of

any links to, or copy or replication of that personal data.

The erasure will not occur if personal data are processed because of:

a) Exercising the right of freedom of expression and information;

b) Compliance with a legal obligation which requires processing by Union or Member

State law to which the controller is subject to or for the performance of a task carried

out in the public interest or in the exercise of official authority vested in the controller;

c) Reasons of public interest in the area of public health in accordance with points (h)

and (i) of Article 9(2) as well as Article 9(3) GDPR;

d) Archiving purposes in the public interest, scientific or historical research purposes


of 85

or statistical purposes in accordance with Article 89(1) GDPR in so far as the “right to

be forgotten“ is likely to render impossible or seriously impair the achievement of the

objectives of that processing; or

e) Establishment, exercise or defence of legal claims.

B. The IoT Lab approach

It is reasonable to conclude, after the discussion above, that the IoT Lab Consortium should

first of all differentiate between:

Anonymized data, which is not in the scope of the “right to be forgotten”, as they

cannot be linked to any identified user;

Personal data related to identify users, whose data subject are entitled to claim the

“right to be forgotten”.

The first category encompasses anonymized data from participants: their data cannot be

linked through reasonable means to any natural person. Ipso facto, they cannot be

addressed by “right to be forgotten“, as the data subject who provided the data has been

"forgotten by design" since the beginning, when his/her data have been collected.

The second category encompasses the data provided by the researchers. In this case, the

principle of proportionality highlighted by the European Court of Justice must be applied. It

is important that participants get a clear and transparent information about the person in

charge of the research since it is the right of the participants to understand the purpose of

the research in which they are eventually taking part. On the other hand, it is important to

enable the researcher to request the “right to be forgotten” and not provide information if he

or her chooses not to. The “right to be forgotten” should be translated into mechanisms

preventing the search of information by the public and third parties on identified users. It

should however, not imply the deletion of the information itself. For instance, the IoT Lab

Testbed as a Service should prevent the public and visitors to look for information related to

a researcher who wants to be forgotten.

However, in conformity with the European Court of Justice’s interpretation and the principle

of proportionality, the reports and other documents related to researches performed on the

IoT Lab platform should not delete the responsible researchers. This is to comply with the

right of the participants to know who is or was in charge of a research in which they took

part.

In order to simplify the management of the platform preventing any search based on the

user names, IoT Lab platform will not enable the search of any personal information.

Moreover, the platform will fully comply with the right of data subjects to access, modify and

erase their personal data in line with Article 12 of Directive 95/46/EC. As a way to establish

a best practice before the adoption of the new rules provided by the General Data Protection

Regulation on the “Right to be Forgotten”, the following proposal is made by the Consortium:

To apply the “right to be forgotten“, as interpreted by the European Court of Justice,


of 85

to personal data collected by the IoT Lab platform.

To differentiate personal data form anonymized data: anonymized data are not

considered personal data, and not subject to the “right to erasure” or the “right to be

forgotten”, since they are completely dissociated from any identifiable individual. This

is also relevant from the principles of “proportionality” and “prior informed consent”:

the participants are informed that shared data are anonymized and used for the

purpose of research activities. Researchers need to rely on stable, reliable and

consistent data sets. Changing data set a posteriori would impact and modify the

research results, and would weaken the reliability and relevance of the IoT Lab

platform itself.

To clearly inform the participants about this constraint through a clear prior informed

consent clause.

To establish a process that will enable non-anonymized end-users, such as IoT Lab

researchers, to benefit from the "right to be forgotten”.

To enable participants to request for his/her profile to be “forgotten”, namely deleted.

This could be a “forget me” button in the mobile app, a Web form or an e-mail address

to which a corresponding request would be sent. Such requests will be automated.

Once the request has been made/accepted the profile will not be used anymore.

However, previously collected data which are fully anonymized will not be deleted so

as not to impact the researcher data set.

If any data is identified as “disanonymized”, the following two options exist on how to

handle the request. The first option would be to erase all data associated with the

participant; i.e. socioeconomic profile and data/measurements/surveys. The second

option would be to erase the socioeconomic profile of the participant and link his/her

associated data to a generic “anonymous” user profile.

The analysis leads us to apply the following differentiated policy according to the data sets:

Category Identification

ability

Personal

data

Data

access

Right to be

Forgotten

Prior

Informed

Consent

Participant

profile

No, Anonymous No Yes NA Yes

Participant

experiment

data

No, Anonymous No No NA Yes

Researcher Yes, Public for

transparency

Yes Yes Yes Yes

Platform Yes, for internal Yes Yes Yes Yes


of 85

administrator use only

Testbed

owner

Yes, for internal

use only

Yes Yes Yes Yes

Sponsor Yes, for internal

use only

Yes Yes Yes Yes

Charity Yes, for internal

use only

Yes Yes Yes Yes

The adopted policy will be based on clear prior informed consent mechanisms. Participants

will explicitly accept to give away experiments data, provided that they are fully anonymized.

However, in order to anticipate a potential evolution of the normative framework or a

technological evolution, we have considered and implemented a mechanism that would

enable, on a case per case basis to access, modify and/or delete data sets linked to an

anonymized identifier. A participant could use this anonymized ID to access his/her data set.

C. The mechanisms identified and implemented to address it

Even if their data are fully anonymized, the participants can at any time easily access their

profile, modify and delete it.

The modification or deletion of the profile is immediate and is applied to any new data

collection. Modification or deletion of a profile is not impacting previously collected data as

long as these data are deemed fully anonymized.

As an additional protection and safeguard, a complementary mechanism enables the

administrator to manually give access, modify and delete data sets according to the

anonymized user ID.

We implement a mechanism that enables the crowdsourcing tool users to easily have their

anonymised socioeconomic profile removed upon their request from the platform and any

storage device connected to it including back-up devices. A clearly visible option in the

crowdsourcing tool was added where the user can send a request to the IoT Lab Platform

Administrator and ask for the deletion of his or her profile. When the user profile is deleted,

an appropriate message is sent back to the user’s mobile tool confirming that the deletion

has been completed. After that, the application returns to the state it was before the

registration of the user.

In practice, the “right to be forgotten” action will be implemented using a forgetUser () API

function. This function call will carry out the following actions:

Delete the user from the database, including all of their socio-economic profile data;

Delete all sensors that are tied to the user's device, as well as the device information;

Delete all data and non-anonymous survey responses that were produced as part of the interaction of the user with the IoT Lab platform;


of 85

Remove the user from any anonymous survey recipient list that researchers may have compiled;

Remove all ratings the user may have left for experiment proposals.

The result of this function call will be the same as if the user had never participated in the

platform in the first place and there will be no way to retrieve any of the data produced. The

deletion will not take place immediately upon request but a unique deletion ID will be

provided. This deletion ID can then be used by the user to check that the deletion operation

was carried out by a Platform Administrator.

In order to call the back end mechanism, we added a clearly visible option “Delete all data”

in the crowdsourcing tool. When the server responds that the data were deleted the user is

then informed and the app is returned to the state before the registration.

Figure 6 illustrates the “right to be forgotten” functionality from the mobile application’s point-

of-view. Following the design principles found in leading innovative applications, this option

is nested inside the application’s options area. The option is placed at the end of this screen

in order to avoid accidental touches by the user.

Figure 6: Delete account action

When the user selects this option provided by the system, a message dialog appears. As

shown in Figure 7, a notification window opens and informs the user if OK is selected, the

account will be deleted. At this stage, the user can either continue by selecting the “OK”

button, or cancel this action by touching the “CANCEL” button or anywhere else on the

screen.

If the user continues, a background task is responsible to call the appropriate forget-user

REST API. When the back end responds successfully, the application is responsible for


of 85

clearing all local data. This happens by deleting stored shared preferences [12] and by

clearing all the generated databases and the IoT Lab privacy notification is cleared. Finally,

the application is restarted to its initial state, i.e. “Welcome to IoT Lab App!” introduction

screens as depicted in Figure 8.

Figure 7: Confirmation Dialog

Figure 8: Initial state of the app

D. A brief risk analysis for this issue

The IoT Lab stakeholders (developers and operators) have paid particular attention to an

efficient and correct implementation of the “right-to-be-forgotten”. The IoT Lab platform has

carefully designed the user interfaces so that upon the initial user device registration, the

user is notified about this right and can exercise it at any time. Correspondingly, the IoT Lab

platform software has been designed so that the only risk for not satisfying a user request

is due to a flawed implementation of the procedures that perform the socioeconomic profile

deletion. This risk is mitigated since the IoT Lab team has put particular effort in designing,

implementing and testing this process.


of 85

5.3 Sliced informed user consent

A. The legal definition and scope provided by IIP

IoT Lab will follow Article 29 Working Party’s recommendations2 and “provide granular

choices when granting access to applications. The granularity should not only concern the

category of collected data, but also the time and frequency at which the data are captured.

Granularity will also mean that the user will be informed of the processing of personal data

before it actually starts, with relevant information provided at the time when a certain data

processing is foreseen (granularity of notices).

B. The mechanisms identified and implemented to address it

We should implement a sliced (granular) User Consent Mechanism which ensures that the

crowdsourcing tool informs users on a timely basis about the policies of the IoT Lab

regarding privacy, anonymity and security when a given data processing is going to take

place. Except for the main text that is provided to the users regarding the IoT Lab “Overall

Policy”, a user should be informed in a "sliced" way for each action he or she is going to

perform and the possible risks that the action can entail. Such notification can occur, for

instance, whenever the user selects to send data from their sensor device, or every time the

dispatch of GPS location data to the platform is allowed. For instance, when a user of the

crowdsourcing tool attempts to provide his or her location, a notification will appear to the

user that the GPS location is a piece of information that could lead to their identification.

Therefore, whenever a user clicks on a field on a form during any stage of his or her

participation in the crowdsourcing experiment, the user will be notified in case the provided

input can potentially lead to their identification. To this end, the information fields will be

classified into two groups depending on whether the respective information can, potentially

lead to privacy breach. Then it is up to the user to decide whether to proceed or not. We

should stress the fact that the crowdsourcing tool under no circumstances asks the user for

sensitive information such as sex orientation, religion, health information, financial

information etc. Therefore, a potential privacy breach (which is always possible no matter

what measures are taken especially when users are careless and can even provide their

real name to the tool) will result in no real harm for the user.

As mentioned in other documents, IoT Lab is designed with respect to users’ privacy in which

a multi-layered interactive system is developed to inform users about the background tasks

that take place.

From the first released version of the smartphone application, a notification mechanism was

implemented that informs the user when an experiment is active. Also, the tool notifies the

users for other actions and settings such as whenever it is going to send data from a sensor

of the user’s device, or every time the user allows the dispatch of GPS location data to the

2 See Opinion 8/2014 on the on Recent Developments on the Internet of Things.


of 85

platform.

Additionally, in the case of location services (GPS), an extra notification is displayed that

informs the users that the app is currently accessing the devices locations, as shown in

Figure 9.

Figure 9: Active location services on Android

Besides the real-time notification presented earlier in this section, our tool offers the option

of a persisting icon in the notification area of the Android mobile smartphones. As seen in

Figure 10 and Figure 11 an icon is displayed on the top of the screen with the appropriate

text that informs users about the ongoing background service. When the user touches it, the

application redirects him or her to the privacy settings area, where sharing configurations

can be changed.

Figure 10: Service notification

Figure 11: Service Notification expanded

Except the notifications that informs a user when an experiment is active, a notification is

also activated when an upcoming experiment is going to start. When a research requests

measurements from a crowd sensor for the first time, it sends along with the data request,

a message describing the nature of the experiment. The user has the choice to withhold

sensor data in case he or she disagrees with the nature of the experiment. This goes beyond

slice informed consent since the user has active knowledge on how his or her data will be

used.


The major risk of “all in one piece” user consent documents which state the user’s rights is

that users rarely pay attention to it and just click “OK” to proceed hastily. Moreover, even if

they read the entire document, they may later forget salient or subtle issues especially when

coming across some data or personal information request which requires from the user


of 85

knowledge of the consent contents. Therefore, when asking for the user’s explicit consent

before letting the user continue on, IoT Lab platform developers have broken the user

consent form into smaller pieces and it appears only in places where it applies. The only

risk, here, is that the user overlooks the consent form or hastily clicks “OK”. This risk can be

mitigated by asking the user twice by reminding him/her what will happen upon clicking “OK”

the second time.

5.4 Decreasing raw data granularity if an experiment can tolerate it

A. The legal definition and scope provided by IIP (Istituto Italiano Privacy)

In accordance with the principle of data minimization, the IoT Lab will decrease the level of

raw data granularity when it does not impinge negatively on the project’s objectives. Raw

data are not personal data per se; however, when combined with other pieces of information

they may enable the data controller to infer some detailed user information. Therefore,

limiting raw data granularity when not needed is a way to prevent potential unnecessary

combination of the latter with other information relating to an individual.

B. The mechanisms identified and implemented to address it

Crowdsourcing experiments rarely require accurate data in order to compute aggregate

information, the average being one of the most often computed data. For instance, whenever

an experiment requires users to provide both their location data as well as environmental

temperature for some statistical function (e.g. average, standard deviation, other moments

of interest, etc.) it is possible that altering the location information can still lead to the

computation of useful information.

Thus, we implement a mechanism that provides coarse grained location measurements, in

order to avert possible identification risks associated with certain data types or combinations

thereof (e.g. location coordinates combined with age and profession, for instance – here

noise can be added to location and age data) which when taken together may uniquely

determine a user.

From the application’s point of view, this can be achieved by removing some decimals in the

coordinates that accompany the measurements broadcast. More specifically, by keeping

only three decimals in the location measurements, the precision of the record is limited to

“neighbourhood/street” (Wikipedia, n.d.).

C. A brief risk analysis of this issue

Beyond what is considered as user identifying information (e.g. name and surname or eID

number) other types of data exists which may lead to the identification of a user by revealing

Personally Identifying Information (PII). Our platform tries to warn the user about such

information or sets of information items when it can be tolerated by the running experiment.

Controlled data contamination is imposed in order to “blur” sensor data sufficiently to avoid

user identification but not enough to contaminate the experimental results themselves.


of 85

5.5 Performing a risk assessment of the IoT infrastructure

A. The legal definition and scope provided by IIP (Istituto Italiano Privacy)

The Consortium has performed a risk assessment over the platform based on the CORAS

Framework [13]. CORAS provides a customized language for threat and risk modelling, and

contains detailed guidelines explaining how the language should be used to capture and

model relevant information during the various stages of the security analysis.

The Assessment also highlights some potential threats to personal data, and providers with

countermeasures. In this regard, please note that the duty to perform a full Data Protection

Impact Assessment or Privacy Impact Assessment (hereinafter DPIA or PIA) is on the

experimenters/data controllers, according to applicable frameworks. The methodology to be

followed for such PIAs can be based on the Privacy and Data Protection Impact Assessment

Framework which the WP29 has adopted on 12 January 2011 for RFID Applications.

According to this methodology:

“As a prerequisite to conducting a PIA for a specific Application, each

organisation must understand how to implement such a process based on the

nature and sensitivity of the data it deals with, the nature and type of processing

or stewardship of information it engages in, and the type (…) of Application in

question. (…) To conduct the initial assessment, an (…) organization has to go

through the decision tree depicted below. This will help the organization to

determine whether and to what extent a PIA is needed (…). The resulting level

in the initial analysis phase helps determine the level of detail necessary in the

risk assessment (e.g., either a Full Scale or Small Scale PIA). This initial

analysis must be documented and made available to data protection authorities

upon request”

The decision tree stated above must be read so that it is adaptable to the IoT platform and

in conjunction with Article 33 of the GDPR, which stipulates that “Where a type of processing

in particular using new technologies, and taking into account the nature, scope, context and

purposes of the processing, is likely to result in a high risk for the rights and freedoms of

individuals, the Controller shall, prior to the processing, carry out an assessment of the

impact of the envisaged processing operations on the protection of personal data. A single

assessment may address a set of similar processing operations that present similar high

risks”.


of 85

Figure 12: An example for a decision tree.

B. The mechanisms identified and implemented

Performing a complete, formal risk assessment of the platform appears to be out of the

project’s focus, which is to provide a platform which is easy to use for participants and

experimenters alike. IoT Lab does process personal data and does so in a way that

minimizes its collection in addition, anonymization techniques are in place. The project

mostly relies on aggregated data and the burden in performing a full DPIA resides with the

data Controller entities, therefore, it can be reasonably concluded that IoT Lab does not

pose high risks for the users. Neither does the IoT Lab platform fall under one of the cases

foreseen by Article 33 (2) of the GDPR, for which a DPIA is required. Moreover, the IoT Lab

Consortium has taken all possible privacy protection measures (and even more) which will

be documented in the official project deliverables, a high-level risk analysis of the platform

would suffice in the light of applicable framework and forthcoming law. In this respect, the

IoT Lab will diligently perform a risk assessment on its platform, which will help in

understanding what the risks are specific to personal data in addition to other risks that may

be identified.


Please refer to section 5.


of 85

6 The risk analysis of IoT Lab platform

6.1 The Risk Analysis Framework

This section presents the context and extent of the risk analysis process. The corresponding

security aspects are described focusing on the specific functionalities and intended use of

the platform.

Figure 13: The CORAS risk analysis and management process.

Establish the context

(Prepare/Describe the TOE) the strategic contexts

the organisational contexts

the risk management context

develop criteria

decide the structure

Treat Risks ADVICE (Requirements)

identify treatment options

evaluate treatment options

select treatment options

prepare treatment plans

implement plans

Mon

itor a

nd

revi

ew

Commun

icate

and

Cons

ult

Identify Risk What can happen? How can it happen?

Analyse Risks

Evaluate Risks compare against criteria, set risk priorities

Accept Risks Yes

No

Determine

likelihood

Determine

consequences

Estimate level of risk

Assess Risks


of 85

6.1.1 The CORAS Risk Analysis Framework

The CORAS project aims to develop a practical framework (seen as a collection of methods,

processes and tools) for performing model-based risk analysis on the security aspects of

information systems, exploiting methods developed within the safety domain, semiformal

description methods (modelling languages) and supporting tools. Please consult [13] for

more on CORAS as well as for downloading the tool (CORAS tool) that assists the risk

analyst in identifying and analysing threats to security critical systems.

The overall CORAS risk management process is outlined in Figure 13. Please consult [14]

for more details on this process.

According to Figure 13, the risk management process is divided into five broad sequential

sub-processes as outlined by the Figure 14 below:

Figure 14: Outline of CORAS risk management process

Each of these five sub-processes comprises a number of activities:

Sub-process 1: Identify Context:

o Activity 1.1: Identify areas of concern

o Activity 1.2: Identify and valuate assets

o Activity 1.3: Identify security requirements

Sub-process 2: Identify Risks:

o Activity 2.1: Identify hazards/threats to assets

o Activity 2.2: Identify vulnerabilities of assets

Sub-process 3: Analyse Risks

o Activity 3.1: Consequence/impact evaluation

o Activity 3.2: Evaluate likelihood of occurrence

Sub-process 4: Risk Evaluation

o Activity 4.1: Determine level of risk

o Activity 4.2: Prioritise risks

o Activity 4.3: Categorize the risks

Sub-process 5: Risk Treatment

Sub-process 4: Risk Evaluation

Sub-process 3: Analyse Risks

Sub-process 2: Identify risks

Sub-process 1: Identify context


of 85

o Activity 4.4: Determine interrelationships among issues

o Activity 4.5: Prioritise the resulting themes and risks

Sub-process 5: Risk Treatment

o Activity 5.1: Identify treatment options

o Activity 5.2: Assess alternative approaches

6.1.2 Scope of the risk analysis

The risk analysis addresses the security aspects the IoT Lab platform has to meet.

Specifically, the risk analysis will target the following:

Identification of the security risks associated with the usage of the platform for conducting crowd-sourcing experiments over a given communications infrastructure (most often the Internet).

Advice on whether the usage of the platform is in accordance with applicable legislation, standards, guidelines and recommendations for data security and user privacy.

Recommendations for the additional security and privacy related improvements that can be provided in the future, after the end of the project.

The focus of this risk analysis will be the security aspects for the platform and in particular

confidentiality, integrity, availability and accountability.

6.1.3 Limits of the Analysis

A. What is to be analysed:

Data: Transmission of data (registration and sensor data) between the users and the platform;

Procedures: The transactions that are foreseen between the users and the platform;

The external threats to the platform from malicious usage;

The risks associated with the usage of the platform by the participating users;

The risks associated with the entailed operation model (e.g., internal or administration threats, usage of sensor data by unauthorized persons, etc.);

The risks associated with the telecommunications components.

B. What will not be analysed

The risks associated with the interface of the platform with other internal applications or systems;

The internal handling and processing of the stored data by other applications except the IoT Lab platform modules;

The risks associated to personal data stored in the platform because of the specific processing performed by the data controllers (i.e., the experimenters);


of 85

The physical threats to the platform.

6.1.4 Identified Security Mechanisms

The two primary security mechanisms used in the IoT platform are:

User registration via a pseudonym only (no email input is allowed) and other generic information submitted via HTML forms.

SSL for transferring data between users’ devices and the IoT Lab platform.

Implementation of the “right-to-be-forgotten”.

6.1.5 Identified Assets

The assets of the platform will be used as input to the RA task in order to assess the

consequences or potential damage of possible actions or omissions of the involved actors.

The following tables list some identified physical (Table 7) and immaterial (Table 8) assets.

Table 7: Identified physical assets

Physical asset Used for Owner

Server (HW) Running the IoT Lab platform application Platform Owner (i.e. the project consortium)

Web browser Connecting to the IoT Lab platform server User device owner

User device Running the web browser User

Telecom network

Transporting web traffic Telecom companies (PNOs)

Internet connection

Transporting web traffic Internet Service Providers (ISPs)

Platform Owner computer systems

Storing data and providing the interface to the application

Platform Owner

Databases Storing data about users, data from sensors and transaction logs.

Platform Owner

Table 8: Identified immaterial assets

Immaterial asset

Used for Stakeholder

Business reputation

Staying in business Platform Owner

User’s Trust in transactions

Contacting good business Platform Owner User

Information in the Database

Storing data about users, sensor data and transactions

Platform Owner User

Information transferred over the internet

Transferring data about users as well as sensor data

Platform Owner User PNOs, ISPs


of 85

6.1.6 Identified Success Factors for the IoT Lab platform

Identified success factors for the IoT Lab platform are:

Spreading of the crowd-sourcing culture and education of people to this new form of voluntary participation;

Fast connections to the Internet for both the user and the platform owner;

Trust to the crowd-sourcing idea and the platform owner (IoT Lab): The users should be confident that the transactions will be confidential and their personal data (even their pseudonym as well as their sensor data) will not be misused;

Accurate and no misleading sensor data which lead to successful experiments with useful results.

User’s trust in the Internet infrastructure in general;

Good response time of the platform.

6.1.7 Applicable Standards and Legislation

The platform owner has to ensure adherence to a broad range of national and international

legislation regarding the trade and business operations. Additional specific applicable

legislation that the platform has to adhere to include Data Protection Law (Directives 95/46

and 2002/58 EC) as listed in [15].

6.2 Security Requirements

This section presents a broad overview of the security requirements of the IoT Lab platform.

In the context of assessing the CORAS framework, these requirements focus on specific

functionalities of the IoT Lab platform. The security requirements addressed are

confidentiality, integrity, availability and accountability and the following elements were

identified and used:

Data:

o User specific data:

Personal data

Device related data

Username (Pseudonym)

Sensor data

User Interface settings and preferences (control of browsing behaviour)

Crowd sourcing application settings and preferences

o Platform’s access/transaction logs

Actors:

o Users

o Platform Owner

o Experimenters


of 85

o Internet Service Providers (ISPs) and Public Network Operators (PNOs)

Hardware/Software:

o User’s device, browser and IoT lab application

o Platform’s computer equipment (servers, networks, databases, etc.)

o Internet infrastructure

Communication of data between actors:

o The user and sensor data are transferred over the Internet between a user and the platform using ISP and PNO infrastructure

o The procedure for a user’s registration to an experiment

o The procedure for a user to enter registration information

o The procedure for involving a user in the experiment

6.2.1 Confidentiality

The main issues addressed within the scope of the IoT Lab project are the consequences

of unauthorised disclosure of user information, either personal or sensor data from his/her

mobile device. In particular, the following general questions were addressed:

What information is not to be disclosed

Which actors should not be able to access confidential information

What are the consequences of disclosing unauthorised information

1. Which actors should have the authority to access information?

1.1. The following user specific data should be accessible by the corresponding user and

the owner of the platform.

1.1.1. Registration information

1.1.2. Sensor data

1.2. The users’ access logs should be accessible by the owners of the platform.

1.3. Individual transactions (client requests and server responses) are accessible by the

owners of the Internet infrastructure for performance monitoring purposes only.

2. Which information should not be disclosed to inappropriate actors?

2.1. The above information should be accessible only by the corresponding actors

explicitly stated.

2.2. PNOs and ISPs involved in the Web infrastructure should not have access to users’

registration and sensor data.

3. What is the consequence of unauthorised disclosure of a user’s personal data?

3.1. This constitutes a violation of relevant Data Protection Law.

3.2. Defacement of the IoT Lab platform due to users’ mistrust.


of 85

4. What is the consequence of unauthorised disclosure of a User’s sensor data?

4.1. Could be very severe since some sensor data may lead to user identification and

hence result in a violation of Data Protection Law.

5. What is the consequence of unauthorised disclosure of a user’s voluntary information

which is requested during the registration process?

5.1. If the user inadvertently entered Personally Identifiable Information (PII), he/she may

be identified.

6. What is the consequence of unauthorised disclosure of a user’s personal preferences

like browser configuration information, mobile device data, etc.?

6.1. Potential violation of Data Protection Law.

6.2.2 Integrity

The issues addressed here are the consequence of unauthorised modification of

information. In particular, the following general questions are asked:

Which information should not be modified by unauthorised actors?

Which actors are not allowed to modify information?

What are the consequences of unauthorised modification of information?

What are the consequences of modification of information in unauthorised ways?

1. Which information should be modifiable by appropriate actors?

1.1. User specific data should be modifiable by:

1.1.1. The corresponding user only

1.2. User provided sensor data should be updated by the platform owners according to

further inputs provided by the users.

2. Which actors are not allowed to modify information?

2.1. Users should not be able to modify any sensor, either maliciously or inadvertently,

data so that the experiment data is not contaminated.

2.2. The platform owners should not modify the user access logs but may process them

further (e.g. for security and accountability reasons).

2.3. The platform owners should not modify users’ personal data (without proper and

timely notification to the user).

2.4. The platform owners should not modify users’ sensor data.

3. What is the consequence of unauthorised modification of user data?

3.1. Unauthorised modification of a username will have the effect that the corresponding

user will not be able to receive participation credit by participating in the user

reputation mechanism.


of 85

3.2. Unauthorised modification of a username would constitute a major breach of the

principle of data accuracy and a violation of Data Protection Law.

3.3. Unauthorised modification of a username will have the effect that the corresponding

user will not be able to make use of the “right to be forgotten” since his/her sensor

data, which are stored in the platform, will no longer be associated with the

appropriate username.

4. What is the consequence of unauthorised modification of sensor data?

4.1. The IoT Lab platform trustworthiness and reputation will be diminished with

immediate consequence that potential users will be reluctant to participate in future

experiments.

5. What is the consequence of unauthorised modification of user access logs?

5.1. The usage of modified access logs may have adverse business results for the IoT

Lab platform since publicly demonstrated modification will diminish trust towards the

platform while it is possible that violation attacks have been hidden.

5.2. The usage of modified access logs may also make the platform manager less

accountable towards competent authorities or users performing audits on the

platform.

6.2.3 Availability

The issues addressed here are the consequence of denying or obstructing access to

information to authorised actors (mainly experimenters and users). In particular, the

following general questions are answered:

Which information should be available to which authorised actors?

Which information should not be available and to which actors?

What are the consequences of denying information to authorised actors?

What are the consequences of delaying or obstructing access to information by authorised actors?

1. What information should be available and to which authorised actors?

1.1. Aggregate experimental results should be available to interested users for

transparency and public knowledge reasons.

1.2. User specific information should be available to:

1.2.1. The corresponding user.

1.2.2. The platform owner only in cases of misuse and/or for security/technical

reasons.

1.3. Access logs should be available to the platform owners.

2. What information should not be available and to which authorised actors?


of 85

2.1. Users should have access only to their own personal and sensor data.

2.2. PNOs and ISPs involved in the web infrastructure should not have access to Users’

personal and sensor data.

3. What is the consequence of denying user specific information to the corresponding user?

3.1. The denial of user specific information (sensor data, transaction log data etc.) will

result in loss of credibility in the platform.

4. What is the consequence of denying sensor or experiment specific information to a user?

4.1. This may cause loss of user credibility in the platform.

5. What is the consequence of denying information to the platform owner?

5.1. The platform owner will be unable to perform proper management of the platform

possibly necessitating the re-initialisation (and therefore loss) of the existing data.

6. What is the consequence of delaying access to information?

6.1. Delaying access to user will result in reduced platform credibility. Time-outs may

even disrupt the service.

6.2. Delaying access to the platform owner will result in increased administration effort.

6.2.4 Accountability

Accountability refers to the prevention of misuse of the platform. The issues addressed here

are the consequence of denying that an action or omission occurred, or not being able to

assign responsibility for it. The following general questions are answered:

Which actions or omissions should not be deniable and by which actors (non-

repudiation)?

For which actions or omissions should responsibilities be assigned (auditing –

mostly for users trying to maliciously interfere with the normal operation of the

platform)?

What are the consequences of denying an action or omission (mostly for system

administrators)?

What are the consequences of not being able to assign responsibility for processing

or modifications of data (mostly for platform owners, which are considered the root

of trust since they rely on the success of the platform)?

1. What actions or omissions should not be deniable and by which actors?

1.1. Access to the user information (even pseudonymous) by the system administrators.

1.2. Modifications to the platform log data by the system administrators.

1.3. Execution of a “right to be forgotten” order by a user.

2. For which actions or omissions should responsibilities be assigned?


of 85

2.1. Responsibilities should be assigned for processing of data, especially when qualified

as personal data.

2.1.1. User specific data (by the corresponding user or the platform owner).

2.1.2. System specific information (by platform owner).

2.1.3. Access logs (by system administrators).

2.2. Responsibilities should be assigned for the administration of the platform.

2.3. Persons in charge of processing personal data within the processing organisations

should also be singled out, instructed and specifically appointed as such.

3. What are the consequences of denying an action or omission (mostly for system administrators)? The main consequence is data security and privacy violation, with respect to user data.

With respect to system data, loss or malicious modification leads to untraceability of

malicious actions.

4. What are the consequences of not being able to assign responsibility for processing or

modifications of data?

4.1. By losing the ability to assign responsibility for data modifications the ability to

maintain data integrity is also lost.

4.2. Breach of the principle of accountability by the data processor and data controllers.


of 85

6.3 Risk analysis tables

HAZOP tables

HAZOP tables from the Risk Identification activity are presented in the following tables.

There is also another table for the assets identified in Section 6.1.5.

Date: 19.02.2016 HAZOP Work Scheme for IoT Lab

Asset: User information when sent over the network and when stored in the platform’s computers

No. Guidewords Threat Consequences Countermeasures Remarks

1 Disclosure User information can be disclosed by physical access to the network (malicious).

Breach of privacy for the user. User does not trust the IoT Lab platform anymore and does not want to participate.

No identifying information is collected at the user’s device. Also, HTTPS connection is established for the user-platform communication.

When the General Data Protection Regulation enters into force, data controllers will have the obligation to notify data breaches to a) competent supervisory authorities and b) data subjects. In this scenario, the data processor (the platform manager) will have the duty to notify data controllers (the experimenters) of any data breach occurred on its systems.

2 Disclosure User information can be disclosed by access to the platform (malicious).

No identifying information is collected at the user’s device. Also, HTTPS connection is established for the user-platform communication

When the General Data Protection Regulation enters into force, data controllers will have the obligation to notify data breaches to a) competent supervisory authorities and b) data subjects. In this scenario, the data processor (the platform manager) will have the duty to notify data controllers (the experimenters) of any data breach occurred on its systems

3 Distortion Low connection bandwidth and/or connection quality when user sends over data.

Bad connection to the platform.

Need to cancel/postpone the connection.

Increase bandwidth and/or connection quality.


of 85


Asset: Sensor information (including, possibly image and audio data) transferred over the network


4 Disclosure The sensor data can be disclosed by physical access to the network (malicious).

HTTPS connection is established for the user platform communication.

5 Disclosure The sensor data can be disclosed by access to the platform (malicious).

Appropriate security measures are taken for the platform based on suitable access control mechanisms, firewalls, and anti-malware software.

6 Manipulation The sensor data is modified (malicious).

The experimental results are maliciously manipulated.

Use of HTTPS connection.

Recommendation to users to install anti-malware software.

7 Distortion The sensor data is distorted due to lack of connection quality.

The experimental results are not usable or misleading.

QoS assurance contract from the PNOs and ISPs.

8 Inference The sensor data indirectly reveal user PII.

User is identified. Controlled contamination of user sensor data.

Avoid acquisition and storage of sensor data that are known to reveal, under certain circumstances, PII.

9 Delay Real-time sensor data is received with considerable delay.

Small consequences, if it occurs on a small scale. Otherwise, crowd sourcing experiment takes more time than expected.

Improve the quality of the connection in a technical way.

10 Destruction The sensor data is corrupted (i.e. received but not decodable/readable).

Small consequences, if it occurs on a small scale, otherwise the experiment will produce misleading conclusions.



of 85


Asset: Platform specific information: Configuration information


11 Disclosure Attack on the main server if the IP address is known to the attacker.

Denial of service attack.

Loss of user information.

Loss of confidentiality of experimental data personal data.

Infection by malware.

Encryption to protect information.

Firewall and policy.

Creation of a DMZ (Demilitarized Zone) between the IoT platform server and the Internet.

12 Manipulation Hacked initial page of the platform.

Unable to connect to the platform server.

Might be connected to another malicious server which intercepts users’ data.

Strict security measures for the IoT Lab platform servers.

13 Destruction

Deletion

The platform server configuration files can be deleted or damaged by mistake.

Unable to connect to the platform server.

Good day-to-day system management practices.


Asset: Session (between user and platform) establishment


14 Unavailability The application at the platform side is not running.

No user participation or delayed participation.

Good day-to-day system management practices.

15 Unavailability The application cannot be started at any of the sides (user and/or platform server).


Re-install software or reboot server/user device.

E.g., when the configuration files are not available or are corrupted.

16 Unavailability Power supply goes down.


Use of UPS.

17 Unavailability Network connection fails.



Use of alternative network connections.

18 Manipulation Configuration file/information is

Good day-to-day system


of 85

changed. management practices.

Strict security measures for the IoT Lab platform servers.


Asset: Physical facilities and equipment (IoT server, IoT server room, rest of the equipment at server’s side)


19 Unavailability Steal/remove any of the equipment.


Physical protection of the room.

When the General Data Protection Regulation enters into force, data controllers will have the obligation to notify data breaches to a) competent supervisory authorities and b) data subjects. In this scenario, the data processor (the platform manager) will have the duty to notify data controllers (the experimenters) of any data breach occurred on its systems.

20

21

22 Unavailability Unavailability of technical support people.

Usually delay (downtime), occasionally cancelled platform operation.

Backup personnel.

Local technical support.


of 85


Asset: Communications infrastructure


24 Disconnection Failure at the communication infrastructure providers (e.g. GSM network).


Very rare, notified in advance in most cases. QoS contract should be in effect.

25

26 Disconnection Instability in access points of the local networks.


Should be further analysed.

27 Disconnection Lack of power supply at platform’s end.

Use of UPS.

28 Disconnection Wireless connection not working.


29 Capacity Not enough bandwidth.

Low quality data (delay) makes it difficult to communicate.



30 Capacity Bandwidth preoccupied by other network traffic.

Must reschedule the user session for later, delay it or even cancel it.




Asset: IOT LAB Software (both sides, user and platform)


31 End-users have incompatible software versions.

User participation is not possible.

Advice users.

32 Software is not working when installed on the user’s device.

User participation is not possible.

Advice users.

33 Disclosure The sensor data is disclosed to

The unauthorised Strengthen the security of


of 85

6.4 Risk evaluation

In this section we are concerned with identifying a level of risk associated with the threats

identified and assessed in the previous sections. General risk levels are identified by

CORAS in D4.1 IoT Lab Cloudification and Interconnection Report. In the risk level matrix,

the identified risk levels (Low risk, Moderate risk, High risk, and Extreme risk) is shown by

different shadings, as indicated in Table 9: Template for risk level matrix.Table 9 below.

The following recommendations, with respect to threats, related to the different risk levels in

the matrix are proposed:

Extreme risk: Before the service is used again, significant improvement of the technical system should be done.

High risk: Senior management should consider carefully if the service can be continued/used.

Moderate risk: Management responsibility must be specified for monitoring these risks.

Low risk: Risks can be managed by routine procedures when/if they occur.

Table 9: Template for risk level matrix.

Consequence

Likelihood

Rare Unlikely Possible Likely Almost certain

Insignificant Low Low Low Moderate High

Minor Low Low Moderate High High

Moderate Moderate Moderate High High Extreme

Major High High Extreme Extreme Extreme

Catastrophic Extreme Extreme Extreme Extreme Extreme

unauthorized persons.

persons can use it.

Potential loss of trust towards the platform.

communication links and the platform with monitoring and protection tools.

34 Programming errors

The software does not work properly, with respect to using correctly the sensor data, due to programming errors.

Misleading experiment conclusions.

Careful implementation and extensive testing.

No experience up to now.

35 Programming errors

The software does not execute correctly the “right to be forgotten” operation.

Serious consequences due to not satisfying the important “right to be forgotten” demand.

Careful implementation and extensive testing.

Being implemented.


of 85

6.5 Risk levels

Table 10 10 shows the level of risk for most of the threats identified in Section 0, based on

the developers’ and platform developers’ views.

Table 10: Risk level table based on the development team’s estimates.

Consequence

Likelihood

Rare Unlikely Possible Likely Almost certain

Insignificant

Minor 4,5

Moderate 1,2,3,33

16,18 7,9,10,14,15,17,24,26,31,32

Major 6,19,22,27,28,29,30,34,35

8,11,12,13

Catastrophic


of 85

6.6 Recommendations

6.6.1 Conclusions and recommendations based on the development expert’s assessment

The risk level matrix, which was based on the development team’s experiences (Table 10),

enables us to extract a list of threats and risks to be closely monitored:

6: The sensor data is modified (malicious).

7: The sensor data is distorted due to lack of connection quality.

8: The sensor data indirectly reveal user PII.

9: Real-time sensor data is received with considerable delay.

10: The sensor data is corrupted (i.e. received but not decodable/readable).

11: Attack on the main server if the IP address is known to the attacker.

12: Hacked initial page of the platform.

13: The platform server configuration files can be deleted or damaged by mistake.

14: The application at the platform side is not running.

15: The application cannot be started at any of the sides (user and/or platform server).

17: Network connection fails.

19: Steal/remove any of the equipment.

22: Unavailability of technical support people.

24: Failure at the communication infrastructure providers (e.g. GSM network).

26: Instability in access points of the local networks.

27: Lack of power supply at platform’s end.

28: Wireless connection not working.

29: Not enough bandwidth.

30: Bandwidth preoccupied by other network traffic.

31: End-users have incompatible software versions.

32: Software is not working when installed on the user’s device.

34: The software does not work properly, with respect to using correctly the sensor data, due to programming errors.

35: The software does not execute correctly the “right to be forgotten” operation.

A systematic check enabled us to ensure that each identified risk is properly addressed and

mitigated. For instance, for the Risk 8 above (“The sensor data indirectly reveals user PII”)

the risk in terms of personal data protection is greatly diminished by limiting the granularity

of data, the distortions and filters applied to geolocalization data, the restrictions for

accessing detailed data, the adoption of anonymization techniques over users’ data and by

the establishment of encrypted channel of communication between servers and IoT Lab

servers. These are measures that have already been taken by the IoT Lab.

While the network architecture has been taken into account when performing the risk


of 85

assessment, a detailed analysis of the network infrastructure utilized by the IoT Lab platform

is not part of this preliminary risk assessment.

Another set of threats that were not addressed are the threats related to other users utilizing

the network and their own devices, which are beyond the scope of this risk analysis as well

as the IoT Lab project.


of 85

7 Conclusion

In this deliverable, we have reported on the work we performed within the context of Task

T2.3 “Identity management and reputation mechanisms” during the first two years of the IoT

Lab project.

This work focused on two main areas. In the first area, we designed and implemented a

Role-Based User Authentication and Authorisation Scheme for the identity management of

the users. In this scheme, we assigned to all types of users in the platform, individual

identifiers that are used for their authentication, authorization and management of privileges

across the platform. The access rights and available functionalities for each user are

different depending their role (e.g. Administrator, Researcher, Participant, Sponsor, Charity,

etc.).

In the second area, we established some effective Reputation Management Mechanisms

based on suitable ranking functions. In this document, we described the rationale behind

these mechanisms and how we implemented them. We also described how these

mechanisms can be used to provide aggregate information to the community of the IoT Lab

project related to the participation and the activities of the platform users (Experimenters,

Crowd Participants, Charities, Sponsors, etc.). We also explained how the Reputation

Management Mechanisms can motivate the participants to be more active, by proposing

new ideas for research projects, by participating in more experiments, by giving feedback

on their experiences with the platform and by providing their ratings.

We also revisited specific important privacy issues, such as the “right to be forgotten” for the

users, the sliced inform consent and the sensor data granularity. Each one of these privacy

issues was discussed from three different viewpoints: the legal definition and scope provided

by IIP (Istituto Italiano Privacy), the mechanisms identified and implemented to address the

issue and a brief risk analysis for it.

Finally, the findings of a detailed risk analysis of the platform were presented, which was

performed using the CORAS risk analysis framework.


of 85

References

[1] “Android Official Website for Security” http://source.android.com/devices/tech/security/index.html

[2] Gamification is defined as the use of game elements in non-gaming systems so as to improve the user experience and user engagement, loyalty and fun (Deterding, Khaled, Nacke, and Dixon, 2011).

[3] Weber, Rolf H. "The right to be forgotten." More than a Pandora's Box 2 (2011).

[4] Pino, G. (2000). “The right to personal identity in Italian private law: Constitutional interpretation and judge-made rights”. In: M. Van Hoecke; F. Ost. The harmonization of private law in Europe (pp. 225-237). Oxford: Hart Publishing. p. 237.

[5] Mantelero, Alessandro (2013). "The EU Proposal for a General Data Protection Regulation and the roots of the 'right to be forgotten'". Computer Law & Security Review 29 (3): 229–235.

[6] European Commission. Proposal for a Regulation of the European Parliament and of the Council on the Protection of Individuals with Regard to the Processing of Personal Data and On the Free Movement of Such Data (General Data Protection Regulation). 2012/0011 (COD). Article 17. Right to be forgotten and To Erasure.

[7] Regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), no. 679/2016, Article 17 "Right to be forgotten and to erasure". http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ENG&toc=OJ:L:2016:119:FULL

[8] "Who can collect and process personal data? - Justice". Ec.europa.eu. 2014-06-26. Retrieved 2014-08-09.

[9] https://support.google.com/legal/contact/lr_eudpa

[10] http://searchengineland.com/google-right-to-be-forgotten-form-192837

[11] Court of Justice, C-131/12, Google Spain SL and Google Inc. v Agencia Española de Protección de Datos (AEPD) and Mario Costeja González, available at curia.europa.eu.

[12] http://developer.android.com/reference/android/content/SharedPreferences.html

[13] http://coras.sourceforge.net/index.html

[14] http://www.uio.no/studier/emner/matnat/ifi/INF5150/h06/undervisningsmateriale/060930.CORAS-handbook-v1.0.pdf

[15] http://ec.europa.eu/justice/data-protection/

researching crowdsourcing to extend iot testbed ......researching crowdsourcing to extend iot...

Documents