5 ms·

If third-party cookies are removed, the tracking parties will just ask web sites to include the script on their web server, so their cookies become "first party

by sedatk 1y ago

If third-party cookies are removed, the tracking parties will just ask web sites to include the script on their web server, so their cookies become "first party" again. I don't understand how this helps the web unless protections against tracking itself, not the methods used, are established.

Dwedit 1y ago
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.
- sedatk 1y ago
  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.
  - chii 1y ago
    > "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.
    - littlecranky67 1y ago
      sure you can, if their script is making a 3rd party xhr request to that tracker.
      - chii 1y ago
        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.
    - kevin_thibedeau 1y ago
      Generate dynamic, short lifetime URLs that are locked to the client IP.
- thayne 1y ago
  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.
- lolinder 1y ago
  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.
blacksmith_tb 1y ago
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.
- sedatk 1y ago
  That's also quite the possibility, and supports my point.
- kstrauser 1y ago
  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.
  - ars 1y ago
    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.
    - deleted 1y ago
      [deleted]
    - secondcoming 1y ago
      This setup already exists, they're called Supply Side Platforms.
    - kstrauser 1y ago
      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.
  - Griffinsauce 1y ago
timewizard 1y ago
> 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/State_Partitioning https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/... [1]: https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Partitioned_cookies https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/...
- littlecranky67 1y ago
  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.
  - timewizard 1y ago
    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.
parrit 1y ago
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.
fiddlerwoaroof 1y ago
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.
coffeefirst 1y ago
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.
rajnathani 1y ago
This should be the top-most comment.
throwawayqqq11 1y ago
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 https://www.freepatentsonline.com/8990330.html The next step will be to strict JS. Im for it.
fastest963 1y ago
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.

by sedatk 1y ago

Dwedit 1y ago

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.

sedatk 1y ago
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.
- chii 1y ago
  > "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.
  - littlecranky67 1y ago
    sure you can, if their script is making a 3rd party xhr request to that tracker.
    - chii 1y ago
      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.
  - kevin_thibedeau 1y ago
    Generate dynamic, short lifetime URLs that are locked to the client IP.
thayne 1y ago
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.
lolinder 1y ago
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.

blacksmith_tb 1y ago

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.

sedatk 1y ago
That's also quite the possibility, and supports my point.
kstrauser 1y ago
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.
- ars 1y ago
  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.
  - deleted 1y ago
    [deleted]
  - secondcoming 1y ago
    This setup already exists, they're called Supply Side Platforms.
  - kstrauser 1y ago
    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.
- Griffinsauce 1y ago

timewizard 1y ago

> 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/State_Partitioning https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/... [1]: https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Partitioned_cookies https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/...

littlecranky67 1y ago
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.
- timewizard 1y ago
  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.

parrit 1y ago

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.

fiddlerwoaroof 1y ago

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.

coffeefirst 1y ago

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.

rajnathani 1y ago

This should be the top-most comment.

throwawayqqq11 1y ago

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 https://www.freepatentsonline.com/8990330.html The next step will be to strict JS. Im for it.

fastest963 1y ago

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.