It's about trust, the third-party ad companies don't trust that the first party will be honest with them, not generating fake impressions or clicks.

There are also trust issues the other way. I've seen a lot of contention between developers and security teams and marketing about putting third party code or proxying third party domains on the first party site for analytics, tracking, ad attribution, etc.

There's all kinds of cryptography available for solving trust problems. I guarantee you that within six months of third party cookies being removed someone will have built an impression signing system that is satisfactory to both the ad companies and the server owners.

I doubt that. Their script could as well be "fetch that script from that URL and run it". They would have fraud detections already in place on their side regardless of which script runs on the client.

> "fetch that script from that URL and run it"

but if you cannot have a third party cookie, the remote site from the tracker cannot be sure that the script was actually downloaded, nor executed.

Generate dynamic, short lifetime URLs that are locked to the client IP.

sure you can, if their script is making a 3rd party xhr request to that tracker.

but this request could be faked, if the first party wanted to fake the traffic (for example, to make ad revenue). This third party cookie is what prevents this faking at this moment.

That's old hat, the future is server to server calls from sites to vendors, profile the client but don't try to run any tracking js on it.

That's vastly more expensive, though. Now you have to run extra servers to make outbound connections to the ad tracker's API server instead of turfing off all the work to visitors. It would be enough to significantly affect the ad market.

Oh no!

I don't think it's that expensive to do. All it takes is one well written package that is easy to install and this will be come standard.

I could even see a data broker centralizing this and distributing tracking to all of their clients. The client would just need to communicate with the central broker, which is not hard at all.

This setup already exists, they're called Supply Side Platforms.

As long as your scale is tiny, sure. At a point you'd need to turn that into an async task queue etc etc.

BTW, I see this as a feature, not a bug. I'm glad it would be harder and more expensive to violate my privacy.

You also get to do it on your fast cloud backend infrastructure instead of the end-users home computer and ISP. They will appreciate the increase in page load speed and overall responsiveness, and as a bonus they can't use ad blockers or hostfile tricks anymore.

That's also quite the possibility, and supports my point.

Embedding 3rd party JS as first party is a security nightmare or a wet dream for malvertising and already here, eg. via extra DNS records lifting ad servers into the first party.

https://www.freepatentsonline.com/8990330.html

The next step will be to strict JS. Im for it.

I think many adtech companies (at least in affiliate marketing) use redirects because third party cookies are unreliable and redirects make all the cookies first party. As mentioned elsewhere, they’ve also been switching to proxies and other such techniques to make it even harder to block their tracking endpoints.

> include the script on their web server, so their cookies become "first party" again.

That script would execute with the origin of the server. It's access to resources and /shared state/ would be hampered by this. So as a cross-site tracking strategy I don't think this works.

> I don't understand how this helps the web unless protections against tracking itself, not the methods used, are established.

Which is why I think state partitioning[0] and CHIPs[1] are good technologies. It allows previously existing standards, like cookies, to continue to exist and function mostly as expected, but provides the user a good amount of default security against cross site trackers and other malware.

[0]: https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/...

[1]: https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/...

Your point is pretty useless, as you assume the web server admins want to be more secure. The opposite is the case, usually they deliberately open up their security model to accomodate 3rd party tracking scripts. For example, Content-Security-Policy headers can effectively prevent all sorts of xss attacks, but they will also prevent 3rd party tracking scripts etc.

You've misunderstood my point. It's not what the server admins want it's what the security policy will allow. If two sites, on two different domains, both use the same script, served directly from their domains, it creates absolutely no workaround for third party cookies. This is because the two sites have different origins. CSP does not create a bypass in this case.

This doesn’t actually help. If you consider Prebid, Criteo already has js running on the site serving the ads, but that js has no mechanism to figure out whether the user has something in their cart and is eligible for retargeting.

The workaround is looking more and more like IP, fingerprinting, and AI. I’d argue this is worse than 3p cookies, which were at least dumb and easy to clear.

Proxies for analytics are already a thing. E.g. plausable shows you how to set one up. A 3rd party cookie can however be the same value sent again and again from the same browser from different sites to the central server tracking you across the web. The global who you are is in the cookie.

Including the script on the publisher's site doesn't allow them to track you from site A to site B which is what third-party cookies let them do.

This should be the top-most comment.