Revision as of 14:13, 7 March 2018

BB26.G
Home Meetings Publications Student corner Factpage

Overview

• WPs of interest
  • WP7 can be a core WP for Privacy Labels BB
  • WP21 is also good for applying Privacy Labels
  • WP11 mentions Privacy Labels.

It is also interesting for applying Privacy Labels because it works with complex systems that manipulate data of various kinds. Fine-grained access control is also applicable, like our 5th step in S-ABAC "Query-based AC", which can also be good to achieve better privacy.

• • We will not be involved in WP12 nor WP14

Activities

• Related activities include those started in BB26.F Measurable on Multi-Metrics and Measurable aspects of Privacy
• Privacy evaluation of the TellU Diabetics app demonstrator from WP21 is planned and under way, with deadline in Spring 2019.

Division of Work and Research Directions

Planned Outcomes

The work in the Privacy Labelling aims to provide the following tangible results.

Privacy Labelling for Decision Makers

The purpose is to have a lightweight version useful for persons that make decisions where privacy aspects are involved. Examples of use:

1. Example of the CEO or Project manager, like from Statsbygg, that need to decide on whether to include many sensors in a Smart office building for monitoring the indoor air quality. What are the privacy implications of this? How should she take a decisions, based on what information?
   • This Result should give here the needed tools to help with the decision.
2. Before doing any expensive and time-consuming PL certification actions, a CEO or investor needs to have initial indications of Privacy Aspects regarding the new App or IoT device or technology that is planned.
   • This Result should enable economical and feasibility calculations of the privacy implications on the business development.
   • This work will be done in collaboration with Smart Innovation Norway.

These examples clarify the Requirement RQ561.

Privacy Labelling for Technical privacy engineers

This is similar to any other certification methods, like for the SIL levels, for the ANSSI security classifications, etc. The goal is two-fold: (i) to have a methodology, i.e., a decision-tree to guide various technological decisions; as well as (ii) to have guidelines for what technologies can achieve what privacy guarantees. This includes a good overview, semantically meaningful, over the various privacy relevant concepts, like anonymization, personal identifiable data, machine learning information extraction, aggregation techniques, deletion, etc. This also includes methods and tools for measuring the various privacy relevant techniques and how much they achieve their purposes.

NOTE that all the above aspects are not related to security, i.e., the confidentiality is assumed provided by other means. For otherwise, if confidentiality of data in transit or stored in broken, then no privacy guarantees can be met any more, thus making any Privacy Labelling irrelevant.

Security evaluation should be done independently of the privacy evaluation.

Privacy Labelling for the Users

This is not present in classical standardisation methods, because those, like the goal above, are meant only for technical people, and have a very simple outcome like a number or a yes/no answer.

The main purpose of Privacy Labelling is to present the outcome of the privacy certification to Users. However, privacy is highly difficult to present, compared to classical aspects like the Energy Consumption labels where the range is the number of consumed KW/hour. Moreover, privacy is also highly personal, i.e., what for some person is highly private for another may not be, and thus does not impact her decisions. The goal is to study how to best present the various concepts involved in technically deciding a privacy label. This means that a User can understand first the privacy implications for some device/service/system that she wants to acquire, as well as how to compare with other similar products based on the privacy aspects. Examples of use:

1. An older lady wishes to buy some Smart Home Energy Management system, but she is concerned that all these new gadgets are too intrusive into her rather classical style of living. Even more so since several of her family members, or friends at the Bridge Club tell her about <<how the TV listens to what people talk in the house>>, or how <<medical persons watch over people taking a bath>>. She wants some simple indication given by some authority that she can trust (and she mostly trusts when government associations are involved) about how much this new system would expose her, so she can decide what to buy, restricted by here limited budget.
2. A young adult who likes to have various new electronic devices, is interested in installing a new app on his phone for tracking his weekend hiking trips. He wants to know about how his location data is being used by the app provider so that he can make an informed decision regarding choosing the various different functionalities that the app promises against the privacy exposure that he would have to accept.

The first example clarifies the Requirement RQ558.

Privacy Labelling for certifying experts and certification bodies

These include minimal requirements, alignment with existing regulations like GDPR, adoption and relation to existing standards of relevance. Examples of use:

1. An expert needs to carry out a certification job for a specific new IoT device. She needs both methodological as well as tool support.
2. A regulatory body, like a GDPR national authority, needs to make a compliance evaluation.

Sub-components

The work in the Privacy Labelling is divided into several sub-components, each trying to achieve one of the above goals.

PL4Decisions

This sub-component works towards the following measurable outcomes.

1. A simplified decision process from PL-CERT, with different domain-specific versions
2. Tools easy to use by decision making people, like questionnaires

This sub-component works to attain the Requirement RQ561.

PL-Methods

This sub-component works towards the following measurable outcomes. This sub-component works to attain the Requirement RQ560.

1. A decision process, with associated tools like UIs and databases of resources
2. Surveys of existing techniques that can be applied to answer the questions at any of the decision nodes. Include:
   1. Anonymization techniques
   2. De-anonymization methods, like machine learning algorithms
   3. Results about how anonymization of data influences desired learning results, e.g., before anonymization some learning and profiling can be done, whereas after anonymization such profiling cannot be done any more and thus the <<personalized pricing scheme>> cannot be applied any more. (see survey chapter A General Survey of Privacy-Preserving Data Mining Models and Algorithms and the book that it comes from [1] along with the standard book Data Mining: Concepts and Techniques 2011)
   4. Differential privacy (see survey [2] and book The Algorithmic Foundations of Differential Privacy and more resources from a simple search)
   5. Survey of Privacy-by-Design concepts and current works. Examples include applications
      1. in Programming,
      2. in System architecture,
      3. in Databases,
      4. in Machine Learning
   6. Privacy for Location data (see old book Privacy, security and trust within the context of pervasive computing or newer survey A survey of computational location privacy or Quantifying Location Privacy or Geo-indistinguishability: differential privacy for location-based systems or A classification of location privacy attacks and approaches)
   7. Privacy Patterns (starting from A Literature Study on Privacy Patterns Research) and question on finding which such patterns involve measurable aspects
   8. Privacy in Biometrics (see book Biometrics: theory, methods, and applications)
   9. Clustering techniques for Privacy (see [3] along with 2017 Privacy and utility preserving data clustering for data anonymization and distribution on Hadoop or An overview of the use of clustering for data privacy or The Effect of Clustering on Data Privacy)
