domain: info shs

text:
Tamara Rezk

Ilaria Castel- Lani

Manuel Serrano

Gaetan Goldberg

Paul-Olivier Dehaye

Frederik Zuiderveen Borgesius

Anna Buchta

Max Schrems

Vincent Toubiana

Estelle Hary

Armand Heslot

Francois Pelligrini

Gábor Gulyás

Claude Castelluccia

Arnaud Legout

Vincent Roca

Mathieu Cunche

Daniel Le Metayer

Tania Jenya

Julie Nicolas

and Bertrand Serpette -they quickly became not only colleagues but good friends. Big thank you also goes to the ANR for awarding me the ANR JCJC PrivaWeb

Chapter 1 Overview

This HDR manuscript is organised as follows. Each of the follow-up chapters introduces the concept or a problem in a studied domain first, followed by the "dream" -that is, the desired state of the world -and the "reality" -underlying the problems in the area at a high level. The contributions in the research area are then presented, and followed by open challenges that still need to be addressed.

In the text, citations to my own work since 2012 appear in plain style as in [19] whereas citations to other works appear in alpha style as in [AEE + 14b].

Chapter 2: Web Application Security describes early works that started immediately after my PhD in 2012, and which we continued in 2016-2017. This chapter covers the following publications: [START_REF] Bielova | Survey on JavaScript security policies and their enforcement mechanisms in a web browser[END_REF] N. Bielova. Survey on JavaScript security policies and their enforcement mechanisms in a web browser. Special Issue on Automated Specification and Verification of Web Systems of Journal of Logic and Algebraic Programming (JLAP), 82 [START_REF] Bielova | Short paper: Dynamic leakage: A need for a new quantitative information flow measure[END_REF]:243 -262, 2013. https://doi.org/10.1016/j.jlap.2013.05.001 [START_REF] Somé | On the content security policy violations due to the same-origin policy[END_REF] D. F. Somé, N. Bielova, and T. Rezk. On the content security policy violations due to the same-origin policy. In Proceedings of the 26th International Conference on World Wide Web, (WWW 2017), pages 877-886. ACM, 2017. https://hal.inria.fr/hal-01649526 Chapter 3: Information Flow Monitors describes research we carried out between 2012 and 2017, both during my postdoc at Inria Rennes and in my early career in Inria Sophia Antipolis. This chapter covers the following publications:

[3] F. Besson, N. Bielova, and T. Jensen. Hybrid information flow monitoring against web tracking. In IEEE Computer Security Foundations Symposium (CSF 2013), pages 240-254. IEEE, 2013. https: //hal.inria.fr/hal-00924138 [START_REF] Besson | Browser Randomisation against Fingerprinting: A Quantitative Information Flow Approach[END_REF] F. Besson, N. Bielova, and T. Jensen. Browser Randomisation against Fingerprinting: A Quantitative Information Flow Approach.

Chapter 2 Web Application Security

Web applications today provide a variety of services to its users. The Web browser has become a virtual machine that received and executes various interactive applications from different stakeholders. These Web applications today implement complex interactions between multiple types of code and data, often directly or indirectly obtained from the Web users.

The Dream While Web browsers are a gateway between multiple stakeholders whose code composes a Web application and end users, browsers should provide proper protection mechanisms to ensure that (i) different sources of Web application cannot interfere with each other in non-authorised ways; (ii) the secret data of the Web users are adequately protected from the Web attacks.

The Reality Web applications are complex because they consists of multiple sources of code [NIK + 12]. Every source can have its own security policy [RBC + 20], and other security mechanisms are enforced directly in the Web browser. Researchers have been proposing solutions to monitor the execution of JavaScript code directly in the browser [START_REF] Hedin | Information-flow security for a core of JavaScript[END_REF][START_REF] Bielova | Survey on JavaScript security policies and their enforcement mechanisms in a web browser[END_REF] and security policies a browser should implement by default. In reality, proposed research solutions are often partial and don't provide well-defined security guarantees, while browser security policies are inconsistent with each other [2, CUT + 21], thus making Web applications vulnerable to Web attacks.

Security Enforcement of JavaScript applications

JavaScript is one of the most used scripting languages on Web. JavaScript code is most often fetched from a remote server: there were 24.48% new inclusions in 2001, and this number grew to 45.46% in 2010 [NIK + 12]. When a remote JavaScript code is included into a web page, it gets the same privileges as any other code inlined in the page. These privileges give JavaScript code the power to perform malicious actions, violating the user's privacy and security. For example, malicious scripts can access the secret user data on the web page and send it to remote servers, or hijack the user's session and perform requests on behalf of the Web user.

Prior research developed verification techniques for JavaScript programs that answer the question "Does your program comply with the security policy?", while more recent security runtime enforcement techniques have been developed -such techniques do not answer the above question but decide whether a given execution of the program satisfies the policy, and can also fix [START_REF] Bauer | Edit automata: Enforcement mechanisms for run-time security policies[END_REF][START_REF] Bielova | Do you really mean what you actually enforced[END_REF] it in case of non-compliance 1 . The first step in securing JavaScript applications consists in identifying the sources of information that must be protected. In case of Web applications, these sources in different research papers have been identified via core DOM objects [START_REF] Singh | On the incoherencies in web browser access control policies[END_REF] and HTML5 APIs [W3C12] accessible to scripts. Two groups of techniques have been developed to protect security-critical objects and APIs: runtime monitoring and information flow control.

The need for systematisation of knowledge. Dynamic techniques based on runtime monitoring [HV05, YCIS07, DdSC09, ML10] observe the program execution and check whether this execution satisfies the security policies in question. These techniques are known to enforce a class of security policies that are based on a single program execution. Secure information flow control techniques [VNJ + 07, CMJL09, LZW10, AF12, HS12] propose program analysis (either static, dynamic or hybrid -see further works in Section 3.1) to find the flows of information inside the program. A particular definition of security policy enforced by these techniques is non-interference. It states that no secret inputs to the program can influence publicly observed outputs. Since it is not possible to detect such information flows by observing only one program execution, the definition of non-interference is based on two program executions.

While these groups of techniques often implemented in practice via modifications of JavaScript engine, using code rewriting or with browser extensions, these works have not been compared against each other with respect to the security properties they enforce and formal security guarantees they provide. Each state-of-the art literature provides a new technique without rigorously comparing it to recent works, thus leaving the reader doubtful as to the formal security guarantees each technique provides.

Survey on JavaScript security. In a single-authored survey [START_REF] Bielova | Survey on JavaScript security policies and their enforcement mechanisms in a web browser[END_REF], we analyse and compare the research literature on security enforcement for JavaScript programs by mapping the works into two groups: runtime enforcement and information flow control. Table 2.1 presents a high level overview of the comparison done in the survey.

This survey was the first to cover both theoretical aspects of enforcement and practical considerations of the web browser architecture. The survey has successfully achieved its goal to introduce the field of Web application security to new researchers and has been cited in numerous papers and surveys on Web security.

Web Browser Security

Modern browsers implement different specifications to securely fetch and integrate content. One widely used specification to protect content is the Same Origin Policy (SOP) [Sam]. SOP allows developers to isolate untrusted content from a different origin. Intuitively, SOP is a mechanism that governs interactions between resources of web pages and protects undesired access between page sources of different origins.

A more recent specification to protect content in web pages is the Content Security Policy (CSP) [START_REF] Stamm | Reining in the web with content security policy[END_REF]. CSP is a mechanism designed to mitigate popular web vulnerabilities, such as cross site scripting attacks (XSS), data leaks attacks, and other types of attacks. CSP allows developers to specify, among other features, trusted domain sources from which to fetch content. One of the most important features of CSP is to allow a web application developer to specify trusted JavaScript sources. This kind of restriction is meant to permit execution of only trusted code and prevent untrusted code to access content of the page. In our work [START_REF] Somé | On the content security policy violations due to the same-origin policy[END_REF], we have reported a fundamental problem of CSP described be-low. CSP [START_REF] West | Content Security Policy Level 2. W3C Candidate Recommendation[END_REF] defines how to protect content in an isolated page. However, it does not take into consideration the page's context, that is its embedder or embedded content. In particular, CSP is unable to protect the page CSP is settled for if the page embeds other content of the same origin. The problem occurs because the CSP policy of a page will not be applied to an embedded content. However, due to SOP, the embedded content has complete access to the content of its embedder. Because same origin embedded content are transparent due to SOP, this opens loopholes to attackers whenever the CSP policy of an embedded content is not compatible to the one of its embedder page (see Fig. 2.1).

We analysed 1 million pages from the top 10,000 Alexa sites and found that 5.29% of sites contain some pages with CSPs [START_REF] Somé | On the content security policy violations due to the same-origin policy[END_REF]. We have identified that in 94% of cases, CSP may be violated in presence of the document.domain API and in 23.5% of cases CSP may be violated without any assumptions. Having found such possible violations on 46 popular websites, including mail.ru, amazon.com, twitter.com and others, we reported this problem to website owners. All our crawling data is publicly available at http://webstats.inria.fr/ ?cspviolations [SRB].

We discussed measures to avoid CSP violations in web applications by installing an origin-wide CSP and embedding content with sandboxed iframes. During our study, we also identified a divergence among browsers implementations in the enforcement of CSP in specific type of embedded content, called srcdoc sandboxed iframes -this divergence revealed a problem in Gecko-based browsers CSP implementation and appeared to be a bug in Mozilla Firefox browsers. To ameliorate the problematic conflicts of the security mechanisms, we discussed measures to avoid CSP violations. Information flow control can also be done dynamically, as Fenton proposed back in 1974 [START_REF] Fenton | Memoryless subsystems[END_REF]. This approach again gained attention in 2000s, when researchers proposed information flow monitors [Zda02, LGBJS06, LG08, RS10, AF10, DP10], that are able to make a verdict about a single execution of an otherwise insecure program and stop it as soon as a potential violation of noninterference is detected. This approach has become particularly popular for dynamic languages, such as JavaScript [START_REF] Hedin | Value-sensitive Hybrid Information Flow Control for a JavaScript-like Language[END_REF][START_REF] Hedin | Information-flow security for a core of JavaScript[END_REF], where precise static analysis is practically impossible.

The Dream Information flow monitors must provide a strong security guarantee of soundness -that a monitor never allows public program outputs to leak secret inputs. However, this is not enough: a monitor might block all executions of the program, and still be sound. Therefore, the monitor should better accept all noninterferent executions, thus ensuring the formal guarantee of transparency1 [BLW05, Erl03, HMS06, LBW09, B12].

The Reality

The notion of noninterference does not apply to one single execution, but to a a set of executions. Therefore it is not possible to reason about each execution in isolation, and it is impossible for information flow monitor to be sound and fully transparent at the same time. The research community therefore compares sound monitors against each other in order to formally prove which monitor accepts more noninterferent executions, and defines this as relative permissiveness [Gue07, AF12, AF10, HBS15].

Hybrid monitoring of attacker knowledge

Hybrid information flow monitors complement an analysis of one program execution with static analysis of other, non-executed branches of the code to detect possible implicit information flows. Several models of hybrid monitors have been proposed in the early 2000 [LG08, LGBJS06, RS10].

Computing attacker's knowledge with hybrid monitors

While monitoring the execution of a program, an attacker can gain a certain amount of knowledge about the secret inputs to the program. The notion of attacker's knowledge has been proposed [START_REF] Askarov | Gradual release: Unifying declassification, encryption and key release policies[END_REF][START_REF] Askarov | Learning is change in knowledge: Knowledge-based security for dynamic policies[END_REF] to define the security conditions of monitors, but have not been used to enforce noninterference.

We have proposed a new model of a hybrid information flow monitor that estimates the knowledge of the attacker about the secret program inputs [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF]. This new class of monitors, called hybrid monitors, are based on a combination of dynamic and static program analysis, and compute how much information about the secret input has been leaked in the program output. We prove that four versions of such monitors never underestimate the attacker's knowledge (soundness) and prove which of the four monitors are more precise than others (in modelling the attacker's knowledge more precisely). All theorems are proven within Coq proof assistant. Given the same initial memory where h1 = false and h2 = true, our first hybrid monitor [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF] computes the knowledge in the output x. The first test on h1 fails, thus the value of y remains unchanged and the knowledge of y is ¬h1. Upon the second test, the monitor concludes that the value of x is 1 in the true branch and 0 in the false branch. As the values are not the same, the knowledge of the output x=1 might depend on h2 and on the knowledge of y. Therefore, the knowledge proved that dynamic and hybrid monitors are incomparable in their permissiveness, we show that a knowledge-hybrid monitor is capable to be provable more permissive than dynamic monitors.

computed by the monitor [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF] is: Approximated knowledge by [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF]:¬h1 ∧ h2

The approximated knowledge is much less precise than the real attacker knowledge. The reason for this gap between estimated and actual knowledge is in the choice of the model of knowledge domain. Intuitively, the knowledge in [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF] is limited to a set of environments that can contribute to the current value of x.

Improving permissiveness of hybrid monitors

It would be expected that hybrid monitors are more permissive than their dynamic counterparts: hybrid monitors should recognize more noninterferent executions2 thanks to the static analysis they rely on for non-executed branches of the program. However, Hedin et al. [START_REF] Hedin | Value-sensitive Hybrid Information Flow Control for a JavaScript-like Language[END_REF]Theorems 2,[START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF] have proven that hybrid and dynamic monitors are incomparable in their permissiveness.

We extended our hybrid monitor [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF] with a more expressive representation of attacker knowledge, build from the one program execution and enhanced static analysis of non-executed branches. We thus have proposed a new family of monitors that profit from the modeled attacker knowledge, that we refer to here as knowledge-hybrid monitors [START_REF] Besson | Hybrid monitoring of attacker knowledge[END_REF]. Such monitors are able to enforce noninterference more permissively thus allowing more executions of programs than previous hybrid monitors [START_REF] Hedin | Value-sensitive Hybrid Information Flow Control for a JavaScript-like Language[END_REF]. Figure 3.1 demonstrates that our knowledge-hybrid monitor is provably more permissive than purely dynamic or purely static approaches.

Moreover, the knowledge-hybrid hybrid monitor is based on a more sophisticated static analysis that much more closely replicates the analysis provided by a dynamic counterpart of the monitor (see a single semantics for static and dynamic analysis in [START_REF] Besson | Hybrid monitoring of attacker knowledge[END_REF]Fig. 3]). As a result, the knowledge-hybrid monitor is able to compute an attacker's knowledge much more precisely.

Example 2.

Consider again an execution of Program 1 from Example 1 when its secret inputs are h1 = false and h2 = true. When Program 1 outputs 1, the attacker learns that either h1 or h2 was true, and the knowledge-hybrid monitor [START_REF] Besson | Hybrid monitoring of attacker knowledge[END_REF] computes the knowledge precisely: Actual attacker's knowledge as computed by [START_REF] Besson | Hybrid monitoring of attacker knowledge[END_REF]: h1 ∨ h2

Application to browser fingerprinting

