Daniel Bosk
email: dbosk@kth.se

Sonja Buchegger

Privacy-Preserving Access Control in Publicly Readable Storage Systems

Keywords: Privacy, Access Control, Cloud Storage, Decentralized Storage, Hidden Policies, Hidden Policy-Updates, Hidden Credentials

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

Introduction

Alice and her friends want to communicate asynchronously. To do this they want to use a publicly available file system and write their messages to different files, which the other party later can read. This is a possible architecture for a decentralized online social network (DOSN). We are interested in enforcing access-control policies in such a public file system which does not have any builtin access control mechanisms. Our approach is to introduce a layer of encryption as a logical reference monitor. Beyond the expected confidentiality, Alice wants some stronger privacy properties as well: her friends should not be able to monitor her activity, e.g. infer with whom else she communicates, even the fact that she communicates with others.

We will present an ideal model of communication and its desired properties in Section 2, this is what we want to achieve. Then we will present the building blocks that we will use, and their accompanying assumptions, in Section 3. We will also assume a simple file system with no built-in access control. This system is discussed and defined in Section 3.1. This includes our adversary model: we will let the adversary control the file system.

Then we give two constructions that implement the functionality using different message-passing models and analyse what properties their primitives must have in Sections 4 and 5. The two message passing models are called the pull model and the push model. In the pull model Alice's friends pull new messages from Alice, whereas in the push model Alice pushes new messages to her friends' inboxes. The motivation is that the pull model is optimized for Alice and the push model for Alice's friends. In a decentralized file system the pull model yields few connections for Alice, but many for her friends (if they have more friends than Alice). Conversely the push model yields many connections for Alice, but only one for her friends (they check their inbox). In some situations connections can be expensive, cf. establishing many Tor [START_REF] Dingledine | Tor: The Second-Generation Onion Router[END_REF] circuits to transfer little data and establishing one circuit to transfer more data.

After presenting our constructions we shortly analyse their algorithmic complexity in Section 6. Finally we compare our results to related work in Section 7 and conclude by summarizing the main contributions and future work in Section 8.

The Ideal Communication Model

There are several ways Alice can implement the message passing with her friends. We will start by presenting an ideal model of communication (Definition 1) whose properties Alice wants to achieve. Then we will proceed to the details of two alternative protocols (Definitions 4 and 6) that yields the properties of the ideal model.

Definition 1 (Communication model). Let C p,S be a (p, S)-communication model with a publisher p and a set of subscribers S. Then we have the following operations defined on C p,S :

-The publisher first runs C p,S [p].setup 1 λ and each subscriber s ∈ S runs C p,S [s].setup 1 λ , where λ is the security parameter. -The publisher p uses C p,S [p].publish(R, m) to publish the message m to the designated recipient set R by making it available to all recipients r ∈ R ⊆ S. -Each subscriber s ∈ S uses C p,S [s].get() to get the set M of published messages m ∈ M for which s was in the recipient set.

Whenever p, S are clear from the context, we will simply omit them, e.g.

C[p].setup and C[s].setup.

There are two ways the adversary can gain information. The first is from corrupted subscribers and the second is from the public file system over which the communication model is implemented. Hence the second is not visible in Definition 1, but will be in Definitions 4 and 6.

In our desired scenario, Alice acts as a publisher and her friends as the subscribers. We want the following properties:

Message privacy No subscriber s ∈ S can use C[s].get for s = s. I.e. no subscriber can read the messages of any other subscriber, we call this property message privacy.

Hidden policies

No subscriber s i must learn which s 1 , . . . , s n ∈ R beyond that i ∈ {1, . . . , n} and s i ∈ R for a given message m. I.e. no subscriber must know who else received a message, we call this property hidden policy. Thus if Alice publishes a message, none of her friends know who else received it and none can read the others' received messages to check if they have received the same message. Hidden policy-updates In addition to the hidden-policy property, we want something we call hidden policy-updates. Consider the following example: Bob might become jealous if he realizes that Alice no longer includes him in the recipient set for her messages. As such Bob should only be able to determine that Alice publishes content by being in the recipient set himself.

There are several ways to implement the message-passing protocol for the communication model in Definition 1. We will focus on two alternative protocols, one using the pull model and the other using the push model for communication. The push model is analogous to the subscription of magazines: a subscriber contacts the publisher and signs a subscription, whenever the publisher issues a new magazine it sends a copy to the subscriber's mailbox. The pull model is the converse of the push model. It is analogous to the selling of magazines in kiosks: the publisher issues magazines and the 'subscribers' come to the kiosk and buy them whenever they want. We can see that our ideal communication model allows both a pull and push strategy for implementation. We will describe and analyse the pull construction in Section 4 and the push construction in Section 5. But first we need to review our needed building blocks.

Building Blocks

We will now describe the primitives and our assumptions upon which we will base our constructions. We start with a general file system, which is publicly readable and has no built in access control. We then describe the general cryptographic primitives we need and finish with the anonymous broadcast encryption (ANOBE) [START_REF] Libert | Anonymous broadcast encryption: Adaptive security and efficient constructions in the standard model[END_REF] scheme which we will use for part of our construction.

A General File System

We will model our system as an abstract file system with the operations append (which includes create) and read. The operations are defined as we intuitively expect: we can create an object, read it and also append to it. The file system itself provides no access control. Definition 2 (Public file system). A file f = (i, m i ) consists of the identifier i and the associated content m i . We define the set of files F = {(i, m i )} together with the following operations to be the public file system FS:

-FS.append(i, m i ) will set (i, m) ← (i, m m ) for (i, m) ∈ F . If {(i , m ) ∈ F | i = i} = ∅, i.
F ← F ∪ {(i, m i )}. -FS.read(i) = m i if (i, m i ) ∈ F , otherwise FS.read(i) = ⊥.
We can see in the definition that anyone can read any object in the file system. Anyone can also create new files and append to existing files.

We will let the adversary Eve operate the file system FS defined in Definition 2. By this we mean that Eve has access to the internal state of FS directly, i.e. the set of files F . She can thus read all files (same as everyone else), but she can also do arbitrary searches since she does not have to use FS.read.

Although Eve could potentially also modify or delete the files, we do not treat denial-of-service attacks by Eve deleting the files. However, as we will see in our constructions, modifications (but not deletions) made by Eve will be detected.

Eve cannot distinguish between Alice's and Bob's requests to the operations of FS -in the definition there is nothing to identify who used any of the operations, so this is consistent with the definition. What she can do, is to record the times at which the operations occurred, since she executes them.

This adversary would correspond to a centralized setting, e.g. having the file system hosted by a cloud operator, or a decentralized setting where the adversary can monitor the network at the file system side.

Cryptographic Primitives

We will use mainly standard public-key cryptography. We need a public-key encryption scheme and two signature schemes. Although we can use shared-key mechanisms in some places, we will maintain a public-key notation throughout this paper and merely point out in the places where a shared-key scheme would be possible.

We will use a public-key encryption scheme E = (E.Keygen, E.Enc, E.Dec). This scheme must be semantically secure under chosen-ciphertext attacks (IND-CCA) and key-private (AI-CCA) [START_REF] Bellare | Key-Privacy in Public-Key Encryption[END_REF], i.e. the ciphertext does not leak under which key it was created. We also need an unforgeable signature scheme S = (S.Keygen, S.Sign, S.Verify).

We additionally need an anonymous and semantically secure (ANO-IND-CCA) [START_REF] Libert | Anonymous broadcast encryption: Adaptive security and efficient constructions in the standard model[END_REF] broadcast encryption (BE) [START_REF] Fiat | Broadcast encryption[END_REF] scheme BE = (BE.Setup, BE.Keygen, BE.Enc, BE.Dec). Let U = {1, . . . , n} be the universe of users. BE.Setup 1 λ , n generates a master public key M P K and master secret key M SK for n users. BE.Keygen(M P K, M SK, i) generates the secret key k Pri i for user i ∈ U . Then BE.Enc(M P K, m, R) will encrypt a message m to a ciphertext c for the set of users R ⊆ U and BE.Dec M P K, k Pri i , c will return m if i ∈ R. Formally we define ANO-IND-CCA by the following game.

Definition 3 (ANO-IND-CCA [START_REF] Libert | Anonymous broadcast encryption: Adaptive security and efficient constructions in the standard model[END_REF]). Let U = {1, . . . , n} be the universe of users and BE be a BE scheme. A BE scheme is anonymous and adaptively IND-CCA (ANO-IND-CCA) if the adversary has negligible advantage in winning the following game.

Setup The challenger runs BE.Setup 1 λ , n , where λ is the security parameter.

This generates a master public key which is given to the adversary A.

Phase 1

The adversary A may corrupt any i ∈ U , i.e. request its secret key k i = BE.Keygen(M P K, M SK, i) through an oracle. Additionally A has access to a decryption oracle to decrypt arbitrary ciphertexts for any i ∈ U , upon request (c, i) the oracle will return BE.Dec(M P K, k i , c). Challenge The adversary chooses messages m 0 , m 1 such that

|m 0 | = |m 1 | and recipient sets R 0 , R 1 such that |R 0 | = |R 1 |. For all corrupted i ∈ U we have i / ∈ R 0 ∪ R 1 \ (R 0 ∩ R 1 ). If there exists an i ∈ R 0 ∩ R 1 we require m 0 = m 1 .
corrupt i / ∈ R 0 ∪ R 1 \ (R 0 ∩ R 1 ). A may corrupt i ∈ R 0 ∩ R 1 only if m 0 = m 1 .
The adversary is not allowed to use the decryption oracle on the challenge ciphertext c * . Guess A outputs a bit b and wins the game if b = b.

We define the adversary's advantage Adv

