Vicenç Torra
email: vtorra@his.se

Guillermo Navarro-Arribas
email: guillermo.navarro@uab.cat

Big Data Privacy and Anonymization

Introduction

Data privacy studies models and methods to ensure that there is no disclosure of sensitive information. The field arose within the statistics community to ensure that sensitive data from census were not disclosed. Later, the problem appeared within the computer science community to ensure privacy in communications, and databases. Three main research communities exist today: statistical disclosure control, privacy enhancing technologies, and privacy preserving data mining. They study similar problems, although the focus is slightly different due to the types of data they consider and the type of uses of these data.

The field has now more than 40 years, starting with e.g. the seminal papers of Dalenius [START_REF] Dalneius | The invasion of privacy problem and statistics productionan overview[END_REF][START_REF] Dalenius | Towards a methodology for statistical disclosure control[END_REF], Chaum [START_REF] Chaum | Untraceable electronic mail, return addresses, and digital pseudonyms[END_REF], and Denning and Schlöder [START_REF] Denning | A fast procedure for finding a tracker in a statistical database[END_REF]. During these years, different types of privacy models have been defined, methods to protect sensitive information according to these privacy models have been proposed, and measures for evaluating disclosure risk, and information loss have also been defined. There is a large number of approaches for different types of data. This does not mean that all problems are solved, but there exists already a solid and useful set of techniques for ensuring different levels of privacy for some types of applications. See e.g. the reference books [START_REF] Duncan | Statistical confidentiality[END_REF][START_REF] Hundepool | Statistical Disclosure Control[END_REF][START_REF] Vaidya | Privacy Preserving Data Mining[END_REF] for details.

The increasing amount of information available, and the coming of big data and data science poses new problems to the field. In this paper we will review some of these problems, and outline accordingly some lines for further research.

The new EU General Data Protection Regulation includes the implementation of the right to rectification and the right to be forgotten. That is, companies need to modify or delete records from a database when users and citizens want to take advantage of these rights. In order to implement these rights, data provenance plays a central role. Data provenance is not a topic specific for big data, but it is with big data, distributed, and dynamic databases, where it can be used in its full potentiality. We discuss in this paper some research topics related to privacy and provenance.

The structure of the paper is as follows. In Section 2 we review some of the existing approaches for privacy on standard databases. In Section 3 we focus on the problem for big data. We review its definition and discuss some of the research questions that we consider more relevant with respect to privacy for big data. In Section 4 we focus on the problems related to data provenance. We discuss data provenance and how data provenance interacts with data privacy. The paper finishes with a summary.

Data privacy for databases

A large number of mechanisms have been developed for ensuring data privacy. They can be classified according to different dimensions. We classify them [START_REF] Torra | Data Privacy[END_REF] according to our knowledge on the type of analysis a third party wants to apply to this data.

-Data-driven or general purpose. In this case, we have no knowledge on the type of analysis to be performed by a third party. This is the usual case in which data is published through a server for future use. It also includes the case that data is transferred to a data miner or a data scientist for its analysis as we usually do not know which algorithm will be applied to the data. For this purpose, anonymization methods, also known as masking methods have been developed. -Computation-driven or specific purpose. In this case, we know the exact analysis the third party (or third parties) wants to apply to the data. For example, we know that the data scientist wants to find the parameters of a regression model. This can be seen as the computation of a function or as solving a query for a database without disclosing the database. When a single database is considered and we formulate the problem as answering a query, differential privacy is a suitable privacy model. In the case that multiple databases are considered, the privacy model is based on secure multiparty computation and cryptographic protocols are used for this purpose. -Result-driven. In this case, the analysis (a given data mining algorithm) is also known. The difference with computation-driven approaches is that here we are not worried on the protection of the database per se, but on the protection of some of the outcomes of the algorithm. For example, we know that data scientists will apply association rule mining, and we want to avoid that they infer that people buying diapers also buy beers. Similarly as in computation-driven analysis, prevention of disclosure for this type of analysis is specific to the given computation producing the specific results. In this case, however, the focus is on the knowledge inferred from the data instead of the actual data.

In this paper we focus on anonymization or masking methods. That is, datadriven methods. In short, anonymization algorithms (masking methods) transform a data file X into a file X with data of less quality. This quality reduction ensures a certain privacy level according to some pre-established privacy model. This is an approach that can be applied to any type of database. It has been successfully applied to, for example, databases, documents, search logs, and social networks.

In addition, the approach is valid not only for protecting data from a syntactic point of view, but also from a semantic point of view. That is, taking into account the meaning of the terms and concepts in the data. For example, when we have words and categories in documents and search logs. For this purpose, we can use masking methods that use ontologies (as e.g. wordnet and ODP) to protect the data.

As masking methods modify the original data reducing its quality, three main research questions appear in the process. The first one is how to reduce the quality of the data. This is done by the masking methods themselves. There is a plethora of methods for this. Then, as data is modified we need to be sure that there is no information loss in the process or that this information loss is as low as possible. In other words, data utility is not reduced substantially in the masking process. Information loss measures are defined to quantify this information loss. Finally, although the quality of the data is reduced to avoid the disclosure of sensitive information, there is no guarantee that all methods satisfy this property. Disclosure risk measures have been defined to quantify the disclosure risk of anonymized data, and they are tightly related to privacy models.

As a summary, we list below the three main research issues related to masking methods.

-Masking methods. Methods that given a database X transform it into another one X with less quality. Masking methods are usually classified into three categories: perturbative, non-perturbative and synthetic data generators. Perturbative methods reduce the quality by means of modifying the data introducing some kind of error into the data. Noise addition and multiplication, microaggregation and rank swapping are examples of perturbative methods. Non-perturbative methods reduce the quality of the data making them less detailed (but not erroneous). Generalization and suppression are examples of them. Synthetic data generators replace the original data by data generated from a model, which has been extracted from the original database. So, the data in X is not the original data but artificial data generated from the model. -Information loss measures. They measure in what extent the transformation of X into X reduces the utility of the data, and the information that is lost in the process. Information loss measures are typically defined in terms of an analysis f to be performed to the data. Then, given this analysis f and the original and anonymized files X and X , we define information loss as

IL f (X, X ) = divergence(f (X), f (X )).
where divergence is a function that evaluates how far are f (X) and f (X ).

A distance on the space of f (X) can be used for this purpose. Naturally, we expect divergence(Y, Y ) = 0 for all Y . Typical examples of functions f include some statistics (means, variances, covariances, regression coefficients), as well as machine learning algorithms (clustering and classification algorithms). Specific measures for some types of databases have also been considered in the literature (e.g., measures on graphs). -Privacy models and disclosure risk measures. They focus on what extent anonymized (masked) data still contains sensitive information that can be used to compromise the privacy of the individuals of the database.

Data privacy for big data

In this section we propose a few open research questions related to big data. To do so, we outline first a definition of big data, and the major difficulties we find with respect to disclosure risk in big data.

Big data

There exists several definitions for big data based on the characteristics of the data. The well-known definition based on the 3Vs underlines volume, velocity, and variety as the main characteristics of big data. There are other definitions that expand this definition with additional terms. They are the definitions based on 4Vs, 5Vs, or even 7Vs.

-Volume. Databases include huge amounts of data. For example, facebook generated 4 new petabytes of data per day in October 2014 (see [21]). -Velocity. Data is flowing to the databases in real time: real time streams of data flowing from diverse resources. Either from sensors or from internet (from e-commerce or social media). -Variety. Data is no longer of a single type (or a few simple types). Databases include data from a vast range of systems and sensors in different formats and datatypes. This may include unstructured text, logs, and videos.

Moving privacy to big data: disclosure risk

For big data, in principle, the same research questions mentioned in the previous section appear. We need to develop masking methods, information loss measures and disclosure risk measures. For them, we need to take into account that the amounts of data are larger, and thus we need to deal with the corresponding computational problems. Nevertheless, besides of that, a new issue appears: there is a new level for privacy risk. This new level of risk is caused by the following three problems.

-Lack of control and transparency. It is more and more difficult to know who has our data. There are different organizations that can have information about ourselves without us knowing it. Information is gathered from sensors and cameras, obtained through screening posts in social networks, and from analysis of web searches. Note also the case of tracking cookies. Finally, there are data brokers that gather as much information as possible about citizens. -Linkability. It is usual for big data to link databases to improve the amount and quality of the information. Linking databases increase the risk of identification as there is more information for each individual. Note that the more information we have on individuals the easier to reidentify them, and the more difficult to protect them. -Inference and data reusability. There exist effective inference algorithms that infer sensitive information (e.g., sexual orientation, political and religious affiliation [START_REF] Kosinski | Private traits and attributes are predictable from digital records of human behavior[END_REF]). One of the main goals of big data analytics is to use existing data for new purposes. This increases the inference ability. As a side effect, data is never deleted waiting for future use.

In the next section we propose a few research lines for data privacy for big data. They are proposed in relation to these three problems just mentioned.

Open research questions for big data

We propose in this section a few research questions related to big data. The first one is about the need to inform users about the risks of inference due to big data. Then, we propose some lines related to anonymization of stand-alone and linked databases. It follows another question related to the need of developing (and using) user privacy. We also discuss the need of developing efficient algorithms for data protection in data privacy. This need is both for user privacy, and respondent and holder privacy. The last one is about data provenance, an issue that is further developed in Section 4.

