Cookies from the Past: Timing Server-side Request Processing Code for History Sniffing Cookies from the Past

Cookies were introduced by Lou Montulli [57] while working in Netscape and are considered the first method to track users on the Web. Cookies allow services to remember a particular user by storing snippets of data on the users’ computers, maintaining a concrete browsing state for a returning visitor. After cookies were first presented, they were rapidly embraced by the web community because of their flexibility and the increased usability they enabled in a broad range of websites. As a result, they are now playing a core role as part of the Internet technology [47].

While cookies were not specifically designed to track users across websites, the abuse of their stateful nature started shortly after their first appearance. Since websites are composed of different resources that may be stored in the same domain hosting the page as well as in other third-party servers, these external resource providers have the capability of including cookies along with their provided resource. Therefore, if a third-party server provides resources to a large number of websites, it can certainly gather an accurate picture of a user's browsing history and profile her habits. For example, a website site.com includes an image from a third-party domain called advertisement.com. The server advertisement.com sends the image along with an HTTP Set-Cookie header, which will be stored on her machine. When the same user visits another website site-two.com that also utilizes images from advertisement.com, her browser will send the previously set cookie to advertisement.com alongside the request for the image. This allows the advertisement server to recognize the user and collect a list of the websites she regularly visits. This behavior, called third-party cookies, is arguably the most widespread technique for web tracking.

However, even the most privacy-invasive third-party cookies are an important part of the web. In fact, the most common usage of this specific type of cookies is web advertisement or analytics. Their web-tracking capability is used to track users’ browsing history and use this information to build a user profile for custom advertisements. In fact, advertising companies have already stated that web tracking is required for the web economy [58]. However, other techniques exist that can be used for analytics and targeting while preserving users’ privacy (e.g., References [2, 4, 5, 22, 24, 68]).

However, both third-party and first-party cookies are widely used and browsers even encourage their usage to ease usability. For example, when a user of the well-known Chrome browser decides to erase all the stored cookies, the browser warns the user that “This will sign out of most websites.” Even more important are the settings regarding cookies. Chrome recommends to enable the permission for websites to read and write cookie data and permits to block third-party cookies. Therefore, the importance of cookies is not only acknowledged by websites, but also by the browsers themselves, albeit the privacy issues that may arise.

Even though it is not a common action among the average web users, third-party cookies can be blocked (as detailed in Section 2.1). However, browsers do not allow users to remove just these cookies, leaving as only option to manually remove them one by one.

A large variety of history-sniffing methods exists. We can group these techniques in two categories:

CSS-based attacks. A common trick a page can use to detect if a user has visited other websites (out of a predefined list of targets) is to check the CSS style used to render links. For instance, by checking the CSS:visited style of a particular link [15] it is possible to tell if that link had been visited before (typically as it is displayed in a different color). Similarly, it is possible to craft other CSS-based techniques [25, 30, 59, 72] even using filters to exploit the differences of the DOM trees [71] by using a timing side-channel attack.

Timing-based attacks. There is a broad range of history-stealing techniques based on timing information. These approaches were first introduced for this purpose to compromise users’ private data by measuring the time differences in accessing different third-party content [20] by discovering if it had been cached by the browser. Extracting users’ true geolocalization for the same purpose is also possible through web timing, due to the high customization present in current websites. It is also possible to detect if the user is currently logged in to certain websites by timing of specific requests [7], exploiting the AppCache [36], or by estimating the size of certain resources [69]. As explained in Section 3, our own attack belongs to this timing-based attack category.

Countermeasures and Shortcomings. Some of the attacks discussed above are already mitigated by browser vendors. For instance, for the CSS:visited style check, all the corresponding browser functions (e.g., getCompu- tedStyle and querySelector) have been modified to always return that the user has never visited the link [40]. Despite these mitigations, recent work has shown that the attack is still possible using new features available in modern browsers. However, several possible defenses exist to avoid the problem, such as the ones proposed by Smith et al. [59]. In fact, one of these new techniques has already been blocked in Google Chrome [23].