A browser fingerprint is a set of information related to a user's device from the hardware to the operating system to the browser and its configuration. Browser fingerprinting refers to the process of collecting information through a web browser to build a fingerprint of a device [START_REF] Laperdrix | Browser Fingerprinting: Exploring Device Diversity to Augment Authentication and Build Client-Side Countermeasures[END_REF]. Passive fingerprinting relies on the HTTP headers and other information a server received together with HTTP requests. Active fingerprinting is performed via a JavaScript code executed in a Web browser, from a wide variety of information from public browser APIs. Browser fingerprinting can uniquely identify a Web user and consequently trace her across the Web.

The hybrid information flow monitors that estimate the knowledge of the attacker that we proposed [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF][START_REF] Besson | Hybrid monitoring of attacker knowledge[END_REF] could be used to detect active fingerprinting if extended to JavaScript language. Following the standard information theory definition of self-information or surprisal used by Eckersley in his state-of-the art paper on browser fingerprinting [START_REF] Eckersley | How Unique is Your Web Browser[END_REF] and other follow-up works, we proposed to adopt it to the attacker knowledge. If the probability of a browser feature f to have a value v is P (f = v), then the self-information is:

I(f = v) = -log 2 P (f = v) (3.1)
If we label all browser features used for fingerprinting as secret program inputs, then our hybrid monitor can detect at the execution time when a JavaScript program performs browser fingerprinting. The monitor observes an execution of a JavaScript program and analyses how much information (in terms of browser and OS features) the program is collecting. The more identifying information the program collects, the more likely it is performing browser fingerprinting.

Example 3. Consider again Program 1 from Example 1.

We assume the following probabilities for fingerprinting features h1 and h2: P (h1) = 0.21 (e.g., a test on a "FireFox" browser name) and P (h2) = 0.01 (e.g., a test on a time zone). In this simple example we assume that the browser features are independent, and therefore P (h1 ∧ h2) = P (h1) • P (h2).

The first hybrid monitor [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF] models the knowledge of the attacker as ¬h1 ∧ h2 and hence, P (¬h1 ∧ h2) = P (¬h1) • P (h2) = 0.0079

Therefore the information leakage the attacker is modeled to receive is

I(¬h1 ∧ h2) = -log 2 P (¬h1 ∧ h2) = 6
.98 bits However, the real knowledge is properly modeled by an advanced monitor [START_REF] Besson | Hybrid monitoring of attacker knowledge[END_REF]:

P (h1 ∨ h2) = 1 -P (¬h1) • P (¬h2) = 0.2179
Therefore the actual attacker's knowledge contains much less information:

I(h1 ∨ h2) = -log 2 P (h1 ∨ h2) = 2.

bits

Browser randomisation against fingerprinting. Several works showed that restricting access to browser fingerprinting APIs or stopping executions of JavaScript programs may not work work in practice [AJN + 13b]. Therefore, several approaches directed at randomisation of browser features have been proposed [START_REF] Boda | Firegloves[END_REF][START_REF] Nikiforakis | Privaricator: Deceiving fingerprinters with little white lies[END_REF]. Nevertheless, none of the proposed approaches have provided privacy guarantees that even with randomisation in place the probability of identifying a user is bounded by a certain threshold. We used information-theoretic channels to model the knowledge of the tracker and the fingerprinting program, and show how to synthesise a randomisation mechanism that defines the distribution of configurations for each user [START_REF] Besson | Browser Randomisation against Fingerprinting: A Quantitative Information Flow Approach[END_REF]. Our randomisation mechanism provides a strong guarantee of privacy (that the probability of identifying the user is bounded by a given threshold) while maximising usability (thus minimizing the number of time the user has to switch to other configurations).

Challenge: The need for a new quantitative information flow measure

Differently from dynamic or hybrid monitors that enforce an all-or-nothing property of noninterference [Zda02, AF10, DP10, AF12, HBS15], our hybrid information flow monitors [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF][START_REF] Besson | Hybrid monitoring of attacker knowledge[END_REF] are more general as they rely on the definition of measure for quantifying information leakage.

A number of definitions for such a measure has been proposed in the scientific An interesting aspect of the proposed definitions is that all of them measure a program as a whole. In other words, they evaluate how much information is leaked on average by all possible program outputs. We will call these measures "average measures". To analyse the leakage of a program as a whole, average measures were previously used by a number of works on static program analysis [BKR09, KR10] and even approximated by a dynamic analysis [START_REF] Mccamant | Quantitative information flow as network flow capacity[END_REF]. While these measures perfectly fit for static program analyses, they cannot be used by dynamic analyses since they do not specify what information an attacker learns through observing one concrete program output. An alternative approach to measure information leakage is to reason about attacker's accuracy in his belief about the secret [CMS09]. This belief tracking measure evaluates the leakage for a concrete secret, and a concrete program output.

We have studied and compared all existing definitions to find a suitable definition for quantitative information flow analysis [START_REF] Bielova | Short paper: Dynamic leakage: A need for a new quantitative information flow measure[END_REF]. Figure 3.2 graphically shows the difference in the definitions of existing measures. A definition of dynamic leakage should evaluate how much information an attacker learns when she observes one program output.

Conclusion

We found out that a suitable measure for dynamic leakage exists only for deterministic programs. This work hence opened a new research question in quantitative information flow area that needs to be addressed by the community: Which definition of dynamic leakage for one program output is suitable for probabilistic programs? Soundness does not allow any insecure executions, but says nothing about secure ones. Transparency requires to allow all secure executions.

Taxonomy of information flow monitors

In early 2010, dynamic enforcement mechanisms gained attention and became used for controlling information flow in JavaScript programs [HS12, SR14, MSR14, DP10, AF12]. Given the dynamic nature of the proposed solutions, we can apply mathematical definitions for reasoning about the security guarantees derived from the well-studied theory of runtime monitoring [START_REF] Bauer | Edit automata: Enforcement mechanisms for run-time security policies[END_REF][START_REF] Erlingsson | The Inlined Reference Monitor Approach to Security Policy Enforcement[END_REF][START_REF] Bielova | A theory of constructive and predictable runtime enforcement mechanisms[END_REF]. The two main notions that have been proposed are:

• soundness that the monitor always prevents information leaks about secret inputs, and • transparency that the monitor does not block executions that do not leak secret information3 . Figure 3.3 proposes a very simplified view of soundness and transparency. In simple terms, a monitor is a recognizer of noninterferent (we call them here secure) executions of a program, similarly to recognizers in pattern recognition 4 . The goal of the monitor is to block all insecure executions, thus complying with the principle of soundness. Orthogonal to soundness, a monitor has a second goal: to accept as many secure executions as possible, and in the best case all of them, thus achieving full transparency.

However, since dynamic information flow monitors enforce noninterference, which is a property of a set of executions [START_REF] Clarkson | [END_REF], they are not able to be sound and transparent at the same time. To improve the situation, several hybrid approaches have been proposed, and approaches based on multi-execution5 .

Precision, permissiveness and transparency

A number of works on dynamic information flow monitors try to analyse precision of monitors. Intuitively, precision describes how often a monitor blocks (or modifies) secure programs. Different approaches have been taken to compare precision of monitors, using definitions such as "precision", "permissiveness" and "transparency". We propose a rigorous comparison of these definitions in this section, originally published in [START_REF] Bielova | A taxonomy of information flow monitors[END_REF]Section 6].

Precision (versus well typed programs) Le Guernic et al. [START_REF] Le Guernic | Automatabased Confidentiality Monitoring[END_REF] were among the first to start the discussion on transparency for information flow monitors. The authors have proved that their hybrid monitor accepts all the executions of a program that is well typed under a flow-insensitive type system similar to the one of Volpano et al. [START_REF] Volpano | A sound type system for secure flow analysis[END_REF]. Le Guernic [START_REF] Guernic | Confidentiality Enforcement Using Dynamic Information Flow Analyses[END_REF] names this result as partial transparency. Russo and Sabelfeld [START_REF] Russo | Dynamic vs. static flow-sensitive security analysis[END_REF] prove a similar result: they show that a hybrid monitor accepts all the executions of a program that is well typed under the flow-sensitive type system of Hunt and Sands [START_REF] Hunt | On flow-sensitive security types[END_REF].

Precision (versus secure programs) Devriese and Piessens [START_REF] Devriese | Non-interference through secure multiexecution[END_REF] propose a stronger notion, called precision, that requires a monitor to accept all the executions of all secure programs. Notice that this definition is stronger because not only the monitor should recognise the executions of well typed programs, but also of secure programs that are not well typed. Devriese and Piessens have proven that such precision guarantee holds for Secure-Multi Execution (SME) monitor [START_REF] Devriese | Non-interference through secure multiexecution[END_REF].

Transparency (versus secure executions) As a follow-up, Zanarini et al. [START_REF] Zanarini | Precise enforcement of confidentiality for reactive systems[END_REF] have proven that another monitor based on SME satisfies transparency. This monitor accepts all the secure executions of a program, even if the program itself is insecure.

Permissiveness (versus executions accepted by other monitors)

In his PhD thesis, Le Guernic [START_REF] Guernic | Confidentiality Enforcement Using Dynamic Information Flow Analyses[END_REF] compares his hybrid monitor with another hybrid monitor that performs a more precise static analysis, and proves an improved precision theorem stating that whenever the first hybrid monitor accepts an execution, the second monitor accepts it as well. Following this result, we investigated other hybrid monitors [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF] (see Section 3.1) and have proven their relative precision in the style of Le Guernic, while Austin and Flanagan [START_REF] Austin | Permissive dynamic information flow analysis[END_REF][START_REF] Austin | Multiple facets for dynamic information flow[END_REF] use the same definition to compare their dynamic monitors. Hedin et al. [START_REF] Hedin | Value-sensitive Hybrid Information Flow Control for a JavaScript-like Language[END_REF] name the same notion by permissiveness and compare the sets of accepted executions: one monitor is more permissive than another one if its set of accepted executions contains a set of accepted executions of the other monitor.

Comparison of information flow monitors

Relative true and false transparency, relative precision

To compare precision of different information flow monitors, we proposed to distinguish two notions of transparency [START_REF] Bielova | A taxonomy of information flow monitors[END_REF]. True transparency defines the secure executions accepted by a monitor, and false transparency defines the insecure executions accepted by a monitor. We found that none of the studied information flow monitors are true transparent for termination-insensitive noninterference. Nevertheless, the notion of true transparency allows us to define a relative true transparency to better compare the behaviours of information flow monitors when they deal with secure executions.

Intuitively, one monitor A is more true transparent than monitor B, if A accepts allows more secure terminating executions than B without modifications. Similarly, a monitor A is more false transparent than monitor B, if A accepts allows more insecure terminating executions than B without modifications.

We have discovered that certain monitors are incomparable with respect to true transparency. To compare them, we proposed a more coarse-grained definition that describes the monitors' behaviour on secure programs. Similarly to the notion of permissiveness [START_REF] Hedin | Value-sensitive Hybrid Information Flow Control for a JavaScript-like Language[END_REF] and precision [START_REF] Devriese | Non-interference through secure multiexecution[END_REF], we proposed to reason about secure programs instead of secure executions. To do so, we first define a set of secure programs P , where a monitor A accepts all the executions of P , that we denote by P(A). Intuitively, relative precision is defined as follows. A monitor A is more precise than a monitor B, if A accepts all executions of more secure programs than B, that is P(A) ⊇ P(B).

We compare previous notions of precision, permissiveness and transparency to our formalisation [START_REF] Bielova | A taxonomy of information flow monitors[END_REF] and summarize our findings in Table 3.1.

Rigorous analysis of five monitors

We rigorously analysed [START_REF] Bielova | A taxonomy of information flow monitors[END_REF] five widely explored information flow monitors: no-sensitive-upgrade (NSU) [START_REF] Zdancewic | Programming languages for information security[END_REF], permissiveupgrade (PU) [START_REF] Austin | Permissive dynamic information flow analysis[END_REF], hybrid monitor (HM) [START_REF] Guernic | Automata-based confidentiality monitoring[END_REF], secure multi-execution Table 3.1: Definitions for comparing information flow monitors from the related works and their relation to our formalisation: true and false transparency [START_REF] Bielova | A taxonomy of information flow monitors[END_REF].

Definition from the literature

Our formalisation [START_REF] Bielova | A taxonomy of information flow monitors[END_REF] Permissiveness [START_REF] Hedin | Value-sensitive Hybrid Information Flow Control for a JavaScript-like Language[END_REF] Relative true transparency + relative false transparency Precision [START_REF] Devriese | Non-interference through secure multiexecution[END_REF] True transparency for all the executions of a secure program Relative Precision (this paper)

Relative true transparency for all the executions of a secure program Transparency [START_REF] Bauer | Edit automata: Enforcement mechanisms for run-time security policies[END_REF] True transparency (SME) [START_REF] Devriese | Non-interference through secure multiexecution[END_REF], and multiple facets (MF) [START_REF] Austin | Multiple facets for dynamic information flow[END_REF], that (at the time of writing) were well-established as state-of-the-art in the foundational security community. We proposed a fine-grained approach to compare and contrast information flow monitors with respect to their security guarantees [START_REF] Bielova | A taxonomy of information flow monitors[END_REF].

We have then further analysed two most widely used information flow control mechanisms, based on multi-execution, that were believed to be the equivalent: secure multi-execution (SME) [START_REF] Devriese | Non-interference through secure multiexecution[END_REF] and multiple facets (MF) [START_REF] Austin | Multiple facets for dynamic information flow[END_REF]. We found a number of fundamental differences in their design and security guarantees [START_REF] Bielova | Spot the difference: Secure multiexecution and multiple facets[END_REF].

Finally, we have then analysed and proposed extensions [START_REF] Ngo | A better facet of dynamic information flow control[END_REF] to the multiple facets (MF) [START_REF] Austin | Multiple facets for dynamic information flow[END_REF], that has been proven to be a good fit for implementing information flow security for JavaScript. Our extension can be used for more complex security policies, optimized the number of multi-executions and has stronger security guarantees than MF.

Challenge: The research community needs to use one unified framework to compare information flow monitors

Our work [START_REF] Bielova | A taxonomy of information flow monitors[END_REF] demonstrated that various information flow monitors have been proposed in the latest years [Zda02, AF10, AF12, DP10, 9], yet when new monitor is proposed, it is rarely rigorously evaluated against previously known monitors.

The notion of soundness only ensures that insecure executions are never allowed by the monitor (see Fig. 3.3), however what distinguishes the monitors is their ability to allow secure executions (of otherwise insecure programs) without modifications 6 .

The notion of transparency helps to reason about monitors, while it is impossible to achieve for noninterference. Therefore, notions of relative transparency -such as relative false transparency and relative true transparency, and relative precision defined in [7, Section 6] -can help researchers to compare monitors between themselves.

Conclusion.

While comparing effectiveness of various pattern recognition systems (such as, for example, face recognition systems) against each other is a common approach in the corresponding research community, this is not the case yet in language-based security research community. The community needs to strive for robust comparisons with respect to soundness and relative transparency and precision when evaluating novel information flow monitors against existing monitors.

Chapter 4 Web Tracking Technologies