These lines of research are based on our own work (see e.g. [START_REF] D'acquisto | Privacy by design in big data: An overview of privacy enhancing technologies in the era of big data analytics[END_REF][START_REF] Torra | Integral privacy[END_REF][START_REF] Torra | Data privacy[END_REF]), and on the research lines discussed in [START_REF] Soria-Comas | Big Data Privacy: Challenges to Privacy Principles and Models[END_REF].

-Issue #1. Technology should help people to know what others know and can infer about them.

As we have stated above, effective machine learning and data mining algorithms can infer sensitive information. Some of these models use data that does not seem a priori sensitive. It is insufficient that we protect sensitive information without protecting what permits us to infer sensitive information. Technology should help people to know about this, and e.g. provide tools in social networks to make people aware of this fact. -Issue #2. Databases should be anonymized/masked in origin. Machine learning algorithms for masked data are required. On the one hand, there exist masking methods that are effective in the sense that they achieve low information loss (with loss disclosure risk). On the other hand, there are machine learning and data mining algorithms that are resitant to errors. In the same direction, not all data is equally important for machine learning algorithms, and some data mining algorithms for big data do not use all data but only a sample of them. Because of that, it is meaningful to consider privacy by design machine learning algorithms. That is, machine learning methods that are appropriate for data that has already been protected. Preprocessing methods for machine learning (dimensionality reduction, sampling, etc.) should be combined with and integrated to masking methods.

Masking methods can be seen as methods to introduce noise and reduce quality, but they can also be seen as methods for dimensionality reduction. See e.g. the case of microaggregation and, in general, methods to achieve k-anonymity. They reduce the number of (different) records in a database by means of generalization or clustering (i.e., building centroids). These generalized records or centroids can be seen as more consolidated (error-free) data. -Issue #3. Anonymization needs to provide controlled linkability.

We have reported that linkability is one of the basic components of big data.

Companies want to combine databases to increase the information about individuals (enlarging the set of variables/attributes available on them). If databases are anonymized in origin, we need ways to ensure that these databases can still be somehow linked in order to fulfill big data requirements. k-anonymity allows linkability at group level. Algorithms for controlled linkability are needed, as well as methods that can exploit e.g. linkability at group level. -Issue #4. Privacy models need to be composable.

Given several data sets with a given privacy guarantee, their combination needs to satisfy also the privacy requirements. There are results on the composability of differential privacy. See e.g. [START_REF] Soria-Comas | Big Data Privacy: Challenges to Privacy Principles and Models[END_REF]. -Issue #5. User privacy should be in place: decentralized anonymity.

User privacy [START_REF] Torra | Data privacy[END_REF] is when users have an active role in ensuring their own privacy. For this purpose, there are methods to protect the identity of the users as well as to protect their data. For example, there are methods for user privacy in communications and in information retrieval. While the research questions mentioned above are to be implemented and used by data holders, user privacy provides users with tools to be used by themselves. User privacy permits that data are anonymized before their transmission to data collectors (or to the service provider). So, there is no need to trust the data collector. Local anonymization and collaborative anonymization are keywords for tools for user privacy. -Issue #6. Methods for big data.

Big data have particularities (the three or more Vs discussed above) that have to be taken into account when developing methods for ensuring privacy. These particularities are for both respondent and holder privacy (i.e., methods applied by data holders) and for user privacy. We can distinguish three types of situations.

• Issue #6.1. Large volumes of data. Efficient algorithms are required for data of high dimension. Algorithms are required for producing masked databases, but also for computing information loss measures and disclosure risk. There exist already some masking methods that have been developed with efficiency in mind for standard databases (e.g., some algorithms for microaggregation), for graphs and social networks (e.g., based on random noise on edges, on generalization and microaggregation), and for location privacy. New methods are needed. • Issue #6.2. Dynamic data. When data changes with respect to time, we may need to publish several copies of the database. In this case, specific data masking algorithms are required. Note that independent application of algorithms for k-anonymity to the same database can cause disclosure. So, the same applies when the database has changed between two applications of the algorithm. • Issue #6.3. Streaming data. Data is received continuously and should be processed as soon as possible because we cannot hold them and process them later. In this case, difficulties arise because at any time information is only partial. Methods based on sliding windows have been developed for this purpose. -Issue #7. Data provenance and data privacy.

The new EU General Data Protection Regulation grants citizens the right to rectify and delete the information about themselves in companies. Data provenance are the data structures that permit companies to know where the information of customers and users is in their databases. Different open research questions appear in the crossroad between provenance and privacy. One of them is the fact that data provenance can contain sensitive information and, thus, privacy technologies needs to be applied to it. At the same time, the fact that data can be modified using data provenance according to customers' requirements poses new privacy problems. We discuss these issues in more detail in the next section. These research topics can also be considered for databases of small and medium size but it is with big data that the research becomes challenging.

Data privacy and data provenance

Data provenance is becoming a key issue in data management, and can have a great impact in data privacy. Despite its relevance it has not been given much attention until recently from the data privacy community. Information provided as provenance can be used to improve privacy data mechanisms, but it is important to note that provenance itself has to be protected from inferences [START_REF] Reuben | Privacy Impact Assessment Template for Provenance[END_REF].

In the era of big data and online social networks, data provenance is also useful to help users to assess the validity and trust of the information. For instance, it can help to identify rumormongers and disinformation centers. As we show in Section 4.2 data provenance can play an important role in the future of big data privacy research.

Broadly speaking, data provenance can be seen as metadata or as an annotation of the data. That is, data is expanded with information of the processes that has led to this data. Provenance can be coarse-grained or fine-grained. That is, we can have information on how a bunch of data (i.e., files or databases have been produced) or we can have information particularized at the record or even at the value level. Fine-grained provenance is what makes provenance useful, as it is only in this case that we have detailed information on how any data element has been produced. E.g., we can know who entered the temperature (fever) of a patient, or in which store our client claimed for a discount.

There are different ways to represent data provenance. There are two types of provenance. They are where provenance and why provenance. Where provenance describes the origin of the data, and why provenance the process that generated the data. A data element in a database typically proceeds from the combination of previous data elements by means of certain processing functions. Therefore, we need a structure to represent the transformations. The most common approaches are chains [START_REF] Hasan | Introducing secure provenance: problems and challenges[END_REF][START_REF] Hasan | The case of the fake Picasso: preventing history forgery with secure provenance[END_REF][START_REF] Mcdaniel | Towards a secure and efficient system for end-to-end provenance[END_REF] and graphs [START_REF] Braun | Securing provenance[END_REF][START_REF] Zhang | Do you know where your data's been? -Tamper-evident database provenance[END_REF].

Securing data provenance

Secure provenance was introduced to ensure security and privacy to provenance data. Observe that provenance data is sensitive. It may contain information on who and when data was updated. E.g., knowing that a certain doctor has modified data from a patient can lead to disclosure on who is the doctor of whom, what type of illness the patient has, and at what time the patient was at the hospital. Files and databases typically flow within departments and between companies. It is specially important to ensure that these third parties cannot access confidential information contained in the data provenance, whilst allowing them to work with the factual data and update the provenance structure itself. For example, this would allow to perform analysis on the medical data, preserving patient privacy. Hence, provenance data needs to follow these databases and this has to be done ensuring e.g., provenance integrity. Secure data provenance focuses on these type of problems. A few properties have been established as a requirement for secure data provenance [START_REF] Zhang | Do you know where your data's been? -Tamper-evident database provenance[END_REF], [START_REF] Hasan | Introducing secure provenance: problems and challenges[END_REF], and [START_REF] Hasan | The case of the fake Picasso: preventing history forgery with secure provenance[END_REF]:

-Distributed. When databases flow through untrusted environments, and provenance data is associated to them, we need secure data provenance systems to be defined so that they work in a distributed environment. We cannot use a centralized approach with trusted hardware. -Integrity. In distributed environments it is important that nobody can forge provenance data. Provenance data is transmitted and provenance structures are modified to add the new processes applied to the data. Nevertheless, as stated above the structure is immutable and no adversary can be granted to change any part of it. In addition, the provenance system should not allow the modification of a value without expanding the provenance structure. Finally, deletion of provenance data should not cause that a record of the database is unreadable. Additional aspects to be taken into account is to consider collusions of intruders (that coalitions of intruders should not be able to attack integrity), repudiation (that intruders should not be able to repudiate a record as it was not theirs) or creating forged structures (intruders should not be able to create new provenance structures). -Availability. We are interested in providing security mechanisms to ensure provenance data availability. Auditors should be able to access provenance information in a secure, fast and reliable manner to perform any required operation, e.g. verify the integrity of an ownership sequence without knowing the individual records. -Privacy and confidentiality. We need to ensure that disclosure does not take place, and this is needed for both the database and the provenance data. Only authorized users can access the information.

These properties need to be combined with the two properties that are general for any provenance system. They are, completeness and efficiency:

-Completeness. That is, that all actions that are relevant to computation should be detected and represented in the provenance structure. Note that this is not always easy, because some operations as e.g. cut & paste or manual copy can exclude relevant provenance information. -Efficiency. Data provenance introduces an overhead to the data. Finegrained provenance can double (or more) the size of a database. In addition, operations on the provenance structure need to be efficient because they also introduce an overhead on the computation time.

All these properties are relevant in the context of big data provenance. Big data is often distributed as different information sources can contribute in a computation or in a decision. Therefore, integrity is a basic aspect. We need that provenance structures are not modified at will, and we need to be sure that only permitted operations are applied to them. Availability is then not only a requirement for auditors but also for the subjects from which the data has been extracted. In order that individuals can access and apply the right to delete or rectify a record, they need to be able to know where their data is or if a certain record contains data that has been generated from their own data.

Considerations about privacy and provenance

When considering big data associated with provenance data, it is important to clearly define the possible scenarios that may arise for data privacy. An accepted classification of possible situations is given in [START_REF] Bertino | A roadmap for privacy-enhanced secure data provenance[END_REF] on the basis of what is protected or where do we want to ensure a given degree of privacy (see Table 1):

-Case 1 : The data are kept private and provenance data are also private.

Both need to be protected and their relation has to be preserved. -Case 2 : The data itself are not protected but provenance data are private.

-Case 3 : Data are private, but the provenance data are not protected. -Case 4 : No privacy protection are applied to neither the data itself nor the provenance data.

Depending on the different purposes, requirements, and nature of the specific data, a given case might apply. Secure data provenance mainly focuses to the case of private provenance when data is distributed (i.e., we need the system to satisfy the requirements discussed in Section 4.1). In the case of centralized private data standard anonymization techniques can be used if we want a singleshot release of this data.

Some of the problems we encounter when data provenance is used depart from standard solutions of data privacy. We discuss a few examples in the next section.

Example of privacy problem with provenance information

In this section we illustrate an example of a specific problem that can arise in big data privacy when considering provenance information. This problem might occur when individuals request the deletion of their related data from a given dataset, and thus the model obtained from the data needs to be revised. This operation will be performed by means of provenance data allowing the data operator to know exactly which specific data has to be deleted.

To describe this example, we introduce some notation. We will consider a set X (a file or a database) to which we have applied some masking method ρ to obtain a protected set χ. From χ, using a certain algorithm A we extract a piece of knowledge Γ . For example, A can be an algorithm to extract decision trees, therefore Γ is the decision tree inferred from ρ(X).

The set X is modified with modifications µ to obtain a data set X , which protected with ρ will yield χ and with algorithm A, the piece of knowledge Γ . E.g., Γ is a (different) decision tree inferred from ρ(X ).

Notation and procedures are represented in Figure 1.

In most cases µ should not be public since it will lead to reidentification of modified records. In front of this scenario some interesting questions might arise.

-An intruder knows S ⊂ X, Γ , and Γ , can this intruder gain knowledge of µ and S ⊆ X \ S with certainty? -An intruder knows χ and χ , will this intruder be able to determine µ? In order to avoid that intruders can make the inferences outlined in the previous lines, privacy models and privacy algorithms can be defined and implemented. In [START_REF] Torra | Integral privacy[END_REF] we introduced a privacy model related to the modifications of a database.

Fig. 1 .

 1 Fig. 1. Example of protected data and its modification

Table 1 .

 1 Cases for privacy and data provenance.

	Data	Provenance
	Case 1 Private	Private
	Case 2 Non-private Private
	Case 3 Private	Non-private
	Case 4 Non-private Non-private

Summary

In this paper we have proposed a few open questions on the topic of data privacy for big data. On the one hand, we have discussed lines related to stand-alone and linked databases. Among them, we want to stress the need that databases are anonymized in origin, and thus technology is developed to permit controlled linkability and composability.

On the other hand, we have discussed issues related to data provenance, and its relationship with data privacy.

Acknowledgements

This work was supported by Spanish MINECO (project TIN2014-55243-P), and Catalan AGAUR (2014-SGR-691).


Amelia Andersdotter
email: amelia.andersdotter@dataskydd.net

Anders Jensen-Urstad
email: anders.jensen-urstad@dataskydd.net

Evaluating Websites and Their Adherence to Data Protection Principles: Tools and Experiences Contributions to IFIP Summer School Proceedings

Keywords: privacy, metrics, data protection, web tools, guidelines, policy procurement

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

With the entry into eect of the new EU rules on data protection in May 2018, there is an urgent need for web developers and other actors in society to make preparations. We have developed two separate tools to identify measures which can be undertaken to improve privacy protection in public websites in Sweden.

In particular, they will assist web developers and web strategists to analyse how they are currently leaking personally identiable information (PII) to third parties, as individuals visit their websites.

Our rst tool is a simple technical mechanism for private persons and web developers to evaluate the leakage of PII from websites. 1 The second tool per- forms more substantive measurement of PII leakage from Swedish municipal ? Co-founders Dataskydd.net. This project was realised through the kind nancial assistance provided by Internetfonden/IIS over the period January-August in 2016. [START_REF] Englehardt | Online tracking: A 1-million-site measurement and analysis[END_REF] See https://webbkoll.dataskydd.net/en/ [in English and Swedish].

websites. 2 In addition, we produced technical advice on how data leakage can be mitigated.

3

We have checked the use of web analysis tools, 4 whether a referrer policy is set, 5 the usage or absence of encrypted connections as well as inclusion of third party services (fonts, forums, weather services or text-to-voice services) or the placement of cookies (both persistent tracking cookies and functional cookies).

Additionally, we provide an element of gamication for Swedish municipalities, in that we developed a ve-step grading system. This allows for municipalities to compare their eorts to other municipalities. With current data leakage rates being generally high, we found, however, that no municipalities obtain better than mid-level results.

This study aims to achieve utility for web designers and website developers, with an emphasis on utility for public sector institutions. While there are a number of web browser plug-ins that could be installed by web visitors to mitigate harms arising from persistent online tracking, 6 this paper is guided by the belief that privacy problems can and should be solved close to the source of the problem. We believe similar methodologies and tests could also be useful in other countries, and in so far as possible we have strived to identify cost-neutral improvements.

Similar tools in the Swedish context

In Sweden, prior examples of web services for monitoring private and public sector compliance with applicable law include Hitta kakor 4 Google Analytics, Adobe Tealeaf, Piwik, et c. [START_REF] Pts | Faktablad -Cookies och lagen om elektronisk kommunikation PTS-F-2005:2[END_REF] Cf. https://www.w3.org/TR/referrer-policy/ 6 Some alternatives include Cookie White List, Privacy Badger, various adblocking applications (such as Adblock Plus or uBlock Origin), Ghostery, RequestPolicy, No-Script, HTTPS Everywhere, uMatrix, Disconnect, Decentraleyes, and similar. In addition to these tools web visitors may opt to use private browsing mode, which is increasingly included by default in most major browsers. Both of these guidelines target the necessary requirements for end-user terms of service formulations given specic options implemented by the web developer.

The success rate in terms of increasing adoption rates of globally desired practises varies.

Accessibility guidelines have generally been well-received. 11 While security- oriented projects, such as the guidelines for encrypted connections and DNSSEC are ostensibly taken seriously at the national level, deployment has been slow. 12 All of the prior guideline projects have been developed under the auspice of the Swedish national regulatory authority for telecommunications and postal services (PTS). The data protection guidelines focus on contract law, and their success rate is dicult to measure. There are no known cases where the privacy terms of a municipal website or other website have been successfully tried in court.

Methodology

We have constructed tests which are technically more convenient to monitor, and which assume an expansive view of the wordings of the legislation. What this means is that our technical monitoring of websites does not accomodate for exibilities in the law to avoid certain types of data forwarding or data collection by referens to privacy terms. This is for a few reasons.

End-users have been demonstrated not to reasonably have the time or capacity to read and understand such terms of services.

13

Having restricted ourselves to investigating municipalities in depth, we deemed it inappropriate to construct a set of tests which would assume the public sector should enter into extensive and dicult to understand agreements with their website visitors.

, We have assumed that it is more interesting for web developers to engage with interesting technical alternatives to monitoring and tracking over engaging with the formulation of terms of services agreements.

Instead we have focused on the ability of web developers to adhere to the data minimisation principle. 14 We have also assumed that adoption of data protection enhancing measures is more likely if website owners and managers are provided with self-measurement and top-listing tools.

The Scoring System

We devised a ve-step scoring system for municipalities which runs from E to A, with A being the highest and E the lowest score. 15 A To get the highest score, a municipality should neither leak PII to third parties (Internet service providers, mobile providers, content delivery platforms, advertisers, etc.) nor collect unnecessary information for their own use. This means use of HTTPS by default, no persistent rst-party cookies, no thirdparty requests (which implies no third-party cookies), referrer policy set to a restrictive value (i.e., no-referrer), setting the HTTP Strict Transport Security header (HSTS), and no insecure requests (i.e., HTTPS to HTTP).

B The second highest score relaxes the requirements for collecting PII for own, in-house use (such as a locally hosted web analysis tool). It requires HTTPS, no third-party requests, and no insecure requests.

C The middle score is obtained for those websites that either have a strong protection against PII leakage to Internet service providers (by for instance employing encrypted connections universally), or having a strong protection against PII leakage to third party web services (content delivery platforms, advertisement networks, web analysis tools, etc.): HTTPS, third-party requests (but none insecure) and third-party cookies or HTTP and no third- E The lowest score, then, is when there are no data leakage protections in place: no encryption, and use of third-party cookies. In our August 2016 test, most municipalities (204 out of 289) ended up with this score. While the scoring system is simple, we have tried not to make it biased towards any particular form of protection against PII leakage. It is, for instance, possible to get at most a C grade without using encrypted connections, but it is not possible to advance beyond a C grade without also remedying PII leakage to third parties. We chose this methodology to ensure that privacy is protected against electronic communications services as well as information society services.

Since we nalised the beta version of our in-depth tool in May 2016, we have produced scores for all Swedish municipalities on three subsequent occasions. The total number of municipalities tested amounted to 290.

Technical Design

We made two tools: a generic tool for privacy checks for individuals (a web service), Webbkoll, 19 and a more sophisticated tool for checking municipality websites (not a publicly available service).

20

In both cases we attempt to simulate a typical user with a typical browser with default settings e.g., with Do Not Track disabled, as that is normally the browser default and with no particular browser extensions installed, and see This called for a typical design where we would have a user-facing frontend server communicating with one or more separate backend servers (which in turn perform the actual visiting and rendering of webpages) through a REST API.

The most resource-intensive part of the infrastructure is the backend. We considered running a real consumer browser such as Firefox through the Selenium framework (as in [1]), but found that the overhead was too great. It should be noted that while Selenium oers more possibilities and a more stable environment, this was less of a concern here than in our later municipality test. Our online tool is not meant to be used for studies or rigorous analysis, but rather as a starting point for web developers and web visitors. 2) It makes sure the input is transformed into a proper URL e.g., example.com becomes http://example.com. Since we check whether a site uses HTTPS by default, we always check the http:// version of a site rst to see whether it redirects automatically; so https://example.com is transformed into http://example.com. It is possible to visit specic pages on a domain (e.g., http://example.com/subpage.html); we keep the path (/subpage.html) but, for security reasons, no query parameters nor anything else. An input of http://user:password@example.com/subpage.html?foo=bar would be transformed into http://example.com/subpage.html before being passed on.

