Introduction to privacy protection Part 3 - Privacy

ID mgt and authentication Priv.-preserving author. Anonymous communications Further issues

Introduction to privacy protectionPart 3 - Privacy-enhancing technologies

Guillaume [email protected]

http://guillaume.piolle.fr/

Master “Machine Learning and Data Mining”, Saint-Etienne

December 16th 2013

Guillaume Piolle Introduction to privacy protection Part 3 - Privacy-enhancing technologies 1 / 68

http://guillaume.piolle.fr/


Privacy-Enhancing Technologies (PETs)

1 Identity management and authentication

2 Privacy-preserving authorizations

3 Anonymous communications

4 Further issues



Identity management and authentication

Requirements

Identification of a person;

Verification of their identity;

Attribution of authorizations;

Auditability and imputability of their actions.

In terms of privacy

Guarantee anonymity, is access is open;

Limit linkability and observability;

Control the revocation of pseudonymity.

+ facilitation of multiple identity management (SSO)



Identity management and authentication: OpenID

Centralized (online) authentication management, reasonably supported.

Main advantage

SSO management of potentially multiple pseudonymous identities.




Principle

Users authenticate themselves with the website of an identity provider oftheir choice, at which they have an account associated to a URI.

To authenticate themselves on an OpenID-compliant website, theyprovide this URI.

The website (with the collaboration of the browser) checks with theidentity provider that the user is properly authenticated, and may fetchprofile information.




Google, Yahoo! and Windows Live ID accounts may be associated toIpenID identities (members of the OpenID foundation).

Ensured properties

Mostly, user comfort;

Limitation of the number of login/password couples, thereforepossible increase in password security.

However. . .

No anonymization of authorization;

The administrators of the visited websites have control over whetherOpenID can be used or not;

No unlinkability property.



Privacy-preserving authorizations

It is possible to give authorizations (including access control) to a remoteuser without obtaining their actual identity.

Anonymous credentials

Proof that a user verifies a set of properties, opening rights to a serviceor resource, without revealing the details of their identity of activity.

Examples: SPKI attestations, limited certificates, “white” identity card,electronic payment proofs. . .



Privacy-preserving authorizations: U-prove, Idemix

Authentication/authorization frameworks with a guarantee ofunlinkability (using anonymous credentials).

U-prove

Developped by Credentica, then bought by Microsoft. Public specificationsince 2010, in order to favour implementation by third-party websites.

Idemix