The Web has become an essential part of our lives: billions are using Web applications on a daily basis. While the users browse the web, they are leaving digital traces on millions of websites [EN16a, NKJ + 13a]. Such traces allow third-party advertising companies and data brokers to continuously profit from collecting a vast amount of data associated to the users. At the same time, the users do not have much control of who is collecting their data and for what purpose. Recent research has shown that such third parties use a wide range of techniques in order to track users across the Web [SCM + 10, RKW12, AWS + 11, OTC14, EN16a, Eck10a, AJN + 13b, NKJ + 13a, LSKR16, DPS20]. These techniques can be used to reconstruct browsing sessions and to create profiles of users, inferring, among others, their hobbies, health status, political inclinations, and level of wealth.

The Dream To escape Web tracking, users decide to use privacy-preserving browsers or install browser extensions. To protect users, browser vendors and extensions rely on either filter lists of known trackers [EL, EP, Disc] or detecting trackers by their behaviour [START_REF] Roesner | Detecting and defending against third-party tracking on the web[END_REF]14,[START_REF] Lerner | Internet jones and the raiders of the lost trackers: An archaeological study of web tracking from 1996 to[END_REF]. Users would prefer that such tools block all unneeded (for users) tracking when they visit websites.

The Reality Protection from tracking is often not effective because trackers re-create cookies after deletion [SCM + 10, AWS + 11] or integrate them into functional third-party content [14]. Moreover, because of a Real-Time-Bidding process [START_REF] Bashir | Tracing Information Flows Between Ad Exchanges Using Retargeted Ads[END_REF] in targeted advertisement, third-parties synchronize cookies between them, in order to merge users' data collected across websites and via different trackers [AEE + 14b, EN16a]. As of today, there is no common methodology that allows to distinguish cookies useful cookies from unneeded tracking cookies. Alternatively, browser fingerprinting [13] allows to track users without storing any identifier in the user's browser [START_REF] Eckersley | How unique is your web browser?[END_REF][START_REF] Laperdrix | Beauty and the Beast: Diverting modern web browsers to build unique browser fingerprints[END_REF]. Finally, users can be uniquely identified only by the browser extensions that have installed to protect themselves [12].

Cookie-based tracking: detection and protection

In the last decade, numerous studies measured prevalence of third-party trackers on the Web [RKW12, AJN + 13b, NKJ + 13a, EN16a, LSKR16, BARW16, YMMP16, BW18, LN18, LGN18]. Web Tracking is often considered in the context of targeted behavioral advertising, but it's not limited to ads. Third-party tracking has become deeply integrated into the Web contents that owners include in their websites.

But how to recognize that a third-party request is performing tracking? To detect trackers, the research community applied a variety of methodologies. The most known Web tracking technique is based on cookies, but only some cookies contain unique identifiers and hence are capable of tracking the users. Some studies detect trackers by analysing cookie storage, and third-party requests and responses that set or send cookies [START_REF] Roesner | Detecting and defending against third-party tracking on the web[END_REF][START_REF] Lerner | Internet jones and the raiders of the lost trackers: An archaeological study of web tracking from 1996 to[END_REF], while other works measured the mere presence of third-party cookies [START_REF] Libert | Third-party web content on eu news sites: Potential challenges and paths to privacy improvement[END_REF][START_REF] Libert | Changes in third-party content on european news websites after gdpr[END_REF]. To measure cookie syncing -a technique that allows two different trackers to match their tracking cookies -researchers applied various heuristics to filter cookies with unique identifiers [AEE + 14b, ERE + 15, EN16a]. However, this approach has never been applied to detect tracking at large scale. Overall, previous works provide different methods to identify third-party requests that are responsible for tracking [START_REF] Roesner | Detecting and defending against third-party tracking on the web[END_REF][START_REF] Yu | Tracking the trackers[END_REF].

Detection of unique identifiers stored in cookies and analysing behaviors of third-party domains is a complex and time-consuming task. Therefore, most of the state-of-the-art works, as well as popular ad-and tracking-blocking browser extensions1 rely on filter lists. In particular, EasyList [EL] and EasyPrivacy [EP] (EL&EP) and Disconnect [Dis] lists became the de facto approach to detect third-party tracking requests in privacy and measurement communities [EN16a, BARW16, LCA + 17, RNV + 18, IAK + 17, EHN18, BW18, BAK + 18, ISPL18]. We summarize the usage of filter lists in security, privacy and web measurement community in Table 4.1.

Nevertheless, filter lists detect only known tracking and ad-related requests. Therefore, a tracker can avoid this detection by using a different subdomain for tracking, or register a new domain if the filter list blocks the entire domain. Third parties can also incorporate tracking behavior into functional website content, which is never blocked by filter lists because blocking functional content would harm user experience. Therefore, it is important to evaluate how effective are filter lists at detecting trackers, how many trackers are missed by the research community in their studies, and whether filter lists should still be used as the default tools to detect trackers at scale. 12]. "Detect" column describes how EL&EP were used to detect trackers: whether the filter lists were applied on all requests ("Req"), on requests and follow-up requests that would be blocked ("Req+F") or whether filter lists were further customised before being applied to the dataset ("Custom"). In the column "Depend", by "Rely" we denote that EL&EP are used to build their results, while "Verify" means that EL&EP lists are used to verify the results.

Detecting cookie syncing and ID sharing

We propose a new, fine-grained behavior-based tracking detection [14]. Our alternative method to detect trackers is inspired by analyzing behavior (HTTP(S) request and responses) that lead to loading invisible pixels when visiting websites. Since invisible pixels have no particular functionality, we use them as perfect suspects for tracking in this research. By crawling 84,658 webpages from top Alexa 8,744 domains, we detect that third-party invisible pixels are widely deployed: they are present on more than 94.51% of domains and constitute 35.66% of all third-party images. Cumulative function of the number of pixels in images with a contentlength less than 100 KB. Out of 2M images, 36% are invisible: 9% have no content and 27% are of size 1 × 1 pixel.

We propose a fine-grained behavioral classification of tracking based on the analysis of invisible pixels, inspired by Roesner et al. [START_REF] Roesner | Detecting and defending against third-party tracking on the web[END_REF]. We use this classification to detect new categories of tracking and uncover new collaborations between domains on the full dataset of 4,216,454 third-party requests. While interested readers can check the classification categories we have detected directly in [14], we here bring particular attention to one category, called first-to-third party cookie syncing that has not been studied explicitly prior to this work.

First-to-third party cookie syncing. We have detected that privacy-friendly first-party analytics cookies get synchronized with third-party tracking cookies.

This technique is particularly worrisome in the light of upcoming deprecation of third-party cookies in the most popular browser, Google Chrome [Goo]. Firstto-third party cookie syncing allows third parties to recognize the user within the visited website, and at the same time link them to their partial profile history collected before deprecation. We present this technique in Figure 4.2.

We detected first to third party cookie syncing in 67.96% of visited domains. In total, we found 17, 415 different partners involved in such syncing. The top couple of partners is google-analytics.com and doubleclick.net. We found that google-analytics.com first receives the cookie as part of the URL parameters. Then, through a redirection process, google-analytics.com transfers the first party cookie to doubleclick.net that inserts or receives an identifier in the user's browser. We found out that google-analytics.com is triggering such first party cookie syncing on 38.91% of visited websites. As a result, doubleclick.net receives its own third-party cookie d_id and is able to conclude that both cookies belong to the same user.

Why Google Analytics syncs cookies with Doubleclick?

We found that the main reason behind such syncronisation activity is the customization of Google Analytics allowing each web developer "Enable the Demographics and Interests reports for the property". The settings webpage of Google Analytics states that "Analytics collects Demographics and Interests data from the following sources:", then listing "Third-party DoubleClick cookie", requiring that "Cookie is present" and specifying that in this case "Analytics collects any demographic and interests information available in the [Doubleclick] cookie" [GAn].

French DPA decision.