ANO-IND-CCA A,BE 1 λ = | Pr[ b = b] -1 2 |.
Throughout BE can be any BE scheme with the ANO-IND-CCA property. However, we will use the ANOBE scheme by Libert, Paterson and Quaglia [START_REF] Libert | Anonymous broadcast encryption: Adaptive security and efficient constructions in the standard model[END_REF] as an example in our discussion and modify it for one of our constructions. For our description of this scheme, which follows, we need slight variants of the above encryption (E) and signature (S) schemes. We need an encryption scheme E = (E.Keygen, E.Enc, E.Dec) which is in addition to key-private also robust (ROB-CCA) [START_REF] Abdalla | Robust Encryption[END_REF]. For the signature scheme S = (S.Keygen, S.Sign, S.Verify), we only need it to be a strongly-unforgeable one-time signature scheme.

An anonymous broadcast encryption Scheme

We will now describe the ANOBE scheme by Libert, Paterson and Quaglia [START_REF] Libert | Anonymous broadcast encryption: Adaptive security and efficient constructions in the standard model[END_REF]. We will use ANOBE to denote this scheme. The algorithms work as follows. ANOBE.Setup generates a master public key M P K = (S, {k Pub i } i∈U ) and the master secret key

M SK = {k Pri i } i∈U , where (k Pub i , k Pri i ) ¢ ← E.Keygen 1 λ . ANOBE.Keygen(M P K, M SK, i) simply returns k Pri i from M SK.
An overview of the encryption function is given in Fig. 1 and an overview of the decryption function in Fig. 2.

Encryption We must first generate a one-time signature key-pair (s, v), then we choose a random permutation π : R → R. Next we must encrypt the message m and the verification key (m, v) for every user i ∈ R in the recipient set R ⊆ U under their respective public key, c i = E.Enc k Pub i , m v . We let the ANOBE ciphertext be the tuple (v, C, σ), where C = (c π(1) , . . . , c π(|S|) ) and σ = S.Sign(s, C). Note that the signature does not authenticate the sender, it ties the ciphertext together and is needed for correctness.

function ANOBE.Enc(M P K, m, R) Recipient set R, m to be encrypted. (s, v) ¢ ← S.Keygen 1 λ
Signature key-pair, security parameter λ Choose a random permutation π : R → R. Decryption We now have data which would like to decrypt. We parse it as (v, C, σ). If S.Verify(v, C, σ) = 0, we return ⊥ as the verification failed. For each

for i ∈ R do ci ← E.Enc k Pub i , m v C ← (c π(1) , . . . , c π(|S|) ) σ ← S.Sign(s, C) return (v, C, σ)
c in C: Compute M = E.Dec k Pri , c . If M = ⊥ and M = (m, v), then return m.
Otherwise, try the next c. If there are no more c to try, then return ⊥. To decrypt an ANOBE ciphertext, we need a trial-and-error decryption procedure to decide if the ciphertext was indeed intended for us. This is costly as it makes the decryption function complexity O(|S|). Libert, Paterson and Quaglia [START_REF] Libert | Anonymous broadcast encryption: Adaptive security and efficient constructions in the standard model[END_REF] presented a tag-hint system along with their ANOBE scheme. The tag-hint system reduced the complexity back to O(1). As this is not relevant for our discussion, we refer the reader to [START_REF] Libert | Anonymous broadcast encryption: Adaptive security and efficient constructions in the standard model[END_REF] but note that it can be used.

function ANOBE.Dec(M P K, k Pri , C ANOBE ) if S.Verify(v, C, σ) = 0 then return ⊥ for c ∈ C do M ← E.Dec k Pri , c Try to decrypt if M = ⊥ then return ⊥ else if M = (m, v) then return m return ⊥

Construction and Analysis of the Pull Protocol

In this construction, each publisher has an 'outbox' file in the file system. This is simply a file object with a randomly chosen identifier. The publisher adds new publications to the outbox and subscribers pull new content from the outbox. In our analysis we define the protocol for the pull model as follows.

Definition 4 (Pull Protocol). Let BE be a BE scheme, S be a signature scheme and FS be a public file system as defined in Section 3. We denote by C Pull p,S the pull protocol implementing a (p, S)-communication model through the operations in Fig. 3. When Alice wants to publish a message m to the recipient set R ⊆ S, she runs C Pull [p].publish(R, m). This operation creates a BE ciphertext and Alice appends the ciphertext to her outbox file. Each friend can then use C Pull [s].fetch to retrieve the ciphertexts from the file system and decrypt them.

function C Pull p,S [p].setup(1 λ ) ip ¢ ← {0, 1} λ (sp, vp) ¢ ← S.Keygen 1 λ (M P K, M SK) ¢ ← BE.Setup 1 λ , |S| for s ∈ S do k Pri s ← BE.Keygen(M P K, M SK, s) Give (k Pri s , vp, ip) to s. function C Pull p,S [p].publish(R, m) c ← BE.Enc(M P K, R, m) σ ← S.Sign(sp, c) FS.append(ip, c σ) function C Pull p,S [s].setup(1 λ ) Receive from p. function C Pull p,S [s].fetch C = FS.read(ip) M ← ∅ for (c, σ) ∈ C do if S.Verify(vp, c, σ) = 1 then Continue with next. mc ← BE.Dec M P K, k Pri s , c if mc = ⊥ then M ← M ∪ {mc} return M
Note that we can have symmetric authentication, e.g. replacing S with a message-authentication code (MAC) scheme, although we use the notation of asymmetric authentication. This would yield different privacy properties, i.e. we remove the non-repudiation which S brings. However, this is not at the centre of our discussion, it just illustrates the modularity of the scheme.

We wanted no recipient to know who else received the message, the ANO-IND-CCA property of the BE scheme gives us exactly this. So we achieve the hidden policy that we wanted.

However, we cannot immediately achieve the hidden policy-update property. Bob can read Alice's outbox, conclude that there are entries which he cannot decrypt and thus he can become jealous. In Fig. 3 we see that Bob can count the number of ⊥ in the output of C Pull [ • ].fetch. One approach to prevent this is that Alice uses a unique outbox per friend, so Bob has his own outbox. This actually reduces the problem to our push construction, which we will cover later. We will instead analyse a simpler solution for the pull protocol now.

Changing Recipient Set in the Pull Protocol

We will now propose and analyse a solution to the problem of hidden policyupdates, i.e. Jealous Bob. This solution, however, is based on the intricacies of the ANOBE construction, and thus require us to use ANOBE. In essence, the ANOBE construction, described in Section 3.3, allows us to create a ciphertext which decrypts to different messages. 1 We will use this to encrypt a special message that updates the outbox identifier i p . Half of the recipients will receive i p and the other half will receive i p . We summarize this algorithm in Fig. 4. Alice could divide her subscribers into an arbitrary number of parts, even |S| for having each subscriber in their own group. But for simplicity we describe the algorithm for dividing the subscriber set into two parts.

function SplitGroup(M P K, S0, S1)

Recipient sets S0, S1 such that

S = S0 ∪ S1 and S0 ∩ S1 = ∅. i0 ¢ ← {0, 1} λ , (s0, v0) ¢ ← S.Keygen 1 λ
Generate new outbox and key-pair.

i1 ¢ ← {0, 1} λ , (s1, v1) ¢ ← S.Keygen 1 λ
One per new group. (s, v) ← S.Keygen 1 λ

One-time signature-verification key-pair. Choose a random permutation π : S → S.

for s ∈ S do if s ∈ S0 then cs ← E.Enc k Pub s , i0 v0 v else s ∈ S1 cs ← E.Enc k Pub s , i1 v1 v C ← c π(s) s∈S
Put all subciphertexts in random order. σ ← S.Sign(s, C) return (i0, s0), (i1, s1), (v, C, σ) We note that this solution does not hide the fact that Alice updated her policy, we just hide from Bob whether he was excluded or not. When Bob get jealous he goes to Eve to ask her help, this means that we must prevent Eve from learning how Alice changed her policy too -the construction is also secure against this strong adversary.

The property we want from this algorithm is that Bob cannot determine how the subscribers are divided. Thus he cannot know whether he is removed or not. This follows from the ANO-IND-CCA property of the ANOBE scheme. We refer the reader to the proof of Thm. 1 in the full version of [START_REF] Libert | Anonymous broadcast encryption: Adaptive security and efficient constructions in the standard model[END_REF]. Now we know that Bob cannot distinguish whether everyone in the recipient set received the same message or not. We will add the split-group algorithm (Fig. 4) as an extension to the pull protocol of Definition 4 and we summarize this as the Extended Pull Protocol in the following definition.

Definition 5 (Extended Pull Protocol). Let C Pull p,S be an instance of the Pull Model as in Definition 4. Then we define the Extended Pull Model to additionally provide the interfaces in Fig. 5. .publish interface and let it keep track of the different groups (instances) in the state, this would make it more similar to the definition of the ideal model (Definition 1). However, for presentation purposes, many simpler algorithms are better than fewer that are more complex.

function C Pull p,S [p].split(R0, R1) (i0, s0), (i1, s1), C ← SplitGroup(M P K, R0, R1) σ ← S.Sign(sp, C) FS.append(ip, C σ) return C Pull p,R 0 , C Pull p,R 1 function C Pull p,S [s].fetch C = FS.read(ip) M ← ∅ for (c σ) ∈ C do if S.Verify(vp, c, σ) = 1 then Continue with next. mc = E.Dec k Pri s , c if mc is new identifier then (ip, vp) ← mc else M ← M ∪ {mc} return M
On the subscribers' side, due to the construction of C Pull p,S [s].fetch, their instance C Pull p,S is automatically turned into C Pull p,Ri , for whichever i ∈ {0, 1} Alice put them in.

Running Multiple Pull Instances in Parallel

Now it remains for us to convince ourselves that Bob cannot distinguish between different instances of the pull protocol: i.e. Alice posting to two both R 0 and R 1 or Alice posting to R 0 and Carol to R 1 .

We will use an information-theoretic argument. We can see that C Pull p0,S0 is information-theoretically independent from both C Pull p1,S 0

Construction and Analysis of the Push Protocol