3) If the URL resulting from 2) has already been checked and is in the database, the old data is fetched and rendered. If the URL is not in the database, or if it is in the database but the user has clicked Check again, we force a new check, and the frontend proceeds to 4).

4)

To prevent abuse, it does some basic rate limiting: per IP (a user can only make a certain number of requests during a certain span of time) and per host (a certain host can only be queried a certain number of times during a certain span of time this is not user-specic). If either criteria is violated, an error is returned.

Finally, if steps 1-5 completed successfully, the user's request is sent to a queue in the job handler also on the frontend for background processing (this handles concurrency, retries, queueing, etc). To allow for multiple backend servers, multiple queues, each having a certain backend URL tied to it, can be specied.

The job handler runs a worker to handle the user's request. The worker sends a HTTP GET request to the backend server. This request contains the URL of the webpage to visit.

The backend server runs PhearJS, 26 a server written with Node.js, handling a number of PhantomJS workers. When PhearJS receives a request from the frontend, it's passed on to one of the workers. The PhantomJS workers visits the URL and renders it, waiting a specied period of time in our case, ten seconds before returning the results. This is to make sure scripts have time to run.

When nished, the resulting data is sent back as JSON to the frontend. This JSON contains all the request and response headers, cookies, HTML content, etc.

The JSON is decoded by the worker process and checked for errors. The worker then proceeds with processing of the data:

