Add Decentraleyes to slighten off a bit Exit traffic and work around some CDNs blocking of Tor
For those who don't know what it does: "Protects you against tracking through "free", centralized, content delivery. It prevents a lot of requests from reaching networks like Google Hosted Libraries, and serves local files to keep sites from breaking. Complements regular content blockers."[1]
For example, according to W3Techs statistics, Google Hosted Libraries is used by 16.9% of all websites, that is a JavaScript content delivery network market share of 70.4%.[2] Decentraleyes works by blocking requests to that CDN and loading the Javascript libraries locally.
That way not only some sites will load slightly faster (or faster for low-bandwidth clients) due to the resources being blocked and loaded locally (which also means slightly less traffic needed for exits), but also will protect from tracking by those CDNs.[3]
This addon doesn't clash with section 2.3. of the Tor Browser Design Doc with regards to ad-blockers as it isn't one.
--
[1] : https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ [2] : https://w3techs.com/technologies/overview/content_delivery/all [3] : "The paper also makes me think about exit traffic patterns, and how to better protect people who use Tor for only a short period of time: many websites pull in resources from all over, especially resources from centralized ad sites. This risk (that it greatly speeds the rate at which an adversary watching a few exit points — or heck, a few ad sites — will be able to observe a given user's exit traffic)..." (replade ad sites with "free" CDNs ;) https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters [4] : https://www.torproject.org/projects/torbrowser/design/ "As a general matter, we are also generally opposed to shipping an always-on Ad blocker with Tor Browser."
Trac:
Username: imageverif
Activity
IMHO we just shouldn't use JavaScript. It JS is enabled, Decentraleyes won't help you. If JS is disabled, we don't need 3rd-party JS at all. Fonts and common CSS should not be cached (if they are, it is a supercookie vector), they should be shipped with browser. The procedure should be clear and on every update there should be an audit by human with publicly available report. But it is a one more fingerprinting vector.
If a site embeds a certain common external ressource, which the browser happens to already have visited and cached and we ship this ressource and skip the first download and checks where is the supercookie vector?
The better solution would of course be teaching website developers to get rid of these frameworks and even more so external hosting, but until they do, Firefox&TorBrowser users would benefit.
With the ongoing rise of adblocker usage by fed-up users across the globe, i think it would be also the right time to discuss this design decision again somewhere else.
Trac:
Username: tokotoko
Cc: N/A to fdsfgs@krutt.org
Replying to imageverif:
For those who don't know what it does: "Protects you against tracking through "free", centralized, content delivery. It prevents a lot of requests from reaching networks like Google Hosted Libraries, and serves local files to keep sites from breaking. Complements regular content blockers."[1]
What exactly is the tracking vector here? Note as well, that there is no single exit relay that gets all the user's browser traffic to see as the content loaded and the exit used is bound to the URL bar domain.
Trac:
Status: new to needs_information-
Replying to gk:
Replying to imageverif: What exactly is the tracking vector here? Note as well, that there is no single exit relay that gets all the user's browser traffic to see as the content loaded and the exit used is bound to the URL bar domain.
Indeed, it's only the header which is uniform for all TBB users (apart from the referrer), and thanks for pointing to TBB's stream isolation, I didn't realize that arma's blog post was written before it was implemented in the TBB.
The only real advantage that may apply here is the usability side that I mentioned in the first comment (and the very small performance gains).
Trac:
Username: imageverif Might be relevant here in regards to comment:1 : https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Notes/CDNsAndTorExitBlocking
According to a W3Techs.com report, jQuery is used by 73.2% of all the websites. With Decentraleyes one can hope for a good reduction in exit traffic to https://ajax.googleapis.com/ and co.
By the way it would be interesting if someone who runs an exit can run an ethical study on how much traffic goes to those CDNs (+).
- : Google Hosted Libraries, Microsoft Ajax CDN, CDNJS (Cloudflare), jQuery CDN (MaxCDN), Yandex CDN, Baidu CDN, Sina Public Resources, and UpYun Libraries.
In light of the DDoS that the Tor network is undergoing, I thought it would be the best time to write a patch for this since with it, (1) popular traffic to CDNs for JS libraries will be virtually gone, helping thus to ward off some exit traffic; (2) it helps with usability when a CDN blocks a particular Tor exit used in a circuit for a website that relies on said CDN for a JS library; (3) faster loading pages for websites with those JS libraries served from CDNs.
Note: Of course, the addon would need to be audited before being added, and since there's already a WebExtension version that only works with >=FF56 that has many advantages over the legacy version, I think it would be better to wait until the FF60ESR period if this is to be considered in the first place.