In fact, all existing techniques fall in the classic “arms race” category, in which attacker and researchers constantly discover new tricks that are in turn mitigated by browser vendors, website developers, or even simply careful user settings. Therefore, we decided to investigate if it was possible to devise a new technique that would (1) rely only on server-side information and (2) that could not be easily prevented without degrading the performance or functionalities of a web application.

In the timing attack presented in this article, we adopt the same threat model used by previous work in the area [7, 69]. In particular, we assume an attacker can run JavaScript code on the client browser to perform cross-origin requests. This code can be either loaded directly by the first-party website or by a third-party service (e.g., by an advertisement or analytics company).

The information collected by our technique allows an attacker to determine which websites were previously visited by the user and on which website the user is currently logged in. There are multiple usages for this data that can result in serious security and privacy implications. The most obvious is related to advertisement, as the usage of the browsing history allows an advertiser to display targeted advertisements. Moreover, an interested tracker could create a predefined list of websites and generate a temporal fingerprint of various users, indicating the user's state in each of them. Even if the fingerprint could not be used as an standalone fingerprinting solution, it will definitely improve the fingerprinting capabilities of other web-tracking techniques. Finally, from a security point of view, this information can be used to perform targeted attacks against particular victims.

The first phase of our approach is the retrieval phase, in which the algorithm computes the time required by a server to execute different paths, according to hypothetical cookies sent by the browser. A simplified pseudo-code of the algorithm is presented in Figure 3. Note that the full implementation of the attacks is executed performing different asynchronous/non-blocking requests and using onreadystatechange event handlers. Moreover, even if security policies such as Same-Origin Policy (SOP) or Cross-Origin Resource Sharing (CORS) may limit the capabilities of interacting with the response of cross-origin requests, the event handler would still be able to correctly catch when the response arrives to the browser—making our attack possible in these cases.

To measure the round-trip times (RTTs), we use the User Timing API [73] implemented in every major browser. The best solution to get a measure of time independent of the current CPU load of the server or the current speed and congestion of the network is to perform a comparison with two different requests sent at the same time. Both time information are obtained side to side, so the workload of the network will likely be roughly the same in the two cases (especially when the experiment is repeated multiple times). To make it more clear, let us consider a simple example. Imagine we are timing the execution of certain function of the server that directly depends on the existence of a specific cookie. Our system would execute a measurement by executing in parallel two requests, with and without the cookies. In a first measurement, when the network workload is low, the system can obtain a value of 30.5 ms when cookies are sent and a value of 20.3 ms without cookies—thus estimating the execution time of the function in 10.2 ms. In a second repetition of the test, when maybe the network load is higher than before, the same experiment can return two different values, such as 45.1 ms with cookies and 34.7 ms without—leading to a similar (even if not exactly the same) time estimation. In Section 5, we present a number of stability tests, designed to verify to which extent our technique is robust against external factors that could tamper the results.

Following the schema presented in Figure 2, if a request requires x seconds to be processed (as opposed to y or z seconds), a simple comparison can be used to calculate the actual state of the user in relation with the website. The first request, the one we named as Case A, is issued without cookies by using:

This guarantees that the server would not receive cookies, even if the browser would have normally sent some for that particular website. Then, our code repeats the request, this time by setting

It is important to remark that the cookies sent in this second request (if any) are completely invisible for our Javascript code. However, the code can still measure the time required to receive an answer and use this information to infer the previous relation between the user and the target website: If the cookies were created in a simple access, the server response time will fall in Case B, but if some login cookies are stored in the browser the time would be more consistent with Case C.

To summarize:

• Not Accessed: If the user never accessed the website, and we perform the timings described above, we will obtain a result close to zero. In fact, the first request will take x seconds, because we made the request without cookies. However, also the second request with cookies will take roughly the same amount of time, as no cookie were available in the browser for the target. In this situation, we can infer than both calls were the same, indicating no previous access to the website under inspection.
  
• Accessed/Logged: If the user accessed the website in the past or if it is currently logged in to it, the result of the comparison of the time taken by the two request will be different from zero. As we are not using absolute values, but only time differences between consecutive requests, our technique can compensate for differences due to different network delays or workloads.
  A more fine-grained classification to distinguish between previous access and current login is also possible if the attacker has information about the different time required for specific actions. We will investigate this option and provide more details in the comparison phase section.
  