1) The nal URL is noted. This is the actual page rendered, after any redirects.

2) From the nal URL the registerable domain is extracted and noted with the help of a library that uses Mozilla's Public Sux List.

27 This list is used by 26 See https://github.com/Tomtomgo/phearjs 27 See https://publicsuffix.org/ browsers to determine where cookies can be set (or not), and we use it to distinguish between rst-party and third-party sites.

3) Cookies are split into rst-party and third-party. We also count the number of unique third-party cookie domains. 4) From requests, third-party requests and insecure rst-party requests are extracted. Request types (secure vs. insecure) are counted. 5) Using a HTML parser we check whether a referrer policy is set using meta referrer (a referrer policy can also be set in a Content-Security-Policy header;

this is checked at a later point).

All the above is saved to the database and the status of the user's request is updated.

Meanwhile, the user is redirected to a status page where the ID of the request is in the URL. The page is reloaded automatically every ve seconds using meta refresh. On every request the frontend checks the status of the page in the databaseif state has changed, the user is redirected to a results or error page, otherwise the status page is shown again. While there are smoother ways to present status and do transitions, this way we avoid having to use cookies.

Finally, the user is presented with a results page. It shows the following:

Whether HTTPS is used by default; and, if so, whether the site uses HTTP Strict Transport Security, and whether there are any insecure requests.

Whether referrers are leaked. First-party cookies. Third-party cookies. Third-party requests, categorized using Disconnect's public tracker list. Certain HTTP headers that can be benecial for privacy and security: Content-Security-Policy, Strict-Transport-Security, Public-Key-Pins, X-Content-Type-Options, X-Frame-Options, X-Xss-Protection. Limitations The tool is limited to what can be checked non-interactively, i..e., things that can be observed by merely loading the page it does not perform any actions such as clicking on links.

Except for rejecting sites with invalid certicates (and checking the headers for HSTS and Public Key Pinning), it does not do any deep analysis of a site's SSL/TLS conguration e.g., vulnerability to various attacks, forward secrecy, support for insecure protocols, etc. Currently we provide a link to Qualys SSL Labs free online service.

At rst some of the tools used did not have all the necessary functionality for our purposes. We contributed some code to PhearJS to add support for returning cookies and requests, Technical Choices Although we had already created our online tool Webbkoll, we opted for the web privacy measurement framework OpenWPM [1] for our municipality study. Our online tool was meant to be used by web developers and others to quickly check a website and gain ideas about possible improvements, while OpenWPM was built specically for collecting data for privacy studies and supported more features, such as the ability to visit internal links.

Deployment We fed a list of the websites of Sweden's 290 municipalities into OpenWPM. OpenWPM which uses Firefox, Selenium and a HTTP proxy then visited each site and tried to visit up to ve internal links. Firefox was congured to run without any particular extensions installed, and with Do Not Track disabled. All data (all HTTP requests and responses, cookies, etc.) was saved to a SQLite database.

We then wrote a program to enrich the database, mainly using information already contained therein, but made more easily accessible to make it easier to produce statistics and (at a later stage with the same program) generate the reports pages. 30 For example, the http_requests table was extended with columns for base_domain (shortest domain assigned to a registrant; used to determine rst-party vs. third-party cookies/requests) and scheme (HTTP or HTTPS); site_visits was extended was extended with e.g. HSTS value, referrer policy, third-party requests, insecure requests and multiple columns for cookies (rstparty and third-party prole and session cookies). Each municipality was also scored using the criteria mentioned in 2.1.

It should be noted that the results for a municipality are based not on a single page, but on the collected data from the initial page plus up to ve internal pages. 28 https://github.com/Tomtomgo/phearjs/pull/5 29 https://github.com/seomoz/publicsuffix-elixir/pull/17 30 Code (MIT license): https://github.com/andersju/municipality-privacy In our setup OpenWPM did not save the HTML content of pages. As referrer policy can be set in both a HTTP header and in a HTML meta element, we let our post-processing tool visit the initial URL of each municipality website, get and parse the HTML and look for meta referrer.

Finally, our tool generated a static website with 1) an overview with a table containing all municipalities, sortable by score/scheme/referrer leakage/number of cookies/etc., and 2) a detailed results page for each municipality, much like the results pages produced by our web service Webbkoll.

Limitations While we did visit a number of internal links in this test, we are limited by what can be done in an automated fashion when we have no prior knowledge of the sites being visited. The internal links are chosen at random, and at the moment we cannot check whether it is, for example, possible to contact one's municipality in a secure way.

The browse command in OpenWPM 0.6.2 loads a specied URL and then tries to visit a specied number of internal links (from the same hostname as the URL) on the initial page. However, we found that no internal links were visited if the initial URL was a redirect; we thus had to use curl and a few command-line tools to process the list of municipality websites, gure out the nal URL of each website, and then write those URLs to a new le that we then used as input to OpenWPM.

We found a bug that in rare instances would make OpenWPM treat external links as internal. This was reported and xed.

Discussion

The following chapter is based on structured interviews with employees from the Swedish public sector as well as interactions with such employees that we have had since the beginning of our project. These interviews and interactions were, however, conditioned on anonymity of the individual civil servants concerned.

The Municipality of Enköping

We were in touch with civil servants working in the Swedish medium-sized municipality Enköping 31 since before we started our project. The municipality was, and still is, in the process of refurbishing their public-facing web environment.

The municipality lacked prior guidelines for web development beyond graphical proles at the start of the project. The changes in the website could therefore be planned freely by responsible sta. While responsible sta had support for a data protection friendly shift from their immediate superiors in the hierarchy (the communications department), interest was more shallow in the municipal IT department. The data protection focus did, however, receive attention from 31 A medium-sized municipality is a municipality with 20 000-50 000 inhabitants ac- cording to Sveriges kommuner och landsting, Kommunsgruppsindelning (2011). the highest publicly elected ocial in the municipality when the new website was launched.