The idea of the push model is for each subscriber to have an inbox in the file system -as opposed to the pull model, where the publisher has an outbox. This is simply a file object with a randomly chosen identifier. The publisher then puts all published material in the inbox of each subscriber.

We can see that if we simply put the broadcast ciphertext from the pull protocol in all inboxes, then Eve can relate them since they contain identical ciphertexts. We thus have to make some more modifications. We will use the protocol in the next definition in our analysis.

Definition 6 (Push Protocol)

. Let E = (E.Keygen, E.Enc, E.Dec) be an AI-CCA encryption scheme, S = (S.Keygen, S.Sign, S.Verify) be a strongly unforgeable signature scheme, and FS be a public file system. We denote by C Push p,S the push model protocol implementing a (p, S)-communication model through the operations in Fig. 6.

When Alice executes C Push [p].setup it generates a signature-verification keypair (s r , v r ) for every subscriber r ∈ S and gives the respective verification keys to each subscriber. Each subscriber r ∈ S, when they execute C Push [s].setup it generates a public-private key-pair. Additionally they randomly choose a string as an identifier for their inbox. They give the public key and the identifier to Alice.

When Alice wants to send a message m to a subset R ⊆ S of her subscribers, she uses C Push [p].publish to create a ciphertext c r with signature σ r for each recipient r ∈ R. Then she uses FS to append c r σ r to the file with identifier i r . The operation C Pull [r].fetch works similarly as in the pull protocol, however, it uses a different file. It starts by reading the inbox from the file system. Then it iterates through the list of entries, decrypting each entry. Each entry, if successfully decrypted, is a new message. It appends the message to the list of messages which it returns upon finishing.

Note that, similarly as for the pull protocol, the authentication scheme S can be symmetric. Here, the encryption scheme E can also be a symmetric-key scheme, provided it is key-private. We can simply let k Pub = k Pri and s = v to achieve this. This would yield private group communication with few key exchanges. However, we use the notation of public-key cryptography in our abstraction. This makes the push protocol modular as well. Before we continue our analysis of what Eve can do against the push protocol, let us first look back at the pull protocol. Imagine that Eve gets access to a publication oracle for an instance of the pull protocol, and remember that she controls the entire file system. It is not hard to convince ourselves that Eve cannot learn anything more from the file system than she can from the ciphertext alone (when playing the ANO-IND-CCA game): each publication just appends the new ciphertext to the same file in the file system -no matter how she changes the recipient set.

function C Push p,S [r].setup(1 λ ) r ∈ S (k Pub r , k Pri r ) ¢ ← E.Keygen 1 λ ir ¢ ← {0, 1} λ Give (k Pub r , ir) to p. function C Push p,S [r].fetch r ∈ S C ← FS.read(ir) if C = ⊥ then return ∅ M ← ∅ for (c, σ) ∈ C do if S.Verify(vr, c, σ) = 1 then Continue with next. mc ← E.Dec k Pri r , c if mc = ⊥ then M ← M ∪ {mc} return M
Let us now look at what Eve can do in the push protocol. Here she can actually learn information by observing the file system. Whenever a message is published she learns which inboxes are used to get messages from the publisher, thus she can relate several inboxes. Hence, the security analysis of this protocol is only interesting when the protocol is run in parallel.

Running Multiple Push Instances in Parallel

There is one issue we must consider before continuing our discussion of the security of the push protocol. For the security discussion to make sense we must first, as for the pull protocol, convince ourselves that Eve cannot distinguish between parallel instances of the push protocol. Thereafter we can continue our discussion of the security of the push protocol run in parallel.

We will give an information-theoretic argument for the indistinguishability. Each encryption in Fig. 6 depends on the following: the public key of the recipient, the signature key for the authentication, and the message. Both the public key and the signature key is unique per recipient and instance. It follows that two encryptions of the same message are equally likely done within the same instance as in two different instances. This follows from the security of the encryption scheme E. Thus, Eve's only chance is to decide from the ciphertexts that they contain the same message, but since E provides IND-CCA security this is possible only with negligible advantage. Now we know that it makes sense to talk of the security when running parallel instances. Assume that we run n instances of the push protocol in parallel. It is not too difficult for Eve to distinguish which inboxes are related. Eventually one instance will publish when no other instance is publishing. Then that instance can be distinguished from others when publishing at the same time, hence Eve can learn more and more over time -even without using anything like the publication oracle mentioned earlier. To deal with this problem, we will introduce a mix-net.

Definition 7 (Mix-net). Let m 1 , . . . , m k be messages from senders 1, . . . , k. A mix-net is a functionality M such that on inputs m 1 , . . . , m k the outputs

M[1](m 1 ), . . . , M[k](m k ) are unlinkable to its senders. More specifically Pr[i | M[i](m i )] = Pr[i] = 1 k .
We note that by definition the mix-net will not output anything until the last input slot has received input.

We will now assume that the calls to FS in the push protocol (Fig. 6) are replaced with

M w [ • ](FS.append( • , • )) and M r [ • ](FS.read( • ))
, where M w and M r are two mix-nets for writing and reading operations, respectively. The input slots are unique to each instance of the push protocol, instance i has input slot

M[i]( • ).
Remember that the inbox identifier is randomly chosen, this means that the probability for an inbox being used by two instances is low (≈ 1/2 λ/2 ). Without the mix-net Eve can also distinguish which inboxes are related by looking at the distribution of messages in the files in the file system. It is unlikely in practice that the behaviour of all publishers will be uniform, so Eve will eventually learn the related inboxes. However, due to the assumed mix-net, it will enforce a uniform number of messages, n messages in yield n messages out. There are mix-nets that add dummy messages to improve throughput -which will be needed for efficiency reasons -but we refer to that literature for a discussion on its security.

Another technique to distort the distribution is that each subscriber can reuse the inbox across instances for different publishers -this is actually desirable for the push protocol also for efficiency reasons, the subscriber has only one inbox for all publishers. However, this allows the publisher to determine that a subscriber subscribes to other publishers, i.e. a scenario related to Jealous Bob, but this time a Jealous Alice. This in turn can be solved by adding noise to each inbox, thus making real messages indistinguishable from noise. A more efficient solution would be for Bob to share an inbox with an unknown other subscriber. Bob can pick an inbox which already contains messages and use the same identifier. This would make fetching new messages less efficient, but will reduce the amount of noise needed.

Finally we note that if Eve did not control the entire file system, she would not be able to relate inboxes that are not in the part she controls. She would be able to read them, but the accuracy of her timing attacks would be reduced to how often she could read the files to detect change. She could still do the message distribution attacks though. This change of the adversary takes us from a potentially centralized setting to a distributed setting where there is no network wide adversary, but an adversary controlling only a part of the network of the file system nodes.

Algorithmic Complexity

We will now summarize the algorithmic complexity for our constructions. The performance is interesting to evaluate from two perspectives: the publisher's (Alice in all examples) and the subscriber's (Bob in all examples). From the publisher's perspective, it is interesting to investigate the needed space for key storage, communication complexity for publication and time complexity for encryption of new material. From the subscriber's perspective, the complexity of key-storage size and the time-complexity of aggregating the newest published messages are the most interesting aspects. An overview of the results is presented in Table 1. The space complexity for the key management is the same for both the pull and push protocols. If we have |S| subscribers, then we need to exchange and store O(|S|) keys: we need one public key per friend.

The space complexity for the ciphertexts are O(|R|) for both models. However, the pull protocol is slightly more space efficient since we need less signatures. In the push protocol we require one signature per ciphertext, i.e. O(|R|), whereas for the pull protocol we only need one per message.

The time complexity for encryption depends on the underlying schemes. But we can see that in the push protocol we get a factor |R| to that of the encryption scheme, whereas we have a constant factor in the pull protocol. The time complexity for decryption on the other hand has a constant factor for both models.

Finally, we look at the communication complexity for the different protocols, which differ slightly. If we look at one single instance, then we get a constant number of connections for the subscribers. However, most subscribers will have to pull from several publishers, this is the argued benefit of push model of communication -there is only one inbox to read.

Related Work

Harbach et al. [START_REF] Harbach | Towards privacypreserving access control with hidden policies, hidden credentials and hidden decisions[END_REF] identified three desirable and (conjectured sufficient) properties for a privacy-preserving access control (AC) mechanism: hidden policies, hidden credentials, and hidden decisions. The work in [START_REF] Harbach | Towards privacypreserving access control with hidden policies, hidden credentials and hidden decisions[END_REF] focused on fully homomorphic encryption and is thus not directly feasible for our purposes. However, the properties are still relevant in our setting.

Hidden policies means that the access policy remains hidden from anyone but the owner and the subjects learn at most if they have access or not. This is the same definition as we used above, and we arguably achieve this property in both of our constructions. Furthermore, we also achieve what we call 'hidden policyupdates' as well (Jealous Bob), which prevents previously-authorized subjects from determining whether they are no longer authorized to access newer versions.

Hidden credentials means that the subject never has to reveal the access credentials to anyone. In our case this is a cryptographic key, and as a consequence we allow the subject to anonymously read the ciphertext from the storage node. This means that the storage node cannot track which subjects are requesting access to which objects.

Hidden decisions means that no-one but the subject must learn the outcome of an access request. This means that no-one should learn whether or not a subject could decrypt the ciphertext or not. However, if everyone only requests ciphertexts that they know they can decrypt (which is the most efficient strategy), then the storage operator can easily guess the decision. Most constructions probably suffer from this, including ours. This decision together with non-anonymized users would allow the storage operator to infer parts of the policy, hence breaking the hidden policy property. To prevent this subjects could also request ciphertexts they cannot decrypt (dummy requests of private information retrieval). However, anonymous requests makes this a less relevant problem.