The algorithm (see Figure 3) takes one parameter n that indicates the number of comparisons to perform. As servers can have specific changes in their workload for many different reasons independent of our tests, we decided to obtain more than one simple comparison. Clearly, the more comparisons the attacker is able (or willing) to perform, the more precise is the model of the server-side computation she can obtain. Nevertheless, there is an obvious tradeoff between the time spent in fingerprinting a single website and the number of websites the attacker wants to test. We will investigate different options and the impact of the number of comparisons on the accuracy of the classification in Section 4.

As explained in the previous section, our code performs a number of measurements by timing different HTTP requests for a target website. By subtracting each pair of requests, with and without cookie, we obtain an array of n time deltas.

To classify this data, we need to obtain a ground truth dataset for the selected websites. To this end, we need to retrieve the computing time information for each of the cases we are interested to detect. By using this information, we can then statistically test whether a set of measurements belong to one group or another, simply by computing a T-test over the two data samples. A T-test is a two-sided test for the null hypothesis that two samples have identical average values. The result tells us which of the three presented cases a certain experiment belongs to.

Before we started our large-scale experiments, we wanted to experimentally verify that our hypothesis is correct and that the time difference among different server functionalities can be successfully distinguished over a long-distance network connection. For this reason, we implemented a toy service based on web.py [62], a simple but powerful Python framework that has been used by famous websites such as Reddit and Yandex. In our example, we controlled the time spent in each path. All HTTP requests sent to the service were issued from a browser located in a different country from where the server was located (Spain and France, respectively), to avoid any possible bias introduced by short-distance connections. The average ping time between the two machines was 13.6 ms.

The server-side application consists of less than 10 lines of code with just a single Python function. In this function, we receive the GET requests, and using the web.cookies method, we are able to check if the request includes any cookie, and its value. The service was designed to introduce no delay for requests without cookies, and a configurable delay (ranging from 1 to 6 ms in our tests) to the processing of any request containing cookies. The specific delay was indicated using that same cookie, which was created with JavaScript thought document.cookie. We were able to control the introduced delay invoking the function sleep from the Python time library.

The results of our experiments are summarized in Figure 4. The graphs show that it is possible to detect the time the server spent processing each request quite precisely (see Figure 4(a)), despite the network load. However, with delays below 4 or 5 ms, the difference among the two sets of requests measured by the browser is not statistically significant, and therefore an attacker could not conclude whether or not cookies were present in the browser for the target website (see Figure 4(b)). Instead, if the difference between two paths was equal or above 5 ms, then even over a long distance connection, it was possible to reliably tell the difference between the two cases. This indicates that it is not necessary for a website to perform complex computations to be vulnerable to our technique and even looking up some data from a database may be sufficient to make it vulnerable to our attack. Obviously, less-optimized servers are more prone to incur larger delays that are easier to observe remotely, while high-end servers may make the path detection more difficult and error-prone. We will analyze all these situations in the following section.

We first populated our list of personal information websites by performing various queries obtained through the auto-complete option offered by different search engines (e.g., “cancer treatment side effects”). We made five different queries for the following six categories: medical, legal, financial, sexual identity, political, and religion. Our tool issues each query on four search engines (Google, Bing, Yandex, and DuckDuckGO) and retrieved the top 100 results from each of them.

To avoid an overlapping between the two lists, we removed from this group domains that also belonged to the Alexa Top10K list. We also removed any website that appeared in multiple categories, as we wanted to focus only on specific areas in isolation. Finally, we obtained a set of 5,243 unique personal information websites. To balance the two groups in the dataset, we selected the same number of websites from the Alexa top list. The combination of the two groups resulted in a final dataset of 10,486 websites.