The focus on data protection in the development of the new website emerged only after the initial steps to change the website had already been taken [2].

Because of this, specications which would have been useful to integrate at an earlier stage had to be appended to the specication afterwards (such as removing referrer leaks and using local analytics tools). This caused additional costs for the municipality (a one-time fee of approximately EUR 2000 for the Piwik server). While this is not a large sum, a continuing problem is the lack of qualied Piwik administrators available from subcontractors. Access to third party analytics specialists is simply higher, making it more time-and cost-ecient to use third party analytics tools.

In November 2016, the municipality has still not crossed the TLS hurdle in spite of having a pre-existing cryptographic certicate which was valid across all the municipality's domains when we rst got in touch with them. The provision of municipal maps stopped working when TLS was turned on, but there is ongoing work to x this problem. Changes in sta in summer of 2016 means that many of the planned changed are stuck, while new sta get accustomed to the work environment. The municipality is still not able to obtain a higher grade than D in the Dataskydd.net privacy web check tool.

Other Municipalities

After launching our municipal top list, we have noticed that more municipalities are adopting the use of referrer policy. We have also had questions from municipalities about the use of encryption.

For instance, it is still the case that some web developers fear that encryption may reduce the availability of the site (for instance, making it slower to load and requiring more server resources). While this is not supported in practical knowledge, 32 , and in fact HTTP/2which brings superior performancein practice requires the use of encryption as no major browser supports unencrypted HTTP/2, it's a legacy concern that is likely to remain for some time.

Additionally, and as with many things that may require alterations in current work ows or technical tools, we have noticed that municipalities that are refurbishing their public web environments with data protection enhancements are likely to be concerned that the data protection enhancements are the cause of problems. For instance, use of referrer policy may get the blame for broken links even if, upon careful analysis, it turns out not to have been the problem.

Other questions that have emerged are covered above in Sections 3.1 and 3.2.

Analysis

The experiences of Enköping indicates that a data protection focus becomes both cheaper and quicker if integrated from the beginning. This provides support for the utility of data protection by design. 32 https://www.maxcdn.com/blog/ssl-performance-myth/ One municipal employee indicated that it would be helpful if some form of procedural standard was developed, equivalent to the standards for web site accessibility which have just been adopted in European law [3].

It may be assumed that the prevalence of non-third party analytics tool specialists increases if the demand for such services increase. The municipality sta also experienced that the most frequent questions they would face from other municipalities related to their experiences of Piwik. A detailed analysis of municipality websites indicates that Enköping is not alone in trying out selfhosted alternatives to Google Analytics.

33

The environment for making changes will dier between municipalities. While Enköping experienced signicant delays in ordering and installing Piwik servers and a low degree of interest in data protection from their IT department, 34 in other municipalities it is the IT department which is responsible for the design and features of the website. 35

We have not received any feedback from private persons who've tried to use our tool to inspire changes in websites that they themselves did not manage.

Conclusions

Many of the tools under development for privacy measurement are primarily used to investigate large numbers of the most popular websites. Our work has focused on a minor subset of websites, those of Swedish municipalities, which were unlikely to be the most visited.

While our goal was to make cost-neutral suggestions for improvements in so far as possible, we found out that even nominally free (gratuite) products or simple changes in the specications for a municipal website may imply signicant enough costs to the municipality that many parts of the municipal administration must be involved in enacting change. The experience of Enköping is that it is doable, but requires considerable eort from responsible civil servants.

The observations from the municipal civil servants are straight-forward, for instance requesting a guideline for data protection friendly developments. But such guidelines are unlikely to be adopted without signicant eort. The tools we developed are not designed to make use of exibilities in the data protection laws, but to provide simple and cheap means to maximise adherence to the principles enshrined in the General Data Protection Regulation Art. 5. Some of our suggestions are more likely to be adopted than others: the number of Swedish municipalities using encrypted connections is increasing, as is the number of Swedish municipalities that introduce a referrer policy. We also believe that adoption of alternative analytics tools will increase, but this will depend on a few front-runners creating a demand for alternative analytics expertise.

33 Alingsås, Arvika, Örnsköldsvik, as per Dataskydd.net:s municipal mapping 20th Au- gust 2016 (cf. footnote 16).

34 Informal dialogue with municipal civil servant in Enköping.

35 Informal dialogues with municipal civil servants in other cities.

72

  and extensive work in the eld of accessibility[4, guideline 1]. 8 More technically inspired guidelines include eorts to improve adoption rates of encrypted connections[4, guideline 7] and DNSSEC. 9 Additionally there have been attempts in Sweden to compile guidelines for data protection on websites[4, guideline 20] and with respect to web cookies. 10 See https://dataskydd.net/kommuner/ [only in Swedish]. 3 In the right-hand column of the test-results accompanying the generic web-check on the website listed in footnote 1, or under the heading Begrepp och tips on the website listed in footnote 2.

  party requests. 20 municipalities out of 289 acquired this score in our latest test on August 20th 2016. 16 This can be compared with 16 municipalities obtaining this score in May of 2016. 17 D The second lowest score is obtained from having partially encrypted connections (with insecure elements loaded in the visitor's browser) and making third-party requests and setting third-party cookies, or from using HTTP but not setting third-party cookies. 64 municipalities ended up with this score in our latest test on August 20th 2016. Two municipalities had shifted from a C score in our May 2016 test to a D score in the August 2016 test, after introducing non-encrypted elements on their websites.

15

  See https://dataskydd.net/kommuner/metodologi.html 16 See https://dataskydd.net/kommuner-201608 17 See https://dataskydd.net/kommuner-201605 The last scores, produced in November 2016, are not accounted for in this text but are available online. 18 In Fig. 1 and Fig. 2 you will nd comparisons of scores between May and August of 2016.

Fig. 1 .

 1 Fig. 1. Distribution of grades assigned by our tool for substantive measurement for all Swedish municipalities in two separate test runs performed on May 30th 2016 and August 20th 2016.

Fig. 2 .

 2 Fig. 2. Number of municipalities which have adopted encrypted connections and protection against referrer-leaks in May 30th 2016 and August 20th 2016 respectively.

Fig. 3 .

 3 Fig. 3. Screenshot of part of results page for regeringen.se, the website of the Government Oces of Sweden.

  28 and to the Elixir library PublicSux to add support for checking whether a domain matches a specic rule in Mozilla's Public Sux List. 29 3.2 Municipalities: Choice of Tool for Backend/Frontend

  7 PTS, http://e-tjanster.pts.se/internet/kakor/ 8 See also http://www.anvandningsforum.se/om/ 9 PTS, information webpage about ongoing work to promote DNSSEC with

	Swedish	public	authorities.	https://www.pts.se/sv/Bransch/Internet/
	Robust-kommunikation/Atgarder/DNSSEC/ 10 PTS-F-2005:2.

  The frontend is written in Elixir, a functional language running on the Erlang VM, and uses the Phoenix web framework. When visiting the website of the tool the user is presented with a single text form eld for entering the domain name or URL of any web page. When the Check button is clicked, the frontend does a number of things: 21 Qualys SSL Labs SSL Server Test. https://www.ssllabs.com/ssltest/ 22 Securityheaders.io. https://securityheaders.io/ 23 Sitespeed.io (https://www.sitespeed.io/), Google's PageSpeed Tools (https:// developers.google.com/speed/pagespeed/) 24 By grant condition. Code (MIT license): https://github.com/andersju/webbkoll 25 See http://phantomjs.org/ 1) It checks whether the user is possibly a bot, and if so, rejects the request.

Therefore we opted for good enough with our choice falling on PhantomJS, 25 a lightweight headless browser based on WebKit (also used by Safari; and a fork of WebKit is used by Chrome). Deployment

We hope that our eort provide a humble starting point for future projects seeking to make data protection by default a feasible option for web developers.


Shyam S Wagle
email: shyam.wagle@student.uni.lu

Cloud Computing Contracts

Keywords: Cloud Contract, Legal Issues, Compliance Status, SLA, Provider Analysis

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Cloud computing is a promising technology for the information technology (IT) industry that has only recently emerged. An increasing number of IT service providers are offering computational, storage, networking, and application hosting services that cover several continents. Small medium enterprises (SMEs) as well as big enterprises are attracted towards the cloud technology. Adopting cloud computing in their businesses has its pros and cons. Some institutions are attracted to cloud computing because of its easy deployment, low initial start-up cost and easily scalablility, while others are serious about the cloud adopting risks. IDC has forecasted that worldwide public cloud services spending will be to double by . There are many technical and legal challenges for cloud users to fully adapt cloud computing in their businesses. In such circumstances, the actual service performance status of CSPs including regulatory compliance status according to the current legal framework, can help cloud users in their decision making to choose cloud services according to their requirements. A mediator, which can facilitate among cloud users to provide cloud services according to the businesses' requirements and finds appropriate users according to the services offered by them, is called cloud service broker (CSB). Mainly, it can play following roles [ ], [ ]:

-Discovery of SLA and law/regulation compliant services -Monitoring run-time SLA and law/regulation compliance -Checking of SLA and law/regulation compliance during the service on-board and at run time -Actuation to maintain compliance.

Cloudforeurope has identified the need for evaluating the performance of competing CSPs to select cloud services according to their requirements under the CloudWatchHub project. The main idea is to accelerate and increase the use of cloud computing across the public and private sectors in Europe and educate SMEs how to choose the right service provider to take account of personal data protection and service level concerns as opposed to price only.

The reference document for CSBs to recommend cloud services to the users is a cloud contract document. Buyya et. al. [ ] have pointed out two contracting models: ) The online agreement is a click wrap agreement where the user agrees to the terms and conditions of the CSPs in an "I agree" box or similar at the moment of service initiation. Online agreement is not subject to negotiation by cloud users. This model is the most commonly followed model by cloud providers, where by cloud users do not have any bargaining power to negotiate the standard agreement offered by CSPs. This analysis is limited to an online agreement model because all the information mentioned here are taken from CSPs' website; ( ) A standard, negotiated, signature-based agreement, which generally occurs when larger companies want to move their critical data or applications to the cloud (for instance to the public cloud). In such an agreement, cloud users are free to push their terms and conditions, and requirements, in the contract document.