There is also related work in the DOSN community. There are several proposals available for DOSNs, e.g. DECENT [START_REF] Jahid | DECENT: A decentralized architecture for enforcing privacy in online social networks[END_REF], Cachet [START_REF] Nilizadeh | Cachet: a decentralized architecture for privacy preserving social networking with caching[END_REF] and Persona [START_REF] Baden | Persona: An Online Social Network with User-Defined Privacy[END_REF]. The AC mechanisms in these proposals focus on providing confidentiality for the data. E.g. Persona uses key-policy attribute-based encryption to implement the AC mechanism and unfortunately, this yields lacking privacy: as this is not policy-hiding, anyone can read the AC policies and see who may access what data. There are also general cryptographic AC schemes that focus on achieving policy-hiding ciphertexts, see the section of related work in [START_REF] Harbach | Towards privacypreserving access control with hidden policies, hidden credentials and hidden decisions[END_REF]. E.g. Bodriagov, Kreitz and Buchegger [START_REF] Bodriagov | Access control in decentralized online social networks: Applying a policy-hiding cryptographic scheme and evaluating its performance[END_REF] adapted predicate encryption for the AC mechanism in DOSNs. Works in this area that have employed policy-hiding schemes for DOSNs have also focused on solving the problem of re-encryption of old data upon group changes. We do not solve this problem, but rather contribute the insight that it would violate our desired privacy properties. So besides being more efficient in some cases, less efficient in others, they do not require the same properties.

Conclusions

We achieve privacy-preserving access control enforcement in a public file system lacking built-in access control. We presented two alternatives: the pull and the push protocols. Both implements the model of a publisher distributing a message to a set of subscribers.

The pull protocol achieves strong privacy properties. It essentially inherits the ANO-IND-CCA property of its underlying BE scheme. The subscribers cannot learn who the other subscribers are even if they control the network of the file system or the whole file system. Further, if the publisher wishes to exclude any of the subscribers from future publications, then all subscribers learn that there was a policy update but no one learns what changed -not even those excluded!

The push model for communication is an interesting case. Conceptually, the only difference between the push and pull models is that we distribute the message, instead of everyone fetching it. This seems to yield better privacy properties at first glance, but it turns out that we had to make considerable changes before we could get any security for the push protocol. Hence the security guarantees are much weaker, we have to make some trade-offs. One alternative is that the adversary can only control a part of the file system, or monitor only part of the network, this would make Eve's timing attacks more difficult. Eve can still compute the distributions of messages over the inboxes and relate them, so we need some techniques to make this estimation more difficult. But it is difficult to achieve any guarantees against the distribution attacks, we have to resolve to techniques like differential privacy. However, there are benefits: unlike in the pull protocol, when the subscriber wants to make a policy update, none of the subscribers will even be notified that there has been a policy update -let alone determine if they have been excluded.

As was pointed out in Section 7, we do not treat group management (i.e. revoking the credentials for subjects) as is done in other schemes. If the publisher excludes a subscriber, it is only from future publications -not from past! In fact, we can conclude from our treatment above that such functionality would actually violate the privacy properties. Even if possible, any subject could have made a copy anyway, i.e. it is the problem of removing something from the Web. However, other group changes are easily done, the most expensive one is to give a new subscriber access to old publications -this requires re-encrypting or resending all publications.

An interesting future direction would be to explore Eve's limitations in the push protocol in more detail. For example, under what conditions can Eve estim-ate the message distributions over the inboxes, according to what distributions should the subscribers add noise? This would help us design an efficient scheme that can distort the distributions and guarantee security.

Both protocols are modular enough to provide better deniability, e.g. using a MAC scheme for authentication of messages would remove the non-repudiation property. To let all subscribers, and not only the publisher, publish messages. Another interesting direction would be the opposite: stronger accountability. An example of desired accountability would be that Bob wants to verify that Carol received the same message, if Alice told him that she sent a copy to Carol as well. Due to the privacy properties this is possible in the current protocols.

  Then A gives them to the challenger. The challenger randomly chooses b ∈ {0, 1} and runs c * ← BE.Enc(M P K, m b , R b ) and gives c * to the adversary. Phase 2 The adversary may continue to

Figure 1 :

 1 Figure 1: An algorithmic overview of the encryption algorithm in the ANOBE scheme.

Figure 2 :

 2 Figure 2: An algorithmic overview of the decryption algorithm in the ANOBE scheme.

Figure 3 :

 3 Figure 3: Functions implementing the communication model for the pull protocol. The publisher's interface is to the left and the subscribers' to the right.

Figure 4 :

 4 Figure 4: An algorithm splitting a subscriber set S into two new S 0 , S 1 .

Figure 5 :

 5 Figure 5: The additional and modified interfaces of the Extended Pull Protocol.We assume there exists a coding that can differentiate a file identifier from an ordinary message.

1 1S i 1 ,

 11 are coming from a split, we can see in Fig.4that the two instances only depend on the randomly chosen identifiers and verification keys, and the sets of users. The public keys can remain the same, the key-privacy property of E will ensure this. It follows that C Pull p1Pull p0,S0 is indistinguishable from C Pull p1,for i ∈ {0, 1}. Thus Bob's only chance is by distinguishing who received what new outbox in the split message, but this is difficult given the ANO-IND-CCA property.

Figure 6 :

 6 Figure 6: Functions implementing the communication model for the push model protocol. The publisher's interface is to the left and the subscribers' to the right.

  e. the file i does not yet exist, this operation will create it by setting

  Give vr to r.

	function C Push p,S [p].setup(1 λ )
	for r ∈ S do
	(sr, vr)
	function C Push p,S [p].publish(R, m)
	for r ∈ R do
	cr ← E.Enc k Pub r , m
	σr ← S.Sign(sp, cr)
	FS.append(ir, cr σr)

¢ ← S.Keygen 1 λ

Table 1 :

 1 The storage, communication and time complexities in the two models. S is the set of all subscribers, R is the set of recipients of a message. All values are O( • ).

	Publisher	Pull Push	Subscriber	Pull Push
	Key-storage size |S| |S|	Key-storage size	1	1
	Ciphertext size |R| |R|	Ciphertext size |R|	1
	Encryption	1 |R|	Decryption	1	1
	Communication	1 |R|	Communication	1	1

If this is not possible for a BE scheme under consideration, then there is always the possibility to create a new instance. However, this might be more costly, since it requires a separate secure channel. But we are not bound to the ANOBE scheme, it simply provides some extra convenience in this case.

Acknowledgements This work was inspired by some work with Benjamin Greschbach and work of Oleksandr Bodriagov and Gunnar Kreitz. We would like to thank the Swedish Foundation for Strategic Research for grant SSF FFL09-0086 and the Swedish Research Council for grant VR 2009-3793, which funded this work. We would also like to thank the anonymous reviewers and especially Anja Lehmann for valuable feedback.


Marit Hansen
email: marit.hansen@privacyresearch.eu

Jaap-Henk Hoepman

Meiko Jensen
email: meiko.jensen@rub.de

Stefan Schiffner
email: stefan.schiffner@enisa.europa.eu

Report on the Workshop on Assessing the Maturity of Privacy Enhancing Technologies

Keywords: Privacy, Data Protection, Privacy Enhancing Technologies, PETs, PET Readiness, PET Maturity, Maturity Assessment, Technology Readiness

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

Introduction

Privacy enhancing technologies (PETs) have been demanded by various stakeholders as an important building block for maintaining and improving privacy guarantees in an increasingly computerised world: John Borking and Charles Raab regard PETs as "a promising aid to achieve basic privacy norms in lawful data processing" [START_REF] Borking | Laws, PETs and other Technologies for Privacy Protection[END_REF]. Ann Cavoukian points out that PETs "embody fundamental privacy principles by minimising personal data use, maximising data security, and empowering individuals" and stresses that "PETs can be engineered directly into the design of information technologies, architectures and systems" [START_REF] Cavoukian | Privacy Protection Measures and Technologies in Business Organizations: Aspects and Standards, chap. Privacy by Design: Origins, Meanings, and Prospects for Assuring Privacy and Trust in the Information Era[END_REF].

In 2007 the European Commission stated in a Memo: "The Commission expects that wider use of PETs would improve the protection of privacy as well as help fulfil the data protection rules. The use of PETs would be complementary to the existing legal framework and enforcement mechanisms." [START_REF]Privacy Enhancing Technologies (PETs) -the existing legal framework[END_REF]. However, today's adoption of PETs in practice is low. In the information security realm catalogues of tools, algorithms, and methods exist that support data controllers and developers in choosing the appropriate measures to protect their assets. For privacy and data protection, this work has not been done, yet. A first step can be seen in a report on Privacy and Data Protection by Design published by the European Union Agency for Network and Information Security (ENISA) [START_REF] Danezis | Privacy and Data Protection by Design -from policy to engineering[END_REF], which gives an overview on today's landscape concerning privacy engineering. While the report identifies different maturity levels of PETs, it does not provide criteria on how to assess the individual maturity. All the same, the European General Data Protection Regulation [3] will demand data protection by design (Art. 23 General Data Protection Regulation) which will encompass the usage of PETs.

For this purpose, data controllers and data processors as well as supervisory authorities will have to decide which PETs are considered state-of-the-art and have to be taken into account when designing, implementing, or operating an information system. Also, standardisation bodies, funding organisations, or policy makers may be interested in knowing about the maturity of a PET. This was the starting point for our work on developing a methodology that can provide comparable information on the maturity of different PETs.

We decided not to limit our view on technology readiness levels as introduced by NASA for arbitrary technologies [START_REF] Mankins | Technology Readiness Assessments: A Retrospective[END_REF], because we are convinced that a mere assessment of technology readiness may result in a misleading outcome for privacy technologies if the quality for privacy protection is neglected. Therefore, we aim at assessing individual results for technology readiness and privacy enhancement quality as a second dimension that are combined into an overall PET maturity score.

In a workshop at the IFIP Summer School on Privacy and Identity Management 2015 we presented our interim results and conducted a preliminary evaluation of our methodology with the audience to receive early feedback. This paper describes our approach, the interaction with the audience, and lessons learnt. A final version of the overall results has been published as an ENISA report [START_REF] Hansen | Readiness Analysis for the Adoption and Evolution of Privacy Enhancing Technologies: Methodology, Pilot Assessment, and Continuity Plan[END_REF].

