3rd Party Cookies & Server-Side Implementations
25 Apr 2021 » Server Side
A few weeks ago I heard of a conversation between Adobe and a customer about server-side implementations of web analytics and optimisation tools. In this case, the problem was that some vendor was misleading our customer. Well, actually, this vendor blatantly lied. I wanted to explain this situation so that none of my readers fall into this trap.
Setting cookies
I am not going to explain again what cookies are. If you need a refresher, check my post on Cookies: Back to Basics. However, I will explain in more detail how cookies are set. There are two ways of doing so: JavaScript or HTTP headers.
JavaScript
Although there are many libraries to help the JavaScript developer to set cookies, all methods end up invoking the same call:
document.cookie = "cookiename=cookievalue; expires=Sun, 24 Apr 2021 12:00:00 UTC; path=/"
Now, all cookies have a domain. Where will the browser store a cookie in the previous case? Under the domain of the browser’s tab or window, also known as the origin domain. If I were to execute this code in this blog, the domain would be www.pedromonjo.com . However, the code above also allows to specify the domain:
document.cookie = "cookiename=cookievalue; expires=Sun, 24 Apr 2021 12:00:00 UTC; path=/; domain=www.mywebsite.com"
So, you may be tempted to set the domain of the cookie to a different domain than the origin. This will work if the cookie domain is a parent of the origin. For example, if your origin is abc.mywebsite.com , you can set a cookie under mywebsite.com . But if you try setting it to a completely different domain, the browser will silently ignore your code and will not set the cookie. If you do not believe me, try it yourself!
HTTP headers
The HTTP protocol defines an HTTP header called: Set-Cookie, which does exactly what it says on the tin. With this header, a server can instruct a browser to set a cookie.
Set-Cookie: cookiename=cookievalue; expires=Sun, 24 Apr 2021 12:00:00 UTC; path=/; domain=www.mywebsite.com
Now, there is one caveat: the browser will only accept cookies for the same domain of the server or a parent domain. Again, if you try to set a cookie under another domain, the browser will silently ignore you.
Let me clarify here one detail. If you have a website under www.mysebsite.com and your images are stored under images.myassets.com , when the browser fetches the images, the server domain will be the latter. So, with all that I have explained so far, browsers will not allow your assets’ server to set a cookie under you website’s domain.
Server-side
And here is where the story I started with, comes back. We have a customer who insisted that another vendor could set cookies under other domains, server-side. I was not part of this conversation, but I am pretty sure that this vendor claimed that they could do something Adobe could not. Our client fell into the trap and bought from this vendor. After the implementation, this client found out that the vendor’s technology was injecting JavaScript under the hood. This infuriated our customer, as the vendor never disclaimed this “detail” and the customer did not want any additional JavaScript. After all, that is why they wanted a server-side implementation.
If you do not want to fall into these traps either, remember to be more tech-savvy than this client. As I have explained, in a server-side implementation, you can only set cookies using HTTP headers and these are limited to you server’s domain and parent domains. This is not a limitation that I have just come up with or imposed by Adobe. It is a limitation that was defined when the web was being defined back in the 90’s and all browsers have securely incorporated. If you want to set domains in other domains, you must use other techniques, that involve JavaScript code and the same principles of ID syncing.
There is no way around it.
Image by rawpixel.com