Interestingly, in November 2020 the French Data Protection Authority (CNIL) sanctioned the website of a popular supermarket chain "Carrefour". In the official text [CNILc], CNIL explains that Carrefour website (1) contains the first-party cookies of Google Analytics, (2) synchronizes Google Analytics cookies with Google Ads (who serve ads with the help of doubleclick.net, and (3) user consent is needed for such data merging (for more details on the legal requirements and exceptions of consent, see Chapter 5).

Conclusion.

Even though third-party cookies will soon be deprecated from the Web [GSa], the browsing profiles collected by the companies and synced across multiple third parties are still accessible, and techniques such as first-tothird party cookie syncing already allow such companies to merge profiles and to continue tracking users via first-party cookies.

How effective are filter lists and browser extensions?

We demonstrate that two popular methods to detect tracking, based on EL&EP and on Disconnect lists respectively miss 25.22% and 30.34% of the trackers that we detect [14]. Moreover, we find that if we combine all three lists, then we still detect 379,245 requests originated from 8,744 domains that still track users on 68.70% of websites. We then analyze how effective are the popular privacy protection extensions in blocking the privacy leaks detected by our method [14]. We study the following extensions: Adblock [AdBa], Ghostery [Gho], Disconnect [Disc], and Privacy Badger [PB]. We performed simultaneous stateful Web measurements of the Alexa top 10K websites in November 2019 from servers located in France. than adblockers (Adblock) in blocking tracking behaviors. However, all studied extensions miss at least 24.38% of the tracking detected by our method. This shows that even though the extensions reduce the amount of tracking performed, they do not solve the problem of protecting users from tracking.

Challenge: How to protect users from Web tracking without breaking Web applications?

In our research [14], we found that both filter lists and browser extensions miss a significant number of trackers that we detect (see Section 4.1.2). However, why do filter lists miss trackers? And is it possible to block all tracking without degrading user experience? In this section we investigate these questions and discuss open challenges.

What type of content contains trackers?

To answer this question, we investigate the type of content that includes cookie-based tracking and sharing of identifiers. Table 4.2 presents the top content types used for tracking and not blocked by the filter lists. We observe that mere loading of scripts already includes cookie-based tracking, followed by loading of big images, likely used for advertisement. Other functional content, such as stylesheets and fonts also contain trackers. We selected the top 30 third party services not blocked by neither of the filter lists but detected by BehaviorTrack, and categorized them using Symantec's WebPulse Site Review. Out of 30 such trackers, EL&EP and Disconnect miss 23% of "Content Server" content, followed by "Social Networking", "Search Engines", and "Web Ads/Analytics" content (see [14,Table 7]). Such content seems to be useful for the functionality of the website and hence filter lists do not block it in order to maintain the user experience. But why does the functional content contain tracking?

Our further investigation of content that contains tracking but is missed by popular filter lists allowed us to find two possible answers to this question. First-party cookies become third-party. First, it is still a very common practice that a cookie set as a first-party is subsequently sent to a third-party thus initiating cross-site tracking. We have detected the following example on a website w3school.com that we demonstrate in Figure 4.5. When a user visits google.com, a first party cookie NID is set in the user's browser. Later on, when a user visits w3school.com, a request is sent to the service cse.google.com (Custom Search Engine by Google). This service seem to provide a search functionality on the w3school.com website. Along with the request, Google's NID cookie is sent to cse.google.com. The filter list cannot block such a request, and is incapable of removing the first party tracking cookies from it because blocking cse.google.com breaks the search functionality of the website. We found that this behavior explains a significant amount of requests missed by filter lists: 45% requests missed by EL&EP and 32% requests missed by Disconnect contain cookies initially set in a first party context.

Large scope cookies.

A cookie set with a 2 nd -level TLD domain can be accessed by all its subdomains: for example, a cookie set with tracker.com as its domain is sent along with all requests to its subdomains, such as sub.tracker.com. Such large scope cookies are extremely prevalent among requests missed by the filter lists. We found that 77% of third-party cookies in the requests missed by EL&EP and 75% of such cookies in requests missed by Disconnect are set with a 2 nd -level TLD domain (such as tracker.com) and hence accessible to all subdomains.

Conclusions. We identified that functional content often delivers or transmits cookies that enable cross-site tracking. Such tracking often happens because (i) initially first-party tracking cookies are sent with requests to fetch (functional) third-party content; and (ii) the scope of cookies is not limited to the subdomain that sets it (e.g., cookies set by cse.google.com have a large scope of google.com). Browser vendors and researchers should work towards more fine-grained approaches than filter lists, identify scripts (instead of domains) responsible for sharing and syncing of cookies, and finally consider techniques to limit first-party cookies that become third-party.

Helping Web developers to remove unwanted tracking

Website developers often need to include third party content in order to provide basic functionality. However, when a developer includes a third party content, they cannot know whether the third party contains tracking mechanisms. If a website developer wants to protect her users from being tracked, the only solution is to exclude any third-party content, thus trading functionality for privacy.

We have developed a new Web application architecture that allows web developers to gain control over certain types of third party content [11]. Our solution is based on the automatic rewriting of the web application in such a way that the third party requests are redirected to a trusted web server, with a different domain than the main site. This trusted web server may be either controlled by a trusted party, or by a main site owner -it is enough that the trusted web server has a different domain. A trusted server is needed so that the user's browser will treat all redirected requests as third party requests, like in the original web application. The trusted server automatically eliminates third-party tracking cookies and other technologies.

Do cookies influence the price you're going to pay?

An alternative monetization strategy to targeted advertising, is price discrimination. Price discrimination involves varying the price of any specific product or service, depending on the amount that a customer is willing to pay. The vast amounts of user-data gathered on the modern web are a natural fit for such a pricing strategy [START_REF] Odlyzko | Privacy, economics, and price discrimination on the internet[END_REF]. Knowing, for instance, that a user visits webpages which sell high-end goods can be used to infer the income level of that user. This knowledge can, in turn, be used to dynamically increase the price of a product on a, seemingly, unrelated website, simply because that user is likely to have the ability and willingness to pay more for that product.

Motivated by several anecdotal reports [START_REF] Sampson | Ryanair exhibit a[END_REF][START_REF] Dawson | Save money on ryanair fares by[END_REF][START_REF] Mattioli | On orbitz, mac users steered to pricier hotels[END_REF], in 2013 we started an investigation on airlines websites in order to detect price discrimination [10] for their tickets. Airline tickets are an attractive target for price discrimination due to the highly volatile nature of their prices. An airline could, for instance, recognize the same user over time, e.g., through the use of thirdparty cookies, and gradually increase the price of a specific ticket. The user is likely to attribute the price increase to flight congestion (many people buying tickets for that specific flight) and buy the ticket at an increased price, out of fear that the price will increase even more.

In January 2014, we performed [VNBJ14] a three-week long experiment: we queried 25 most popular airlines twice a day, with 66 user profiles, from two different geographical locations simultaneously resulting to a total of over 130,000 queries. The 66 profiles included combination of features of (i) various browsers and operating systems, (ii) 3 types of consumer profiles based on cookies collected from affluent, budget, and flight comparer websites, (iii) different cookie settings (with/without first/third party cookies), and (iv) two geographical locations.

Conclusion.

We found that, at the time, airlines seem not to be employing any systematic price discrimination. At the same time, we show how difficult it is to establish cause and effect for airline prices and we make available the set of prices that we collected so that it can be used on future research on the topic of price discrimination [START_REF] Vissers | Online airline price discrimination dataset[END_REF].

Browser Fingerprinting

The Web environment today has become very rich and dynamic. While first web browsers supported simple static HTML pages, new Web APIs, HTML5 and CSS3 made it possible to include a large variety of content into web applications. Moreover, the Web today is usable on a diverse variety of devices, that use various operating systems, that run diverse web browsers and mobile applications. Figure 4.6 demonstrates diversity of software and hardware of today's devices 2 .

Thanks to such diversity, browser fingerprinting3 became more and more efficient at uniquely identifying and tracking Web users. Browser fingerprinting is rooted into the origin of the Web, and client-side software, such as browsers and apps, and have been sharing device-specific information in its origin to improve user experience, therefore protection from fingerprinting is a very complex problem. A definition of browser fingerprinting that we use in this manuscript have been proposed by Laperdrix in his Phd thesis [START_REF] Laperdrix | Browser Fingerprinting: Exploring Device Diversity to Augment Authentication and Build Client-Side Countermeasures[END_REF]:

A browser fingerprint is a set of information related to a user's device from the hardware to the operating system to the browser and its configuration. Browser fingerprinting refers to the process of collecting information through a web browser to build a fingerprint of a device. Via a simple script running inside a browser, a server can collect a wide variety of information from public interfaces called Application Programming Interface (API) and HTTP headers.

An API is an interface that provides an entry point to specific objects and functions. While some APIs require a permission to be accessed like the microphone or the camera, most of them are freely accessible from any JavaScript script rendering the information collection trivial. Contrarily to other identification techniques like cookies that rely on a unique identifier (ID) directly stored inside the browser, browser fingerprinting is qualified as completely stateless.

Survey on Browser Fingerprinting

Browser fingerprinting has been a subject of numerous studies in the last decade, starting from now well-known works of Mayer [START_REF] Mayer | person... a pamphleteer[END_REF] who noticed that differ-ences in browsing environments could be exploited by a remote server to identify users, and Eckersley [START_REF] Eckersley | How Unique is Your Web Browser[END_REF], who found that 83.6% out of 470,161 collected fingerprints were unique. The field has since exploded as researchers kept on finding new fingerprinting attributes and evaluating how robust and unique they are, such as Canvas API [api15, MS12, AEE + 14a], WebGL [api18b, MS12, CLW17], Web Audio API [START_REF]Web Audio API[END_REF][START_REF] Englehardt | Online Tracking: A 1-millionsite Measurement and Analysis[END_REF], and many others.

To systematize knowledge in the field of browser fingerprinitng, we have written the first and only survey so far [13] on the research performed in the domain of browser fingerprinting, while providing an accessible entry point to newcomers in the field. We explain how this technique works and where it stems from. We analyze the related work in detail to understand the composition of modern fingerprints and see how this technique is currently used online. We cover browser fingerprinting literature on the following topics:

• history of browser fingerprinting and all studied fingerprinting attributes,

• measures to evaluate uniqueness of fingerprinting attributes,

• adoption of fingerprinting and techniques used to detect fingerprinting,

• a taxonomy of defense mechanisms by categories, benefits and drawbacks,

• discussion on challenges in science, technology, business and legislation. While interested reader can find all the technical details in the survey [13], two aspects of it deserve further analysis and critical evaluation, that we further discuss in Section 4.2.3.

Fingerprinting Web users by browser extensions

Since the web browser is the tool people use to navigate through the Web, privacy research community has studied various forms of browser fingerprinting. Fingerprinting of users' devices is similar to physical biometric traits of people, where only physical characteristics are studied. Similar to previous demonstrations of user uniqueness based on their behavior [OCJ12, AÁC15],behavioral characteristics -such as browser settings and the way people use their browsers -can also help to uniquely identify Web users. For example, a user installs web browser extensions she prefers, such as AdBlock [AdBa], LastPass [Las] or Ghostery [Gho] to enrich her Web experience. Also, while browsing the Web, she logs in her preferred social networks, such as Gmail [Gma], Facebook [Fac] or LinkedIn [Lin].

Detecting Web browser extensions. In recent works, Sjösten et al. [SVAS17],

Starov and Nikiforakis [START_REF] Starov | Xhound: Quantifying the fingerprintability of browser extensions[END_REF] and Sánchez-Rola et al. [START_REF] Sánchez-Rola | Extension breakdown: Security analysis of browsers extension resources control policies[END_REF] explored complementary techniques to detect browser extensions. These works were focused on the technical mechanisms to detect extensions, but what was not studied is how browser extensions contribute to uniqueness of users at large scale.

Linus [START_REF] Linus | Your social media fingerprint[END_REF] showed that some social websites are vulnerable to the "loginleak" attack that allows an arbitrary script to detect whether a user is logged in a vulnerable website. However, it was not studied whether Web logins can also contribute to users' uniqueness.

Large-scale study of uniqueness by browser extensions. We performed the first large-scale study of user uniqueness based on browser extensions and Web logins [12], collected from more than 16,000 users who visited our website.

Our experimental website identifies installed Google Chrome [Goo] extensions via Web Accessible Resources [START_REF] Sjösten | Discovering browser extensions via web accessible resources[END_REF], and detects websites where the user is logged in by methods that rely on URL redirection and CSP violation reports. Our experimental website was able to detect the presence of 13K Chrome extensions, (approximately 28% of all free Chrome extensions at the time of the experiment).

We also detect whether websites where the user is logged in out of 60 websites.

Uniqueness of users based on browser extensions and Web logins.

We discovered that 55% of users that have installed at least one detectable extension are unique; 20% of users are unique among those who have logged into one or more detectable websites; and 89% are unique among users with at least one extension and one login. Moreover, we discover that 23% of users could be uniquely identified by web logins, even if they disable JavaScript. We furthermore show that browser extensions and web logins can be exploited to fingerprint and track users by only checking a limited number of extensions and web logins. We have applied an advanced fingerprinting algorithm [START_REF] Gulyás | Near-optimal fingerprinting with constraints[END_REF] that carefully selects a limited number of extensions and logins. Fig. 4.7 shows uniqueness of users when a limited number of extensions is tested. The last column shows that 54.86% of users are unique based on all 16,743 detectable extensions. However, by testing 485 carefully chosen extensions we can identify more than 53.96% of users. Besides, detecting 485 extensions takes only 625ms.

Evaluating the privacy dilemma.

Given our results, one could argue that "the more privacy extensions you install, the more unique you are". In our work [12], we evaluate the trade-off between increase of users' uniqueness with the number of privacy extensions she installs; against the privacy gain (computed as third-party cookies blocked) of the privacy-preserving extensions such as Ghostery [Gho] and Privacy Badger [PB]. We further show that some of these extensions increase user's unicity and can therefore contribute to fingerprinting, which is counter-productive.

Conclusion.

Our work [12] illustrates, one more time, that user anonymity is very challenging on the Web. Users are unique in many different ways in the real life and on the Web. This work shows that users are also unique in the way they configure and augment their browser, and by the sites they connect to. Unfortunately, although uniqueness is valuable in society because it increases diversity, it can be misused by malicious websites to fingerprint users and can therefore hurt privacy.

Another important contribution of this work is the definition and the study of the trade-off that exists when a user decides to install a "privacy" extension, for example, an extension that blocks trackers. We argue that these "privacy" extensions are very useful, but they should be included by default in all browsers. "Privacy by default", as advocated by the new EU privacy regulation, should be enforced to improve privacy of all Web users.

Challenge: How to measure uniqueness of browser fingerprints?

Several measures have been proposed to evaluate uniqueness of fingerprints: evaluating percentage of unique users, anonymity sets and entropy-based measures.

In this section we take the simplest example: percentage of unique users.

Several studies aimed at estimating how unique are the users based on their browser fingerprints at large scale. This evaluation should shed light on the effectiveness of user recognition and tracking by browser fingerprinting. Recently, three such large scale studies were published: Panopticlick [START_REF] Eckersley | How Unique is Your Web Browser[END_REF], AmIUnique [START_REF] Laperdrix | Beauty and the Beast: Diverting modern web browsers to build unique browser fingerprints[END_REF] and Hiding in the Crowd [START_REF] Gómez-Boix | Hiding in the Crowd: an Analysis of the Effectiveness of Browser Fingerprinting at Large Scale[END_REF]. Panopticlick [START_REF] Eckersley | How Unique is Your Web Browser[END_REF] was the first to measure browser fingerprinting at a large scale. This study is based on 470,161 fingerprints in 2010 and they authors found that 83.6% of fingerprints were unique 4 . AmIUnique [START_REF] Laperdrix | Beauty and the Beast: Diverting modern web browsers to build unique browser fingerprints[END_REF] is based on 118,934 fingerprints collected in 2016, and similarly to the results of Panopticlick, 89.4% of them were unique. AmIUnique study, however, revealed that some of the browser attributes, such as plugins and fonts, that were the most unique features in 2010, were not so useful in 2016. Additionally to the browser attributes from Panopticlick, AmIUnique has tested newly discovered attributes, such as HTML5 canvas [api15]. Hiding in the Crowd [GBLB18] analyzed 2,067,942 fingerprints collected on one of the top 15 French websites. Their findings provide a new layer of understanding to the domain as 33.6% of fingerprints from their dataset were unique. Table 4.3 shows that different studies find rather different results as to the uniqueness, and hence possibility to track online, based on browser fingerprinting. Therefore, several research questions need to be answered: Why the results in these studies are so different? What are the different design choices in these studies that could make an effect on the outcome? How should we, as a community, measure browser fingerprinting and how to compare different studies?

Panopticlick

Choice of fingerprinting features. It is rather intuitive that depending on the features studied, the fingerprint may turn out to be more or less unique. For example, since Flash plugins is no longer supported, recent studies don't include it as a fingerprinting feature. As a demonstration, Laperdrix in his PhD thesis [START_REF] Laperdrix | Browser Fingerprinting: Exploring Device Diversity to Augment Authentication and Build Client-Side Countermeasures[END_REF] compared uniqueness results of fingerprints with and without Flash based on 60,617 fingerprints that contained Flash in 2017 and found that absence of Flask makes users less unique.

increased uniqueness to 94.2%) Size of the dataset. The first answer is the sample size of the dataset used in the experiments. Indeed, it's rather expected that the bigger is the dataset, the less unique are the users in it. While no studies have analysed this phenomena in details, we have made a preliminary evaluation in our work on uniqueness based on browser extensions [12], in order to compare our results with related works at the time [SSB17, SN17]. Figure 4.8 shows % of unique users in our dataset of 7,643 users while simulating previous studies with 204 [START_REF] Sánchez-Rola | Extension breakdown: Security analysis of browsers extension resources control policies[END_REF] and 854 [START_REF] Starov | Xhound: Quantifying the fingerprintability of browser extensions[END_REF] users. We clearly see that with bigger dataset comes smaller ratio of unique users. By exploring this comparison, we raise a fundamental question: What is the "right" size for the dataset? Bias in the dataset. The second criteria that impacts the results is bias of the studied audience. It is a fundamental question in such studies that needs to be carefully analysed: how should we, computer science researchers, reach general audience for our measurements? Recent studies go for various options. First, some works [SSB17, [START_REF] Laperdrix | Beauty and the Beast: Diverting modern web browsers to build unique browser fingerprints[END_REF]12] address students, colleagues, and technical forums -and such sample is biased towards Internet-savvy users. Second option is to use collaborative tools, such as Amazon Mechanical Turk. Such tools are known to provide audience that is not representative, since users often Indian and US-based users, who are willing to invest their time into surveys or experiments. They might even use a different system or browser that they use for normal everyday life. Finally, some studies integrated browser fingerprinting scripts into popular websites [START_REF] Gómez-Boix | Hiding in the Crowd: an Analysis of the Effectiveness of Browser Fingerprinting at Large Scale[END_REF]. Such approach needs to be carefully evaluated from ethical point of view, as well as legal aspects in privacy and data protection in the country of the researchers (where data processing takes place) and of the users, from whom the data has been collected.

Duration of an experiment. Browser fingerprints change quickly over time:

Vastel et al. [START_REF] Vastel | FP-STALKER: Tracking Browser Fingerprint Evolutions[END_REF] showed that out of 1,905 studied browser instances, 50% changed their fingerprints in less than 5 days, 80% in less than 10 days. It means that if researchers collect the users' fingerprints for a long period of time, a big portion of them might appear to be unique just because for the many users the fingerprint has changed. Therefore, to take a "snapshot" of users' fingerprints, researchers need to collect many of them in a short time period. This requirement influences the choice of sampling and bias in the dataset (see previous paragraphs).

Time frame and location of the users. Depending on the software and devices the studied population is using, the results of uniqueness of browser fingerprints may differ significantly. For example, back in 2010, when the first measurement study was conducted by Eckersley [START_REF] Eckersley | How unique is your web browser?[END_REF], very relatively few people in the US had smartphones, while today almost everyone has one. In the same way, location of tested users impacts the results -fingerprints of users in countries with a more limited number of software and hardware providers are much less diverse than in countries with a big variety of software and devices.

Recognizing returning visitors. Finally, researchers must ensure that they recognize users that come back to their experimental tool. This is particularly important in case of experimental websites such as https://amiunique. org/, where the same tech-savvy users come back to check uniqueness of their browser fingerprint. Since fingerprints change significantly over a short period of time [START_REF] Vastel | FP-STALKER: Tracking Browser Fingerprint Evolutions[END_REF], researchers need to employ mechanisms to recognize users that come back several times to their experimental websites. As such, Hiding in the Crowd study [START_REF] Gómez-Boix | Hiding in the Crowd: an Analysis of the Effectiveness of Browser Fingerprinting at Large Scale[END_REF] opted for storing only one fingerprint per user (and store a cookie to recognise the user when they come back). Let's analyse this design choice. On one hand, if the user never deletes the cookie, then their old fingerprint will be compared to the fingerprints of other users, which are newer. In practice, their fingerprint may changed, and became even more similar to those of other users (e.g., due to the same system updates that other users received), but the website won't take it into account. Therefore, the diversity this study observes will seem bigger than it is in reality. On the other hand, if the user continuously deletes their cookies and often visits an experimental website, then their fingerprint (that doesn't change much) will be counted many times. This will provide a smaller diversity of fingerprints. As a result, the choice about recognition of returned visitors impacts the outcome of the study and either

million Alexa study with OpenWPM

In 2016, Engelhardt and Narayanan released the OpenWPM platform [rep18] and performed an analysis of the Alexa top 1 million sites to detect and quantify emerging online tracking behaviours [START_REF] Englehardt | Online Tracking: A 1-millionsite Measurement and Analysis[END_REF]. Their findings provide more accurate results than in the past as they instrumented extensively a very high number of JavaScript objects to build a detection criterion for each known fingerprint technique [EN16b, Section 3.2]. Out of 1 million websites, they found 14,371 sites performing canvas fingerprinting, 3,250 sites performing canvas font fingerprinting, 715 sites performing WebRTC-based fingerprinting, and only 67 sites performing AudioContext fin-gerprinting. These numbers are much higher than what was reported in previous studies. Their definition of fingerprinting is much broader and inclusive than the other studies presented in this section. A website is deemed to be performing fingerprinting if at least one attribute out of a list of 17 is present in the recorded payloads. They identified 6,876 (68.8%) websites as performing fingerprinting which is a much higher number than what was reported in the past. 84.5% of them are third parties and the authors identified in total 284 attributes that can be used for fingerprinting.