The remainder of the text is organised as follows: After we have briefly introduced related work such as technology readiness levels in Section 2, we present our framework developed for assessing PET maturity, cf. Section 3. The following Section 4 describes the evaluation performed during the IFIP Summer School and its results. Finally, Section 5 summarises our findings.

Related Work

The National Aeronautics and Space Administration (NASA) uses the Technology Readiness Levels (TRL) scale, that ranges from 1 to 9 [START_REF] Mankins | Technology Readiness Assessments: A Retrospective[END_REF]. For the NASA TRL scale guidance reports and TRL Calculators are provided to help gathering the necessary information. The European Commission uses nine Technology Readiness Levels in its funding programme Horizon 2020 [START_REF]European Commission: Horizon 2020 -Work Programme 2014-2015, Annex G. Technology readiness levels (TRL)[END_REF] that are comparable to the NASA TRL scale:

-TRL 1: basic principles observed -TRL 2: technology concept formulated -TRL 3: experimental proof of concept -TRL 4: technology validated in lab -TRL 5: technology validated in relevant environment (industrially relevant environment in the case of key enabling technologies) -TRL 6: technology demonstrated in relevant environment (industrially relevant environment in the case of key enabling technologies) -TRL 7: system prototype demonstration in operational environment -TRL 8: system complete and qualified -TRL 9: actual system proven in operational environment (competitive manufacturing in the case of key enabling technologies; or in space)

Many aspects of the TRL approach have been critically discussed over the last decades, in particular by pointing out limitations and needs for a multidimensional approach [START_REF] Nolte | Did I Ever Tell You About the Whale?, Or Measuring Technology Maturity[END_REF]. Improvements of the process have been proposed for the TRL assessment process [START_REF] Olechowski | Technology Readiness Levels at 40: A Study of State-of-the-Art Use, Challenges, and Opportunities[END_REF]. In particular it has been pointed out that assessing 'readiness' without regarding 'quality' is of limited value, e.g. [START_REF] Smith | An Alternative to Technology Readiness Levels for Non-Developmental Item (NDI) Software[END_REF]. For PET assessment it is questionable whether readiness scores are meaningful without knowledge about the privacy enhancement quality: a wide adoption of a PET with a high readiness score, but unsatisfying protection may prevent the development and deployment of better solutions.

Many privacy researchers are working on determining selective privacy properties of information and communications technologies which shows the current need for expert knowledge in the assessment process. For an overview on relevant criteria we took into account standards related to security properties and quality assessment methodologies, such as ISO/IEC 27004 [START_REF]Information technology -Security techniques -Information security management -Measurement[END_REF], NIST Special Publication 800-55 [START_REF] Chew | Performance Measurement Guide for Information Security[END_REF], Control Objectives for Information and Related Technology (COBIT) [START_REF]ISACA: COBIT 5 for Information Security[END_REF], and the recently released ISO/IEC standard 25010 on Systems and Software Quality Requirements and Evaluation (SQuaRE) [START_REF]Systems and software engineering -Systems and software quality requirements and evaluation (SQuaRE) -System and software quality models[END_REF].

The Assessment Framework

In this section, we present a four-step assessment process and define the scale for readiness as well as the scale for quality. We also point out how the assessment should take place and how the individual results are combined to express the maturity of a PET.

The assessment process

The assessment process consists of four steps (see Figure 1) that are performed by the person responsible for the assessment: the assessor.

First, the assessor properly defines the Target of Assessment (ToA), i.e. the PET in focus. Without clarity on the PET to be assessed, its scope, its boundaries, and its interfaces a meaningful assessment is not possible. of a PET usually have to be assessed separately, e.g. if the running code still lacks some privacy functionality that is conceptualised for a future version. Second, the assessor creates a board of experts whose opinions will be used as input in the assessment process. The experts should be familiar with the domain of application the PET is assessed and/or with privacy engineering. We believe that at least five experts should be involved if possible. Different expert boards likely will have differing results. While reproducibility of the assessment cannot be guaranteed (and exact reproducibility is highly unlikely), the process should be transparent for maximum comprehensibility.

Third, the assessor gathers measurable indicators as well as asks for the expert opinions by means of dedicated forms, consisting of both a scale-based assessment and a detailed opinion comment part.

Fourth, the assessor combines the separate results-a Readiness Score and a Quality Assessment-into the final PET Maturity Level. Further, the assessor compiles the Assessment Report from the collected input as well as the documentation and logging processes.

The involvement of the experts and the combination of their opinions and measurable indicators both for readiness and quality evaluation is illustrated in Figure 2.

The following subsections describe the scales for readiness and quality as well as criteria for their assessment.

A scale for readiness

The intuitive understanding of readiness denotes whether a PET can be considered state-of-the-art, i.e., it can be deployed in practice at a large scale, or whether effort, i.e. time and money, is needed to achieve this goal. On this basis we define the following levels, see also [START_REF] Hansen | Readiness Analysis for the Adoption and Evolution of Privacy Enhancing Technologies: Methodology, Pilot Assessment, and Continuity Plan[END_REF]. idea: Lowest level of readiness. The PET has been proposed as an idea in an informal fashion, e.g. written as a blog post, discussed at a conference, described in a white paper or technical report. research: The PET is a serious object of rigorous scientific study. At least one, preferably more, academic papers have been published in the scientific literature, discussing the PET in detail and at least arguing its correctness and security and privacy properties. proof-of-concept: The PET has been implemented, and can be tested for certain properties, such as computational complexity, protection properties, etc. "Running code" is available. No actual application of the PET in practice, involving real users, exists. Not all features are implemented. pilot: The PET is or has recently been used in practice in at least a small scale pilot application with real users. The scope of application and the user base may have been restricted, e.g. to power users, students, etc. product: The highest readiness level. The PET has been incorporated in one or more generally available products that have been or are being used in practice by a significant number of users. The user group is not a priori restricted by the developers. outdated: The PET is not used anymore, e.g., because the need for the PET has faded, because it is depending on another technology that is not maintained anymore, or because there are better PETs that have superseded that PET.

Note that over its lifetime a PET may have different readiness levels, depending on its evolution. Also, there are transition phases where mixed levels could be appropriate, e.g. a readiness level of pilot/product for a PET that is currently being beta-tested as a (commercial) general purpose product after having been used in some pilots. that allows for utilising the ToA gets obsolete or ceases to exist, or 2) a devastating quality problem of the ToA was revealed, which cannot be fixed.

A scale for quality

The following characteristics for PET quality have been developed from the ISO/IEC system and software quality models standard ISO 25010 [START_REF]Systems and software engineering -Systems and software quality requirements and evaluation (SQuaRE) -System and software quality models[END_REF] with several adjustments. For more information see [START_REF] Hansen | Readiness Analysis for the Adoption and Evolution of Privacy Enhancing Technologies: Methodology, Pilot Assessment, and Continuity Plan[END_REF].

Protection: Protection should be understood as the degree of protection offered (in terms of for example unlinkability, transparency, and/or intervenability) to prevent privacy infringements while allowing access and normal functionality for authorised agents. Also depends on the type of threats and attacks against which the PET offers protection. Trust assumptions: Trust assumptions are characterised by the technical components and/or human or institutional agents that need to be trusted, and the nature and extent of trust that must assumed in order to use the PET. The more components or agents need to be trusted, the lower the score. For example, whether the system assumes an honest but curious adversary, whether the system is based on a non-standard cryptographic assumption, whether it relies on a trusted third party, or whether a trusted hardware component is used. Standard assumptions, for instance that the software and hardware need to be trusted, are out of scope. Note that trust assumptions can also be legal, i.e. a juridical process is a critical part of the protection offered, or organisational, i.e. the protection offered depends on procedural safeguards.

Side effects: Side effects are the extent to which the PET introduces undesirable side effects. These effects include increased organisational overhead due to key management, increased use of bandwidth (without performance impact) due to cover traffic, etc. Assessing side effects depends on the composability, i.e. how easy it is to compose the PET with other components without negatively influencing these components, and on the number and severity of these side effects themselves. Reliability: Reliability is the degree to which a system or component performs specified functions under specified conditions for a specified period of time. It is measured in terms of fault tolerance and recoverability, as well as in terms of the number of vulnerabilities discovered. Performance efficiency: Performance efficiency is the performance relative to the amount of resources used under stated conditions. It is measured in terms of resource use, i.e., storage, computational power, and bandwidth and speed, i.e., latency and throughput. Operability: Operability is the degree to which the product has attributes that enable it to be understood, and easily integrated into a larger system by a system developer. It is measured in terms of appropriateness, recognisability, learnability, technical accessibility, and compliance. Maintainability: Maintainability is the degree of effectiveness and efficiency with which the product can be modified or adapted to underlying changes in the overall system architecture. It is measured in terms of modularity, reusability, analysability, changeability, modification stability, and testability. Open source software typically scores high on this characteristic. Also, systems that have an active developer community, or that have official support, score high. Transferability: Transferability is the degree to which a system or component can be effectively and efficiently transferred from one hardware, software or other operational or usage environment to another. It is measured in terms of portability and adaptability. Scope: The scope refers to the number of different application domains the PET is applied in or is applicable to.

The quality characteristics cannot be automatically assessed in a meaningful way. Instead, expert knowledge is necessary. However, several soft indicators can support the experts: Protection 1) documented protection levels and properties. Trust assumptions 1) documented trust assumptions. 2) described adversarial model. 3) legal measures. 4) organisational measures. Side effects 1) documentation on known side effects. Reliability 1) availability of stress test reports. 2) the number of unsuccessful or successful penetration tests. 3) number of vulnerabilities discovered. Performance efficiency 1) benchmarks or performance figures for storage, computational power, bandwidth, latency and throughput. Operability See maintainability.