In summary, a CSB can play two roles in a cloud computing architecture: ) Service matching according the requirements of the cloud users, and ) a regulatory compliance check according to the current legal framework. Current cloud service brokering frameworks recommend cloud services to the users by considering the service performance status of the CSPs, and most of these frameworks are not aware of the current legal framework. In the literature, most of the research works on the cloud service brokering are: ) service performance service discovery and matching [ ], Quality of Service (QoS) management and optimization [ ], interoperability in multi-cloud architecture [ ] and so on. The current cloud service-brokering framework is not techno-legal friendly, which can be capable to check both legal and service performance compliance in a single platform. Cloud users and providers are often reluctant to take advantage of cloud computing services because they think that either the terms and conditions are unclear or are unbalanced in the favour of CSPs . More often CSPs try to avoid their responsibilities, as in security and data protection for the users, to be on the safe side in terms of any legal obstacles; however, these are the current big issues in cloud computing contracts from the legal point of view. In our observation, most of the CSPs provides contractual issues under the terms of service and SLA section on their website. Our main source of information in analyzing the regulatory compliance status is: terms of service, SLA agreement, and any frequently asked questions (FAQ) available on the website of the cloud service provider.

In a survey conducted by W. K. Hon et al. [ ], the authors pointed out six major terms included in standard cloud computing contracts, which cloud users are highly interested to negotiate. These are the: ) Limitation of liability in data integrity and disaster recovery, ) Service Level Agreement (SLA), ) Security and privacy, ) Vendor lock-in and exit, ) Provider's ability to change the service features, and ) Intellectual property rights (IPR). The survey shows that cloud users are not yet convinced with current practiced standard cloud contracts. In cloud computing, cloud contract documents are yet to be standardized and develop defined standard terminology [ ]; however, some recent attempts [ ] towards standardization of cloud SLA have been performed .

The rest of the paper is organized as follows: Section presents the overview of the SLA assured cloud service brokering framework. Section identifies data protection risks in cloud computing from a cloud contractual point of view. We briefly present terms of service and SLA commitments offered by international cloud service providers to check the regulatory compliance status of them according to the current legal framework in Section . Based on it, we point out some important points to be included in a current cloud contract to make it safe and fair for both CSPs and cloud users. An approach to checking the regulatory compliance status of CSPs has been proposed as a main contribution http://ec.europa.eu/justice/contract/cloud-computing/index-en.htm https://ec.europa.eu/digital-single-market/en/news/cloud-service-level-agreementstandardisation-guidelines of the paper in Section . . Since, in the cloud contract, most of the terms are related with data privacy issues, the analysis is heavily influenced by the EU data protection regime. The paper concludes with the overall concept in Section . sets of alternatives to the cloud users. In this paper, we mainly address the regulatory compliance status analysis of CSPs to recommend services to the users.

SLA Assured Cloud Service Brokering Framework

Safe and Fair Terms and Conditions in Cloud Computing

As the data from various cloud users is stored in a shared infrastructure environment, there exists the possibility of the accessing of confidential data by un-authorized users or media. This causes many technical issues to protect data from unwanted access as well as it creates legal issues due to the dynamic nature of service access in cloud computing. The recently enacted EU's General Data Protection Regulation (GDPR) repealing the EU's Data Protection Directive / /EC , gives fundamental rights to the data users (data subjects) with respect to their personal data while requiring "data controllers" to follow rules and restrictions with respect to their data processing operations [ ]. The regulation is designed to further addressing new technological developments. Cloud users are entitled to be informed of the identity of any data controller and the purposes for which personal data are being collected or processed. According to the GDPR, data controllers should follow a main set of privacy protection principles on data protection that define the individual rights of the users and the responsibilities of data controllers that process personal data: fair and lawful processing, collection and processing only for a proper purpose; should be adequate, relevant and not excessive; should be accurate and up to date, should be retained no longer than necessary; giving the data subject access to his/her data, keeping data secure; and no transfer of personal data to a country that does not provide an adequate level of privacy and personal data protection. New penalties (including fines of up to the greater of either e million, or -% of annual worldwide turn over) in the new regulation are intended to make CSPs serious about their regulatory compliance.

An Opinion of the Article Working Party has categorized data protection risks in cloud computing, into two major broad groups, ) and ): ) risk due to a lack of control over the data. Under this category, lack of availability due to lack of interoperability (vendor lock-in), lack of integrity caused by the sharing of resources, lack of confidentiality in terms of law enforcement requests made directly to a CSP, lack of intervenability due to the complexities and dynamics of the outsourcing chain and data subjects' rights, and lack of isolation within the CSPs' clients are the main data protection risks, and ) risk due to insufficient information regarding the processing operation (hence, a lack of transparency). Mainly these risks may arise from the controller not being aware of certain conditions: for example, that some form chain processing is taking place involving multiple processors and subcontractors, personal data are processed in difference geographic locations within the European Economic Area (EEA), and personal data are transferred to third countries outside the EEA.

However literature from many standardardization bodies and organizations have many points to be considered in the list to make the terms and conditions in the agreement safe and fair, following some major points addressed by the Cloud Select Industry Group -Subgroup on Service Level Agreement (C-SIG-SLA) . In addition, the authors in [ ] considered analyzing the regulatory compliance status of CSPs through the terms of service mentioned in the contract document, which is clear and transparent to every parties involved in the agreement. All the important points mentioned in the section that follows are represented in Personal Data Protection Service Level In a SLA agreement, the most important part is to define how the CSP acts as a data processor or data controller or joint controllers (notably by processing personal data for their own purposes, outside of an explicit mandate from the user). It is also necessary to describe applicable data protection codes of conduct, standards, and certifications. If personal data are processed, it is necessary to define the purposes of processing, openness and transparency of subcontractors. The document should define who is accountable for a personal data breach. Another important issue in the data management service level is a detailed list about the geographical location(s), where user data may be stored and/or processed and preferred geographical location for the storage of the user data. Last but not least, a SLA agreement must define the access request response time period within which the provider shall communicate the information necessary to allow the user to respond to access requests by the data subjects.

. Provider Lock-In and Exit

Lock-in is one of the top concerns of cloud users. Most of the cloud users may not wish to be locked-in for long time with an initial contract. Users should be free to leave the service after a short, specific time. Users should be allowed to leave the service when they feel that the service is not appropriate for them or the same service is available in the market at a cheaper price from another CSP. While this is a commercial issue, the main concern is how a user's data and metadata can be recovered once the service is terminated for whatever the reason. Data formats should be easily accessible, readable and importable into other applications of other CSPs, independently. Data retention and deletion are also important issues in a cloud contract. Users should be assured about retention of their data and the complete deletion of their data after contract termination [ ].

.

Terms and Conditions

As usual, like in other contracts there should be minimum terms, a renewal period and a notice period. Long initial terms may be one of the issues of provider lock-in. Many of the CSPs set automatic renewal provisions, which may mislead cloud users if there are not a fixed notice periods. These terms and conditions depend on types of services and types of business scale. Suspension rights must be also clearly mentioned in an agreed contract document.

.

Changing Service Features

CSPs should not be entitled to change terms without consent, or at least should give users notice and allow them to terminate the contract . Any changes in service must not adversely affect the previous commitment. Users must be notified within a sufficient time mentioning the key changes and impact of changes.

.

Intellectual Property Rights

Intellectual property rights (IPR) issues arise frequently in relation to cloud processed data and, or applications. This generally happens due to the issue of who owns data in the cloud contract document not being addressed properly.

Analysis of Terms of Service and SLA committed to by CSPs

In this section, we first provide the terms of service and SLA commitments of some incumbent CSPs. The main sources of information come from the terms of service, SLA document, security practices, privacy policies, the cloud documentations on getting started and other user guides, and FAQs by CSPs. We second expose some missing major items in the current cloud contracts. We third (in a following sub-section) offer two tables that explain these two sets of issues; the second table uses a simple pictorial format. What follows are the details in relation to the incumbent CSPs.

Microsoft Azure: Microsoft Azure offers a specific SLA commitments in multiple services. Its SLA commitment ranges from maximum . % to . %. It provides sector/region-wise SLA commitments to the cloud users. It offers detailed information regarding the data transfer; however, information on data law and jurisdiction. It provides the geo-locations of data centres and monitoring facility of cloud services.

