The server-side redirect for ITP 2.3

Please note that the below article was written before the March 2020 update to ITP 2.3. Following the update, link decoration is no longer a defining criteria for Apple’s ITP to trigger – so the method mentioned in this article to strip link decoration will no longer mitigate its side effects for any publishers who may be affected. It is however still a valid method for publishers to protect user privacy, by preventing third parties from tracking users across domains.
Permutive customers are still supported to succeed unaffected by the impact of Apple’s ITP.

—

Permutive customers are supported to succeed in a privacy-compliant fashion and without ITP impact, which can be a side effect of Apple’s campaign to tackle third-party cross-domain tracking. For any other publishers who are impacted by ITP 2.3 or who simply wish to prepare for the privacy-led future ahead, this post includes the theory and simple technical implementation of a server-side redirect service to strip URL query parameters and prevent local storage being marked for deletion by ITP 2.3. 

 

The behavior described in ITP 2.3 was rolled out with Safari version 13. For more general information around the ITP program, please refer to the series of posts published by Apple’s WebKit team.

 

The goal of the server-side redirect 

 

Apple’s WebKit team has set out clear criteria to define the “abuse of link decoration” for cross-site tracking, which is the target of ITP 2.3’s restriction. A countdown of seven days will start for deletion of local storage data for a website if both of the following conditions are satisfied: 

 

1.    the website from which the request originated (the Referrer in the request) is classified as a tracking site. (The list of tracking sites is a moving target which is maintained by each individual device using on-device Machine Learning.)

 

2.    the URL of the request contains query parameters (key-value pairs in the URL after the ? sign that are also sometimes referred to as GET parameters)

 

Addressing either of these conditions will prevent the use of link decoration for cross-site tracking, and therefore prevent the countdown for local storage deletion from being triggered. 

 

As the list of tracking sites is not static and cannot be influenced, there is little that can be done to combat the first condition above. However, a server-side redirect service is a way to successfully address the second condition by removing query parameters from the URL. This way, one of the trigger conditions is not met and local storage will not be marked for deletion. 

 

Ultimately, the redirect service promotes user privacy by preventing third-party scripts that run on the page from tracking users across the web.

 

How the server-side redirect works (in theory)

 

Normally, a request for website A would be served by its web servers, returning the requested content. However, when a redirect service is in place, the webserver must first check the existence of query parameters in the requested URL. If no query parameters exist, the request gets processed as normal. If query parameters are present, a redirect response is immediately returned pointing to the same requested URL but with the query parameters removed. This redirect response will instruct the browser to request the page again, this time using a clean URL that will not trigger the conditions for local storage deletion.

 

The following diagram describes the journey of a request subjected to the redirect service, i.e. one with query parameters:

 

 

1.    A user, via a browser, accesses website A with a URL containing query parameters e.g. exampleA.com/article/1?cid=1234

2.    Website A’s web servers, upon receiving the request with query parameters, return a 301 redirect response with the location set to the same original URL with its query parameters stripped out. E.g. exampleA.com/article/1

3.    The browser follows the redirect response and opens the new page – this time without query parameters. From this point onwards, Website A‘s web servers respond as they normally do

4.    The actual content of the page returns.

 

Step 2 in the diagram is the critical one. It’s this server-side redirection response in the presence of query parameters that will stop ITP 2.3 from marking local storage for deletion.

 

The server-side redirect service in practice

 

Now that we understand the goal and the theory behind a server-side redirect service, this section of the post demonstrates what it means in practice for developers.

 

The following example focuses on an off-the-shelf nginx configuration with no customization. The same concepts should be easily replicable to other software stacks but may vary depending on the individual characteristics of your own configuration, tech stack and use cases.

 

server {
  listen 80;
  server_name localhost;  

  # enables nginx to sit behind a reverse proxy
  absolute_redirect off;

  # only redirect if query parameters exist in the request
  if ($is_args) {
    # redirect to the requested URI (no query parameters)
    return 301 $uri;
  }

  location / {
    root /usr/share/nginx/html;
    index index.html index.htm;
  }
}

 

The nginx configuration above contains the minimum necessary to implement the redirect service (and was tested using nginx version 1.17.4). There are three notable points relating to this configuration:

 

1.    Turning off absolute_redirect allows you to run this configuration where the protocol and port number of nginx does not match one of the external services e.g. reverse proxies, containers, etc. It would mean the location in the redirect response will be relative to the current page.

2.    The absolute_redirect and if condition for query parameters can be restricted to a single location section in nginx (rather than for the entire server section)

3.    The absolute_redirect directive has been available since version 1.11.8.

 

Testing it with Docker

 

If you paste the configuration above into a local file, say default.conf, you can run an nginx instance with Docker for validation, as follows:

 

docker run -ti --rm -p 8080:80 -v
$PWD/default.conf:/etc/nginx/conf.d/default.conf nginx

 

If you then access http://localhost:8080?param1=value1 in your browser, you will be automatically redirect to http://localhost:8080/.

 

Important notes

 

Permutive customers are supported to succeed without ITP impact, which can be a publisher side-effect of Apple’s campaign to tackle third-party cross-domain tracking. The server-side redirect is a potential solution for any other publishers who are affected to address technical challenges around ITP 2.3 – and a way for all publishers to protect user privacy. However, there are factors that must be taken into account before implementing this or any other change.

 

For example, your site might make genuine use of query parameters. (An important caveat from Apple WebKit: “If your website relies on query parameters for functioning correctly, implementing such redirect service might break things.”)
You may have existing processes in place to measure campaign performance – or, you might require a mechanism for performing link click attribution.

 

Privacy-preserving alternatives to requirements such as these are being developed by browsers to prepare for a privacy-compliant future (e.g. the ad click attribution by WebKit engineers, and the privacy sandbox proposal by the Chromium team), but there is still some way to go. It’s therefore important to be aware of your individual circumstances when considering server-side redirects or other infrastructural changes, and discuss any concerns with your DMP or other relevant technology providers.

 

For more of our thoughts on ITP 2.3, take a look at our article ‘What publishers can do about ITP 2.3’.