10K Majestic study

Conclusion.

Our analysis demonstrates the complexity of detecting fingerprinting, and that various studies relied on different set of websites, used various detection methods, made measurement in different years and obtained different results 5 . Therefore, policy makers and non-technical audience need to be aware that every reported result must be taken into account with all the technical details in mind. As a computer science research community, we need to converge on the methodology to detect fingerprinting in order to be able to evaluate and compare various studies on browser fingerprinting.

Chapter 5 GDPR & ePrivacy Compliance

Web advertising relies on continuous data collection and tracking that allows advertising companies and data brokers to profit from processing a vast amount of data associated to Web users. The ePrivacy Directive 2002/58/EC [ePD02], amended in 2009 (ePD) 1 [ePD09] made it mandatory to collect user's consent before any access or storage of non-mandatory data, such as cookies and other tracking technologies. Since May 2018, the General Data Protection Regulation (GDPR) [GDPR] redefined the rules on what a legally compliant consent means. In case of websites, consent is usually presented in the form of consent pop-ups that should provide a meaningful choice to accept or reject such data collection. Today, EU users encounter such pop-ups on almost every website.

The Dream Website users would like to be provided with clear and comprehensive information and being able to control [ePD09, Art.5 [START_REF] Besson | Hybrid information flow monitoring against web tracking[END_REF]] the usage of tracking technologies by websites and third parties. Users would like to refuse tracking which is unnecessary for the website to function properly, and do so in appropriate settings, which renders their consent free, unambiguous, informed and specific [START_REF][END_REF]Art.4(11), Art.7]. Consent should be asked prior [START_REF][END_REF]Art.6] to any data collection, and the user should be able to revoke it at any time [START_REF][END_REF]Art.7(3)]. Moreover, users would like to have access to the data collected by third parties via tracking technologies [START_REF][END_REF]Art.15].

The Reality Web tracking is inherent to the website design, and appears before any interaction with consent pop-ups [14,[START_REF] Lerner | Internet jones and the raiders of the lost trackers: An archaeological study of web tracking from 1996 to[END_REF][START_REF] Libert | Changes in third-party content on european news websites after gdpr[END_REF][START_REF] Papadopoulos | Cookie synchronization: Everything you always wanted to know but were afraid to ask[END_REF]. Though prevalence of consent pop-ups on websites increases over time [DUL + 19, HWB20, vAWN19], such pop-ups often only collect consent and do not actually prevent unwanted tracking [TTG + 17, TTBM19, SRDK + 19, 16]. Moreover, many consent pop-ups integrate manipulative design strategies to coerce the user towards acceptance [DUL + 19, LK15, VFG + 19, NLV + 20, 16, 20]. Additionally, when exercizing their Subject Access Rights on websites, users don't manage to obtain any data collected via third-party cookies [15].

Application of GDPR and ePrivacy Directive to Web tracking technologies

In this section, we introduce the following EU Data Protection laws: GDPR and ePrivacy Directive, and how they are applied to Web tracking technologies. This section mostly includes background knowledge from our legal journal publication [19]. The contributions of this paper are further presented in Section 5.2. "Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers. (...) This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them".

Personal

Note that personal data do not consist only in the data originally collected via the web service, but also in any other information collected through other means and that can be linked to personal data collected through the web service. It also means any other information inferred that relates to an individual. The European Data Protection Supervisor (EDPS) declares that the use of browser fingerprinting can lead to a certain percentage of assurance that two different sets of data collected belong to the same individual [EDPS6]. Thus, the GDPR applies to data that can identify users (i.e. when identification of users is likely), whether they are meant or used to track the online activity of such users.

According to the GDPR, processing of personal data can be performed lawfully only if one of the six legal basis of processing applies [GDPR, Article 6(1)]:

1. the data subject has given consent to the processing of his or her personal data for one or more specific purposes; 2. processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;

3. processing is necessary for compliance with a legal obligation to which the controller is subject; 4. processing is necessary in order to protect the vital interests of the data subject or of another natural person; 5. processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; 6. processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. 11) and 7 [GDPR].

Our contributions in this chapter. For websites, consent for cookies and other tracking technologies is usually presented in the form of consent pop-ups. We further analyse conditions for valid consent in detail and present 22 low-level legal and technical requirements for valid consent pop-ups in the context of Web applications in Section 5.2. We then present our work on the automatic analysis of consent pop-ups and further work on consent digitally stored in the browser in Section 5.3. We then found out that the consent pop-ups we studied, implementing IAB Europe Transparency and Consent Framework (TCF), actually contain a possibility for website publishers and advertisers to rely on other legal basis than consent, called legitimate interest (legal basis number 6 in the list presented earlier in this section). Hence we study the legality of using legitimate interest in Section 5.4. Since consent pop-ups are interfaces between users and the website, by collaborating with researchers in design and in law, we evaluate four design strategies in consent pop-ups from both legal and UX perspectives and identify manipulative strategies -see Section 5.5. Finally, in Section 5.6 we analyse the GDPR Subject Access Rights [GDPR, Article 15], and detect the problems in user identification and in the exercise of the data subject requests when the user is tracked via third-party cookies.

Legal requirements for consent pop-ups and means to enforce them

Behind the scenes of almost any website lay pervasive, sophisticated and ubiquitous browsing tracking technologies that collect and share information on the behavior and preferences of users, which is later monetized in the data-driven society. Consent pop-ups2 , that ask for user's consent in almost every website a EU user visits, are a result of EU legislation: the ePD amended in 2009 [ePD09] and the GDPR [GDPR] that came into force in May 2018.

In practice, legal compliance of consent pop-ups within websites raises several important and practical questions that we investigated in our research [19]:

• What makes a consent pop-up compliant with the EU Law?

• What kind of consent pop-ups website publishers, consent management providers, and other industrial players should build up to be compliant by design and by default? • Moreover, how regulators can efficiently audit websites' consent pop-ups and tracking technologies to verify compliance?

To answer these questions, it is no longer sufficient to be a legal expert, nor does it suffice to be a technical expert and detect cookies and other tracking technologies that are used on the audited website. To decipher the ePrivacy and GDPR requirements, we have set up an interdisciplinary team of a legal scholar and two computer scientists experts in Online Tracking. Our joint legal and technical expertise allowed us to deep dive and combine the knowledge of both areas -Data Protection Law and Computer Science. In our work, published in December 2020 in the interdisciplinary international journal of law, technology and society -"Technology and Regulation" [19]-we have provided a comprehensive legal and technical analysis on legal requirements, design and implementation of consent pop-ups.

Tracking technologies exempted of consent. In our analysis, we only refer to the use of Browser-based tracking technologies (BTT) that require consent. According to Article 5(3) of the ePD [ePD09], consent is not required when the purpose of trackers is: Communication: used for the sole purpose of enabling the communication on the web; and

Strict necessity: cookies and BTT strictly necessary to enable the service requested by the user: if BTT is disabled, the service will not work.

The 29 Working Party (29WP), now known as European Data Protection Board (EDPB), issued Guidelines (WP194) [WP212] giving advice on interpretations of these two exceptions from consent in the context of websites (considering browser cookies, but also extending to all BTTs):

• The communication exemption applies when the transmission of the communication is impossible without the use of the BTT (e.g. load-balancing cookie). Hence, using BTT to merely "assist" or "facilitate" the communication is insufficient. • The strict necessity exemption involves a narrow interpretation. It means that the use of BTT must be restricted to what is strictly necessary (and hence essential) to provide a service explicitly requested by a user. Thus, using BTT that is reasonably necessary or important implies that the service provided by the website publisher would not function without the BTT. In this regard, when a website functional content includes BTT (for example, when a Customised Search Engine used on a website includes a tracking third-party cookie -see Section 4.1.3), then it is not enough to justify the strict necessity since the website owner has a different implementation choice that would work without BTT.

In our work, we analyse in details the Data Protection Authorities (DPAs) guidelines, as well as 29WP (now EDPB) and propose an analysis of purposes that need consent and purposes exempted of consent, according to these sources (for details, see [19,Table 5]).

22 fine-grained requirements for a legally valid consent. We first identified 7 high-level requirements for valid consent from the GDPR and the ePrivacy Directive in the context of websites. By analysing them further and applying technical knowledge, the 7 requirements were further refined into 22 fine-grained and operational requirements for rendering a valid consent. Figure 5.1 shows an overview of these 22 low-level requirements. This result stems from an interdisciplinary effort that not only identifies legal requirements but also provides a technical analysis of the possibility to detect violations automatically and at scale. Each of the 22 requirements contains:

• a deep legal analysis of all comprised legal sources, including binding sources (GDPR, ePrivacy, case-law), non-binding sources (EDPB and DPA regulatory guidelines) complemented with our own interpretation based on legal and technical experience gleaned in the team; • a simple explanation and examples of violations of each requirement on a High-level requirements are derived from GDPR [GDPR], ePrivacy Directive [ePD09] and CJEU case law. Low-level requirements are derived additionally from non-binding sources, such as EDPB and DPA guidelines, complemented by Legal (L) or Computer Science (CS) interpretation. Assessment of each requirement can be done manually (M), with CS tools (T), via user studies (U) or via a combination of them.

real world website; • investigation on how to detect violations of each requirement most efficiently and at scale. We distinguish three ways to detect violations, and for some requirements, a combination thereof is needed: 1. technically, by an expert using automated tools3 , or 2. manually, relying only on a human operator, or 3. performing user studies to evaluate the perception of end users.

Our analysis shows that to verify legal compliance of a consent pop-up on a website, an auditor must not only be familiar with the technical tools to detect every cookie and tracking technology, but also know the data processing purpose of each detected technology. Moreover, the auditor should be able to find out how consent is stored in the browser (see further discussion on problems of storage of consent in the browser in Section 5.3 and on the challenge of consent standardization in Section 5.5.2). Finally, be able to run user studies to validate, for example, whether the information is provided in clear and plain language. Such combination of legal, technical and social studies knowledge is extremely hard to achieve. [19] is the first to systematize legal and technical knowledge in Online Tracking and End-to-end Consent areas and to propose practicallyminded parties, such as DPAs, privacy NGOs, designers 4 or researchers, a clear roadmap on how to verify compliance of a website consent pop-up with the EU legislation. This work also sets a guide to data protection specialists to help website providers achieve the desired compliance with the GDPR and ePrivacy. We argue that many current practices -such as shared consent among websites -are problematic and policy makers should converge on the rules for consent and advance with a unified framework of the ePrivacy Regulation that will be applied similarly to GDPR: uniformly to all EU member states and all organizations providing online services or tracking EU residents.

Conclusion. Our work

Challenge: Defining purposes exempted of consent

In our work [19], we analysed purposes for data collection (and hence of tracking technologies) that require consent and those that are exempted of consent [19,Table 5]. This analysis was based on the opinions and official guidelines of various EU Data Protection Authorities (DPAs), European Data Protection Board (EDPB) and European Data Protection Supervisor (EDPS).

We noticed that the question Which purposes are exempted of consent? is answered differently by various DPAs. That is, there is no consensus on when tracking technologies can be used without consent, and hence auditing of websites becomes complex and depends on the interpretation of consent exemption rules by each individual DPA. In particular, we observed that:

• the biggest divergence in DPA's opinions lays in the purpose of analytics, also called as audience measurement; • DPAs often disagree on which purposes must rely on consent and which ones can be used with a different legal basis, such as legitimate interest [GDPR, Art.6(1)(f)]; • DPAs and EDPB often take into account such properties of cookies and BTT as duration (session or persistent) and scope (first or third party), while these properties do not determine the purpose and can be easily forged (see our feedback to the Italian DPA [24, Section 4]). The ePrivacy Regulation, that is currently under discussion, could unify the rules on consent exemption, but its latest text is still so high level that it leaves a lot of space for DPAs to interpret and set up their own rules on consent exemption, and even to do it on a case-to-case basis, which makes automatic, large-scale and precise auditing impossible.

Conclusion.

If Data Protection Authorities, and hence EDPB, provide unified rules on purposes that require consent and the ones exempted of consent, computer scientists could propose automated tools that would speed up the auditing process of consent compliance and help DPAs to efficiently enforce the GDPR and the upcoming ePrivacy Regulation.

Do consent pop-ups respect user's choice?

Although many research efforts took place after the GDPR to detect and analyze cookie banners and their impact on tracking technologies and on the users, no study has analyzed what actually happens behind the user interface of cookie banners yet. It is unclear how to meaningfully compare the interface of the banners shown to the users with the actual consent that banners store and transmit to the third parties present on the website.

In our work with a computer scientist and a researcher in law [16], that was done at the same time as our analysis on legal requirements for valid consent [19], we investigated new questions regarding the storage of consent in the user's browser. This work has lead to new requirements R14 "Post-consent registration" and R15 "Correct consent registration" of the legal requirements on consent, shown in Figure 5.1 in Section 5.2. In this work [16], we explored the following questions, that correspond to the legal requirements on consent from Answering such questions, ensuring a proper functionality and legal compliance of a consent pop-up is usually left to the website publisher and is completely obscure for the website visitor.

IAB Europe Trasparency & Consent Framework (TCF) and Consent Management Providers (CMPs).

In reaction to the GDPR, the European branch of the Interactive Advertising Bureau (IAB Europe), an advertising business organization, produced the Transparency and Consent Framework (TCF) [START_REF]Transparency and consent framework[END_REF]IAB20a] to structure the practices of actors of the tracking and advertisement industry regarding consent collection. Notably, they introduced the notion of Consent Management Providers (CMPs) -actors in charge of collecting consent from the end-user, and redistributing this consent to advertisers. Figure 5.2 shows a typical example of a consent pop-up implemented by a CMP. CMPs provide consent pop-up, store the user's choice as a browser cookie, and provide an API for advertisers to access this information.

Open specification of consent storage by the IAB Europe TCF. To standardise5 the technical implementation of these consent pop-ups, the IAB Europe TCF (currently on version 2.0 [IAB20a]) was developed to preserve the exchange of data within the advertising ecosystem, which now requires being able to demonstrate how, when, from whom, and on which legal basis that data is collected. The actors in this ecosystem are IAB Europe, advertisers (called "vendors"), Consent Management Providers (CMPs), publishers, and data subjects (see Figure 5.3). When a user makes their choice in a IAB Europe TCF consent pop-up, they consent that their data will be invisibly collected and further used with respect to several purposes, pre-defined by IAB Europe TCF (we discuss all the purposes in Section 5.4). Alongside with the purposes, the consent pop-ups include a list of around 700 third party advertisers, called "vendors" 6 , that rely on the allowed purposes to collect users' data as they browse the website.

Semi-automated analysis of consent pop-ups.

Thanks to the open specification of the TCF, we performed [16] the first systematic comparison of the consent chosen by the users and the consent stored by the CMPs, which is further transmitted to third-party advertisers present on a website. Within our analysis of consent, we were able to measure both the GDPR and the ePD compliance of consent pop-ups implemented in the TCF. We note that the responsibility for the suspected violations is shared between the publishers and the CMPs.

