Brave Browser First To Nix CNAME Deception (theregister.com) 47
An anonymous reader quotes a report from The Register: The Brave web browser will soon block CNAME cloaking, a technique used by online marketers to defy privacy controls designed to prevent the use of third-party cookies. The browser security model makes a distinction between first-party domains -- those being visited -- and third-party domains -- from the suppliers of things like image assets or tracking code, to the visited site. Many of the online privacy abuses over the years have come from third-party resources like scripts and cookies, which is why third-party cookies are now blocked by default in Brave, Firefox, Safari, and Tor Browser.
In a blog post on Tuesday, Anton Lazarev, research engineer at Brave Software, and senior privacy researcher Peter Snyder, explain that online tracking scripts may use canonical name DNS records, known as CNAMEs, to make associated third-party tracking domains look like they're part of the first-party websites actually being visited. They point to the site https://mathon.fr/ as an example, noting that without CNAME uncloaking, Brave blocks six requests for tracking scripts served by ad companies like Google, Facebook, Criteo, Sirdan, and Trustpilot. But the page also makes four requests via a script hosted at a randomized path under the first-party subdomain 16ao.mathon.fr. When Brave 1.17 ships next month (currently available as a developer build), it will be able to uncloak the CNAME deception and block the Eulerian script. Other browser vendors are planning related defenses. "Mozilla has been working on a fix in Firefox since last November," notes The Register. "And in August, Apple's Safari WebKit team proposed a way to prevent CNAME cloaking from being used to bypass the seven-day cookie lifetime imposed by WebKit's Intelligent Tracking Protection system."
In a blog post on Tuesday, Anton Lazarev, research engineer at Brave Software, and senior privacy researcher Peter Snyder, explain that online tracking scripts may use canonical name DNS records, known as CNAMEs, to make associated third-party tracking domains look like they're part of the first-party websites actually being visited. They point to the site https://mathon.fr/ as an example, noting that without CNAME uncloaking, Brave blocks six requests for tracking scripts served by ad companies like Google, Facebook, Criteo, Sirdan, and Trustpilot. But the page also makes four requests via a script hosted at a randomized path under the first-party subdomain 16ao.mathon.fr. When Brave 1.17 ships next month (currently available as a developer build), it will be able to uncloak the CNAME deception and block the Eulerian script. Other browser vendors are planning related defenses. "Mozilla has been working on a fix in Firefox since last November," notes The Register. "And in August, Apple's Safari WebKit team proposed a way to prevent CNAME cloaking from being used to bypass the seven-day cookie lifetime imposed by WebKit's Intelligent Tracking Protection system."
You gotta leave something in... (Score:3)
Some form of cross-domain user tracking is needed for DoubleClick and Commission Junction to do their work... they've got to tie the ad seen on a site to the sponsor getting a sale.
As these techniques go away, another one pops up. It has to, otherwise news sites would complain.
Re:You gotta leave something in... (Score:5, Insightful)
No, we actually don't. If they want to make that connection they can do it in the URL path or parameters. There's no technical reason the source of ads needs to be concealed, only a) a desire by the web sites hosting the ads not to be responsible for the ads they carry and b) a desire by the ad networks to not tell users who's responsible for the ads. To borrow a line, it's an imperfect world and we don't always get what we want.
Re: (Score:2)
URL Tracking doesn't cover the situation where a customer sees the ads then thinks for a while... CJ usually pays for users who go to the sponsor 30 days after the impression.
Re:You gotta leave something in... (Score:5, Insightful)
Sounds like that aspect of their business model might not work out, then. I suspect that our civilization will weather that storm.
Re: (Score:1)
Re: (Score:3)
It's more like Wack-a-Mole...
Re: (Score:2)
Apple and Google have both developed APIs for that. They are quite similar and one will eventually become a standard.
Basically they allow the advertiser to supply an ID for each ad and get a ping-back when the user clicks it, but the idea is that the ID doesn't contain enough information to identify the user and the browser delays the ping by a random amount (up to a few days) so it can't be tied to any particular sale.
Re: You gotta leave something in... (Score:2)
Two years (Score:2)
Where "many years" means "two or three". By February 1997, ad networks were using cookies for this purpose.
Re: (Score:2)
Pretty soon all ads will "look like" first-party (Score:5, Insightful)
The day will come when - for the sake of money - ads will be routed through the hosting web site.
So an ad that appears on www.example.com's web page that's a 3rd party or "CNAME cloaked" ad today will be routed through the www.example.com server.
Inefficient? Yes. More costly to deliver? Yes. Harder to block? Yes.
Re: (Score:3)
I’m fine with that, because it’ll stop letting these sites feign ignorance regarding all the crap their web pages are trying to force down our throats.
And, unless they start hard-coding the ads in honest-to-goodness html rather than relying on scripts to generate them on the fly, they’ll still be easy enough to block.
Re: (Score:2)
It’ll stop letting these sites feign ignorance
No it won't. They'll still blame the advertisers and claim ignorance. The technical nuances won't end that.
Re: (Score:3)
The day will come when - for the sake of money - ads will be routed through the hosting web site.
So an ad that appears on www.example.com's web page that's a 3rd party or "CNAME cloaked" ad today will be routed through the www.example.com server.
Inefficient? Yes. More costly to deliver? Yes. Harder to block? Yes.
I, personally, see that as a plus. That means that websites can't pawn off adding ads and the responsibility of making sure the ads are not bad (i.e. not ones that block the page, forces you to a different page, etc.) and the cost onto some third party. I feel like a lot of [large company] websites these days feign ignorance when it comes to bad/unsavory/controversial /intrusive/resource hog/large (in memory size) ads because they can just pawn the responsibility off. Maybe if it costs them something, they'
Re: (Score:2)
Comment removed (Score:4, Insightful)
Re: Pretty soon all ads will "look like" first-par (Score:2)
And yet that is how it worked for many years before the internet. Either you work for Facebook/Google or you've bought into their business model.
Re: (Score:2)
Re: (Score:2)
You want us to go back to the days of having a handful of publishers who gatekeep every single thing we read and watch? Either you work for Facebook/Google or you've bought into their business model.
Wait, what? The original comment is literally referring to a time where large corporations like Facebook and Google didn't exist and NO ONE had the same gatekeeping power on data and info like they do now. Like isn't that your point? Wasn't that your goal?
In which case, you must work for Fox or Comcast as, based upon your original comment, you clearly want us to go back to the bad old days when only a handful of corporations were able to economically publish content we read.
Wait, what? That's why the internet became so well-loved and used in it's introduction to the general public. Because there WAS NO handful of large corporations controlling what can be published AND there was virtually no cost to "publishing content". (ISP
Re: (Score:2)
Just as the anti-spammers made email immeasurably less useful
In what way is email "immeasurably less useful"?
Re: (Score:3)
Re: (Score:2)
You're probably Gen Z or something, but there was a time in the mid nineties when if you sent an email, you could expect it 99% of the time to arrive at the destination. You didn't have to follow up with messages via other channels to ensure it had arrived.
When I send or expect email, it arrives in the inbox 95% of the time. As intended. Email that doesn't is usually sent by companies and looks like an ad, so I'm not disappointed that it ends up in the spam folder.
Sure, it's N=1 and YMMV, but normal email use does still exist.
Re: (Score:2)
Name calling; classy.
I've been using email since about 1995 and can honestly say that these days spam is far better under control than it has ever been.
At some point my domain was fetching 20k+ spam per day. I remember the war between spammers and anti-spammers; I was part of it, running all kinds of filters and custom rules to ensure email remained usable for my domains. Please understand that the sheer volume of spam was making email unusable at times.
Today only the spammers have a serious chance of getting their emails to arrive because they know how to game the system.
This is just bullshit, and you know it.
Re: (Score:2)
Re: (Score:2)
This will never happen. What you're suggesting is that for this technical change to be made, every organization that puts up a website will have its own advertising department, selling advertisements. That's not sustainable, it's not possible for the vast majority of ad supported websites.
I'd like to respectfully disagree with you on this point. Like we tend to think a lot of large departments have dedicated people handling things. But, in actuality, a lot of them don't or handle them in ways we tech people assume they would. Like, they might have a "department" of someone that handles web ads on their site. But that department might just be one person who was handed the responsibility despite having no training or experience with it. After all, I once had to explain to a sys admin at at
Re:Pretty soon all ads will "look like" first-part (Score:4, Insightful)
The problem for advertisers with that solution is that they have no way of checking that the ad is actually shown. They have to trust the host for their analytics and billing, and it makes things much more complicated, especially for small players that advertisers have every reason not to trust.
It is actually easier to imagine the opposite: content will be routed through the advertiser's network. Imagine something like cloudflare, but instead of just delivering content, it also inject ads and the content owner get his share of the revenue.
This is terrible for the open web: more centralization, more control from tech giants. That's why I am not a fan of the war against 3rd party whatever. It gives more power to those who have their own ad networks. For example, Google can easily track you across all their sites and show you ads they can monetize, it is all first party. But a small, self-hosted blog can't do that, and doesn't have enough resources to negotiate their own advertising contracts. It isn't just about ads, you may want to integrate with a third party content processor for instance.
And since we are talking about Brave, Brave solution is for everyone to go through Brave. They don't want to free you from tech giants, they want to be the tech giant.
Re: (Score:1)
Re: (Score:2)
A web analytics company I worked for in the early 2000s was doing that back then to deal with third-party cookie blocking and cross-site data issues. We'd have the client either create A records pointing at our load balancer's public interfaces or delegate a subdomain to us so we could manage the records.
Taxation Evasion Aspects will cost big bikkies (Score:2)
Re: (Score:2)
This isn't too bad. Ads make web pages slow - either overloaded ad servers or other reasons. Often times the hosting server is faster and able to serve the ad faster.
Even better, if ad networks started delaying, it forces the server to hang onto connections far longer and increases their server load, so maybe the site owners can pick ad networks that provide services without excessive server load.
"will come"? (Score:2)
It's already here.
Over the last month or so, both cnn and thehill have started running their own ads as part of their main page.
(I don't know if thehill has stopped pop-under to go with this; I turn off javascript before letting them load)
hawk
Re: (Score:2)
If sites have to handle all the bandwidth for the third party ads and tracking they try cram onto a page because its proxied by their servers, maybe they'll think twice about how much they foist on the user.
Brave on smartphones (Score:3, Informative)
Re: (Score:2)
Have you tried Firefox? Better add-on UI, no "rewards" crypto currency bullshit.
A recent change fixed rendering on most sites, it's very close to being perfect. Slashdot desktop mode is still broken but for most stuff it's a great browser and you can use your choice of ad-blocker and privacy enhancement.
Re: (Score:2)
You still can't install ad blockers though. Isn't any browser for iOS just a front end for Apple's?
Re: (Score:2)
Oh yeah, iOS... Well I don't know then, on Android you can install uBlock Origin and in fact all other add-ons now.
Re: (Score:2, Insightful)
What for?
CNAME is a legitimate part of the DNS system. You haven't won some sort of victory over the evil doers of the web. You've just broken a feature.
Yay you.
Re: (Score:3)
Uh huh. Given that you're posting this on "tech.slashdot.org", which is itself a CNAME record, I'm gonna call BS on that.
Re: (Score:2)
They are probably BSing. But perhaps you don't know that if you drop the "tech" off the hostname portion of the URL, Slashdot will still serve you the content you're looking for. I wrote user scripts to do that for me [greasyfork.org] because 1) I want the same color scheme across the site and 2) Occasionally Slashdot breaks in ways that effect the cnames but not base slashdot.org. I finally wrote the script[s] during one of those periods.
Re: (Score:2)
I did know. (Profile links go to the main domain.) But site-specific greasemonkeying aside, (and this is for the sake of general readers, I get the feeling you already know it) the web would be utterly unusable with CNAME records blocked as the GP seems to be suggesting. Traditionally, in fact, *all* web servers -- particularly back in the good old days when they were named "www" -- were CNAMEs for the actual server names (so that one could maintain one's nerdy server naming patterns.)
So much for hosts file guy (Score:4, Interesting)
From the summary:
When APK was promoting his DNS blocklist updating tool, I remember telling him several times that sites were going to randomize hostnames to evade blocklists. He never believed me. Now we have evidence.
Useless, cos Reverse Proxy (Score:2)
Re: (Score:2)
You don't even need that.
In DNS, a CNAME record just says "instead of a.b.com, go look at x.y.com" And then "x.y.com" resolves to, say, 192.0.2.7.
The trivial and obvious workaround is to just setup a.b.com to point directly to 192.0.2.7. It's a little more overhead to administer than CNAME aliasing (since you need all such domains to update if the IP address changes, although you could automate this), but it's way less work than running a proxy.
Re: (Score:2)
Re: (Score:2)
The problem with that kind of blocking is that most of these are being hosted on large, multi-tenant infrastructure, where that IP address can correspond to many different web sites -- some tracking-related, and others not. Even if they weren't, you're describing a huge, mostly manual effort that goes well beyond the resources anyone would dedicate for this kind of heuristic mitigation.