We implemented our BakingTimer proof-of-concept by using a custom crawler based on the well-known web browser Chrome without using any flag that may influence the network connectivity in any way. We can perform multiple actions using the Chrome debugging protocol (with the remote-debugging-port parameter), which allows developers to control the browser [9]. For instance, we can access different websites using the navigate command or run JavaScript code on the current website once loaded with the loadEventFired event and the evaluate command. The executed code uses xmlHttpRequest to perform the corresponding requests of the presented technique. Even if it would have been possible to implement the experiments by using a simple Python script, we decided to rely on a real-world browser to obtain the most realistic results possible. Our crawler follows two different phases to obtain the data that we will later use to check if a target server is actually vulnerable to the attack.

• Never Visited: First, the tool cleans every previous access information stored in the browser. Then, it starts making the different requests described in Section 3 (i.e., both with and without cookies, which in this case are none) from a third-party website (blank tab). This data will be later used as a baseline for requests performed when no previous access was done.
  
• Previously Visited In this case, the browser first accesses the website under inspection. No cleaning process is performed, so all cookies automatically created by the website are saved in the browser and sent to the server in the following requests. After that, it goes to a third-party website (blank tab) and starts making the different requests described in Section 3 to that same website under inspection.
  

Once all the data was retrieved, we performed the statistical tests described in Section 3 to identify whether the time information in the two groups of requests are statistically different or not. We also repeated the experiment with different number of requests to check their influence on the final result. To be practical, we tested with a minimum of 10 and a maximum of 50 comparisons (therefore ranging from 20 to 100 HTTP requests per target website). The higher the number, the more stable is the measurement, but so is the amount of time required to run the test. Therefore, the choice boils down to a tradeoff between precision and scalability. We believe that if the attacker is only interested in a handful of websites, then it would be possible to perform even more than 50 comparisons.

It is also important to note that, since we need to repeat the requests multiple times, it is possible that the first request “pollutes” the browser by setting cookies that are later sent in the following tests. In other words, if (i) the target website sets cookies on cross-origin requests and (ii) those cookies are the same (in number and nature) of those set when the website is loaded in the browser, then our timing attack would not work.

However, this does not seem to be very common, as more than half of the 10,486 websites we tested are vulnerable to our technique. The actual percentage varies between 40%, when the minimum number of comparisons is performed, and 53.34% if our attack performs 50 comparisons. Figure 5 shows the success rate at different numbers of comparison for the two groups separately.

This group includes 5,243 websites from the Alexa top websites list. As websites in these categories are visited by a large number of users, most of their servers and the code they run are likely more optimized, thus making more difficult to measure the timing side channel. This is confirmed by the fact that our attack worked on 35.61% of the websites in this category. This result is still quite severe, as it means than a webpage could still reliably identify if its users had previously visited more than one-third of the most popular pages on the Internet.

To get a deeper analysis of the obtained results, we clustered the websites in different categories, and we computed the percentage of each of them that were vulnerable to our attacks. To determine the category, we used three services: Cloudacl [14], Blocksi [6], and Fortiguard [21]. Their category names are similar, and, after a normalization process, we settled for 78 different category names. Table 1 shows that the top six categories vulnerable to the attacks include around 40% of the websites, with a peak of 43.75% in the case of sport-related websites in the Alexa top list.

This group includes 5,243 websites from six different categories related to private personal information—i.e., medical, legal, financial, sexual identity, political, and religion. The results from these websites allow us to understand two different aspects. First, we can verify the amount of websites directly related to sensitive information that are vulnerable to our attack. Second, it gives us an opportunity to test less-popular websites (as 85% of the vulnerable sites in this category are ranked below the Alexa Top500K) to observe whether smaller server infrastructures can result in a higher accuracy of our technique.

The results of our experiments show that a stunning 71.07% of all the analyzed websites in this group are vulnerable to the BakingTimer attack. If we break down the result by category, we see that all have similar percentages and there is no clear difference between them (see Table 1). This result is much higher than the one obtained in the top Alexa group, but the difference is not due to the number of cookies. In fact, we compared the mean and standard deviation of the number of cookies in privacy-sensitive websites and highly popular websites. Unsurprisingly, the results show that highly accessed websites have a higher mean number of cookies $(9.03\pm 7.87)$ compared to the number of cookies in private personal information websites $(5.83\pm 5.49)$. This means that the main reason behind the difference is not linked to the number of cookies, but more likely to the slower servers or the less-optimized code responsible to process the incoming requests.

