Mozilla has further beefed up anti-tracking measures in its Firefox browser. In a blog post yesterday it announced that Firefox 86 has an extra layer of anti-cookie tracking built into the enhanced tracking protection (ETP) strict mode — which it’s calling “Total Cookie Protection” (TCP).
This “major privacy advance”, as it bills it, prevents cross-site tracking by siloing third-party cookies per website.
Mozilla likens this to having a separate cookie jar for each site — so, for e.g. Facebook cookies aren’t stored in the same tub as cookies for that sneaker website where you bought your latest kicks, and so on.
The new layer of privacy wrapping “provides comprehensive partitioning of cookies and other site data between websites in Firefox”, explains Mozilla.
Along with another anti-tracking feature it announced last month — targeting so called “supercookies” — aka sneaky trackers that store user IDs in “increasingly obscure” parts of the browser (like Flash storage, ETags and HSTS flags), i.e. where it’s difficult for users to delete or block them — the features combine to “prevent websites from being able to ‘tag’ your browser, thereby eliminating the most pervasive cross-site tracking technique”, per Mozilla.
There’s a “limited exception” for cross-site cookies when they are needed for non-tracking purposes — Mozilla gives the example of popular third-party login providers.
“Only when Total Cookie Protection detects that you intend to use a provider, will it give that provider permission to use a cross-site cookie specifically for the site you’re currently visiting. Such momentary exceptions allow for strong privacy protection without affecting your browsing experience,” it adds.
Tracker blocking has long been an arms race against the adtech industry’s determination to keep surveilling web users — and thumbing its nose at the notion of consent to spy on people’s online business — pouring resource into devising fiendish new techniques to try to keep watching what internet users are doing. But this battle has stepped up in recent years as browser makers have been taking a tougher pro-privacy/anti-tracker stance.
Mozilla, for example, started making tracker blocking the default back in 2018 — going on to make ETP the default in Firefox in 2019, blocking cookies from companies identified as trackers by its partner, Disconnect.
While Apple’s Safari browser added an “Intelligent Tracking Prevention” (ITP) feature in 2017 — applying machine learning to identify trackers and segregate the cross-site scripting data to protect users’ browsing history from third-party eyes.
Google has also put the cat among the adtech pigeons by announcing a planned phasing out of support for third-party cookies in Chrome — which it said would be coming within two years back in January 2020 — although it’s still working on this “privacy sandbox” project, as it calls it (now under the watchful eye of U.K. antitrust regulators).
Google proposes new privacy and anti-fingerprinting controls for the web
Google has been making privacy strengthening noises since 2019, in response to the rest of the browser market responding to concern about online privacy.
In April last year it rolled back a change that had made it harder for sites to access third-party cookies, citing concerns that sites were able to perform essential functions during the pandemic — though this was resumed in July. But it’s fair to say that the adtech giant remains the laggard when it comes to executing on its claimed plan to beef up privacy.
Given Chrome’s market share, that leaves most of the world’s web users exposed to more tracking than they otherwise would be by using a different, more privacy-proactive browser.
And as Mozilla’s latest anti-cookie tracking feature shows, the race to outwit adtech’s allergy to privacy (and consent) also isn’t the sort that has a finish line. So being slow to do privacy protection arguably isn’t very different to not offering much privacy protection at all.
To wit: One worrying development — on the non-third-party-cookie-based tracking front — is detailed in this new paper by a group of privacy researchers who conducted an analysis of CNAME tracking (aka a DNS-based anti-tracking evasion technique) and found that use of the sneaky anti-tracking evasion method had grown by around a fifth in just under two years.
The technique has been raising mainstream concerns about “unblockable” web tracking since around 2019 — when developers spotted it being used in the wild by a French newspaper website. Since then use has been rising, per the research.
In a nutshell the CNAME tracking technique cloaks the tracker by injecting it into the first-party context of the visited website — via the content being embedded through a subdomain of the site which is actually an alias for the tracker domain.
“This scheme works thanks to a DNS delegation. Most often it is a DNS CNAME record,” writes one of the paper authors, privacy and security researcher Lukasz Olejnik, in a blog post about the research. “The tracker technically is hosted in a subdomain of the visited website.
“Employment of such a scheme has certain consequences. It kind of fools the fundamental web security and privacy protections — to think that the user is willfully browsing the tracker website. When a web browser sees such a scheme, some security and privacy protections are relaxed.”
Don’t be fooled by the use of the word ‘relaxed’ — as Olejnik goes on to emphasize that the CNAME tracking technique has “substantial implications for web security and privacy”. Such as browsers being tricked into treating a tracker as legitimate first-party content of the visited website (which, in turn, unlocks “many benefits”, such as access to first-party cookies — which can then be sent on to remote, third-party servers controlled by the trackers so the surveilling entity can have its wicked way with the personal data).
So the risk is that a chunk of the clever engineering work being done to protect privacy by blocking trackers can be sidelined by getting under the anti-trackers’ radar.
The researchers found one (infamous) tracker provider, Criteo, reverting its tracking scripts to the custom CNAME cloak scheme when it detected the Safari web browser in use — as, presumably, a way to circumvent Apple’s ITP.
There are further concerns over CNAME tracking too: The paper details how, as a consequence of current web architecture, the scheme “unlocks a way for broad cookie leaks”, as Olejnik puts it — explaining how the upshot of the technique being deployed can be “many unrelated, legitimate cookies” being sent to the tracker subdomain.
Olejnik documented this concern in a study back in 2014 — but he writes that the problem has now exploded: “As the tip of the iceberg, we found broad data leaks on 7,377 websites. Some data leaks happen on almost every website using the CNAME scheme (analytics cookies commonly leak). This suggests that this scheme is actively dangerous. It is harmful to web security and privacy.”
The researchers found cookies leaking on 95% of the studies websites.
They also report finding leaks of cookies set by other third-party scripts, suggesting leaked cookies would in those instances allow the CNAME tracker to track users across websites.
In some instances they found that leaked information contained private or sensitive information — such as a user’s full name, location, email address and (in an additional security concern) authentication cookie.
The paper goes on to raise a number of web security concerns, such as when CNAME trackers are served over HTTP not HTTPS, which they found happened often, and could facilitate man-in-the-middle attacks.
Defending against the CNAME cloaking scheme will require some major browsers to adopt new tricks, per the researchers — who note that while Firefox (global market share circa 4%) does offer a defence against the technique Chrome does not.
Engineers on the WebKit engine that underpins Apple’s Safari browser have also been working on making enhancements to ITP aimed at counteracting CNAME tracking.
In a blog post last November, IPT engineer John Wilander wrote that as defence against the sneaky technique “ITP now detects third-party CNAME cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days. This cap is aligned with ITP’s expiry cap on all cookies created through JavaScript.”
The Brave browser also announced changes last fall aimed at combating CNAME cloaking.
“In version 1.25.0, uBlock Origin gained the ability to detect and block CNAME-cloaked requests using Mozilla’s terrific browser.dns API. However, this solution only works in Firefox, as Chromium does not provide the browser.dns API. To some extent, these requests can be blocked using custom DNS servers. However, no browsers have shipped with CNAME-based adblocking protection capabilities available and on by default,” it wrote.
“In Brave 1.17, Brave Shields will now recursively check the canonical name records for any network request that isn’t otherwise blocked using an embedded DNS resolver. If the request has a CNAME record, and the same request under the canonical domain would be blocked, then the request is blocked. This solution is on by default, bringing enhanced privacy protections to millions of users.”
But the browser with the largest marketshare, Chrome, has work to do, per the researchers, who write:
Because Chrome does not support a DNS resolution API for extensions, the [uBlock version 1.25 under Firefox] defense could not be applied to this browser. Consequently, we find that four of the CNAME-based trackers (Oracle Eloqua, Eulerian, Criteo, and Keyade) are blocked by uBlock Origin on Firefox but not on the Chrome version.
Discussing the research findings, Tom Van Goethem, another of the paper authors, said the team’s data shows that web publishers who use CNAME tracking are using it to supplement other, more “typical” third party tracking methods.
“Our data shows that publishers who adopt CNAME-based already have a considerable number of trackers (20+ per site on average), and find that this number of trackers remains stable over time. This indicates that CNAME-based tracking is not used as a replacement of the typical third-party tracking, but rather to increment their tracking capabilities, e.g. targeting users with anti-tracking mechanism,” he told TechCrunch.
The researchers were not focused on coming up with a causal explanation for the rise in the use of CNAME cloaking. But Van Goethem said that they found some trackers using it only against the Safari browser (“which is known to include strict anti-tracking protections”) — which suggests (at least) a partial explanation for rising use of the technique.
Asked what kind of community response they’d like to see to combat the CNAME scheme he said: “Ideally, more anti-tracking defenses should adopt robust measures against CNAME-based tracking such that users are protected regardless of the browser they’re using.”
Browsers need to deploy multiple defences to combat a variety of techniques in order to effectively defend user privacy. So, in the case of Firefox’s new TCP feature, Van Goethem noted that while it doesn’t affect CNAME-based (first-party) tracking “in essence”, it does protect against cookie syncing between sites that employ first-party tracking.
“With CNAME-based tracking, the tracker can follow the user’s activities on one specific site (that includes the tracker), but it needs to synchronize cookies with other sites to link the tracked activities of one specific user on site A to the activities of that same user on site B. Total Cookie Protection would prevent this,” he explained.
Other non-cookie-based tracking techniques l– ike device fingerprinting and ephemeral fingerprinting — can also be used to circumvent browser-based defences against cookie-based tracking. “This means that defenses need to be complete, and provide protections against all types of tracking in order to safeguard users,” per Van Goethem.
“We hope that our large-scale analysis, which shows that CNAME-based tracking is on the rise, will raise awareness, and incentivize users and browser vendors to advance defenses against this tracking mechanism,” he added.
“Furthermore, we hope that our study will highlight the potential security impact that publishers face by including CNAME-based trackers. Throughout our study we discovered two security issues that affect all visitors of publisher sites; in one case the issue is still not fixed (despite multiple attempts of reaching out to the tracker to report the vulnerability), putting visitors of hundreds of websites at risk.”
Regulatory action/enforcement could also be helpful in curbing use of the CNAME technique, he also suggested.
This report was updated with additional comment.
WebKit’s new anti-tracking policy puts privacy on a par with security
Comment