[poitrus]

They might yes, but it is orders of magnitude harder to setup and maintain than this, and as a website owner, you have to put even more trust in your ad serving solution than today.

[jefftk]

Reverse proxying is a little harder, but not much. In NGINX, for example:

    location /adtech/ {
        proxy_pass https://adtech.example/;
    }

What additional trust are you thinking about? HttpOnly cookies are already sent when you use the subdomain approach.

[x0x0]

js running on your domain can read eg login cookies

at least if you cname definitelynotads.yourdomain.com to js.ads.com, the javascript running on definitelynotads... can't read host-only login cookies on yourdomain.com.

[A1kmm]

In the vast majority of cases integration is by the including a script controlled by the advertising network in the page they are advertising on.

So for the purposes of the browser security model, the script already runs in the domain of the host site. It can directly read any non-HttpOnly cookies, and can make any request it likes using XMLHttpRequest to APIs on the host site using the user's cookie without relying on CORs.

The only very minor difference between first and third party script inclusion is access to HttpOnly cookies (depending on the cookie scoping).

Both of the first party script inclusion approaches have mitigations available to the host site: in the proxy approach, the server could filter the cookies before proxying. In the CNAME approach, taking care with cookie scoping could solve the problem. Careless adoption is likely to open security flaws under both techniques.

[mr_toad]

> The only very minor difference between first and third party script inclusion is access to HttpOnly cookies

That’s not a minor difference, http only is used for authentication.

[jefftk]

Correct. Authentication should always be via cookies with "HttpOnly" set, since (a) the cookie is not needed client side and (b) it somewhat limits the damage XSS can do.

[jefftk]

Sites generally set Domain= on their cookies, and so include subdomains. For example, if you click "sign in" on apple.com it brings you to secure2.store.apple.com and after entering your password it sets a cookie with "Path=/; Domain=apple.com; Secure; HttpOnly".

You're right that this does reduce security on some sites: if domain.example doesn't set Domain= on their cookies then ads.domain.example (CNAMED to js.ads.example) won't see the cookies but domain.example/ads would. This is pretty rare, though, because sites you log into generally do need their cookies to work across subdomains.

Except this problem is easier to handle with reverse proxies than with subdomains: with subdomains the cookies are sent whether you want to or not, while with a reverse proxy the site owner can configure it to strip cookies.