From this category, we selected two popular websites, related to gaming and clothing, that were detected to be vulnerable to our BakingTimer attack (Section 4) and that have been the target of different phishing attacks— in one case for the huge number of users and in the other case for the high economic value of their customers. More concretely, World of Warcraft (WoW) and Gucci.

In both cases, after the user logs in, a number of cookies are created in the user's browser to store this new status (e.g., wow-session and gucci-cart, respectively). The presence of these cookies makes the server take a different execution path, resulting in a different computation time. We followed the same analysis principles as the ones used when we analyzed the websites in Section 4 and detected both websites fall in our simplified three-paths model presented in Figure 2. The results show that each of the different states (e.g., not accessed, accessed, and logged in), does not match any of the other two states when performing the statistical test of the comparison phase (see Section 3).

Detecting if a user has previously visited a website linked to specific information such as religion or sexual identity can leak some private information to third parties the user may not even be aware of. However, if the third party could actually detect that the user is currently logged in to one of those websites, the link between the user and the website becomes much stronger.

From this category, we picked a religious website (Dynamic Catholic) and a sexual related chat/forum (LGBTchat.net). Again, the presence of login cookies (i.e., xf_user and frontend_cid) made the two applications take different execution paths, whose computation time was sufficiently different to be reliably fingerprinted by our solution.

In all previous cases, when the user logs out from the website, the different cookies related to the login status are deleted by the server. In this situation, a third-party website would still be able to detect that the user has visited the website in the past, but it would not be able to distinguish if she had an account and she ever logged in to the service.

While this may seem obvious, there are also websites for which it is not true. In fact, some sites do not properly (or at least not completely) delete all cookies they created in relation to the login process. This could be either because the cookie-deleting process was not performed correctly or because the website developers explicitly decided to maintain part of the login information stored in the cookies even when the user is not logged in. However, the presence of these cookies can be sufficient to trigger a different code execution in the application that can be detected by our technique. This allows third-party to be able to differentiate users that just accessed the websites from those who own an account, even if they are not logged in at the time the test is performed.

For instance, both Microsoft/MSN and Openload fall into this category because of the presence of, respectively, a MUID cookie and a cookie with an MD5 hash as name. In both cases, when the user logs out of the service, some cookies are deleted but some others are maintained in the browser. In these two specific cases, we first classified the websites following the same three-state schema as in previous cases. Then, we logged out of the service and checked if this state would be classified as logged or accessed. Our results show that, in both cases, the comparison phases classified this state as logged. This indicates that even if the user logged out, if the website does not correctly delete all related cookies, it would be possible to detect a previous logged state.

To obtain the most reliable results, it is important to perform the experiments against multiple real-world websites. In fact, synthetic websites or small sample sets may not correctly capture all the implementation patterns encountered in the wild. Our tests show that more than half of the websites we analyzed are vulnerable to our attack. This means two important things: First, that there is a measurable, statistically significant difference between the time the server spends processing the two classes of requests (with and without the access cookies); second, either the website does not set cookies on cross-origin requests or those cookies are different from the one created on a regular access.

Table 2 shows the different state-of-the-art timing methods and their different characteristics, both in terms of adopted technique and on the type and size of the experiments performed to validate.

Table 2. A Comparison of Current State-of-the-art Timing Methods for History Sniffing

Approach	Type	Login	Difficult	Previous	Websites
		Status	Clean	Access	Analyzed
Timing Attacks on Web Privacy [20]	Web & DNS Caching	✗	✗		$\lt$10
Exposing private information... [7]	Server Boolean Values			✗	$\lt$10
Cross-origin Pixel Stealing [32]	Cross-origin DOM Structure			✗	$\lt$10
Identifying Cross-origin... [36]	HTML5 Application Cache		✗	✗	$\lt$10
The Clock is Still Ticking [69]	Cross-origin Resource Size			✗	$\lt$10
Our Approach (BakingTimer)	Cookie-based Request Timing				10,486