First, we designed an automatic method to detect the presence of a consent pop-up developed by a Consent Management Provider (CMP). We automatically detected 1,426 websites with such banners. We also developed and used a methodology to intercept the consent stored in the browser. By analyzing the content of consent, we were able to provide information to Web users about the companies behind CMPs on the website they visited.

Second, by collaborating with a legal scholar, one of the co-authors [16], we thoroughly analyzed the GDPR, the ePrivacy Directive and other legal sources to identify four potential legal violations specific to cookie banners: Consent stored before choice, No way to opt out, Pre-selected choices and Non-respect of choice. These violations then helped us improve and extend the list of requirements for valid consent [19].

Detected GDPR and ePD violations on 54% of websites. We have then developed a method to evaluate regulatory compliance of websites. We quantify the identified suspected violations on 1,426 websites by automatic-, semiautomatic crawls and manual detection. By analyzing cookie banners' design and consent stored in the browser on a subset of 560 websites, we have found at least one suspected violation in 304 out of 560 websites (54%), presented in Table 5.1.

Problem of shared consent. We have then measured the problem of escalation of shared consent between CMPs. The TCF allows different CMPs and publishers to rely on each other's consent, set in a shared cookie. We observed that 3 websites store a positive consent before any user action in the shared cookie, while 20 websites store a positive consent in a shared cookie even if the user has explicitly opted out. Such invalid consent can be reused by any CMP and publisher and therefore escalates non-compliance to other websites. Finally, we quantified third-party requests that transmit consent and that belong to known third-party tracking services. We observe that various third parties receive consent with third-party requests, where the origin of consent does not necessarily match the CMP present on the website. Such consents are set before user action on 69 websites and despite user refusal on 38 websites. We observe that the number of third-party tracking requests increases both after positive consent and after refusal. The cookie banner stores a positive consent before the user has made their choice in the banner. Therefore, when advertisers request for consent, the cookie banner responds with the positive consent even though the user has not clicked on a banner and has not made their choice yet.

1,426 141 (9.9%)

No way to opt out

The pop-up does not offer a way to refuse consent. The most common case is a pop-up simply informing the users about the site's use of cookies 560 38 (6.8%)

Preselected choices

The pop-up gives user a choice between one or more purposes or vendors, but some of the purposes or advertisers are pre-selected: pre-ticked boxes or sliders set to "accept". 508 236 (46.5%)

Nonrespect of choice

The consent pop-up stores a positive consent in the browser even though the user has explicitly refused consent. 508 27 (5.3%) Table 5.1: Detected GDPR and ePrivacy suspected violations on websites with IAB Europe TCF consent pop-ups via semi-automatic analysis in September 2019 [16].

Tools for auditing. To measure compliance, we have designed two tools.

Cookinspect [START_REF] Matte | Cookinspect[END_REF] is a Selenium-and Chromium-based crawler which automatically and semi-automatically visits websites, logs stored consent and intercepts transmission of consent to third parties. Cookie Glasses [START_REF] Matte | Cookie glasses[END_REF] is a publicly available browser extension for Google Chrome and Firefox that allows users to detect a CMP that implements a TCF banner and see if their choice is correctly transmitted to advertisers by CMPs.

Impact on society. The European Center for the Defense of Digital Rights called "None Of Your Business" (NOYB) NGO, led by Max Schrems, issued three formal complaints with the French Data Protection Authority (CNIL) in December 2019. NOYB used our "Cookie Glasses" extension that decodes the consent stored in the browser after the user interacts with the cookie banner. These complaints addressed 3 popular French websites: CDiscount, AlloCine and VanityFair and third party ad targeting companies Facebook, AppNexus and PubMatic who received cookies on the 3 French websites unlawfully [fDR].

Purposes in IAB Europe's TCF: which legal basis and how are they used by advertisers?

An advertiser willing to be involved in the IAB Europe TCF [II18, IAB20a] (see Figure 5.3) and wishing to appear in CMP-based consent pop-ups must register within the TCF. At the moment of registration, an advertiser must select one or more of the predefined purposes for data processing. These purposes are presented to website users in consent pop-ups while collecting their consent (and are often presented in the second layer of the pop-up). For each purpose, advertisers must choose a legal basis for processing: consent or legitimate interest. Note that legitimate interest is, just like consent, one of the six legal basis for processing personal data [GDPR, Article 6(1)] that we presented in the Section 5.1. Figure 5.4 presents a screenshot of the registration form advertisers use to subscribe to IAB Europe TCF. The choice of the purposes and their legal basis hold strong legal compliance implications -both on the advertisers, but also on the publishers side, as the latter include third-party resources in their websites.

According to Article 8 of the Charter of Fundamental Rights of the European Union [Eur], personal data must be processed fairly for specified purposes and on the basis of a lawful ground. Article 5(1)(b) of the GDPR [GDPR] predicates the "Purpose Limitation" principle which mandates personal data to be collected for specified, explicit and legitimate purposes. Identifying the appropriate legal basis that corresponds to the purpose of the processing is of essential importance. Which purposes require consent? In our work [17] we identified the legal requirements for defining purposes based on the GDPR, the 29 Working Party (now EDPB endorsed) and Data Protection Authorities guidance that helped us to answer the following questions: "Does a purpose satisfy the requirements of the purpose specification principle?" and "Which is the legal basis for a specific purpose?". We then analyse the purposes defined in IAB Europe's TCF versions 1.1 and 2.0, and in Table 5.2 presents our result on whether such purposes comply with the legal requirements and which purposes should rely on consent. Further legal analysis can be found in our paper [17].

Declaration of purposes and their legal basis by advertisers. We then collected data about all advertisers registered in both versions v1.1 and v2.0 of the IAB Europe TCF in Januray 2020. Our goal was to measure which purposes are used by advertisers and which legal bases advertisers have declared for each purpose. We identified in Table 5.2 that purposes 3 and 5 of TCF v1.1 ("Ad selection, delivery, reporting" and "Measurement") require consent. Figure 5.5a details the results for each individual purpose in IAB Europe TCF v1. 1 [II20a]. Overall, we detect a particularly worrisome number of advertisers: 175 (31%) and 199 (35%) advertisers respectively rely on legitimate interests for purposes 3 and 5 that require consent according to our analysis in Table 5.2.

Figure 5.5 shows that hundreds of advertisers rely on legitimate interest for purposes that instead should rely on consent. Figure 5.5b renders an analysis of purposes for the Global Vendor List of v2.0 [START_REF]Global vendor list (GVL[END_REF]. The number of advertisers registered in this version was smaller in January 2020, but we still saw that a significant portion of advertisers use legitimate interest for purposes that require consent. For example, 17% advertisers rely on legitimate interest for purpose 2 ("Select basic ads"), and 25% advertisers do it for purpose 7 ("Measure ad performance"), while our legal analysis in Table 5.2 demonstrated that purposes 2 and 7 require consent. It is also notable that 32% of advertisers use "flexible purposes" for at least one purpose thus allowing publishers to change the legal basis for such purposes [II19]. Purpose specification for third-party cookies. In our work [18], we investigated the legal compliance of purposes for 20,218 third-party cookies outside of the IAB Europe TCF framework. Surprisingly, only 12.85% of third-party cookies have a corresponding privacy/cookie policy where a cookie is even mentioned. Overall, we find out that purposes declared in cookie policies do not comply with the purpose specification principle in 95% of cases in our automatized audit.

Conclusion.

Our work [17,18] demonstrates the persistence of the advertising industry using in non-compliant (with GDPR [GDPR] and ePD [ePD09]) methods for tracking and profiling, bundled in often complex and vague presentation of purposes. The importance of this is further underlined by the extended prior work, guidance, as well as enforcement actions and court decisions in the field.

Dark patterns, manipulative design strategies and their legality in consent

We have identified several design strategies for consent pop-ups, that are not officially violating the legal requirements of valid consent but yet are questionable as to their manipulative power on Web users [19].

In a joint work with a researcher in design and researchers in law [20], we have further approached four design strategies that correspond to various forms of dark patterns and user manipulation and yet are not explicitly banned by EU Data Protection Authorities (DPAs).

Data Collection and Framing. We relied upon our previously collected dataset (see Section 5.3) that contains 560 websites of French, Italian or Englishspeaking EU countries. From this dataset, we focused on locating a range of potentially manipulative design exemplars, using recorded videos or screenshots of the consent experiences to support a manual and collaborative analysis of their design and text. In total, we reviewed recordings from over 50 sites and extensively analyzed the design and users' means of interaction with the consent banners on these websites. While reviewing other recent and relevant literature on ethical issues in the design of consent banners (e.g., [NLV + 20, MB20, SNGS20]), we identified four main phases in the consent task flow (Figure 5.6):

1. the initial framing as a user enters the site; 2. the presentation of configuration options to accept or select more precise consent options; 3. the means of accepting the configuration options; and 4. the ability to ultimately revoke consent.

INITIAL FRAMING

CONSENT TASK FLOW

CONFIGURATION

ACCEPTANCE REVOCATION Figure 5.6: The task flow of the consenting process by phase [20].

Within this task flow, we worked as a research team to identify four different combinations of design choices that were represented in the dataset and raised productive ethical dilemmas when viewed from multiple disciplinary perspectives. Because our main goal in this paper is to examine the complexity of these design outcomes and not to identify how common these patterns occur "in the wild," we used the dataset as a source of inspiration and departure rather than as a means of conducting a content analysis or other inductive form of inquiry. Interaction criticism approach. We use an interaction criticism [START_REF] Bardzell | Interaction criticism: An introduction to the practice[END_REF] approach to analyze and reflect upon these design strategies from multiple perspectives: 1) design choices evident in the consenting process artifact itself; 2) the possible experience of the end user; 3) the possible intentions of the designer; and 4) the social milieu and impact of this milieu on the other three perspectives [20]. We consider the four following design strategies that did not receive much attention so far analysed in the literature, especially not from an interdisciplinary approach combining design, law and computer science perspectives. The consent task flow highlighting these four strategies, potentially violated consent requirements and detected dark pattern strategies are shown in Figure 5.7.

Consent wall blocks access to the website until a user expresses their choice regarding consent. The design choice allows a user to select between acceptance and refusal; however, the concrete use of the website is blocked until a choice has been made. In our work on legal requirements for valid consent [19], we explain that this strategy is likely at odds with freely given and readable and accessible requirement of valid consent (see R20 of Tracking wall is an instance of a consent wall, however with more detrimental consequences to the user. In addition to blocking access to the website until the user makes their choice, a tracking wall gives the user only one option: to consent and accept any terms offered by the site, without any possibility to refuse. In the legal domain, a tracking wall is also called a "cookie-wall" or "take it or leave it" choice [START_REF] Borgesius | Tracking walls, take-it-or-leave-it choices, the gdpr, and the eprivacy regulation[END_REF]. Differently from a consent wall, a tracking wall cannot result in a reduced service because the only option the user has is merely to accept consent in order to access the website. Tracking wall has been recognized as violating the law by several DPAs (see R4 in Figure 5.1 and [19, Section 5.2.1] on further discussion), yet there is no consensus across all EU countries as to the legality of this practice.

Reduced service refers to the practice of a website offering reduced functionalityfor example, allowing a user access to only limited number of pages on a website-based on their consent configuration options. In the scope of consent on websites, reduced service is a result of the user refusing consent in some or all of the proposed privacy configurations. An extreme case of a reduced service occurs when a website fully blocks access because the user refuses some of the privacy configurations. This strategy has not been analysed in previous work, and hence deserves further investigation and guidance from the DPAs and EDPB.

Manipulative design choices and other configuration and acceptance barriers, such as imposition of hierarchies, aesthetic manipulation (known as "interface interference"), toying with emotion, reading order manipulation or hidden information all constitute manipulative design strategies coercing the user towards acceptance. Such strategies is under thorough inspection by several EU DPAs. We explicitly list requirements R11 "Affirmative action design", R12 "Configurable banner", and R13 "Balanced choice" in Figure 5.1 to propose first rules towards protecting Web user from such manipulation.

Conclusion.

All such manipulative strategies, often called dark patterns, are coercing the user towards acceptance, often under a fear of not accessing the service if the user rejects. We were the first to analyse them in depth and show that most of the design strategies appear in practice due to different intentions of designers, website owners, consent pop-up providers and regulators [20]. Policy makers should provide more guidelines on which strategies indeed violate the EU law and which ones need further investigation.

Challenge: Roles of CMPs under GDPR: controllers or processors?

Although recent work, including ours [16,17], has started to address the complex technical and legal aspects of the IAB Europe TCF ecosystem [HWB20, NLV + 20, PC20, DUL + 19], neither prior work nor court decisions have so far discussed the role of the CMPs. In our feedback to the European Data Protection Board (EDPB), we have underlined the complexity and raised questions about the legal role of Consent Management Providers (CMPs), whether they are data controllers and/or data processors [START_REF] Bielova | Call for Feedback to the EDPB regarding Guidelines 07/2020 on the concepts of controller and processor in the IAB Europe Transparency and Consent Framework[END_REF]. However, it is currently unclear what the role of CMPs is under the GDPR, and consequently what their legal requirements and responsibilities are.

In our recently accepted publication [21], with a co-author, expert in EU Data Protection Law, we investigate if and when CMPs can be considered a data controller -i.e., an actor responsible for determining the purposes and means of the processing of personal data [GDPR, Art. 4 [START_REF] Bielova | A taxonomy of information flow monitors[END_REF]] -or a data processor -i.e., an actor which processes personal data on behalf of the controller [START_REF][END_REF]Art. 4(8)]. Discerning the correct positioning of CMPs is crucial since compliance measures and CMPs liability depend on their accurate characterization [START_REF][END_REF]Recital 79]. To determine the role of CMPs under the GDPR, we answer the following research questions:

• When are CMPs processing personal data?

• When do CMPs act as data processors?

• When do CMPs act as data controllers?

• What are the liability implications of CMPs acting as controllers?

Our argumentation is based on: (1) legal analysis of binding legal sources (GDPR and case-law) and relevant data protection guidelines from the European Data Protection Board and Data Protection Authorities, (2) document analysis of the IAB Europe TCF, and (3) empirical data gathered on our own website by deploying Quantcast and OneTrust -the two most popular CMPs in the EU, found respectively on 38.3% and 16.3% of the websites with a EU or UK TLD analyzed by Hils et al. [START_REF] Hils | Measuring the Emergence of Consent Management on the Web[END_REF].

Although CMPs are explicitly designated as data processors by the IAB Europe TCF specifications [IAB20a], we analysed four functional activities of CMPs that enables their qualification as data controllers. In our work [21], we included a technical description of such activities followed by a legal analysis. These activities refer to:

• Including additional processing activities in their tools beyond those specified by the IAB Europe; • Scanning publisher websites for tracking technologies and sorting them into purpose categories;

• Controlling third-party vendors included by CMPs;

• Deploying manipulative design strategies in the UI of consent pop-ups -we underline when such strategies could violate legal requirements for valid consent (Sections 5.2 and 5.5).

Conclusions.

Our work [21] started an investigation into the legal role of Consent Management Providers under GDPR. We provided the first elements that can help DPAs and EDPB to reason about the role and activities of these organisations. However, more in-depth analysis and legal guidance is required for the website publishers who are often unaware of the decision making power and capabilities of CMPs.

