Enter: Third Party Cloaking Mitigation

The Webkit team (the browser that powers Safari and iOS) has a long history at this point of deploying features to promote privacy and limit the effectiveness of entities that violate user privacy, such as advertisers. With the goal of promoting user privacy in mind the Webkit team has been monitoring the industry since the the last change in September of 2020. They noticed that an increasing number of advertisers and third parties are leveraging a gap in the defenses of the current design, and have decided to submit a patch which will address the problem. In typical fashion this change forces a shift in how websites need to be designed in order to adhere to the new landscape in regard to cookies.

What Happened?

The Webkit team has effectively redefined what “third party” means in terms of web development. To understand why this was required we should review some history for the added context.

Typically, the various parties are considered like this.

First Party: The URL of this website is cunderwood.dev this is the Top Level Domain, and anything that is part of the domain, is typically considered by Domain Name System (DNS) standards – as first party.

Also First Party: Because of the above, if I had a subdomain, such as analytics.cunderwood.dev this subdomain is still under cunderwood.dev, and is also considered first party.

Third Party: If however I allowed google.com to load content / set cookies on cunderwood.dev, then what google.com did would be considered third party, as the Top Level Domain names do not match.

This is well understood across the web and this separation of domains confers some security benefits.

When advertisers faced restrictions with the limits phased upon first party cookies and script writable storage as part of Intelligent Tracking Prevention, they decided to use a different integration method to appear as a first party to the browser. This is where the original CNAME Cloaking Mitigation came from. It would identify resource paths that pointed at external domains with-in the DNS records and limit the cookies they could set in a similar way to if the service had been installed in more traditional means, such as JavaScript.

Faced with having even the ability to use CNAMEs taken away, services started asking websites to modify their DNS records yet again, this time – instead of using a CNAME record, to leverage a direct A / AAAA record instead. This would continue to allow the advertiser or service to appear as first party to the browser. This result doesn’t leverage the Domain Name System since a A/AAAA record is a reference to a IP Address directly (such as 123.23.23.123). Since the CNAME records weren’t used, the existing mitigation measures failed to detect and modify cookies that were set by the external service. The new Third Party Cloaking Mitigation was developed to handle this use case.

How Does it work?

Interestingly, the patch notes link to the exact pull request – we so can see how this works in practice before the rollout. Due to the fact we’re not able to use the Domain Name Service to determine site boundary, the code instead leverages the IP Addresses involved for a comparison point. Let’s look at an example.

For each request the system will attempt to find evidence of Third Party Cloaking – first it will attempt to validate if CNAME Cloaking is used. In the event that the CNAME path isn’t being leveraged, then it will run the following checks:

First it will look at the Network Mask of the Top Level Host – so if this site’s IP Address is 162.241.218.208 The logic in the patch would take the first 50% of it, 162.241 and use that as the Network Mask.

Then for each request the website makes the logic compares the responding IP Address in the same way. So in the event the responding request has an IP Address which also equates to 162.241 then enough of the address matches that the response is considered first party by the browser.

If however, the website was talking to a remote system (such as a Server Side Google Tag Manager instance) then the responding request would be on a different Network Host. Google’s App Engine may respond on IP Address 10.0.1.0 for example, so when the logic looks at the network mask of 10.0 and compares that to 162.241 it would determine those are not, in fact, the same and treat the request as a third party response, despite it being considered a first party response under the Domain Name System. When this happens the cookies set by the request are likewise limited to 7 days.

It’s this reclassification of the boundaries between first and third party that can present issues because it affects everything that functions like that, regardless if it is used for tracking. It also classifies legitimate first party resources as third party if the networks which host the requests don’t match which can have unexpected effects.

How May You be Impacted

Websites may be either not impacted, or heavily impacted, depending on their overall network design. To understand of you are specifically impacted in your use case – I would first speak to your friendly helpful networking engineer.

However a few scenarios come to mind which would likely be impacted.

Microservice Architectures

In common Microservice Architectures it may be that the various services are spread across multiple data centers, clouds or related network designs. This means that if those same Microservices also set cookies, the cookies they set may be restricted to 7 days when previously they may have been longer.

The impact here tends to revolve around the potential for things such as guest shopping carts to not exist beyond a week, or users being prompted to re-authenticate more often. The specifics will depend greatly on what those services do, and on if the need to persist information via a cookie beyond 7 days is present. Here, an application architect that understands those specifics would be handy in understanding how your specific web application is impacted.

Hybrid Architectures

Hybrid Architectures split between a host and a cloud, or between multiple clouds are very likely impacted by this change in the same way as described above because they are, by design, split over multiple network hosts.

A application architect would be the person to speak to in this architecture to establish to what degree you would be impacted with this change.

Google Tag Manager Server Side (or related Marketing services)

Server Side Tag Managers, Optimization Platforms, Identity services and the like leveraging A/AAAA records and that set cookies will be impacted because of this change. So if you are using a service like Google Tag Manager deployed in a Server Side configuration in order to set cookies to preserve identity or handling marketing scenarios (because the advertiser had you add a A/AAAA DNS record) those services are going to see any cookies they set brought in line with a 7 day lifespan once this is rolled out to users.

The exact impact on the related services from this reduction will vary to be in line with the same impacts we saw in 2019 and be dependent on the specific use cases those vendors are addressing. This may or may not be concerning as a result.

Here, you’d want to speak to analytics engineer or data engineer to understand how this may impact your website, analytics, optimization or marketing integrations.

When Does This Launch?

Currently unknown. Should it become part of iOS16.2 (and the related Mac Release) we may see this in mid December. Should it skip that release and become part of iOS16.3 (and the related Mac Release) we’ll start seeing the impact of this I suspect in the February / March 2023 timeframe.

What Can You Do?

Fixes here are technical in nature and dev teams, after determining impact, will need to decide which solution makes sense. Both of the possible solutions for preserving cookie duration require engineering effort, and for some sites, this may be non-trivial. Regardless of which solution offered the one selected still has to comply with various data protection regulations, and those need to be considered in regardless of the forward path.

Move all Cookies to be set under the primary network host

In what would likely be a considerable lift – engineering could shuffle all the services which need to set cookies to be underneath the primary host domain, allowing those services to set cookies for the intended duration (longer than 7 days). For some websites this may not be easily possible, be very expensive, or both.

Leverage a Proxy Service on the primary network host

Instead of moving everything around, a development team could create a pass-through proxy server on the Network Host to act as a ‘bridge’ between the host and the remote services. This is likely easier / cheaper to setup, but does introduce an additional ‘hop’ in the network chain which may affect overall performance response times if not scaled properly for the expected level of traffic. Careful consideration should be given to the expected network load and, depending on where the server is located, this solution may involve ingress/egress costs which increase with traffic volume.

Do nothing and embrace the new world

It should be clear at this point that cookies are a volatile technology. Instead of engaging in the arms race, it is possible to accept the new world, and instead modify expectations that some data will simply be unavailable beyond the 7 day window. While this is easier said than done, I think it’s important discussion to be had prior to investing large amounts of time / money in refactoring a website’s infrastructure. This may be the ideal time to consider a transition to a first party CRM based strategy.