The majority of previous works allowed an attacker to detect the login status of a victim in other websites. Only one [20], apart form ours, allows also to detect the access state (but this same technique is unable to detect the login status). The only technique able to detect both access and login state is the one presented in this article.

Most of existing attacks, including our own, do not rely on any other browser resource than the cookies. This makes the technique resilient to generic browsing history cleaning processes, as browsers explicitly discourage users to delete cookies in their settings (see Section 2). Two techniques are instead based on different types of browser caching that, in contrast to what happens with cookies, are even deleted by default, and therefore users can easily and without any major consequence delete them when needed.

Regarding the number of websites analyzed, as nearly all the techniques are only able to detect the login status, the manual effort needed to perform a large-scale analysis made large-scale experiments unfeasible. We also presented a similar set of experiments in Section 6, but we also performed an automatic analysis of over 10K websites divided in different categories to provide a general overview of how effective this attack can be.

The first version referencing this technique [26] just indicated that if detected (case-insensitive match), the browser must append an attribute called samesite-flag to the newly created cookie with an empty value. The following version [27] included two possible values: Strict and Lax. If the value is set to Lax, it indicates that the cookie should only be sent on requests within the same site or through top-level navigation to that specific site from other different sites. A value of Strict limits the cookie inclusion on request only to those originated from the same site. If none of those two options is indicated (i.e., the field is either malformed or left empty), it would be enforced as Strict. It is important to note that for instance, if www.example.com requests an image from static.example.com, it would be considered like a same-site request. Browsers should use an up-to-date public suffix list (such as the one maintained by Mozilla [39]) to detect these situations. A new version of the draft was published in April 2016 [28], which includes one main modification to the previous one: If the SameSite attribute is included, but no case-sensitive match is found for Strict or Lax, the browser should ignore it. This differs from the preceding version, which suggested to use a Strict enforcement on this same situation. Additionally, the revised version included the value None, which should only be set in cases where the SameSite attribute was not indicated (defined as “monkey-patching” in the draft).

In May 2019 a completely new Internet-Draft was published titled “Incrementally Better Cookies” [45]. In this document, there are two main changes inspired by the HTTP State Tokens draft [44]: (i) cookies are treated as Lax by default (breaking backwards-compatibility); and (ii) cookies that require cross-site delivery can explicitly opt in to that behavior indicating the None value in the SameSite attribute when created. There is an additional important point in the second case: Those cookies need the Secure attribute, indicating that they must be transmitted over HTTPS. The last version [46], published in March 2020, included a temporal option, where unsafe top-level requests (e.g., POST) can include recent cookies (e.g., created less than two minutes before) that did not indicate the attribute.

The SameSite attribute was implemented in all three major browser families, but each family followed a different strategy in the process. We will explain how each of them adopted this countermeasure and the market share of each of them (based on the data of March 2020 of Stetic [60]), to assess the impact.

• Google Chrome (49.82% of the market): Started implementing the SameSite attribute in version 51 [10], published mid 2016, following the draft published in April of that same year [28]. In this case, only cookies with valid values would be used, and no default enforcement was implemented. This approach was adopted until version 79, all together accounting for 13.49% of the total web users (27.08% of the Google Chrome share). The more recent behaviors presented in the last draft [46] (Lax by default) started to be implemented in version 80 [65]. However, they are currently only deployed for a limited population, to monitor and evaluate the impact on the ecosystem, with the plan of gradually increasing the distribution in subsequent rollouts.
  Nowadays, Google indicates that it is still targeting an overall limited population of users with the last Chrome version. Taking into account that 35.33% of the web users browse with this version and that only a small percentage of them implement have it implemented, we can expect that in total less than 2% of the total web user are running this restricted policy in their browsers. It is interesting to note that this more restrictive SameSite behavior will not be enforced on Android WebView or Chrome for iOS for now, reducing even more the number of users that run this functionality. Moreover, Chrome has implemented new policies to avoid possible problems regarding this change in the cookies behavior (e.g., LegacySameSiteCookieBehaviorEnabled), which will allow browsers with the restrictive behavior implemented to revert to the legacy SameSite behavior [66].
  Due to the extraordinary global circumstances (COVID-19), at the time of this writing, Chrome is temporarily rolling back the enforcement of this SameSite restrictions, starting from April 2020 to the end of the year [11]. According to Google, this is done because “we want to ensure stability for websites providing essential services including banking, online groceries, government services and healthcare that facilitate our daily life during this time.”
  