3. Techniques for measuring various relevant privacy aspects, including tools to automatically do the measuring
   1. Include the multi-metrics framework
4. Tools for aggregation of the privacy measurements
5. Examples of use

PL-UX

This sub-component works towards the following measurable outcomes.

1. Privacy Labelling color range and visual cues, including icons
2. Privacy Label user friendly explanations, i.e., details
3. Usability studies to evaluate the User response

This sub-component works to attain the Requirement RQ559.

PL-CERT

This sub-component works towards the following measurable outcomes.

1. A certification process with all decision points identified and methods for making and evaluation and decision at the respective point.
2. Clearly described relationships with existing standards
3. Method of aligning Privacy Labelling to existing regulations including GDPR and Norwegian National regulations from Datatilsynet

This sub-component works to attain the Requirement RQ560.

RoadMap

Deliverables and Documents

Practical Aspects

Implementations and User Testing

• See the RoadMap

Demonstrations and Use Cases

• In WP7 in an initial preliminary phase at M14
• In WP21 in a more concrete phase at M24

Air Quality monitoring Use Case of WP7

The work in WP7 involves complex systems and algorithms for processing data coming from multiple sensors and other information sources (like weather report) in order to achieve a high precision monitoring of indoor air quality (IAQ), both in real-time and in quality of the measurements. Thus WP7 provides good use cases for all components of the Privacy Labelling work. Refer to the respective Deliverable D7.1 for detailed scenarios presentations. Consider the following aspects of the IAQ and related privacy questions/concerns.

An office environment, or an industrial facility (like for storage of goods or for processing of food) is equipped with various sensors like temperature, humidity, pressure, various gasses, particles, sound, luminosity, 3D camera, motion, window and doors latch/open sensors (see the slide 18 f the VTT presentation in the 14 Feb 2018 meeting).

• One Privacy question is how many of these sensors are needed for each specific air quality functionality that is desired? The more sensors the more accurate information can be inferred about the occupancy and processes/behaviours that are happening at some point in time in the respective indoor location.

This sensors information is gathered in cloud-based systems (see the presentation of Centria from 14 Feb 2018 meeting and their FOAM platform) that use powerful tools for big data processing like Apache KAFKA and SPARK, Cassandra (see presentation of ITI from 14 Feb 2018 meeting).

• One Privacy question is, how is this data being processed in these far-away cloud systems? Can transparency be achieved?
• Another Privacy question is, what kind of information can these powerful systems extract from the sensors data? How much profiling can be done? These questions are related to research on privacy in static databases like differential privacy.

However, the data from the sensors first goes through a gateway/router inside the facility before reaching the cloud platform (see presentation from Centria slide 5 or from F-Secure from 14 Feb 2018 meeting). Therefore, various forms of processing can be done on the gateway, some relevant for privacy.

• Can the gateway do some anonymization pre-processing of the sensors data? This work should be done in accordance with the cloud system so that the amount of annonymization does not interfere with the cloud functionality (e.g. the same profiling should be possible, like for various price agreements)

The work in WP7 uses both poor-quality sensors (see presentation of IMEC from 14 Feb 2018 meeting) as well as high-grade sensors (see presentation of QPLOX or RDVELHO from 14 Feb 2018 meeting).

• One Privacy question is how much information needs to be collected from one sensor to achieve the expected functionality? For example, with a high-grade sensor too often measurements can provide enough information to extract various privacy sensitive information, like what activity s carried in the office, i.e., typing at computer, walking, sitting, reading (see recent research on this aspect from ESORICS 2017).
• With poor-quality one usually claims that more sensors are needed, however, how many and where to be placed is important so that not to infer more information than needed.

The above example and questions are relevant for the PL-CERT and PL-Methods components. These components would be applied both at the sensor level and immediate gateway (processing unit), as well as on the overall system, i.e., including the cloud systems.

• Work on clustering (see presentation of Nokia from 14 Feb 2018 meeting) is relevant for anonymization. Can this be performed by the gateway, or only by the cloud?

The scenarios described in Deliverable D7.1 include several aspects regarding the presentation of the data to users, including presenting privacy aspects to the concerned users. Here is where the work of the PL-UX component would be applicable.

The work of SmartIO works with users that are at decision levels, i.e., the responsible for building a new smart office facility, or retrofitting one with smart-* capabilities. For this kind of users the PL4Decisions would be applicable. Our work would focus on the air qualify functionality and privacy questions.

SCOTT status

From Ramiro: An overview of the instructions for updating the building blocks and the collection of the requirements can be found in this presentation (slide 19-24). https://projects.avl.com/16/0094/WP26/Documents/02_Meetings%20and%20WebEx/20170703_SCOTT_Presentation_WP26.pptx?Web=1

The official and complete instructions can be found in the following presentation from SP1 requirements management. https://projects.avl.com/16/0094/WP01/Documents/03_Deliverables/SCOTT%20REQM%20Approach_Guidance_June2017.pptx?Web=1