Maintainability 1) whether the system is modular in design. 2) whether test suits exist. 3) whether the ToA is open source. 4) availability, extent and detail of documentation. 5) whether an active developer community exists. Transferability 1) list of different software and/or hardware platforms the ToA has been ported to. 2) evidence regarding the amount of work needed to port the ToA. 3) whether the ToA uses general purpose programming languages and build environments, and standard libraries. 4) availability and detail of instructions to port the ToA to other platforms. Scope 1) list of application domains the ToA is known to be applicable to. 2) number of different products serving different markets that use the ToA.

For the quality assessment the experts assign for each of these nine characteristics a score in the following five-value range:

--(very poor) -(poor) 0 (satisfactory) + (good) ++ (very good)

The experts are asked to assign an overarching total quality score on the same scale. The standard calculation would be to combine the nine individual scores with different weights:

-The characteristics protection and trust assumptions have a factor 3 weight.

-The characteristics side effects, reliability and performance efficiency are calculated with factor 2. -For the remaining characteristics, i.e. operability, maintainability, transferability, and scope factor 1 is used.

By this way of calculation, the importance of protection and trust assumptions for PET quality is clearly emphasised.

Combining readiness and quality to express maturity

For combining the information on readiness and quality on the maturity of a PET, we propose to communicate the overall scale in the following way, putting the quality score into superscript:

readiness quality
For instance, a PET maturity level of pilot + denotes readiness level pilot and quality +. Figure 3 contains all possible combinations.

Evaluation

During the work on PET maturity, we discussed our interim results with several people from the privacy engineering domain. In addition, we conducted two evaluations: one evaluation strictly following the four-step process with roles of the assessor and experts under rather controlled conditions that took part in autumn 2015, and previously another less formal experiment for gathering early feedback. This second evaluation experiment was conducted during the 2015 IFIP Summer School with the participants who were willing to contribute. Both evaluations are described in [START_REF] Hansen | Readiness Analysis for the Adoption and Evolution of Privacy Enhancing Technologies: Methodology, Pilot Assessment, and Continuity Plan[END_REF] where it is also pointed out that further work has to be invested for assessing a wide range of PETs. In August 2015, the IFIP Summer School on Privacy and Identity Management took place in Edinburgh. All attendees were invited to participate in the evaluation. The audience consisted of both experienced scientists on privacy engineering or privacy requirements and Ph.D. students from the disciplines of law, computer science, or social sciences. A workshop on "Assessing PET Maturity" was held on Wednesday, 19th of August, 2015. Prior to this workshop, all participants were asked to fill out a questionnaire for assessing a specific PET. Note that no precautions were taken to avoid double submissions or to prevent exchange of opinions between participants. The different readiness scales and privacy enhancement quality characteristics (see Section 3.2 and Section 3.3) were explained to the participants in two pages of introductory text as part of the questionnaire. As Target of Assessment the tool for anonymising Internet communication TOR -The Onion Router was chosen because most of the Summer School attendees had probably at least heard about that PET or had gathered some practical experience. For simplicity reasons, we did not give more information on the Target of Assessment than "The Onion Router (TOR)" (see Figure 4).

The questionnaire was filled in by 14 attendees. Most of them took less than 20 minutes for filling in the questionnaire, only one person needed significantly more time. During the workshop with several more people who had not filled in the questionnaire, the results of the evaluation were presented and discussed.

Evaluation results

Looking at the definitions in the readiness scale, most participants thought that for TOR the readiness level of product would be appropriate (see Figure 5). Two participants were in favour of pilot, one person considered TOR as outdated.

In the discussion at the workshop most people agreed on the readiness level product. In the debate it was scrutinised whether a valid business model is necessary for the assessment product and how the attacks by the National Security Agency, as reported in the files from Edward Snowden's NSA revelations (e.g. for TOR [START_REF]NSA: Tor Stinks -presentation slides as part of Edward Snowden's NSA revelations[END_REF]), would influence the evaluation.

In the quality assessment, the differences were bigger (see Figure 6): One participant attested poor quality (-), the others regarded TOR's quality as good (+). One participant did not vote at all. In such a situation, the detailed comments would have to be discussed among the experts, as it is known in reviewers' discussions on the quality of an academic paper. Also, it makes sense to document the reasoning so that it becomes clear which sources have been used by the experts, how reliable they may be, and whether their judgement focuses on specific usage contexts.

It is also interesting to look in more detail into the differing assessment results for each quality characteristic (see Figure 7). Obviously the participants had different views on several aspects regarding TOR. The characteristic protection was not regarded as poor or very poor by any participant. In the discussion it turned out that in particular the characteristic side effects were understood differently by the participants. Variations in assessments for operability, maintainability, and transferability can be explained by different practical experience with the tool. Despite all differences in the detailed assessment, almost all participants agreed both on readiness and quality, resulting into a PET maturity level of product + . The experiment's results were used to prepare a controlled small-scale study for another PET maturity assessment where the roles of the assessor and experts were clearly assigned, the experts were chosen on the basis of their knowledge, it was enough time for an evaluation, the experts met in a phone call to discuss their individual results, and the procedure was well documented (see [START_REF] Hansen | Readiness Analysis for the Adoption and Evolution of Privacy Enhancing Technologies: Methodology, Pilot Assessment, and Continuity Plan[END_REF]). This following evaluation of our PET maturity assessment methodology focused on the adequacy, ease of use, effectiveness, and effort required to evaluate a PET.

Both experiments showed that the methodology is easy to use for experts, but probably not for non-experts. Also the lack of practical experience can be a problem when being asked to score characteristics related to operation of a PET. The separation between readiness and quality scores was acknowledged by the participants in the experiments. It was also evident that a fully automatic assessment on the basis of easily collectable and measurable indicators would not yield reliable results. Therefore the combination with an assessment by human experts was regarded as a necessity for a meaningful outcome.

Since the experts' opinions play an important role, the exact results may not be reproducible with other groups of experts. The tasks of the assessor, especially the choice of experts, the definition of the Target of Assessment, and the consolidation of the individual results, have to be exercised with due diligence.

The methodology should be further investigated with a larger number of PET assessments and an evaluation of the documented assessment processes. We believe that the consistent application to a set of different PETs will elicit the usefulness of the methodology.

Conclusions

The assessment of privacy enhancing technologies will become increasingly important as soon as the European General Data Protection Regulation has come into force. However, this is not an easy endeavor. In particular the direct application of the Technology Readiness Level scale could lead to misunderstanding if the privacy enhancement quality is ignored in the assessment.

We have proposed a framework for assessing both PET readiness and PET quality properties that can be combined into a PET maturity score. For this, we use input measurable indicators as well as human experts who are involved in the assessment process in a way comparable to scientific reviewers. In preparation of a controlled experiment that strictly followed the proposed process (see [START_REF] Hansen | Readiness Analysis for the Adoption and Evolution of Privacy Enhancing Technologies: Methodology, Pilot Assessment, and Continuity Plan[END_REF]) we used the opportunity of the interdisciplinary IFIP Summer School on Privacy and Identity Management to test the developed questionnaires and gather feedback from the participants.

We hope that the developed methodology will be used for assessing the maturity for PETs with varying complexity. Our vision is an easily accessible repository with PETs and their assessment results where readiness and quality can be discussed, where input for further improvements can be collected, and where researchers and developers can contribute to advance the state-of-the-art. This could boost the deployment of PETs by system developers and designers, the demands from data controllers and data processors, and the integration in the checking and consulting activities of the supervisory authorities competent for privacy and data protection.

Fig. 2 .

 2 Fig. 2. PET Maturity Assessment Methodology

Fig. 3 .

 3 Fig. 3. Overview of Possible PET Maturity Level Values

Fig. 5 .Fig. 6 .Fig. 7 .

 567 Fig. 5. Readiness Assessment of TOR

  Different versions

	Define Target of Assessment
	Elaborate PET Maturity Level Concurrent Assessments Gather Measurable Indicators Gather Expert Opinions Select Board of Experts	Documentation	and Logging
	and Assessment Report

Fig. 1. Overview of the PET Maturity Assessment Process

  Threshold indicators can help determining the readiness level: idea→research: This threshold indicator is met if there exists at least one scientific publication that focuses on the ToA. research→proof-of-concept: This threshold indicator is met if there exists at least one working implementation (e.g. laboratory prototype, open source project, proof of existing code, or similar, that compiles and executes, and implements the ToA). proof-of-concept→pilot: This threshold indicator is met if there exists at least one real-world utilisation of the ToA, with non-laboratory users, performed in a real-world application context. pilot→product: This threshold indicator is met if there exists at least one product available in a business market, or in a context in which the utilisation of the ToA happens in a real-world business context with transfer of value. product→outdated: This threshold indicator is met if 1) the only technology

PET Maturity Assessment -Evaluation Form Target of Assessment:

	The Onion Router (TOR)

Readiness Assessment ⃝ idea ⃝ research ⃝ proof-of-concept ⃝ pilot ⃝ product ⃝ outdated Comments on the Readiness Assessment: Quality Assessment

							PET Maturity Assessment -Questionnaire
							Explain the term
							"maturity" in the context
							of PETs in your own
							words:
							Was it clear to you what
							you had to do for this
							questionnaire? Please
							comment:
	Overall Score:	⃝ --	⃝ -	⃝ 0	⃝ +	⃝ ++	How much time did it take to evaluate the Target of Assessment?	_________ Minutes
		very poor	poor	moderate	good	very good	Do you think this type of evaluation measures
							everything that is relevant
	Comments on the Quality						to determine the maturity
	Assessment:						of a PET? Please comment:
							Do you think some of the
							questions asked are
							irrelevant to determine
	Quality Characteristics	Score		Comment			the maturity of a PET?
	Protection						Please comment:
	Trust Assumptions
	Side Effects
	Reliability
	Performance Efficiency
	Operability
	Maintainability
	Transferability
	Scope

How would you improve the assessment and the forms? Please comment: Please fill out both forms and return them to either Marit, Meiko, or Jaap-Henk! Thank you!

	Fig. 4. Questionnaire for evaluating TOR