• Apple Safari (30.97% of the market): Apple implemented the SameSite attribute at the end of 2018 in iOS 12 and macOS 10.14 (Mojave) [67]. The developers followed the second version of the draft about Samesite [27], indicating that cookies will be enforced to Strict by default. At the time of its implementation, a newer version of the draft already existed [28], where there is no default enforcement for cookies, only the general Strict or Lax. This was reported as a bug [70] and fixed in Safari 13 (17.33% of the browser share). However, the Safari development team indicated that they are not planning to backport this fix in older iOS or macOS versions, and they recommend developers to check the user-agent value before creating the cookie, to act accordingly.
  
• Mozilla Firefox (15.28% of the market): Mozilla implemented the SameSite attribute in mid 2018 in Firefox 60 [43]. They followed the last version of the original draft [28], cookies do not have a default enforcement, and there are the Strict and Lax options if opted in. However the developers are currently making some tests in Nightly [41], with the first version of the final draft [45], where Lax is the default. However, they do not plan to include it in the stable version. (“We are not planning to ship this feature yet. We are testing in nightly only to see the level of breakage.” ) Moreover, Mozilla is running additional tests with the last version [42], where the developers included the option of unsafe top-level requests when cookies are newly created (<2minutes).
  

To summarize, most of the browsers are implementing the SameSite attribute without any default enforcement, and just a small percentage of the global web population (maybe 1 to 3%), will have access to the restricted version in a near future.

Now that we better understand the adoption of the SameSite attribute on the browser side, we wanted to also measure to which extent website developers implemented the SameSite attribute on the server side. Moreover, we are interested in analyzing how this new feature could affect the attack presented in this article. For this purpose, we used the Tranco 1M most accessed domains list [35], which is a combined ranking of Alexa [3], Cisco Umbrella [13], Majestic [37], and Quantcast [49], to offer better confidence and stability.

We used a custom crawler based on the open-source web browser Chromium to access the corresponding websites, and we collect all the information regarding cookies (e.g., headers and creator) using a custom instrumentation developed using the Chrome debugging protocol (CDP) [9]. Our extension loads the home page of the domains and then recursively visits three random pages from each website, up to a distance of three starting from the home page (up to 13 pages per website), following the approach presented in previous studies [50]. To avoid the detection of our crawler, we also implemented the most recent methods proposed to mimic real users [16, 55, 56].

Out of the 1M websites we visited, 76% created cookies. In total, we detected the creation of 138M cookies. However, the attack presented in this article does not use all the different cookies that are created in an access, but only those first-party cookies that were dynamically generated (using JavaScript or the HTTP Set-Cookie header). For example, if all cookies created on the website are first-party cookie generated statically (i.e., in the main page request), the attack would not work, as those cookies would be polluted in subsequent requests performed to detect the users’ state (as previously indicated in Section 4).

Therefore, we started by checking what is the percentage of cookies that are interesting for our history-sniffing attack and found that 56% of all the cookie creation we detected were dynamic first-party cookies, 37% were third-party cookies, and only 7% were actually static first-party cookies. This shows that the cookies required by our attack represent, by far, the biggest group of cookie type found on websites nowadays.

Even if indicating percentages of global numbers can help to comprehend the scale of the phenomenon, those percentages could be misleading if only a small group of websites generate many cookies of one specific type. To give a more accurate view of the current state, we performed an additional analysis in which we calculated the percentage of each of those cookie types per website, and then we represented the occurrence of each of them. Figure 7 shows three curves representing, respectively, static first-party, dynamic third-party, and third-party cookies. The Y axis shows the number of websites, while the X axis shows the percentage of each type of cookie. So, for instance, we see that around 10K sites have 90% of their cookies belonging to the dynamic, first-party category—but less than 1K have 90% of static, first-party cookies. From the figure, we can draw two conclusions: First, static cookies are a minority in most of the websites (left part of the graph); second, dynamic, first-party cookies are a vast majority in many websites (right side of the graph). This indicates that the cookies used for our attack exist in most websites, and that they represent the largest percentage of all cookie on each of them.

