Cname cloaking, a disguise of third-party trackers • Hacker News Board

Re: Cname cloaking, a disguise of third-party trackers

#81

Post by ignoramous » Sat, Nov 23, 2019, 10:54 PM UTC

poitrus wrote: post #77

ignoramous wrote: post #59

Earlier quoted context omitted.

I personally setup nextdns for 30+ people. It is that simple and useful. Thanks. I've a couple of questions, though: 1. Do you run one unbound instance per configuration, or share among multiple configurations per user or...? The reason I ask is, sometimes the latencies are too high, 2000ms+. Should I be creating less configurations per account? 2. How could nextdns combat ad-networks resorting to DoH: https://1.1.1.…

1. Check https://github.com/nextdns/nextdns 2. JS can’t set a custom resolver, I don’t think DoH can help with that. If yes, source please

Thanks Olivier.

Re: nextdns-cli: I think you may have misunderstood my question. I was more curious abt how the backend worked: Do you run one unbound instance per nextdns-configuration?

Re: DoH: I was pointing to the fact that XHR request to 1.1.1.1 (or any DoH provider that supports application/dns-json) can now resolve domain names. In this case, there's no reliance on either browser's DoH resolver or resolver set by OS / AccessPoints / VPNs.

Re: Cname cloaking, a disguise of third-party trackers

#82

Post by noman-land » Sat, Nov 23, 2019, 11:01 PM UTC

jefftk wrote: post #78

QUFB wrote: post #76

Earlier quoted context omitted.

Honest question, and I'm not making any value judgements: Do you have any moral issues working an adtech?

I've written some about this here: https://www.jefftk.com/p/value-of-working-in-ads

"It is difficult to get a man to understand something, when his salary depends on his not understanding it."

Re: Cname cloaking, a disguise of third-party trackers

#83

Post by fwxwi » Sat, Nov 23, 2019, 11:11 PM UTC

What's the difference between this and what Instart Logic has been doing for years now? https://github.com/gorhill/uBO-Extra#purpose

Re: Cname cloaking, a disguise of third-party trackers

#84

Post by poitrus » Sat, Nov 23, 2019, 11:13 PM UTC

ignoramous wrote: post #81

poitrus wrote: post #77

Earlier quoted context omitted.

1. Check https://github.com/nextdns/nextdns 2. JS can’t set a custom resolver, I don’t think DoH can help with that. If yes, source please

Thanks Olivier. Re: nextdns-cli: I think you may have misunderstood my question. I was more curious abt how the backend worked: Do you run one unbound instance per nextdns-configuration? Re: DoH: I was pointing to the fact that XHR request to 1.1.1.1 (or any DoH provider that supports application/dns-json ) can now resolve domain names. In this case, there's no reliance on either browser's DoH resolver or resolver se…

Oh sorry. We have developed a custom DNS solution that sites in front of unbound. We only use unbound for standard recursion and caching, all custom configuration management is operated in this home made DNS proxy.

For trackers to use DoH, they could certainly perform XHR requests to resolve a domain, but they won't be able to use it to perform a request from the browser. You may use " rel="nofollow">http:// instead of " rel="nofollow">http://, but this has two issues:

1. You won't be able to use virtual hosting (the Host header is gone), and thus you need one IP per "service", which is doable but harder, more custom and more expensive.

2. You won't be able to use HTTPS, except with an expensive certificate that is somewhat harder to setup.

As most websites are HTTPS now, a non HTTPS tracker would rase mixed content errors. Not to mention that this IP would quickly be blocked by browser based ad blockers, and IPs are harder than domains to change.

And all this is doable without DoH, you just embed the IP the ad library embedded by the site.

Re: Cname cloaking, a disguise of third-party trackers

#85

Post by hk__2 » Sat, Nov 23, 2019, 11:18 PM UTC

fwxwi wrote: post #83

What's the difference between this and what Instart Logic has been doing for years now? https://github.com/gorhill/uBO-Extra#purpose

Wow it goes even further: https://github.com/gorhill/uBO-Extra/wiki/Sites-on-which-uBO...

> Instart Logic will detect when the developer console opens, and cleanup everything then to hide what it does. I had to trick IL's script into thinking the dev console was not open to take the pic above.

Re: Cname cloaking, a disguise of third-party trackers

#86

Post by jefftk » Sat, Nov 23, 2019, 11:19 PM UTC

noman-land wrote: post #82

jefftk wrote: post #78

Earlier quoted context omitted.

I've written some about this here: https://www.jefftk.com/p/value-of-working-in-ads

"It is difficult to get a man to understand something, when his salary depends on his not understanding it."

I do the work I do because it allows me to donate: https://www.jefftk.com/donations

I would not do this work if I thought it was harmful, and if I decided it was harmful there are many jobs I could take instead.

I'm open to being convinced that my work is net negative! I've quit Google before: https://www.jefftk.com/p/leaving-google-joining-wave

Re: Cname cloaking, a disguise of third-party trackers

#87

Post by IAM2019 » Sat, Nov 23, 2019, 11:29 PM UTC

The article explains that trackers traditionally loaded some external JS which then phoned home and tracked users via third-party cookies.

I would like to point out that it has never been the case for Google Analytics and possibly other trackers. The developers of a website are supposed to copy/paste the Google Analytics snippet directly into their own JS, such that GA has access to first-party cookies. And then GA phones home some tracking data leveraged by this first-party cookie.

Blocking third-party cookies never blocked this kind of tracking. You needed to block the domains that the script requested via AJAX. But it is indeed made difficult with CNAME Cloaking, because the domains requested are subdomains of the current domain, and can be changed regularly as explained by the article.

There is no end-game solution against tracking. It will all come down to tracking companies ordering websites to install some library directly in their back-end and pass it user data as well as behavioral data captured from some other library installed in the front-end. Tracking data will pass through applicative pipes and it will be impossible to block reliably.

Re: Cname cloaking, a disguise of third-party trackers

#88

Post by A1kmm » Sat, Nov 23, 2019, 11:32 PM UTC

x0x0 wrote: post #57

jefftk wrote: post #55

Earlier quoted context omitted.

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.

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.

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.

Re: Cname cloaking, a disguise of third-party trackers

#89

Post by StavrosK » Sat, Nov 23, 2019, 11:34 PM UTC

jrockway wrote: post #79

na85 wrote: post #45

Earlier quoted context omitted.

Start providing content that users are willing to pay for?

The problem is that subscription models are flawed, at least for things like Ars Technica. In most cases, people don't want to commit a portion of their monthly budget to a specific website for the rest of their life. I don't know how often I read Ars Technica, but it's probably a couple of articles a month. That is worth maybe $0.10 to me, so they can never collect that profitably. They use ads because then I "pay"…

Brave is doing that exact thing, or so I hear. I've even made $1 or something from them.

Re: Cname cloaking, a disguise of third-party trackers

#90

Post by alkonaut » Sat, Nov 23, 2019, 11:34 PM UTC

homero wrote: post #16

kerpele wrote: post #15

I can’t believe Ars Technica would do this. Do they not realize who their audience is?

That also means most of their audience blocks ads. What are they to do?

The answer I keep returning to: if shady ads is what keeps your business running, stop running your business. Switch off the lights and the servers and go home.