Developped by IBM (mostly, in the context of the PrimeLife EU project).Developpe par IBM (principalement, dans le cadre du projet europeenPrimeLife.

Prototypes exist for both, but no actual products available to the generalpublic for now. An EU projet (ABC4Trust) aims at merging both systemsin a common standard.



Privacy-preserving authorizations: e-Cash

Expected properties of an electronic banknote

Anonymity: a note does not identify the person for whom it isemitted;

Infalsifiability: only a bank can emit a note, which then cannot bealtered;

Unicity of cash collection: impossibility to replay a payment;

Liquidity: ability to “break” a note into smaller ones, or to aggregateit with other ones.




Digicash and RSA blind signatures 1/2 (D. Chaum 1982)

1 The Client wishes to withdraw a note from their Bank. Theygenerate a message M in the form “This is note number: N”, whereN is a random number. They multiply N with a random number r ,encrypted with the Bank’s public key (blinding). They encrypt theresult with their private key and send it to the Bank:

Client→ Bank :{

M × r PBank}SClient

2 The Bank checks the Client’s signature and their balance. If itallows withdrawal, it signs the blind message and sends it back:

Bank→ Client :{

M × r PBank}SBank

= MSBank × r




Digicash and RSA blind signatures 2/2 (D. Chaum 1982)

3 The client “unblinds” the message M by dividing by r . They obtainM, signed by the bank, which they can send to a Merchant:

Client→ Merchant : MSBank

4 The Merchant may check the authenticity of the banknote, and sendit to the Bank for cash collection;

5 The Bank may check its own signature, check that no other note Nhas been cashed before and credit the Merchant’s account.



TLS/SSL

TLS/SSL

Principle: encryption of the connection between the browser and the webserver (https:// websites).

Symmetric encryption, using a“session key”negotiated on the fly betweenthe web server and the browser.

SSL : Secure Socket Layer (Netscape, v1 [?], v2 [1995], v3 [1996])

TLS : Transport Layer Security (IETF [1999]), RFC 2246 (1.0),4346 (1.1), 5246 (1.2)

Encountered algorithms: from RC4-128 to AES-256. The weakestcyphers, quite often, are only used by banks.



TLS/SSL

TLS/SSL

Server authentication: The browser only negotiates with the server ifthe latter is able to show a valid cryptographic certificate proving itsidentity. Beware of browser alerts!

Client authentication: Optional (rarely used). Example: formerconfiguration of the French tax website (impots.gouv.fr), wheretaxpayer could authenticate with a personal certificate delivered by aministry service.

Ensured properties

Authentication (server, optionally client) ;

Confidentiality of communications between client and server;

Integrity of exchanged messages.

Usable for any protocol over TCP.



TLS/SSL

TLS/SSL

The privacy point of view

We are protected from eavesdropping from the outside, but not fromthe client nor from the server;

“Passive” protection → good property for a user privacy protectiontool;

It is the service provider, not the user, who decides that theprotection is available;

It is absolutely necessary not to ignore browser alerts, and tounderstand them.



TLS/SSL

TLS/SSL: how to negotiate a session key?

Using asymmetric encryption (e.g. RSA)

The server publishes its public key;

The client chooses a random session key;

the client sends the session key, encrypted with the server’s publickey.



TLS/SSL


Advantages of using asymmetric encryption

No need to share a secret beforehand;

The eavesdropper doesn’t learn anything about the session key.

Note: in fact, they don’t share the session key, but a “pre-master secret”from which the key is derived in a deterministic fashion.



TLS/SSL


Using asymmetric encryption: drawback 1

An attacker could impersonate the server (for instance with an “ARPspoofing” or “DNS poisoning” attack) and replace the server’s RSA key byits own. They could then learn the session key.

→ Man-in-the-Middle (MitM) attack



TLS/SSL


Using a Public Key Infrastructure (PKI)

Using an electronic certificate allows to prove one’s identity and avoidMitM attacks. A certificate includes:

One or several public keys;

Identifying information (DNS domain, e-mail address. . . );

At least one signature.

Either the certificate is signed by a well-known “trusted” authority, or itmust be (recursively) checked that the signer can show such a certificate.

When we contact a website, the certificate aims at convincing us that wetalk to the actual owner of the domain name, and not with an attacker.A challenge can be set up: the interlocutor must prove that theyactually control the private key associated to the certificate.



TLS/SSL


TLS certificate pitfalls 1/2

The safety of the system lies on the management(sometimes problematic) of revocation lists forcertificates which have become invalid;

The certificate only shows information about theinterlocutor’s identity, they don’t say whetherthey are honets, trustworthy, or whether theirplatform is secure. . .

The system relies on a set of “root” certificationauthorities, built-in in software and operatingsystems. Who decides who we should trust, andhow?



TLS/SSL


TLS certificate pitfalls 2/2

It is relatively easy to buy a certificate (with acertification chain linking to a root CA) withouttoo much verification on one’s identity;

States and large companies may obtain (orimpose) rogue certificates allowing MitM attacksand (mass) decryption of all TLScommunications going out of a network;

Affairs like Comodo, DigiNotar and more recentlyAnssi/DGTresor may cast a doubt about CAs’ability to ensure the security of theirinfrastructure and procedures.



TLS/SSL


Using asymmetric encryption: drawback 2

If an attacker records the encrypted communications, and then managesto get access to the server’s private key (through intrusion, extorsion,corruption, legal requisition. . . ), they will be able to decrypt allmessages afterwards.

How to avoid that?



TLS/SSL


The Diffie-Hellman key exchange protocol

The server chooses two numbers g and p and sends them to theserver (in cleartext);

The server chooses a random (secret) number a and sends A = g a

(mod p) to the client;

The client chooses a random (secret) number b and sends B = g b

(mod p) to the server;

Each party can calculate the session key K = Ab (mod p) = Ba

(mod p) = g ab (mod p).



TLS/SSL


Advantages of Diffie-Hellman

No need to share a secret beforehand (as previously);

The eavesdropper doesn’t learn anything about the session key (aspreviously);

Protects against MitM attacks (as previously);

Even if one of the machines is later compromised, the session keycannot be recovered.→ Perfect Forward Secrecy (PFS).

Obviously, Diffie-Hellman does not exempts one from checking servercertificates: this is another kind of property.



TLS/SSL

TLS Handshake and Application Data Records

TLS Handshake

Optional authentication: simple (server only) or mutual;

Negotiation of a 48-byte pre-master secret, of an encryptionalgorithm and of a hash algorithm;

Possibility ot recover a previous session.

TLS Application Data

Confidentiality (symmetric encryption) of the session;

Integrity (keyed hash) of the sesion.



TLS/SSL

TLS/SSL Handshake

* : optional message



TLS/SSL

TLS/SSL Handshake: hello client

ClientHello

Cryptographic suitesTriplet suite (ordered by preference)

Key exchange algorithm: RSA or DH (variants exist);Encryption algorithm and key/block sizes: null, RC4, RC2, DES,3-DES, DES40, Camellia, AES;Hash algorithm: null, MD5, SHA.

Nc : 256-bit random number (32 bytes)

Also contains:

Versions supported by the client;ID of a previous session to recover (or null);Timestamp (GMT Unix Time): for use by the upper protocol layer;Compression method (used before encryption).



TLS/SSL

TLS/SSL Handshake: hello serveur

ServerHello

Crypto suite: triplet chosen by the server in the client’s list (orhanshake failure alert);

Ns : random number, different and independent from Nc ;

Also contains:

Versions accepted by the server (taken from the client’s list);New session ID (or previous, reused session ID);Compression method.



TLS/SSL

TLS/SSL Handshake: server key

Server certificate (optional)

Public key certificate or DH certificate (g , p);

Certification chain.

ServerKeyExchange (optional)

Sent only if the certificate public key is not fit for encryption (i.e. toolong to be authorized for exportation, or signature-only algorithm);

Contains a temporary public key for the server, or the publicserver-side elements of an ephemeral Diffie-Hellman (g , p, g a[p]);

Signature with the secret key corresponding to the public key on thecertificate.



TLS/SSL

TLS/SSL Handshake: cle client

Client certificate (if required by the server)

Public key or DH certificate;

Certification chain.

ClientKeyExchange

pre-master-secret (48 bytes) chosen by client and encrypted with theserver’s public key. . .

. . . or. . .

. . . public client-side elements of a Diffie-Hellman (g b[p]), g et pbeing those sent by the server.

CertificateVerify

Hash (MD5 or SHA) of previous messages



TLS/SSL

TLS/SSL Handshake: key calculus (1/2)

PRF function

+ is the concatenation operator

PRF(secret[1,N], label, seed) = P MD5(secret[1, N2 ], label + seed)

⊕ P SHA-1(secret[ N2 + 1,N], label + seed)

A(0) = seed, A(i) = hash(secret, A(i-1))P hash (secret, seed) = hash(secret, A(1) + seed) + hash(secret,A(2) + seed) + hash(secret, A(3) + seed) + ...

Calculus of the master secret and key block

master secret = PRF(pre master secret, “master secret”, Ns + Nc )[1..48]

If D.H., pre master secret = g ab[p]

key block = PRF(master secret, “key expansion”, Ns + Nc )



TLS/SSL

TLS/SSL Handshake: key calculus (2/2)

Key block partitionning

client write MAC secret : hash size first bytes of the key block

server write MAC secret : hash size next bytes

client write key : key material length next bytes

server write key : key material length next bytes

Finished

First message to be protected by the negotiated algorithms;

PRF(master secret, finished label, MD5(handshake messages) +SHA-1(handshake messages)) [1..12]

finished label = “client finished” or “server finished”



Proxies

Anonymous communications: Proxies

Proxies

Simple solution (90’s style) to communicate in an “anonymous” fashion(anon.penet.fi in the 90’s, Proxify for web traffic. . . ).

Basically hides source IP;

Hides only source IP (and often very basically);

Variable auditabiliy obligations of providers;

Necessary trust in the provider, who has access to all traffic and IPsin clear;

Specialization by protocol;

Connection to proxy can easily be observed and blocked.



Virtual Private Networks

Anonymous communications: VPNs

Virtual private networks (VPNs)

Principle: The user connects to the VPN (via a client software), whichprovides them with a new IP address, in a new network. The user’soriginal IP is completely masked, replaced by the virtual IP. The bindingbetween the user and the virtual IP may be static or dynamic.In addition: encryption of all communications between the user and theVPN.

VPNs are often provided by institutions (remote access to corporateresources) or as a paying commercial service.









Virtual private networks (VPNs)

Substitution of source IP for any observer located after the VPNserver;

Confidentiality of content (including target IP) against any observerbetween the client and the VPN server;

Can be generalized to any kind of traffic;

Possible authentication of the VPN provider;

No additional confidentiality after the VPN server (except for thesubstituted IP);

Necessary trust in the VPN provider, who has access to all trafficand IPs in clear;

No applicative anonymization;

Connection to VPN can be observed, identified and blocked.





Technologies used for the tunnel

IPsec (in L2TP/IPsec);

MPPE (Microsoft Point-to-Point Encryption) + MS-CHAPv2 +PPTP (Point-to-Point Tunneling Protocol);

TLS/SSL (used by OpenVPN) ;

Datagram TLS (DTLS, used by Cisco AnyConnect) ;

SSH.



Freenet

Anonymous communications: Freenet

Distributed application allowing document publishing, storage and access:

Organized as a peer-to-peer network;

Guaranteeing connection anonymity (upload, search, download);

Resisting to censorship (“impossible” deletion of documents);

Providing plausible deniability.

First version in March 2000.



Freenet


Technical principles

When a file is stored on the network, it is fragmented anddisseminated on peers (with encryption and replication);

When a file is accessed, fragments are fetched, reassembled,decrypted;

The routing protocol does not allow a peer to identify who isoriginally publishing a fragment, performing a search or fetching afragment;

A peer cannot easily discover which files they host fragments of;

Darknet et open-net connecting modes;

Freenet provides an infrastructure which can be used by otherapplications;

Freesites: websites accessible only through Freenet;

Small world network model.



Freenet


Peer storage space management

Most searched for fragments are given priority;

When storage space become insufficient, the least searched forfragments may be deleted to make space for new fragments.

No pair is responsible for hosting a given fragment!The more a file is searched for, the more it is replicated: the only way todelete a file from Freenet is that everybody stops looking for it.



Freenet


Fragmentation and encryption

Each file is fragmented in encrypted 32kio fragement files. The name ofeach fragment file is its cryptographic hash, and is used to build a CHK(Content Hash Key).

A manifest lists all the fragments of a given file. The file name of afragment constitutes its access key.

The distributed fragment storage method allows one to fetch a fragmentif one knows its access key.



Freenet


Fetching and decryption

A client can ask for a file with a query of the following type:http://localhost:8888/CHK@xxx,yyy,zzz

The string CHK@xxx,yyy,zzz is the CHK of the manifest: xxx is itsaccess key, yyy its decryption key and zzz a set of cryptographic settings.

The client fetches the manifest, decrypts it, then fetches/decrypts everysingle listed fragment.

Consequence

It is hard for a peer storing a given fragment to discover which file itbelongs to, and therefore it is hard for them to decrypt them.



Freenet


Distributed Hash Tables (DHT)

Data structures based on key-value pairs (hashtable), distributed over anetwork of nodes.

Used for distributed storage in a general fashion (in particular for p2papplications).

Fully distributed, fault-tolerant and scalable system.

Data is accessed by a full, precise identifier (the key may be a hash of thename), does not allow keyword-based search.

Many variations exist on the same theme.



Freenet


Distributed Hash Tables (DHT)

Principle: the key space (hash space, address space) is partitionned so asto associate a node or cluster of nodes to each partition, in order to allowrouting. A distance operator is defined on the key space.

For instance, nodes might be labelled by numbers regularly distributed inthe key space (ni ), the node nk being responsible for the storage of allkeys situated between nk and nk+1 (in the ChordDHT version).

Operations: put(k, data) and get(k) queries are propagated in thenetwork up to the node responsible for the storage of this key.



Freenet


Overlay networks and key-based routing

To guarantee a proper routing, nodes must organise themselves in orderto ensure the following property:

For each key k and each node n, either n is responsible for thestorage of k or there is a node n′ among n’s neighbours whichis closer to k (in the sense of the distance within key space).

It is then easy to find a naive routing algorithm.

There is a trade-off between the number of neighbours for each node(which must remain limited to facilitate maintenance) and the length ofthe longest route. Most DHTs aim at a ©(log n)/© (log n) equilibrium(definition of a small world).



Freenet


The overlay network in Freenet

Nodes are given identifiers between 0 and 1;

Starting from a given configuration, one tries to reach a small worldconfiguration by swapping positions (in the darknet version) in orderto shorten the distance between neighbours (use ofMetropolis-Hastings algorithm);

Starting from a random topology (and from a random datadistribution on nodes), the network spontaneously evolves into astructure made of clusters and cliques hosting very similar keys.



Freenet


Data insertion (principle)

1 Reception of a put(k, data) query at node x ;

2 From this key, calculate a number xk in [0,1];

3 Put data in local cache;

4 If there is a neighbour x ′ such that d(x ′, xk ) < d(x , xk ), forward thequery to x ′.

x doesn’t know where the query originates from (but the query chaincan be rebuilt if enough nodes collude or are compromised);

x doesn’t know which nodes are going to store the fragment.



Freenet


Fragment fetching (principle)

Initialize neighbour markingReceive get(k) query from x0If corresponding data is in the local cache :send (k, data) to x0, end.

Else:If query TTL has expired:send back "failure", end.

Else:Mark x0, calculate x(k), decrement TTLWhile unmarked neighbours exist:Forward query to x’, neighbour closer to x(k)Mark x’Receive messageWhile message is get(k) from x’’:

Mark x’’, Send back "failure" to x’’End WhileIf message is (k, data):

Put (k, data) in local cacheSend (k, data) to x0, end.

If message is "failure":Continue

EndwhileEndif

Endif



Freenet


Signed Subspace Keys (SSK)

CHKs allow the management of static files.

SSKs allow the publication of data whose content change over time, butwhose authenticity must be ensured: freesites, typically.

Principle: at insertion time, the author generates both a symmetric keyfor encryption and an asymmetric DSA key pair for fragment signature.The public key is stored (encrypted) along with the fragments. SSK iscomposed of the hash (access key) of the public key (xxx), of asymmetric key (yyy), of crypto settings (zzz) and of a string serving as ahuman-readable identifier for the freesite.

SSK@xxx , yyy , zzz/sitename/



Tor

Anonymous communications: Tor

Tor = The Onion Router

Principle: make network packets transit by a number of nodes (machines)randomly selected, using multiple layers of encryption between nodes(hence the onion metaphor).

Tor is a network of machines (Tor nodes), with “entry nodes” and “exitnodes”, that everyone can use.



Tor




Tor




Tor

Establishing a Tor circuit from node A: principle

A chooses a sequence of nodes starting with an entry node (B) and endingwith an exit node, and fetches the public keys of the nodes in the circuit;

A internally associates to B a new circuit ID circIDAB ;

A sends a create message to B, containing circIDAB and the first half ofa Diffie-Hellman, encrypted with B’s public key;

B sends back a created, with the second half of the Diffie-Hellman and ahash of the session key KAB ;

A sends a relay extend message to B, designating C and giving the firsthalf of a Diffie-Hellman encrypted with C ’s public key;

B chooses a new circuit number circIDBC , which it internally associates tocircIDAB ;

B forwards the message to C in a create message labelled with circIDBC ;

C sends back a created message, which B forwards to A in the form of arelay extended message: A and C share KAC ;

etc.



Tor


Ensured properties

Client IP hidden from everyone except the entry node;

Message content and destination encrypted up to the exit node (asensitive point).

However. . .

Need to use a specific local proxy on the client machine;

Need to “torrefy” applications;

Very high latency, unsuitable for large data volumes;

No applicative anonymization: one can be identified by the contentof one’s communications;

Entry and exit nodes are public, and may be blacklisted.



Tor


Tor hidden services

Web sites or other kind of services, accessible only from Tor. A hiddenservice has a .onion URI, but no IP: no geolocalization, a prioricompletely anonymous.

Setting up a hidden service

1 The service provider chooses several introduction points among Tornodes, establishes circuits with them and sends them its public key;

2 The service provider creates a descriptor including its public key andthe list of introduction points, and signs it;

3 The service provider publishes the descriptor in a DHT, under aXXX.onion key where XXX is a 16-character string derived from itspublic key.



Tor

Access to a hidden service

1 The client knows the XXX.onion (obtained by the means of a searchengine, for instance: http://ahmia.fi/);

2 The client downloads the descriptor from the DHT;

3 The client chooses a node to serve as a rendez-vous point, itestablishes a circuit with it and sends it a session secret;

4 The client forges an introduction message, including the RDV pointand the session secret, encrypted with the service’s public key;

5 The client sends the introduction message to an introduction point(through a Tor circuit), which forwards it to the service provider;

6 The service provider decrypts the introduction message andestablishes a circuit to the RDV point, with which it authenticatesitself with the session secret;

7 The RDV point notifies the client, client and service provider maythen communicate with each other through their respective circuitsto the RDV point.



A glimpse of a few research works

“Privacy-aware” personal assistants

One of the main principles of research in privacy: ensure that the userscontrol their own data themselves and that their data are primarily storedon their own personal devices (avoid centralized, online solutions for datastorage and processing).

Introduction of the concept of software agent.

Personal agents (user agents): they are trusted with (personal) data, incharge of protecting them.




Automated reasoning on regulations

The issue

If a personal agent is in charge of properly protecting personal data, itmust be able to know what is permitted or forbidden to do with thesedata, including in the legal sense.

Symbolic AI techniques are used to represent and reason on norms, laws,regulations, contracts, policies. . .

Deontic logic, logical inference engines.

Hard problems

Conversion from a natural language expression to a formal languageexpression, inference of the “personal” aspects of data.




Distributed architectures and sticky policies

Search for integrated, distributed solutions for personal data protection.

Issue

How do we know whether the data we send to a third party are going tobe processed “properly” (regarding privacy)?

Very common principle: if we have a security policy relevant to thesedata, we forward it along with the data (sticky policy).

Ok, but what then?

Either we build a distributed application architecture (often prettycomplex, sometimes disproportionately so) imposing compliance withsticky policies, or we hope that the third party agent is of good faith. . .It is a matter of trust.




Usage control and trust levels

The issue of trust

When you send personal data (or other kind of sensitive information) toan entity, a person or a system, you necessarily base your decision onsome kind of trust relationship between you and them.

However, What and who do we trust, and is it really justified?





agent PAw système d'exploitation

agent distant

composant de traitement

matériel

tiers de confiance

confiance

certification

Level 1: Trust in remote agent






agent distant


matériel

tiers de confiance

confiance

certification

Level 2: Trust in remote OS






agent distant


matériel

tiers de confiance

confiance

certification

Level 3: Trust in remote hardware






agent distant


matériel

tiers de confiance

confiance

certification

Level 4: Trust in a certification authority





tiers de confiancespécialisé

agent utilisateur agent de service agent de service

10

1

2

34

5

6,11

89

7

interaction

interaction optionnelle

An architecture based on sticky policiesand Trusted Computing (M. Casassa Mont et al. 2003)



Conclusion

Conclusion on tools

Many specialized tools, no global protection.It is of utmost importance to understand what is protected or not by atool!The combination of two or more tools may or may not bear sense (thedevil is in the detail).

Research perspectives: it is often difficult to foresee which tools will leadto efficient and well-deployed tools (importance of market penetration,editor policies, funding hazards. . . ).



Conclusion

Security and privacy

Some means exist to increase privacy without harming securityproperties: authorization without identification, auditability withstrong pseudonymity. . . They only have to be used!

Importance of taking into account organizational and politicalaspects along with technical ones: everyone must be aware ofprivacy issues and goals;

Importance of Privacy by Design;

Importance to keep in mind:

Data sovereignty (or self-determination): give control to the user,decentralize to the maximum on user devices;Data minimization: finality and proportionnality, need-to-know,data destruction as soon as possible.



Conclusion

Future rights and challenges?

To be foreseen/defined/implemented:

Right to be forgotten/to oblivion;

Right to lie, to approximation;

Right to repudiation;

Right to data portability. . .



Sources & credits

Y. Deswarte, Protection de la vie privee : principes et technologies (transparents), Supelec2013 ;

L. Me & R. Chaillat, Le commerce electronique : un etat de l’art, In Annales destelecommunications, 53(9-10), pp. 361-376, octobre 1998 ;

A. Quenolle, Les evolutions du Reglement du Parlement Europeen et du Conseil relatif a laprotection des personnes physiques a l’egard du traitement des donnees a caracterepersonnel, http://www.myprivacyspace.net/, 2012.

– Erik S. Lesser, In A Face Is Exposed for AOL Searcher No. 4417749, New York Times,http://www.nytimes.com/, 2006 ;

– Hay Kranen Mondrian lookalike.svg, 2007 (CC-BY 2.5, Wikimedia Commons) ;

– OpenID Foundation, http://www.openid.net/ ;

– The Freenet Project, http://freenetproject.org/ (GFDL 1.3) ;

– The Tor Project, Inc., http://www.torproject.org/ (CC-BY 3.0).


http://www.myprivacyspace.net/evolutions-du-reglement-europeen-relatif-aux-donnees-a-caractere-personnel/

http://www.nytimes.com/2006/08/09/technology/09aol.html

http://www.openid.net/

http://freenetproject.org/

http://www.torproject.org/

Date post:	26-Feb-2022
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times

Introduction to privacy protection Part 3 - Privacy

Documents