After detecting that dynamically created first-party cookies are the most common type of cookie, we wanted to analyze how those cookies are protected against the history-sniffing method presented in this article. In total, around 99% of the cookies did not indicate any type of SameSite attribute, but as we indicated before, this may misrepresent reality, because some small number of websites may create a disproportionate amount of cookies. By following the same approach described above, we calculated the percentage of dynamic first-party cookies with the different possible SameSite attribute values and reported the occurrence of each of them in Figure 8 (log scale). The figure shows that Strict and None values are not very common, indicating that developers do not normally implement neither the extreme restrictive nor the open options. The two most common values we found are Empty and Lax, which, respectively, provide a milder form of protection and no explicitly selected choice. However, the distribution resembles the one seen in Figure 7 regarding cookie type.

Lax is generally more common in low-percentage cases (<30%), but Empty is the prominent choice for a very large amount of websites. Again, this clearly indicates that dynamic first-party cookies with empty SameSite attributes are present in most websites and that they represent the largest percentage of all cookie on them.

If we now take into account the browser adoption for the SameSite attribute, we can clearly see that today the protection offered by the SameSite attribute against our attacks is very small. Only a very small percentage of websites are protecting their cookies (Strict or Lax), and a very small percentage of the total web user population, as calculated in the previous subsection, is using (or will be using in the near future) a browser that implements restrictive enforcements (e.g., Lax by default) [46].

We wanted to go one step further, so we calculated which is the percentage of websites that, due to the little implementation of the SameSite attribute described in the previous subsection, are susceptible to be vulnerable to our technique. To be conservative, we will separate those websites that have unprotected identifier cookies from those that do not, assuming that it is more likely that a cookie that stores an identifier can trigger a different path on the server request processing code. To identify possible identifiers, we pre-filter cookies by using zxcvbn method proposed in a recent GDPR related work [52]. To be as precise as possible, we divided websites in three different groups:

• Susceptible: Created dynamic first-party cookies that contain possible identifiers, without using the SameSite attribute, or with None value.
  
• Improbable: Similar to susceptible, but in this case the cookies did not contain a likely identifier value.
  
• Safe: Did not create dynamic first-party cookies that could make the site vulnerable to our attack.
  

Overall, 65% of all the websites with cookies are susceptible to being vulnerable, 7% were improbable to be vulnerable, and only 29% were certainly safe. It is important to note that these numbers do not indicate that those websites are in fact vulnerable, as their server-side code may not depend on certain cookies to trigger different code paths. However, we can say that those websites can be vulnerable based on the adoption of the countermeasures currently offered.

Finally, we wanted to check if there are differences between website categories (classified using website-to-category data from a commercial engine [63, 64]). We performed this same classification based on that data and reported the results of the top and bottom six categories in Table 3. Results hint that websites with high user interaction rate (such as shopping, news, and forums) are more prone to be vulnerable, while security/privacy dubious websites belonging to the malicious, suspicious, and analytics categories are less prone. One of the possible reasons for this is that highly interactive websites create multiple dynamic first-party cookies to communicate with the user, and the second group of websites relies more often on third-party cookies.

This analysis demonstrates that, to be completely protected from the technique presented in this article, all cookies must set the SameSite attribute with the Strict or Lax value. As long as one of the cookies involved does not specify this option, the attack would still work. Due to the sensitive nature of login cookies, they could be more prone to use this option. Nevertheless, it is important to remark that some sites could lose part of their core functionalities as a result of using Strict or Lax SameSite cookies. In fact, many types of websites, such as social networks or cashback services, rely on cookies to be added in third-party requests, and therefore the global applicability of this countermeasure could be limited in several website categories.