The State of Online Tracking pt.2
First-party vs. Third-party
Web privacy is going through a renaissance, with pressure from all fractions of internet users, from activists to governments, we’re in a moment where web and browser developers are being forced to consider safer alternatives to online tracking. For example, Samsung Internet allows you to turn off third party cookies the Sites and Downloads page in settings under “Cookies.” So, we’ve all kind of agreed that third-party cookies are on the way out (learn more about cookies in part 1), but what takes their place? Google proposes First-Party Sets. Later in the series we’ll have a look at this proposal in more detail but in this post, I want to talk a little about the general concept of “first-party”.
What/Who/Where is a First-Party
There are two main classifications of ownership on the web, first-party and third-party. In my last post I spoke about what a third-party cookie is but these classifications don’t just apply to cookies, they can apply to many different web components i.e. APIs, databases, etc.
The way we tend to classify ownership online is through domains, it’s currently the most straight-forward way of doing things. For example, we can see that apples.fruit.com, grapes.fruit.com, and pears.fruit.com are all subdomains of fruit.com and are owned by the same entity. Since domains can’t have shared owners and require admin rights/access, they have a certain level of security. In this case, the three listed domains would all have a first-party relationship with fruit.com since the root is the same.
It’s helpful for me to imagine this as a chart structure.
Our three subdomains inherit from the root domain and are able to access permissions, storage (cookies, databases, security certs, etc) and APIs that are attached to fruit.com. A good real-world example of this is Google.
If you’ve used any Google service, you may have noticed how easy it is to share information between the services. You can be sent an invite to your email with the date and location inputted into your calendar and then ur calendar can share the location with maps. Google is huge, so each service/subdomain does have it’s own unique set of permissions and storages but foundationally, it’s the same principle. maps.google.com, docs.google.com and calendar.google.com are all have a first-party relationship with google.com.
The Third-Party
The third-party classification is kind of the inverse of first-party, the relationship between domains isn’t inherited like it is first-party since there isn’t a mutual root domain. For example, while we’re on apples.fruit.com we may want to share a particularly beautiful golden delicious to Instagam to show our friends and since there’s an Instagram share button on the site, we can do that in an instant. However, instagram.com and apples.fruit.com are completely different domains owned by different entities, this is a third-party relationship. apples.fruit.com has given instagram.com permission to post on your behalf so that you can easily share your favourite apple pictures. How the permission is granted will be dependent on the service but in situations like ours, usually as long as you’re logged into instagram.com you’ll be able to use the share buttons.
If we go back to our chart, the relationship may look something like this.
Instagram doesn’t inherit from apples.fruit.com nor any of the fruit.com domains, it’s more of a horizontal relationship, which can be severed at any time. They don’t share any of the same resources but may, for a set time, have access to data and/or functionality.
A good real world example of this is any news site, but we can look at The Guardian.
On this article, the share buttons are highlighted, if I click the Twitter button while logged into Twitter, I get the following screen
By clicking the Twitter share button while logged in, I’ve given guardian.com permission to create (but not post) a tweet on twitter.com on my behalf. Since guardian.com and twitter.com don’t share the same root domain, their relationship with each other is third-party. guardian.com can’t share the same SSL certificate with twitter.com or access any database hosted at twitter.com like a first-party relationship may allow.
Final Thoughts
The internet is stitched together with links and those links point to domains which act as addresses. If the root domain is the house, the subdomains are the rooms. In the W3C Privacy Community group, this idea is being thrown into question since we’ve come a long way since the internet was created. We’ve pretty much agreed that third-party cookies aren’t good, but how do we now share data within third-party relationships? What about companies who own multiple brands hosted at different domains (e.g. Alphabet owns both google.com and youtube.com)? I’ll be going into detail about this new Google proposal in my next post.