Acknowledgments. Part of this work was supported by the European Commission, FP7 ICT programme, under contract no. 318424 (FutureID project). S. Schiffner is currently employed by ENISA; the views presented in this paper are those of the authors and do not necessarily reflect those of ENISA. The work documented in this paper is part of ENISA's ongoing efforts to foster the uptake of privacy-enhancing technologies in Europe.


Gustavo Luis

E Gabriela Esquivel-Quirós

Barrantes

An Experience with a De-identifying Task to Inform About Privacy Issues

Keywords: privacy concerns, de-identification, re-identification, education

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

Introduction

Information is constantly flowing from most of our electronic devices. We generate all kinds of information: social, geographical, financial, and many others. If the information refers to an individual, and if it is intentionally or unintentionally published, it might expose sensitive information which the individual might wish to, and possibly has the right to, keep private. This issue has been raised everywhere, but we were interested in the situation in Costa Rica; a small country with an educated population, and relatively high information and communication technology (ICT) penetration [START_REF] Bolaños | Acceso y uso de las tic en la administració pública, empresas y hogares[END_REF].For years, it has produced and exported software, and international software and hardware companies now have part of their operations in our country [START_REF]Costa Rica líder en Latinoamérica en exportación de software -Cámara de Tecnologías de Información y Comunicación de Costa Rica (CAMTIC)[END_REF].

Privacy issues have developed at different paces depending on the country. Costa Rica had a slow start in legislation and general awareness about privacy. Until recently, there were no specific privacy laws, and instead privacy breaches were dealt mostly by the Constitutional Court, using Habeas Data, which is a constitutional court action available in some countries, used to protect the rights of an individual over its own data, and in some ways analogous to the more commonly-known Habeas Corpus [START_REF] Avendaño | Protección de datos en el gobierno digital[END_REF].

In 2011, the first privacy-specific law was approved, the "Ley de Protección de la Persona frente al tratamiento de sus datos personales" [START_REF] Rica | Asamblea Legislativa: Ley de protección de la persona frente al tratamiento de sus datos personales[END_REF], and in 2013 the regulations for the law were published [START_REF]Reglamento a la Ley de protección de la persona frente al tratamiento de sus datos personales[END_REF]. The law also created PRODHAB, a regulatory agency ("Agencia de Protección de Datos de los Habitantes") which started operations in 2013 [START_REF] Rica | Asamblea Legislativa: Ley de protección de la persona frente al tratamiento de sus datos personales[END_REF][START_REF]PRODHAB -Agencia de Protección de Datos de los Habitantes[END_REF].

Costa Rica has experienced scandals due to breaches in privacy, including some very prominent ones in recent years that received wide media coverage. For example, there was the case of Keylor Navas, a relatively famous national soccer player, in which it came to light that his family in Costa Rica was the subject of more than 20 frivolous consults at the hands of employees of the Organization for Judiciary Research (OIJ) [START_REF] Marca | Keylor Navas spied on by the Costa Rican police[END_REF]. The case started in October 2014, and caused a public outcry that ended up in an inquiry by a Legislative Assembly commission [START_REF] Soto | Diputados crearn comisin para investigar espionaje en el OIJ contra Keylor Navas[END_REF]. The commission reached its conclusion in May 2015 [START_REF] Mata | Congreso señala débil protección de datos en el OIJ[END_REF], but by November 2015 it had disappeared from the public view, without significant consequences.

However, even with the new law, the PRODHAB, the press coverage of privacy breach scandals, and the general level of education, people in Costa Rica seem mostly unaware or indifferent to privacy issues, as could be inferred from the press coverage of such cases. Each time a given person suffers a privacy breach, there is enough public outrage to keep it in the news for some time, but it is mostly forgotten soon after. We believe that this reflects a cognitive dissonance between beliefs about privacy and actual attitudes about data online. This phenomenon has been well documented in other countries, and is referred to as the "Privacy Paradox " [START_REF] Preibusch | Guide to measuring privacy concern: Review of survey and observational instruments[END_REF].

A different privacy issue also present in Costa Rica has to do with the general lack of understanding of the complex interactions among different pieces of data that could link seemingly "sanitized" data to sensitive information about the individual. For example, some of the recent rulings of the Constitutional Court show that judges consider privacy important, but are not aware that the data being authorized for release could be used to put individuals in danger [START_REF] Herrera | Sala IV: Salario de los empleados del Estado es un dato público[END_REF]. This so-called "re-identification" threat is also a well-documented reality, with most documented cases dealing with data published in the United States ([24], [START_REF] Narayanan | Robust De-anonymization of Large Sparse Datasets[END_REF], [START_REF] El Emam | A systematic review of reidentification attacks on health data[END_REF]). Given all of the above, it was important for us to test directly what the situation was in Costa Rica. More specifically, we wanted to determine how easy (or difficult) it would be for a non-expert to re-identify local individuals. Therefore, we decided to run a limited re-identification exercise with a group of educated, but non-expert participants. We also restricted it to "young" people (under 35 years of age), as there is evidence indicating that the privacy paradox is an issue in this group [START_REF] Marwick | Youth, Privacy and Reputation (Literature Review)[END_REF]. However, after running the task we realized that it had an unexpected outcome regardless of how easy it was for the participants to identify the local individuals, so we decided to report our findings from the re-identification task as evidence for a possible educational strategy to raise awareness about privacy issues.

In Sections 2 and 3 we define basic privacy and data protection concepts, respectively. In Section 4 we present the methodology used. Section 5 presents our results and their analysis. Section 6 summarizes our findings, and Section 7 proposes future directions for this work.

Privacy

The concept of "privacy" has no single, clear and definite meaning, and varies widely between different cultures. This concept is discussed in philosophy, politics, law, sociology, anthropology, psychology, and other areas. The difference between the public and the private have been recognized in some form in most societies, albeit there is no general agreement about the meaning, the limits, and the application of these limits (legal framework) [START_REF] Rica | Asamblea Legislativa: Ley de protección de la persona frente al tratamiento de sus datos personales[END_REF] [11] [START_REF] Shklovski | un-googling" publications: The ethics and problems of anonymization[END_REF].

Following Daniel Solove [START_REF] Solove | A Taxonomy of Privacy[END_REF], privacy can be generically conceptualized as a barrier that people can hold to provide themselves with some relief from different sorts of social friction, which will allow them to function as a member of a society without being overwhelmed by the multiple pressures it imposes.

A definition for privacy that is relevant for information privacy was given by Alan Westin [START_REF] Westin | Privacy and Freedom[END_REF]: "Privacy is the claim of individuals, groups, or institutions to determine for themselves when, how, and to what extent information about them is communicated to others."

William Parent [START_REF] Parent | Ethical issues in the use of computers. chap. Privacy, Morality, and the Law[END_REF] defines privacy as the condition of not having undocumented and unauthorized personal information in possession of other parties. His position is that there is a privacy loss when others acquire personal information about an individual without his or her authorization. Personal information is defined by Parent as any information about facts that the person chooses to not reveal about him or herself. In this view, personal information becomes "documented" only if it becomes public with the authorization or actions of the individual.

The concept is in fact very dependent upon the context [START_REF] Solove | A Taxonomy of Privacy[END_REF] wich makes raising awareness about issues related to it complicated, which might explain why conciousness about privacy in the general population remains an elusive goal.

Identification, de-identification and re-identification

For terminology only, we will follow the decisions about data privacy definitions stated in the Internal Report 8053 of the National Institute of Standards and Technology of the United States [START_REF] Garfinkel | NISTIR 8053. de-identification of personal information[END_REF]. In particular, we will not use the term "anonymization", and "personal information" will refer to any information from an individual, but "identifying information" would be the subset of personal information that could be used to identify that individual. The definition recognizes that personal data from which all identifying information has been removed, sometimes can be traced back to the individual.

A de-identification process concerns itself with stripping identifying information from personal information. The purpose is usually to decrease the risk of sensitive data about the individual being associated back to him or her. A process used to defeat de-identification is called re-identification. Such a process attempts to link data back to its originator. There are many possible strategies to accomplish this task [START_REF] El Emam | A systematic review of reidentification attacks on health data[END_REF].

Methodology

Given that the focus of our main exercise was to probe the ease of re-identification in our environment, the methodology focused on re-identification details. Most of the post-exercise written questions were oriented in that direction, and individual concerns about privacy were not directly referenced. For the purpose of this paper, we relied on items that provided indirect indications about the participants' concerns about privacy, and the oral responses of the participants during the interactions with the experimenters. Subsection 4.1 describes the design of the re-identification exercise that was to be carried out by the participants in the study. Subsection 4.2 deals with the details of the exercise execution. Subsection 4.3 presents the indicators taken from the questionnaire used by the participants to qualify the exercise.

Exercise design

The design of the re-identification exercise required choosing the following:

1. A base dataset; 2. The de-identified subsets; and 3. A group of individuals who will execute the exercise. The choices taken are described below.

Choosing the base dataset The exercise required the participants to reidentify a group of people, given some weakly de-identified data. Therefore, the first challenge was to define this group. The requirements for the base dataset were the following:

1. We had to be able to find enough publicly available information about them 2. They had to be somehow "interesting" for the participants in the exercise 3. They had to be relatively public figures so we would not infringe any local privacy laws 4. We needed a relatively large number of individuals (more than 20) to be able to choose different combinations among them Some possibilities included local politicians, entertainment personalities, fairy tale characters, and sports figures. We ended up choosing local football (soccer) players, given the World Cup excitement, and the importance of football in Costa Rica. More specifically, we choose all the players that were called in a single selection summons, which gave us a total of 30 players.

We collected the following publicly-available information about the players:

-Local ID number (Cédula de identidad ) -Complete name -Birth date -Marital status -Number of children -Province were registered to vote -Current club

Choosing the de-identified subsets After collecting the base dataset, we had to define the subsets of de-identified data that would be given to study participants to re-identify. We defined two subsets for the exercise, to test if restricting the amount of de-identified information would make a difference in the re-identification efficacy. The first subset was comprised of data from three queries on the base dataset, and no further data was provided during the exercise. The definition of the queries follows:

