5. Cookies cloning with front-end implementation

In September 2019, Apple introduced ITP 2.3, a significant privacy update that removes 3rd-party cookies after 7 days. Google has also implemented restrictions on certain aspects of 3rd-party cookies, and has announced plans to block 3rd-party cookies by default in future updates of Chrome browser. Mozilla has already been blocking 3rd-party cookies by default since 2019. It is highly likely that other browsers may also be implementing or planning restrictions on 3rd-party cookies.

How does this affect you?

When utilizing Safari, it is important to note that the browser automatically deleted stored SLID cookies, used by the Gravity Field personalization platform to identify users, if a user has not visited your site for 7 or more days. Thus, a returning user will be perceived as new. The consequences will be significant: the number of Safari users will be overestimated, which will impact several aspects of personalization, including reports and A/B testing. To overcome this limitation, it is necessary to pass the SLID cookie from your server, transforming it into a 1st-party cookie, which in turn will allow you to avoid the influence of the above restrictions.

These limitations work the same way in any browser that restricts 3rd party cookies. In the future, there may be differences in the restrictions of different browsers.

The solution lies in setting the SLID cookie by the backend application that serves your website. Cookies installed this way are perceived as 1st-party (own domain cookies, not third-party ones) and are not subject to Intelligent Tracking Prevention (Apple ITP), and will have a prolonged lifespan. The installation process consists of two steps:

  1. Checking the user's current cookies.

  2. Processing the cookie according to one of the scenarios below:

    2.1. If the user has a cookie named _slid_server, its lifespan needs to be updated to one year. The identifier value remains the same.

    2.2. If the user has a cookie only named _slid and there is no cookie named _slid_server, the identifier must be copied from the _slid cookie to a new cookie named _slid_server. Do not set HttpOnly parameter for the new cookies.

Example:

Suppose the value of the _slid cookie is 63317316ce625bd9270b6442. It is necessary to duplicate this value into a new _slid_server cookie and set the lifespan to 31556951 as the maximum value of the attribute. Result: _slid_server=63317316ce625bd9270b6442;max-age=31556951

The cookie must be set from the root domain in the format ".yourdomain.com".

Interaction scenario

  1. The user visits your site.

  2. Your server (backend application) receives a request to display a page in the browser. Requests from returning users include either both the _slid and _slid_server cookies or just the latter.

  3. The server application performs the following steps:

    1. Checks if the request has _slid cookie.

    2. Checks if the request has _slid_server cookie.

    3. If there is only an _slid cookie in the request, duplicates it as a new _slid_server cookie. If both cookies are present, proceed to step d without duplication.

    4. Returns the new cookie as a response header with a lifespan of 1 year. These actions set the _slid_server cookie as a 1st-party server cookie. Thus, its lifespan cannot be forcibly reduced by a browser anymore (keep in mind that the _slid cookie will continue to be returned, no need to change that).

  4. After matching identifiers, the user will see the content rendered for them. Thus, user data will not be lost, even if they have not visited the site for more than 7 days.

Code samples

>>> curl -v http://yoursite.example.com --cookie "_slid=63317316ce625bd9270b6442"                                                                                                                                                                                                                                                                                        19:55:13
*   Trying 172.217.18.4...
* TCP_NODELAY set
* Connected to yoursite.example.com (172.217.18.4) port 80 (#0)
> GET / HTTP/1.1
> Host: yoursite.example.com
> User-Agent: curl/7.64.1
> Accept: */*
> Cookie: _slid=63317316ce625bd9270b6442
>
< HTTP/1.1 200 OK
< Date: Mon, 30 Mar 2020 16:55:16 GMT
...
< Content-Type: text/html; charset=ISO-8859-1
...
< Set-Cookie: _slid_server=63317316ce625bd9270b6442; expires=Wed, 29-Apr-2021 16:55:16 GMT; path=/; domain=.google.com; Secure

Validation of the installation using the example of the Chrome browser

To verify the correctness of the installation, you need to:

  1. Open developer tools (Command+Option+J) for Mac or Control+Shift+J (Windows, Linux, Chrome OS).

  2. Go to the Network tab

  3. Select Preserve Log and clear history

  4. Refresh the page

  5. In the column with event names, find the one where the name is the address of your site

  6. Go to the Headers section of this event

  7. In the Request headers subsection, the values of the _slid and _slid_server cookies should match

Note that verifying the correctness of cookies is impossible through the Applications section of developer tools, since this section includes both server-side and client-side cookies and some of them may be automatically removed by Safari.

Last updated

Was this helpful?