Cloud Sigma: Similarly, Cloud Sigma also offers at least % monthly uptime irrespective of a specific service. The terms of service detail liability, privacy policy, IPR, governing law and jurisdiction . Information related to data centre locations is also provided. However, the terms and conditions are not clear enough as is recommended by standard cloud contract guidelines.

Elastic Host: Elastic Host provides a service specific SLA offer that ranges from at least . % to %. It lacks specific details on privacy and security issues in the provided SLA agreement provided, and puts more liability on the users. The proposed agreement is specific in terms of governing law and jurisdiction.

Century Link Cloud: Century Link Cloud is very specific in terms of its SLA document. It commits to % uptime for public/private networks and at least . % for the rest of the services. It provides a privacy policy , data retention issues, governing law, and jurisdiction; however, it is not specific on data liability and other issues, which are necessary to make a safe and fair cloud contract. It provides data centre locations on its website.

Digital Ocean: However, Digital Ocean does not provide specific SLA commitments. According to the service offers, it provides at least . % monthly uptime in network, power and virtual server availability. The offered document provides information related to the liabilities, and governing law, data privacy but a detail related to physical security is still missing in the document.

GoGrid Cloud: GoGrid Cloud , provides a very specific SLA commitment for each cloud service. It also provides a regional, specific performance matrix in its SLA document. It is more specific on privacy and security issues, IPR and third party offerings, and choice of law, and jurisdiction; however, it does not take more liabilities in user's data.

UpCloud: UpCloud commit to a minimum of % monthly uptime to all services, irrespective of the specific cloud service. The terms of service are not clear on data security and privacy, governing law, jurisdiction, and data centre locations .

IBM Cloud: IBM does not provide specific service SLA metrics. The terms of service of IBM is well organized, and provides the details of security descriptions, data protection, conditions of trans-boarder data flow and information regarding the governing law and jurisdiction . It also provides information on data centre locations.

Exoscale Cloud: Exoscale Cloud provides . % availability in all its services . The terms of service are well described and clear. The document is specific on data security (however, it takes less liabilities), data protection and privacy, governing law and jurisdiction, data storage and IPR.

Baremetal Cloud: It provides . % availability unspecific with a cloud service. The SLA and terms of service provided are not sufficient on data privacy or provider's liabilities; however, it provides an information related to physical level security and data centre locations.

Arubacloud: Aruba cloud provides at least . % availability to all cloud services with the exception of % in power and air conditioning . It provides detailed information on the processing of personal data with specific applicable law, jurisdictions and competency, but it provides the less information regarding the security issues from a technical point of view. It also provides an information related to data center locations and service monitoring details.

Softlayer Cloud: It does not provide a SLA commitment specific to particular services. In its SLA agreement document, it uses the sentence "SoftLayer will use reasonable efforts to provide a service level of % for the public/private network...", but it guarantees a service credit for more than two hours . It is not clearly mentioned how this is provided; however, it agrees to maintain reasonable and appropriate measures related to physical security to protect user content . The document is specific on data protection and privacy, governing law and jurisdictions. It also provides the geographical locations of data centres.

Vaultnetwork Cloud: The Vault network Cloud endeavours to have service(s) available for access by any party in the world . % of the time . The document provided does not detail security, data privacy and protection issues. It is specific on governing law and jurisdictions.

CloudCentral: It commits . % uptime commitment to infrastructure services . The terms and conditions are clear in liabilities, governing law, and IPR, but there is not sufficient information on data privacy and physical security.

It is worthwhile to mention that cloud users still believe current contracts are not fair and remain favourable towards the CSPs. We identify here some major missing points in current cloud contracts, which can be helpful to improve the fairness and transparency of the cloud contracts. Four specific issues follow:

. Lack of Liabilities and Indemnity Most of the providers state their entire liability according to the charge paid by the user or a maximum amount. This could be considered to limit or exclude the legal rights of the user under some laws (for instance, under EU law it is considered to be an unfair contract [ ]) . Consent for the Collection and Processing of Personal Data for Secondary Non-Compatible Purposes Information that is collected from cloud users for the internal purposes of the CSPs, and gathered by them, such as billing or management of the cloud services, will belong to the CSPs [ ]. However, this information should not be used for the unfair advantage. In our analysis, most of the providers do not mention theses issues in their terms of service, but some providers still use this information for other purpose without seeking the particular consent from the data subject [ ].

. Lack of Transparency

As we already discussed, there is a lack of a standardized format and terminology of cloud contracts in cloud computing. Cloud providers prefer to include terms according to their feasibility in the proposed terms of service and SLA. Unclear, and sometimes unfair, terms of service in the cloud contract misguide the rights of cloud users in contract breaching. The lack of a clear monitoring technique in the SLA, hidden payment obligations, and automatic renewals can occur due to unclear terms of service in the cloud contract. . SLA agreement a. Lack of Service Monitoring The user pays as per usage in terms of cloud computing. So, service credit and other claims will be authorized according to the SLA agreement. Many of the contract terms do not mention about the methods of service monitoring. SLA monitoring has become a challenging issue, because it has been observed that all the cloud service providers may not provide services to the user according to their SLA commitments [ ]. b. Disaster Recovery In the most of the contract documents, how CSPs manage disaster recovery of the services is not clear. A well-managed disaster recovery plan is a very significant criterion for users who desire to select an appropriate CSP. c. Location of Data In our observation, many of the CSPs provide information related to data centre locations on their website. Cloud users can choose an appropriate location according to their requirements, but this information is not still part of the terms of service and SLA. d. Data portability, Data irretrievability Very few CSPs provide the information related to data portability and irretrievability. Cloud users should be easily able to retrieve their data if they prefer to switch to another CSP due for any reason.

Sometimes, it is hard for most of the cloud users to follow these points, since they are not aware of the existing legal framework or they do not have sufficient legal knowledge to follow the legal framework. In the next section, we propose how a performance evaluation technique (called the Heat Map technique) can be implemented to check the regulatory compliance status of the CSPs. The Heat Map table (second of the two tables) gives complete information on the regulatory compliance status of the CSPs in a visualized form. the regulatory compliance status of the CSPs. Information on service performance status, including regulatory compliance status, facilitates cloud users in their decision making to choose appropriate CSPs according to their requirements.

The main motivation of our paper is analyzing the regulatory compliance status of the CSPs. We assign a corresponding ordinal level according to the fair and transparent contract document that the CSPs' have committed to the users (see We assign to ordinary levels according to the detailed specification provided in the SLA document, terms of service and so on. If there is not any information provided, we assign 'NA' in that particular parameter. -"Available, complete and included all the points", -"Available, sufficient and missing some points", -"Available, insufficient and missing some points", -"Available, insufficient but not clear points" 'NA' -"Not Available".

We assign corresponding ordinal level according to fair and transparent contract document they have committed to the users (see Table ). The proposed visualized table gives an idea to cloud users, cloud service brokers, and regulatory bodies of just how CSPs are aware of regulatory compliance in contractual terms in cloud computing. The first row in the Table states the criteria of the evaluations. The second row represents the weight of the criteria. However, since different weights can be assigned to the evaluation according to the evaluator requirements, we have assigned an equal weight in each sub-criterion by considering that all criteria are equally important. The tau value represents the dominancy level of sorting (for instance . is the dominancy level in this case). However, none of the CSPs provide sufficiently complete information to make a safe and fair contract, although cloud providers Amazon, Google Cloud Storage and Microsoft Azure give more information in their contract document than other cloud providers in selected cloud providers in this regulatory compliance analysis (See Table ). The ordinary levels and heat map tables presented in this section are only for explanatory purposes (see for example, Table ) and should not be considered in any case as conclusive because expressing legal issues using quantitative value is not straightforward. It is worthwhile to mention here that this paper is only concerned with the transparency levels of the providers in terms of their contract document available on their website according to the current legal framework and does not check the service performance level of CSPs.

Concluding Remarks

A cloud contract is the most important legal binding document in cloud computing, which ensures fair and safe to all parties before delivering or receiving services. Obviously, it is not possible to cover all the terms and conditions in a cloud contract document, but any contract should nevertheless be clear enough to, and fair for all, the parties involved in the agreement. The cloud contracts currently committed to by CSPs do not seem to be sufficient as fair, safe and transparent cloud contracts. The available literature, the recommendations of different independent bodies, and an analysis of the terms of service and SLA agreements committed to by CSPs, show that cloud users are still not convinced about current cloud contracts. The heat map table presented in this paper gives the current position of CSPs according to their regulatory compliance status in their contract documents. A pictorial table of this information, committed to by the CSPs, helps cloud users in their decision making to choose an appropriate CSP according to their requirements. It also helps cloud service brokers to recommend CSPs according to users' needs. Potential future work includes an implementation of the proposed heat map technique in the SLA assured service brokering framework [ ], which covers both service performance status and regulatory compliance status when recommending services to users.

  Kousiouris et al. [ ] and Casalicchio & Palmirani [ ] have introduced legal compliance checking capabilities in cloud brokering but does not consider the service performance compliance in recommending cloud services to the cloud users. Wagle et al. [ ] and [ ] have proposed evaluation techniques to evaluate the performance of the CSPs. But, these papers are mainly focused on service performance analysis of cloud providers.