-Birth year, age, place of birth, province where registered to vote, for all 30 players -Marital status and number of children, but only for married players -Number of children and current club, but only if the current club was local.

The second de-identified subset was potentially different for each participant. No data was given outright, but a participant could request from the experimenters up to three queries from the base dataset, with the following rules:

-In the first query, a participant could request all the data in a non-direct ID column (for example, column "number of children", but not "Local ID number"). The student could specify the column by name, but could only pick one, two or three columns. -In the second query, a participant could request at most two columns, but only 50% of the data for that column was given (data for 15 randomly chosen players). -In the third query, the participant could request only one attribute, and again, only 50% of the data would be returned.

Choosing the participants We needed as participants a group of young people who were not very familiar with either computer security or privacy issues. We had the generous cooperation of the students and the professor in the FS408 Thermodynamics class, at the end of 2013. This is a second-year course in the curriculum of the Bachelor Degree in Physics at the Universidad de Costa Rica.

None of the students in the group had previous, specialized experience in security, data mining, or protection of data privacy, and they were all Physics majors. There were 49 participating students. They were naturally divided into two attendance modalities: 34 in-class and 15 remote students. We used this natural division to test two different types of query.

The participants were mostly male given that the student population for the Physics major at the Universidad de Costa Rica presents a marked gender imbalance, as it can be seen in Table 1. However, both the group and each of the subgroups were very homogeneous in age. The youngest student was 19, and the oldest 29 at the time. Table 2 summarizes the age distribution of the participants in the exercise.

Execution

The full class had to attend a brief presentation on general privacy issues. This presentation included basic concepts on privacy protection, and legal consequences of information published online, showing local and international examples ([3], [START_REF] Rhodes | Google-Motion-to-Dismiss-061313[END_REF]). We showed them examples of potential dangers such as identity theft, and misuse of sensible information. After the talk, all students had to participate in a group activity where they re-identified characters in a fairy tale, with a subsequent discussion of methods and results. During both activities, they were allowed to ask questions, make suggestions and offer opinions. The next step was to explain the rules of the identification exercise, but before that, an explanation was given about the possible uses of the data to be collected, and the possibility of opting-out. Those students who were willing to participate had to complete and sign informed consent forms.

There was a small reward associated to the completion of the exercise. If the student demonstrated serious effort towards the re-identification, and answered a question about the entropy of the data, the completed exercise counted as an extra quiz. The actual re-identification success did not count towards the grade.

Afterwards, all students were given their respective instruments, which included the de-identified datasets, and a questionnaire to be completed after the exercise. They were given a week to complete it. In-class students were given the fixed dataset and remote students had to generate their own using the rules explained in Section4. The goal was to identify (obtain the names) of the largest number of players. As mentioned in Section4, the reason that different datasets were used for each group is that originally the exercise was meant to compile information about the ease of re-identification in Costa Rica.

The answers to the exercise were collected a week after it was handed out. The experimenters had a brief discussion session with the students at that point. The students in the remote modality had the responsibility to be present if there was an evaluation activity, so all of them attended the class in the first week, but most of them were not present for the discussion on the second week.

Questionnaire and analysis strategy

The questionnaire that the students had to complete after completing the reidentification exercise, contained nine items, divided into three closed, and six open-text questions. The questions were oriented to determine the difficulty of the re-identification task. Because the written instrument was not explicitly designed to measure levels of concern about privacy, we used the answers to the following items as proxies for concern:

-Perception about the exercise: This was a single-choice question. It stated: "In which category would you assign this exercise?". It had four possibilities: "challenging", "interesting", "normal" and "boring". -Guess about the correct number of re-identifications: The answer to this question required a number from 0 to 30. The question was: "How many people did you re-identify?".

Results and Analysis

We will start by presenting the efficacy of the actual re-identification performed by the students (Subsection 5.1). Next we show the perceptions about the exercise itself (Subsection 5.2) which is the closest to a direct indicator of a change in concern about privacy. We then analyze the self-reported perception of accuracy (Subsection 5.3) as an indicator of learning. Attitudes during the in-class interactions are described in Subsection 5.4. Finally, in Subsection 5.5 there is a brief discussion of the results.

Success in re-identification

The students were quite successful finding who the players were. All participants completed the exercise, and turned it in on time. As explained in Section 4, being able to correctly identify the players was not being graded in itself. Even so, a large percentage of students (90% for the in-class and 93.3% for the remote groups) identified correctly more than 96% (29 or 30) of the de-identified players.

The student who identified the smallest number of players, "only" managed to identify 16 of them, although he claimed to know next to nothing about football. In fact, students were so effective in the re-identification, that they corrected one player's birth date, on which we inadvertently had introduced a mistake when collecting the information.

Figure 1 presents the normalized frequency histograms for the number of correctly re-identified players.

Perceptions about the exercise

The ratings given by the students to the exercise are summarized in Table 3. Given the unconcerned attitudes revealed during the first week activities (see Subsection 5.4), the change to consider the exercise as mostly "interesting" (67.7 and 73.3% for in-class and remote students, respectively), constitute a clear indicator of a growing concern. Note that the exercise itself belongs to a discipline different from the group's major, so it is unlikely that the rating reveals a a disciplinary issue.

Efficacy perception

When students had to complete the questionnaire, they still did not know if their re-identifications were correct. We asked them to guess how many players they had identified correctly. Table 4 compares their self-evaluated accuracy with the reality of how many players they had identified correctly. It turns out that their guesses are quite close to reality, which indicates that they had really understood the underlying processes. This result, combined with the fact that 48 out of 49 students identified 25 or more of the 30 players with no previous knowledge about re-identification techniques, shows that this is not a difficult process with common tools and data available today online.

Attitude change: the in-class interaction

We describe the subjective assessment of the authors about students' attitudes before and after the exercise.

In the first session, after our talk, most students agreed that they cared about their privacy, but considered that it was not at risk because of the information publicly available about them. Some even offered details on people they knew whose identity was stolen, but the general feeling was that it was something that happened to other people, and that they were safe. Even after running the mini-exercise of re-identifying characters in a fairy tale, their concern did not increase, as they claimed that it was "too easy".

A week later, after completing the exercise, the authors met with the students to pick up the answers and have a group discussion about the results. The mood of the group was more guarded, and some of the students expressed apprehension about their data online, and some of them explained that they did not realize that it was "so easy" to find a trove of information about people.

Discussion

The indicators used suggest that there may be an attitude change about privacy after executing the re-identification exercise, which was engineered to be relatively easy (it was weakly de-identified). Interestingly enough, it made no difference whether students received a pre-made group of de-identified data, or could devise queries by themselves. We thus believe that the most valuable part of the experience was the exercise itself, because it was hands-on [START_REF] Schneider | Preparing for future learning with a tangible user interface: The case of neuroscience[END_REF].

The talk itself, which warned about what the students later discovered through the exercise, had no measurable effect, so it was surprising when some of the previously sceptic students expressed concern about privacy in the after-exercise discussion. Although we are just describing a single case, our results are consistent with constructivist literature in education [START_REF] Bransford | Rethinking transfer: A simple proposal with multiple implications[END_REF].

We believe that the most valuable insight is that the task described, being very easy, but definitely practical, could be adapted to raise the privacy awareness of almost any person by executing a re-identification exercise.

We cannot say at this time whether any attitude changes will be maintained, which would be interesting to investigate in the future.

Conclusions

We presented a case where a group of students showed an attitude change about privacy issues after completing a hands-on re-identification exercise.

Almost all students (48 out of 49) were able to re-identify 25 players or more, even though they were not trained for the process, confirming the assumption that it is not very complex.

During the first session, students were not particularly interested in the exercise. After the students finished the re-identification process, some of them expressed more concern for their privacy in the post-exercise session. From the answers in the questionnaire, we know they were interested, which is in itself an attitude change. We argue that the interest about the exercise reflects an internal process that led to the greater concern expressed by some in the second session, which potentially suggests an attitude change about privacy.

The ease of resolution, plus the increased interest, points us in the direction that similar exercises could be used to raise awareness about privacy in the general population.

Future work

We intend to test the results of the case presented with a larger, more diverse sample. However, the delivery described (talk, synthetic re-identification exercise, re-identification exercise with real individuals), is relatively expensive. We expect to eventually develop automated, online versions of similar exercises, which would allow us to reach a larger public.

Fig. 1 .

 1 Fig. 1. Frequency (normalized) of correctly re-identified players

Table 1 .

 1 Summary of gender distribution of participants.

	Population Male Female Total Population
	In-person	26	8	34
	Remote	14	1	15
	Whole group 40	9	49

Table 2 .

 2 Summary of age distribution of participants.

	Population Average Stand.Dev Median Mode
	In-person	21,21	1,49	21	20
	Remote	23,07	3,13	22	21
	Whole group 21,78	2,27	21	20

Table 3 .

 3 Exercise ratings

	Rating	In-class Remote
	Challenging 1 (2.9%)	0 (0%)
	Interesting 23 (67.7%) 11 (73.3%)
	Normal 6 (17.6 %) 3 (20%)
	Boring	4 (11.8%) 1 (6.7%)

Table 4 .

 4 Self-evaluation of success in re-identification

	Real Population Average Stand.Dev. Average Stand.Dev. Guessed
	In-person	28,82	2,64	29,29	2,39
	Remote	29,4	1,06	28,6	5,15
	Whole group	29	2,28	29,08	3,43

Acknowledgments. This work was done for research project 834-B4-150 at Universidad de Costa Rica (UCR), the Research Center in Information and Communication Technologies (CITIC) and the Department of Computer Science (ECCI). Funding was also received from the Ministry of Science and Technology

of Costa Rica (MICITT) and the National Council for Scientific and Technological research (CONICIT). Special thanks to Professor Hugo Solis, his FS0408 students, and the Physics Department at UCR.