Challenge: Standardization of consent

The amount of website audits, complaints and regulatory enforcement actions related to consent -both from DPAs and the Court of Justice -have substantially increased. However, all these actions depend on complex manual analysis of websites that includes detection of a tracking technology; identification of a purpose of each tracking technology; analysis whether consent is required; evaluation of consent compliance requirement. Recent guidelines by the EDPB and DPAs clarify and strengthen the rules for consent requirements and propose best practices, but the implementation of consent on websites still diverges. Several questions hence need to be answered that were object of debate in a panel discussion at Computers, Privacy and Data Protection (CPDP 2021) conference [CPDP], the top-level event for legal privacy experts:

• What are the next steps for a streamlined, auditable and scalable consent?

• How can legal and technical experts help to devise a compliant-by-design consent? • Would standardization of consent help?

• What concrete building blocks need to be defined by policy-makers and the legislator?

As of today, there is no unique standard to represent consent collected on website in a digital form. IAB Europe has its own standard that, as we show in Sections 5.3, 5.4 and 5.5, triggers a number of open legal problems either in the TCF standard or in its implementation.

Foundational elements for standardized consent. For consent to be standardized, it should contain a number of elements that are mandatory to make it streamlined, auditable and scalable. In our contribution to the public consultation to the CNIL [22], we underline four standardized elements: purposes, categories/types of data collected, data controllers, and trackers that facilitate the data collection. These building blocks are needed to be defined by Data Protection Authorities or the EDPB for a standardisation of consent:

• an exhaustive list of standardized purposes: the purposes should be humanunderstood and machine-readable. Additionally, a taxonomy of purposes would allow to reason about them (inclusions, implications and generalisations). Previous works, such as P3P [P3P] have proposed an initial structure for taxonomies of purposes, and proprietary taxonomies have been recently designed by private companies, such as the one of TrustArc [TArc]. • it should be clear which standardized purposes should rely on which legal basis (consent or other): with standardized purposes, DPAs could set stricter rules on which purposes should be used with consent and which are definitely exempted of consent and under which conditions (see discussion in Section 5.2.1). • categories (e.g., personal, sensitive) and types (more fine-grained description) of data collected should be standardized. Each tracker will then be able to contain a complete description of collected or processed data type. • standardized presentation of data controllers and data processors, such as the company name, domain URL, privacy policy link, etc. Some recent attempts have been made by computer scientists to collect this information [START_REF] Libert | An automated approach to auditing disclosure of thirdparty data collection in website privacy policies[END_REF][START_REF] Libert | webxray domain owner list[END_REF], but more guided approach is needed to enforce such rules. • standardized naming convention and description for trackers from a predefined name convention and labels that helps determine the nature and owner of the tracker since identifying ownership of trackers has been shown to be a complex task [START_REF] Bashir | Tracing Information Flows Between Ad Exchanges Using Retargeted Ads[END_REF]. • some elements of a standardized design interface or clear black list of design patterns for a consent pop-up should be defined to avoid user manipulation and dark patterns (see Section 5.5). • standardized storage of consent in a digital form should be provided. Without a standard representation of consent storage, it is very complex, timeconsuming and not scalable to assess many of the compliance requirements (see R1, R2, R14, R15, R21, R22 in Figure 5.1 of Section 5.2).

One purpose per tracker. In a standardized consent, in a given consent scope, each tracker should have only one standard purpose, categories/types of data collected, list of data controllers and a legal basis applied to it. This would facilitate the auditing process for DPAs. The same standard can be used to inform the users about the purposes of all the trackers present on a website independently of the legal basis.

Consent within Web browser interface. If consent is standardized, it can be also set in a web browser interface. Web browsers could provide an interface to register a consent pre-defined by the user, using the same standard as other actors. This will allow the browser to exchange the consent with the data controllers automatically. Some of such proposals have been made, such as Global Privacy Control [GPC], and require further legal evaluation in the scope of EU Data Protection law.

Conclusion.

Standardized consent would provide many benefits to website publishers, consent banner providers, DPAs and other auditing organisations.

It would provide legal certainty, save time and resources, and at the same time harmonize approaches across the EU. Standardization of consent would enable automatic and scalable auditing of compliance.

GDPR access rights and third-party cookies

When Web users are continuously track by third parties on the Web (often without a valid consent -see Sections 5.3 and 5.5), users would like to know what information is collected and processed about them via online trackers and their collaborations with various parties (see Section 4.1). Moreover, users would like to know what data is collected about them when are tracked via stateless tracking techniques, such as browser fingerprinting (Section 4.2) Chapter 3 of the GDPR [GDPR] defines various rights for the users' (called "data subjects") and aims at protecting their personal data. Every European Data Protection Authority (DPA) provides advises, explanations and recommendations to help data controllers (website owners in the context of this manuscript) implement such rights for the users. However, the GDPR does not provide any prescriptive requirements on how to authenticate a data subject request. The lack of guidance and interpretation makes it hard to respect GDPR in practice: data subjects are denied from their access right, the lawfulness of the processing and the derived legal rights are impossible to check in practice. We therefore conducted an interdisciplinary study [15] with two legal scholars and two computer scientists in order to understand the goals and tensions between that data subjects (Web users) and data controllers (website owners).

View of the data subject (user).

Every data subject would like to benefit from the rights specified in GDPR, but still wonders: How do I exercise my access right? How do I prove my identity to the controller? These questions are critical to build trust between the data subject and the controller. The data subject is concerned with threats like impersonation and abusive identity check: Impersonation occurs when a malicious party attempts to abuse the subject access request (SAR) by impersonating a subject to a controller. Abusive identity check can occur when a data controller is too curious and verifies the identity of a subject by asking irrelevant and unnecessary information like an electricity bill or government issued documents.

View of the data controller (website owner). Symmetrically, every data controller needs to know how to proceed when they receive an access request: Is the request legitimate? What is necessary to identify the subject's data? These concerns aggravate when controllers deal with indirectly-linked identifiers, such as IP addresses, or when they have no prior contact with data subjects, as in Google Spain [GSp]. Most of all, data controllers want to avoid data breaches, as it can result in legal proceedings and heavy fines. Such consequence occurs in two cases: (i) the data controller releases data to an illegitimate subject, or (ii) he releases data of a subject A to a legitimate subject B.

Tension between data subject and data controller. All these questions concern the authentication procedure between the data subject and the controller. They both share a common interest in holding a strong authentication procedure to prevent impersonation and data breaches. On one hand, the data subject should not provide too much personal information that could compromise her privacy. On the other hand, the controller needs to ask the appropriate information to identify the subject's data without ambiguity. Therefore, there is clearly a tension during this authentication act between the controller, who tries to get as much information as possible, and the data subject who wants to provide as little as possible. Plausibly, subject access rights can probably increase the incidence of personal records being accidentally or deliberately opened to unauthorised third parties [START_REF] Cormack | Is the Subject Access Right Now Too Great a Threat to Privacy?[END_REF].

Evaluating authentication procedures. In our work with two legal scholars [15], we study the tension during the authentication between the data subject and the data controller. We first evaluate the threats to the SAR authentication procedure and then we analyze the recommendations of 28 DPAs of European Union countries. We have then evaluated the authentication procedure when exercising the access right of the 50 most popular websites and 30 third-party tracking services. Several popular websites require to systematically provide a national identity card or government-issued documents to authenticate the data subject. Among third-party tracking services, 9 of them additionally to thirdparty cookies demand other personal data from the data subjects, like the identity card or the full name. We explain that such demands are not justified because additional information can not prove the ownership of the cookie.

Conclusion.

We then provide guidelines to Data Protection Authorities, website owners and third party services on how to authenticate data subjects safely while protecting their identities, and without requesting additional unnecessary information (complying with the data minimization principle). In the conclusion of our work [15] we provide some initial ideas on how digital identifiers can be redesigned in such a way that data subjects can safely exercise their rights and data controllers can safely respond to SAR requests and be compliant with the GDPR.

Challenge: Proof of ownership for cookies is needed

When exercising SAR on third party services, users have to follow complex procedures requiring understanding of legal text [UTD + 18]. In our work [15], we have discovered that Subject Access Request (SAR) procedures that implement GDPR access rights, though compliant with the law, are suffering from a number of security vulnerabilities and implementations that can lead to data breaches. The problem is that the same technology that is used to track users (such as cookies) was not initially designed to identify users. Cookies (as many other digital identifiers) are chosen by third parties on the server side and stored on the client side (in the browser). Cookies can subsequently be changed in the browser or, if not properly secured, even stolen by network attackers. As a result, cookies are not sufficiently secure to be used to reclaim the data associated with a Subject Access Request and to prove data ownership. For this reason, today many third parties refuse SAR and don't provide access to users' data.

Is there a solution? The problem with cookies and similar stateful tracking technologies is that they are at odds with the legal rights provided by the GDPR due the way cookies are generated and used today. To introduce a change: (i) cookies should be generated on the client side. By using cryptographic schemes an easy and safe mechanism for a user to claim cookie ownership can be designed; (ii) the current HTTP protocol should be modified to account for the possibility to have cookies and other identifiers generated on the client-side.

Finally, the adoption by the browser vendors, website owners and third parties of such a mechanism is crucial and should be supported by policy makers to ensure that technologies allowing proof of ownership are indeed compliant with the current and future EU Data Protection Laws. of consent puts an enormous pressure on the user interacting with the system. Therefore, the design of interfaces of systems is of crucial importance since it determines the legality of consent based interactions. Hence, an transdisciplinary collaboration between computer science, law and researchers in UI and design is also very important to ensure that the Web user is not manipulated when making important decisions regarding her privacy protection choices.

Technical expertise and research of computer scientists is of crucial importance for EU Data Protection Authorities and other policy making organisations, such as the EU Commission or the Organisation for Economic Co-operation and Development (OECD), who conduct audits and/or provide highly-important guidelines to protect privacy on the Web.

Upcoming legal and technical challenges. The EU will soon finalise the ePrivacy Regulation [START_REF]ePD02[END_REF], that is currently under a trialogue discussion between the European Parliament, EU Commission and the Council of the European Union. From a legal perspective, the latest proposal of the ePrivacy Regulation has a number of open questions and challenges with respect to the latest technological developments and need a careful evaluation by computer scientists, and also researchers in design. For example, current debate includes:

• the usage of tracking-and cookie walls (Section 5.5),

• exception from consent for the purpose of audience measurement (Section 5.2.1), • whether consent can be expressed in the browser settings (Section 5.5.2). From a technical perspective, third-party cookies will be deprecated from the Web in 2022, and Google proposed a new Privacy Sandbox [GSa]. This new proposal has been recently criticized by pro-privacy NGOs and organisations, such as Electronic Frontiers Foundation (EFF) [EFFG]. Therefore, the proposal needs to be carefully evaluated both from a technical perspective, as well as from a legal perspective as to its compliance with the EU Data Protection law.

  (a) same-origin embedded page does not have a CSP and makes embedding page vulnerable to attacks.(b) same-origin embedded page has a weaker CSP than the embedding page thus weakening the protection of the embedding page.

Figure 2 . 1 :

 21 Figure 2.1: Fundamental problem of Content Security Policies (CSP) in embedded pages. If either embedded (resp. embedding, not shown here) page has no CSP or a weaker CSP than embedding (resp. embedded) page, the overall protection of the Web application is set by the weakest CSP (or no CSP).

Example 1 . 1 1

 11 Program 1 shows a program snippet where h1 and h2 are secret inputs and x and y are two public variables. The output operation makes the program output visible to the attacker whose goal is to learn any information about the secret inputs h1 and h2. Program x = 0; y = 0; 2 if (h1) then y = 1; 3 if (h2) then x = 1 else x = y; 4 output x Consider an execution of Program 1 when its secret inputs are h1 = false and h2 = true. When Program 1 outputs 1, the attacker learns that either h1 or h2 was true: Actual attacker's knowledge: h1 ∨ h2

  (a) from Hedin et al. [HBS15].(b) our result from[START_REF] Besson | Hybrid monitoring of attacker knowledge[END_REF].

Figure 3 . 1 :

 31 Figure 3.1: Relative permissiveness revisited from [6]. While Hedin etal.[START_REF] Hedin | Value-sensitive Hybrid Information Flow Control for a JavaScript-like Language[END_REF] proved that dynamic and hybrid monitors are incomparable in their permissiveness, we show that a knowledge-hybrid monitor is capable to be provable more permissive than dynamic monitors.

Figure 3 . 2 :

 32 Figure 3.2: Different measures of information leakage from [8]. Average measures evaluate the amount of leakage for all possible program inputs and outputs (all inputs and outputs are highlighted in vivid colors). Belief tracking evaluates the leakage associated to one input and one output. Dynamic leakage should measure the amount of information leaked when an attacker observes one program output that could have been caused by several possible inputs.

Figure 3 . 3 :

 33 Figure 3.3: Visualisation of the concepts of soundness and transparency.Soundness does not allow any insecure executions, but says nothing about secure ones. Transparency requires to allow all secure executions.

  monitoring back in 2011 [B12, page 121].

  Figure 4.1 shows the distribution of the number of pixels in all collected images.

Figure 4 . 1 :

 41 Figure 4.1: Number of pixels in 2M images collected on 85K pages [14].Cumulative function of the number of pixels in images with a contentlength less than 100 KB. Out of 2M images, 36% are invisible: 9% have no content and 27% are of size 1 × 1 pixel.

Figure 4 . 2 :

 42 Figure 4.2: First-to-third party cookie syncing. In this example, the script loaded from google-analytics.com shares the first-party cookie ga_id via a redirection in a request parameter to doubleclick.net.As a result, doubleclick.net receives its own third-party cookie d_id and is able to conclude that both cookies belong to the same user.

Figure 4 .

 4 3 provides an overview of third party requests blocked by filter lists or detected as tracking requests according to our method, that we call Behavior-Track. Out of all 4, 216, 454 third party requests collected from 84, 658 pages of 8, 744 successfully crawled Alexa top domains: • 2, 558, 921 (60.7%) requests were blocked by EL&EP, • 2, 757, 903 (65.4%) were blocked by Disconnect, and • 2, 724, 020 (64.6%) were detected as performing tracking by BehaviorTrack.(a) EasyList & EasyPrivacy (b) Disconnect

Figure 4 . 3 :

 43 Figure 4.3: Effectiveness of filter lists at detecting trackers on 4, 216, 454 third party requests from 84, 658 pages. Further explanations on why filter lists miss trackers can be found in [14, Section 5.1].

  Figure 4.4 represents the effectiveness of the extensions in blocking the tracking requests detected by our method. Similarly to Merzdovnik et al. [MHB + 17], we show that tracker blockers (Disconnect, Ghostery and Badger) are more efficient

Figure 4 . 4 :

 44 Figure 4.4: Percentage of third party requests still allowed by ad-and tracking-blocking browser extensions. 2,924,480 tracking requests detected by our method were collected on Alexa top 10K websites. For further details, check [14, Section 6].