Figure

  Figure shows our proposed SLA assured cloud service brokering framework. The National Institute of Standards and Technology (NIST)'s cloud reference architecture [ ] has defined specific roles for multiple actors in reference architectures. In the proposed SLA assured cloud service brokering framework, the cloud service broker (CSB) collects the requirements of users with their priority list of cloud services. The CSB then matches the offers of CSPs to provide services to the users according to these priority lists. The service monitoring module monitors the service performance of CSPs including regulatory compliance status of the CSPs. Wagle et. al [ ], [ ] have addressed service verification, service performance evaluation, sorting and ranking based on service performance monitoring, service performance pattern analysis, and pattern prediction for recommending optimal

Figure .

 . Figure . SLA Based Brokering and Service Verification Framework

  Table as criteria and sub-criteria to analyze the regulatory compliance status of the CSPs.Performance Service Level The performance service level includes the availability of the services (uptime, percentage of successful requests, percentage of timely service provisioning requests), response time of the service, capacity parameters (number of simultaneous connections, number of simultaneous cloud service users, maximum resource capacity, service throughput) and support (support hours, support responsiveness, resolution time). Service Level Service reliability, authentication and authorization, cryptography, security incident management and reporting, logging and monitoring, auditing and security verification, vulnerability management and security control governance are the major points to be included in a security service level agreement. Service reliability, which is directly interconnected with the level of redundancy that a CSP can provide at the user authentication and identity assurance level, should be mentioned for authentication and authorization. How a cloud service provider handles information security incidents is of great concern to cloud service users. Incident reporting is also important in security incident management. Logging is the recording of data related to the operation and use of a cloud service. Monitoring means determining the status of one or more parameters of a cloud service. Logging and monitoring are ordinarily the responsibility of the cloud service provider.Data Management Service LevelFrom the security and regulatory point of view, it is necessary to classify data, for example, the user's data, provider's data, cloud service derived data and so on. It is also necessary to include data backup, mirroring and restore, lifecycle of data and data portability with different formats and interfaces in the agreement.

	Security

. Liabilities

Providers try to exclude liabilities altogether or restrict liabilities as much as possible because they provide commoditized services [ ]. It is also true that it is not always practical to expose the CSPs to unlimited liabilities for a small deal.

Liabilities of data loss of Infrastructure as a Service (IaaS) providers, liabilities for intellectual property rights infringement of software by Software as a Service (SaaS) providers are some examples of conflicting issues mostly between users and providers [ ].

. Service Level Agreement

A SLA is a documented agreement between the cloud service provider and cloud user that identifies services and cloud service level objectives (SLOs). It should include minimum level objectives that CSPs can provide to the cloud users and details about what happens when the CSP has failed to provide agreed minimum level objectives. The C-SIG-SLA has defined a set of SLA standardization guidelines for CSPs and professional cloud users, while ensuring the specific needs of the cloud market and industry are taken into account. This document is specifically targeted at the European cloud market. We highlight some major points, which are important to be included in a SLA agreement:

Table .

 . Criteria and sub-criteria for evaluating cloud services

	Criteria	Sub-criteria	Short Name
	Liabilities	Liabilities	Li
	Performance Service Level	Availability	Av
		Response Time	Res
		Capacity	Cap
	Security Service Level	Service Reliability	Rel
		Authentication and Authorization	Au
		Security incident mgmt	inc
		Reporting	Rep
		Logging	Log
		Monitoring	Mon
	Data Management Service Level	Data Classification	Dcls
		Data Backup, Mirroring and Restore BMR
		Data Lifecycle and Portability	DLP
	Personal Data Protection Service Level Code of Conduct	Ccon
		Purpose of Specification	Pspec
		Openness, transparency and notice OTN
		Accountability	Acc
		Geographical Location of user data DL
	Provider Lock-in and Exit	Lock-in	In
		Exit	Ex
	Terms and conditions	Terms and conditions	TC
	Changing Service Features	Changing Service Features	CS
	Intellectual Property Rights (IPR)	IPR	IPR
	.

Pictorial Analysis of CSP's Contracts in Ordinary Values A

  SLA assured service brokering framework is proposed in [ ]. This framework recommends the cloud services to the user that have a verified service performance delivery against the SLA commitments of CSPs. Wagle et al. [ ] and [ ] proposed evaluation techniques to evaluate the service performance of the CSPs. These two papers are mainly focused on service performance analysis of the CSPs. In cloud computing, specifically in a public cloud scenario, regulatory compliance management is also critical issue as the cloud users outsource data processing and storage to CSPs that can be under legislation/regulation [ ]. Casalicchio and Palmirani [ ] have introduced a conceptual framework for legal compliance checking in cloud brokering, but the framework does not give a clear picture of

  Table.We then implement a Heat Map technique [ ], [ ], [ ] proposed for service performance evaluation to evaluate the regulatory compliance status of the cloud providers. Using this Heat Map technique, potential CSPs are sorted into marginal performance quantile classes to rank the CSPs with multiple performance criteria in increasing order or decreasing order [ ]. Performance quantile class is associated with the colours ranging from dark red (worst) to dark green (best) for the performance heat map visualization (See the colour legend for the 7-tiles in Table). We have considered the major parameters described in section of this paper. All the information is taken from the CSPs' websites. The developed heat map table offers a graphic display, which shows to what extent CSPs are accepting regulatory compliance in their contractual documentation.

Table .

 . Pictorial View of Cloud Contracts offered by International CSPs

  . S. S. Wagle, M. Guzek, P. Bouvry, and R.Bisdorff. An Evaluation Model for Selecting Cloud Services from Commercially Available Cloud Providers. In IEEE th International Conference on Cloud Computing Technology and Science (CloudCom), pages -, Nov . . Shyam S. Wagle. SLA Assured Brokering (SAB) and CSP Certification in Cloud Computing. In Utility and Cloud Computing (UCC), IEEE/ACM th International Conference on, pages -, Dec . . Shyam S. Wagle, Mateusz Guzek, and Pascal Bouvry. Cloud Service Providers Ranking Based on Service Delivery and Consumer Experience. In th IEEE International Conference on(CloudNet), pages -, Niagara Falls, Canada, October . . W.K.Hon, Christopher Millard, and Ian Walden. Negotiating Cloud Contract: Looking At Clouds From Both Sides Now. Standford Technology Law Review, .

http://ec.europa.eu/justice/data-protection/reform/index-en.htm http://eur-lex.europa.eu/legal-content/ http://ec.europa.eu/justice/data-protection/article-/documentation/opinionrecommendation/files/ /wp -en.pdf

https://ec.europa.eu/digital-single-market/en/news/cloud-service-level-agreementstandardisation-guidelines

https://www.cloudindustryforum.org/search/site/CIF https://azure.microsoft.com/en-us/support/legal/sla/summary/

https://www-.ibm.com/software/sla/ https://www.exoscale.ch/terms/ https://www.baremetalcloud.com/legal-terms https://www.arubacloud.com/company/general-conditions.aspx http://static.softlayer.com/sites/default/files/sla.pdf http://static.softlayer.com/sites/default/files/assets/page/Terms-of-Service.pdf https://www.vaultnetworks.com/about/company-policies/terms-of-service/ https://www.cloudcentral.com.au/sla/ https://www.cloudcentral.com.au/terms-and-conditions/

Acknowledgements I would like to thank the LAST-JD programme for financially supporting to perform this research. I am also thankful to Prof. Dr. Pascal Bouvry and Prof. Dr. Raymond Bisdorff for their valuable suggestions in preparing this paper.

privacy and security issues in the terms and conditions document is not clearly detailed .

GMOCloud: GMO Cloud offers at least . % monthly uptime for all cloud services. The SLA document offered by GMO is not a service-specific commitments. It provides details of security & backup, and IPR; however, it is silent on data privacy and governing law. The terms of service place the liability on the cloud users to protect their own privacy . It provides detailed information of data centre locations.

HP Cloud: The SLA offer of HP Cloud ranges from at least . % to % in a specific cloud service. There is a limited information of data privacy and security in its terms of service. Detailed information of the SLA and terms of service are not easily available, as the company is not planning to expand its public cloud services further.

Amazon: Amazon provides various cloud services, however, Amazon S and Amazon EC are its most popular cloud services. It offers at least . % uptime for both S and EC services. It provides a well organized contract agreement for specific services , . The contract agreement offered contains detailed information on security and data privacy, governing law and IPR.

RackSpace: Rackspace cloud service provider provides a service specific SLA commitment. Monthly uptime from at least . % to maximum % is offered in its SLA document. It guarantees the user data privacy according to applicable data protection/privacy law . It also provides a detailed information on its global security policy.

Google Cloud: Google Cloud offers a service specific SLA. It ranges from at least . % to % monthly uptime based on the service offer. It covers most of the important terms in its terms of service. Data processing, security terms, compliance with different regulatory frameworks, governing law and jurisdiction are all covered in the agreement . The SLA monitoring issues are still not clear, however, in the commitment document. According to the document, it is possible to choose data centre according to users' preferences in different locations.

City Cloud: City Cloud offers a SLA commitment of at least % monthly uptime in all its services, irrespective of the specific cloud services. It does not provide detailed terms of service related to security and data privacy, governing