Figure 4 . 5 :

 45 Figure 4.5: First-party cookie NID set in a first party context of google.com becomes "third-party" when user visits w3schools.com. First party cookie NID is set in the user's browser upon the visit to google.com. This cookies is automatically sent to google.com when a third-party content from cse.google.com is fetched by the browser upon her visit to w3schools.com.

Figure 4 . 6 :

 46 Figure 4.6: Visualisation of hardware and software diversity. Numerous types of devices, operating systems, browsers and applications introduce variety in browser fingerprinting.

Figure 4 . 7 :

 47 Figure 4.7: Results of general fingerprinting algorithm [12]. Testing 485 carefully selected extensions provides a very similar uniqueness result to testing all 16,743 extensions.

Figure 4 . 8 :

 48 Figure 4.8: Uniqueness of Chrome users based on their extensions only vs. number of users [12]. 204 is the number of users used in [SSB17] and 854 the number of users considered in [SN17]

  Finally, in 2018, Al-Fannah et al. crawled the top Majestic 10,000 websites and recorded what was sent out by the browser [ALM18].

Figure 5 . 1 :

 51 Figure 5.1: Requirements for a valid consent on consent pop-up [19]. High-level requirements are derived from GDPR [GDPR], ePrivacy Directive [ePD09] and CJEU case law. Low-level requirements are derived additionally from non-binding sources, such as EDPB and DPA guidelines, complemented by Legal (L) or Computer Science (CS) interpretation. Assessment of each requirement can be done manually (M), with CS tools (T), via user studies (U) or via a combination of them.

Figure 5 . 2 :

 52 Figure 5.2: A typical consent pop-up on a popular cooking website marmiton.org provided by a Consent Management Provider "Didomi" that implements IAB Europe's Transparency & Consent Framework (TCF) [II18]. Screenshot made on 10 November, 2020.

Figure 5 . 1 :

 51 Figure 5.1: • Do consent pop-ups silently register a positive consent even if the user has not made their choice (R14)? • Do consent pop-ups actually respect user's choice made in the user interface (R15)? • Do they nudge the user to accept everything by pre-choosing a positive consent (R11)?

Figure 5 . 3 :

 53 Figure 5.3: Actors under IAB Europe TCF ecosystem [21]. IAB Europe, Advertisers (called "vendors"), Consent Management Providers (CMPs), Publishers, Data Subjects. The IAB Europe defines the purposes and features that are shown to users. Registered vendors declare purposes and legal basis and the features upon which they rely.CMPs provide consent pop-up, store the user's choice as a browser cookie, and provide an API for advertisers to access this information.

Figure 5 . 4 :

 54 Figure 5.4: A registration process for an advertiser ("vendor") under IAB Europe TCF v2.0. Screenshot made on 19 October 2020 at https: //register.consensu.org/.

Figure 5 . 5 :

 55 Figure 5.5: Purposes and legal basis of processing [17] declared by the registered advertisers in IAB Europe's Transparency and Consent Framework v1.1 and v2.0, measured in January 2020.

Figure 5 . 7 :

 57 Figure 5.7: Flowchart describing the forms of manipulation we observed in our dataset in relation to the consent task flow, compliance requirements, and dark patterns strategies [20].

Fig- ure 5 . 1 in

 51 Section 5.2).

Table 2 .1: Comparison of dynamic mechanisms based on runtime mon- itoring and information flow security analysis for JavaScript from [1].

 2 Information Flow Control (IFC) is a set of techniques to control how information flows through the execution of the program and is focused on enforcing the formal security guarantee of noninterference, ensuring that secret program inputs don't flow into public outputs. The first proposals to enforce noninterference were based on static analysis [SM03, HS06, MKS15] applied to the program as a whole, thus ensuring that all executions of the program satisfy noninterference.

	(a) Dynamic mechanisms based on runtime monitoring.
			Hallaraker	Yu et al.	Phung et al.	Meyerovich
			and	Vi-	[YCIS07]	[DdSC09]	and
			gna [HV05]				Livshits [ML10]
	Security proper-
	ties
	safety		✓			✓		✓	✓
	renewal					✓
	Formal guaran-
	tees
	soundness		×			✓		✓	×
	transparency		×			✓		×	×
	Implementation	auditing	code	code rewrit-	JS engine
	strategy		interactions	rewriting	ing	modification
			(b) Information flow security analysis.
			Vogt		Chugh	Li et al.	Devriese	Austin	Hedin
			et	al.	et	al.	[LZW10]	and	and	and
			[VNJ + 07]	[CMJL09]		Piessens	Flana-	Sabelfeld
								[DP10], De	gan	[HS12]
								Groef et al.	[AF12]
								[DDNP12]
	Information
	flow
	explicit flow		dyn		stat		stat	dyn	dyn	dyn
	implicit flow		stat		stat		×	dyn	dyn	dyn
	Formal guar-
	antees
	termination-		×		×		×	✓	✓	✓
	insensitive
	noninterference
	time-sensitive		×		×		×	✓	×	×
	noninterference
	precision	or	×		×		×	✓	×	✓
	transparency
	Implementation
	strategy
	browser exten-			✓		✓
	sion
	JavaScript en-	✓					✓	✓	✓
	gine

Table 4 .1: Usage of EL&EP lists in security, privacy, and web measure- ment communities (venues from 2016-2018) [14, Table

 4

  Blocking vs detection. Filter lists are designed to block outgoing requests that are suspected to contain trackers. We have to be aware that techniques designed to block trackers, such as filter lists and browser extensions, are by nature drastically different from techniques for detection and visualisation of trackers. We show it with our dataset below.For simplicity, we say that a request is FT is it matches one of the rules of the studied filter list. While comparing requests and responses we detect as tracking

	Content type	Missed by EL&EP Missed by Disconnect
	script	33.38%	35.27 %
	big images	20.62%	21.73 %
	text/html	13.77%	14.73 %
	font	8.79%	0.09 %
	invisible images	6.68%	12.21 %
	stylesheet	6.17%	3.05 %
	application/json	4.00%	4.83 %
	others	6.59%	8.12%
	Table 4.2: Top content type detected by BehaviorTrack [14] on the
	708, 308 requests missed by EL&EP and the 640, 809 missed by Dis-
	connect. We refer to images with dimensions larger than 50×50 pixels
	as "big images".

with BehaviorTrack to FT requests, we noticed that a significant number of requests we detect would have been blocked by the filter lists. This phenomena happens because requests detected by BehaviorTrack are not included directly in the website but instead are initiated by other third-party FT requests that would have been blocked if a browser extension based on filter lists was installed. By further analyzing the requests only detected as tracking by BehaviorTrack and missed by EL&EP (resp. Disconnect), we found that 14.31% (resp. 6.73%) of the requests detected only by BehaviorTrack are requests initiated by FT requests.

Table 4 .

 4

		[Eck10c] (2010)	AmIUnique [LRB16b] (2016)	Hiding in the Crowd [GBLB18] (2018)
		Desktop	Desktop	Mobile	Desktop	Mobile
	Number
	of finger-	470,161	105,829	13,105	1,816,776 251,166
	prints
	Unique
	finger-	94.2%	89.4%	81%	35.7%	18.5%
	prints

3: Uniqueness measured by three studies of browser fingerprinting

[13]

. Each study is based on a different sample of users in size and bias, measuring slightly different fingerprinting features, and over different periods of time in different years. The results differ significantly.

Table 4 .4: Overview of five major studies measuring adoption of browser fingerprinting on the web [13].

 4 Each study defined "fingerprint" as a set of varied features across studies. The sites crawled and the year varies. More importantly, each detection method was different and tailored to the studied fingerprinting features.

		Fingerprinting
		techniques	Sites crawled	Prevalence	Detection method
		detected
	Cookieless Monster [NKJ + 13b] (2013)	Detection of 3 known fingerprinting libraries	10K sites (up to 20 pages per site)	0.4%	Presence of JS libraries provided by BlueCava, Iovation and ThreatMetrix.
	FPDetective [AJN + 13a] (2013)	JS-based and Flash-based font probing	1M sites (homepages) 100K sites (25 links per site) for JS 10K (homepages) for Flash	0.04% (404 of 1M) for JS-based 1.45% (145 of 10K) for Flash-based	Logging calls of font probing methods. A script that loads more than 30 fonts or a Flash file that contains font enumeration calls is considered to perform fingerprinting.
	The Web Never Forgets [AEE + 14a] (2014)	Canvas fingerprinting	100K sites (homepages)	5.5%	Logging calls of canvas fingerprinting related methods. A script is considered to perform fingerprinting if it also checks other FP-related properties.
	1M Alexa study with Open-WPM (2016) [EN16b]	Canvas AudioContext fingerprinting, canvas-based font probing, WebRTC and	1M sites (homepages)	1.4% for canvas fingerprinting AudioContext 0.0067% for 0.325% for canvas font probing 0.0715% for WebRTC	Logging calls of advanced FP-related JavaScript functions.
	10K Majestic study [ALM18] (2018)	17 attributes others) (including OS, screen, geolocation, IP address among	10K sites (homepages)	68.8%	Data leaving the browser must contain at least one of the 17 monitored attributes.

  data. Websites, and more generally, web services must be operated in compliance with the data protection principles. Personal data means any information relating to an identified or (directly or indirectly) identifiable natural person. In determining whether the information relates to an identifiable individual, website publishers need to consider any means that could reasonably be used by them or any third party to enable the identification of an individual[START_REF][END_REF] Art. 4(1), Recital 26][WP136]. Examples of personal data include: IP addresses, user identifiers, URLs of the visited pages and other parameters that enable the user to be singled-out. Usage of cookies for storing identifiers are explicitly mentioned in [GDPR, Recital 30]:

Applicable rules for consent: the ePrivacy Directive and the GDPR.

  The ePrivacy Directive (ePD) [ePD02, ePD09] prescribes in Article 5(3) that websites are mandated to obtain users' informed consent before using any kind of tracking technology. Article 2(f) and Recital 17 of the 2002 ePD [ePD02] define consent in reference to the one set forth in Directive 95/46/EC [D95-46], the GDPR predecessor. The GDPR points out the conditions for obtaining valid consent in Articles 4(

https://team.inria.fr/privatics/

https://project.inria.fr/privaweb/

More discussion on the verification vs. enforcement is given in[START_REF] Falcone | You should better enforce than verify[END_REF].

In works on reference monitors, transparency requires that the semantics of executions that obey the security property in question is preserved[START_REF] Bauer | Edit automata: Enforcement mechanisms for run-time security policies[END_REF].

In this section, we only consider termination-insensitive noninterference.

Bauer et al. [BLW05] actually provide a more subtle definition, saying a monitor should output a semantically equivalent trace.

Figure 3.3 is inspired by the visualisation of precision and recall for pattern recognition from Wikipedia https://en.wikipedia.org/wiki/Precision_and_recall accessed on March

5, 2021.

For the introduction to hybrid monitors, see[START_REF] Guernic | Precise Dynamic Verification of Confidentiality[END_REF][START_REF] Guernic | Confidentiality Enforcement Using Dynamic Information Flow Analyses[END_REF], while multi-execution has been proposed for the first time in[START_REF] Devriese | Non-interference through secure multiexecution[END_REF].

Interestingly, I've been writing exactly the same conclusion in my PhD thesis on runtime

Popular ad-blocking browser extensions AdBlock Plus[adbb] and uBlockOrigin[ubl] also rely on EasyList and EasyPrivacy. Disconnect browser extension [Disc] and in Enhanced Tracking Protection of Firefox browser [fir] rely on Disconnect list.

This figure is a slightly modified version of figure produced by Pierre Laperdrix.

We use the terms "browser fingerprint" and "device fingerprint" interchangeably.

Even without Flash or Java plugins, that at the time were very popular and if enabled,

More insights into technical challenges in measuring adoption of browser fingerprinting can be found in[13, Section 3.4]

ePrivacy Directive is known among computer scientists and website developers as "cookie law". The upgrade of the ePD into an ePrivacy Regulation is currently under discussion.

Previous works give various names to this mechanisms, such as "cookie banner", "consent notice", or "consent banner". We will use the term "consent pop-up" in the rest of this manuscript because invisible data collection applies to various tracking technologies (not only cookies) and are often implemented in various types of pop-up mechanisms (not only banners).

In our technical analysis, we assume that the expert has access only to the client-side code accessible in a Web browser. DPAs can have additionally access to the server-side code during audits.

We further discuss the role of design in consent pop-ups in Section

5.5.

Standardization is used within the meaning of streamline at scale consent implementation.

All such advertisers are listed in the IAB TCF Global Vendors' List [IAB20b]. This list contains

vendors as of 30[START_REF] Rights | Say "NO" to cookiesyet see your privacy crumble?[END_REF]

Acknowledgements

I would like first to thank Frank Piessens for raising my interest in the Web security at the end of my PhD back in 2011 and making me realise I can do anything if I work hard and when I am truly motivated. Big thank you goes to Frédéric Besson and Thomas Jensen for helping me advance in the new field of Secure Information Flow and sponsor me to attend my first IEEE Security & Privacy in 2012, where I have met the amazing (back thank a PhD student) Franzi Roesner who was presenting her new NDSS'12 paper there in a poster session. I immediately got interested in her work and in Web Tracking Technologies and Ashkan Solani's investigations into cookie respawning only heated up my curiosity. I would like to thank my colleagues who welcomed me in the first Inria team

project funding -this gave me the freedom to explore a completely new area of Web Privacy, combining technical and legal research. my research at Inria Sophia Antipolis.

under-or overestimates the actual diversity and uniqueness of fingerprints.

Conclusion.

To measure the ground truth about diversity and uniqueness of users' browser fingerprints, the community should not use experimental websites, but rather browser extensions, such as in the latest work of Vastel et al. [START_REF] Vastel | FP-STALKER: Tracking Browser Fingerprint Evolutions[END_REF]. The design of the study should be critically analysed with respect to the (non-exhaustive) list of parameters we discuss in this section. As a research community, need to reflect on the design of such studies to be able to compare them (to the new studies as well) in a long term. The community needs to come up with a list of "ingredients" for a solid measurement strategy of uniqueness of browser fingerprints at scale.

Challenge: How to compare prevalence of browser fingerprinting?

Various works studied adoption of browser fingerprinting on the Web. We analysed [13] Chapter 6

A short conclusion

Our work covers a broad area of privacy protection of Web users, and contains both theoretical and practical contributions. There are numerous challenges to be resolved in order to advance privacy protection on the Web. In this short conclusion, we first remind the challenges we raised in the manuscript, underline the importance of transdisciplinary collaboration within several disciplines, and then briefly describe upcoming legal and technical challenges in the next few years.

The important challenges that still need to be resolved by both the legal and computer science research communities, as well as by policy makers: §3. The need for transdisciplinary collaborations. Our work demonstrates the need for an transdisciplinary collaboration between technical and legal researchers to work hand-in-hand before new laws are written. For example, all contributions in Chapter 5 were accomplished thanks to long-term collaboration with a legal scholar, where an transdisciplinary dialog has taken place upon regular visits over the last 3 years. Technical experts need also to be invited to the discussion of new legal proposals or their amendments.

Additionally, since EU Data Protection law contains consent as one of the legal basis 1 , many data controllers rely on it when processing personal data. The usage 1 See a full list of legal basis in Section 5.1.