Opened 3 years ago

Last modified 8 months ago

#22089 needs_review enhancement

Add Decentraleyes to slighten off a bit Exit traffic and work around some CDNs blocking of Tor

Reported by: imageverif Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability-website, tbb-performance
Cc: fdsfgs@…, indigotime Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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."

Child Tickets

Attachments (2)

0001-Bug-22089-Add-Decentraleyes.patch (1.7 KB) - added by cypherpunks 22 months ago.
0001-Bug-22089-Add-the-Decentraleyes-addon-to-the-Tor-Browser.patch (1.8 KB) - added by cypherpunks 22 months ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 3 years ago by imageverif

Another advantage: Since some CDNs block some Tor exits (eg cdnjs.cloudflare.com), the resources will not be loaded thereby breaking some websites and making the TBB less usable on those websites. Using the proposal above may help solve this problem.

comment:2 Changed 3 years ago by cypherpunks

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.

comment:3 Changed 3 years ago by cypherpunks

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.

Last edited 3 years ago by cypherpunks (previous) (diff)

comment:4 Changed 3 years ago by tokotoko

Cc: fdsfgs@… added

comment:5 Changed 3 years ago by blockflare

Summary: Adding Decentraleyes to stop tracking by large CDNs (with slightly less traffic for exits) in the TBBAdd Decentraleyes to stop tracking by large CDNs (resulting in slightly less traffic for exits) in the Tor Browser

comment:6 Changed 3 years ago by imageverif

Keywords: tbb-performance added

Since this may positively affect TBB performance.

Last edited 3 years ago by imageverif (previous) (diff)

comment:7 in reply to:  description ; Changed 3 years ago by gk

Status: newneeds_information

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.

comment:8 in reply to:  7 Changed 3 years ago by imageverif

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).

comment:9 Changed 3 years ago by cypherpunks

This would be a lot more usefull in an upstream Firefox browser where the "exit" stays pretty consistent.

comment:10 Changed 2 years ago by cypherpunks

Status: needs_informationnew

comment:11 Changed 2 years ago by cypherpunks

Summary: Add Decentraleyes to stop tracking by large CDNs (resulting in slightly less traffic for exits) in the Tor BrowserAdd Decentraleyes to slighten off a bit exit traffic and work around some CDNs blocking of Tor

comment:13 Changed 23 months ago by cypherpunks

Keywords: tbb-usability-website added; tbb-usability removed

comment:14 Changed 23 months ago by cypherpunks

Summary: Add Decentraleyes to slighten off a bit exit traffic and work around some CDNs blocking of TorAdd Decentraleyes to slighten off a bit Exit traffic and work around some CDNs blocking of Tor

comment:15 Changed 22 months ago by cypherpunks

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.

Last edited 22 months ago by cypherpunks (previous) (diff)

Changed 22 months ago by cypherpunks

comment:16 Changed 22 months ago by cypherpunks

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.

Last edited 22 months ago by cypherpunks (previous) (diff)

comment:17 Changed 22 months ago by cypherpunks

Status: newneeds_review

comment:18 Changed 18 months ago by cypherpunks

analyze the proposed privacy, security, and performance gains adding $extension to Tor Browser, especially compared to the privacy, security, etc. means Tor Browser *already* offers. Please, include the downsides of adding $extension to the browser as well (our design document might help).

gk will take some time before adding that into the TB design document so I'll go ahead now:


# Compatibility

The proposed extension is a WebExtension that is compatible with the FF60 ESR release.

# Gains

## Privacy gains

There are no crucial privacy gains compared to what the Tor Browser already offers.

## Security gains

Since the proposed extension will fetch libraries locally, this helps in rare cases in which CDN providers are hacked and used to serve malicious/junk/cryptojacking code (see [1] for a recent example that doesn't apply in this case, but just to illustrate the point).

Some CDN endpoints don't support HTTPS[2], and some website operators user them. With the proposed extension this problem will be addressed since the fetch won't happen and libraries will be served locally.

## Performance gains

Since the proposed extension will fetch libraries locally, this will help significantly in time load to fetch said libraries from the known CDN endpoints, especially in mobile devices with TBA.

This performance gain will apply to the Tor network itself, though it will be very small and limited.

## Usability gains

Some CDN endpoints block Tor exit nodes, with this extension this problem can be solved since the resources will be fetched locally.


# Downsides

## Usability downsides

Some redirects by the proposed extension fail when a website assigns the "crossorigin" attribute to a script element that references an injectable resource. The relevant issue is not fixed on FF60, but has received a design approval from Mozilla developers.[3][4] That said the extension has a whitelist of such domains to prevent the said issue from occurring in the first place,[5] and there are proposed methods to detect sufficiently enough of these domains.[6] The developer of the extension further adds:

The plan is to completely get rid of the list of tainted domains. That said, since older versions of Firefox will not magically disappear, and vendors of other web browsers might not approve the necessary API changes, being able to detect tainted domains will likely stay relevant.[6]

## Security downsides

There are no known security downsides.

## Performance downsides

There are no known performance downsides.

Moreover, there is no significant memory footprint since only a list of dozens of URLs[5][7] is cached, unlike HTTPS Everywhere for instance.

## Privacy downsides

Decentraleyes usage may be detected with JS but that will be harmless if everyone already has it, so no privacy concerns to note.


[1] : https://scotthelme.co.uk/protect-site-from-cryptojacking-csp-sri/

[2] : Such as BaiduCDN (apps.bdimg.com).

[3] : https://git.synz.io/Synzvato/decentraleyes/issues/16#note_3620

[4] : https://bugzilla.mozilla.org/show_bug.cgi?id=1419459

[5] : https://git.synz.io/Synzvato/decentraleyes/blob/master/core/interceptor.js#L53

[6] : https://git.synz.io/Synzvato/decentraleyes/issues/294

[7] : https://git.synz.io/Synzvato/decentraleyes/blob/master/core/mappings.js

Last edited 17 months ago by cypherpunks (previous) (diff)

comment:19 Changed 16 months ago by cypherpunks3

An example that I encountered today where this may have been useful on stackoverflow:

Loading failed for the <script> with source “https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js”.

This make stackoverflow unusable for comments/answers/voting...etc.

comment:20 Changed 14 months ago by indigotime

Cc: indigotime added

comment:21 Changed 8 months ago by cypherpunks

Any comments from the upper echelon (gk, ...etc)?

comment:22 in reply to:  21 Changed 8 months ago by gk

Replying to cypherpunks:

Any comments from the upper echelon (gk, ...etc)?

I am not convinced yet this is worth the effort. comment:18 is a good start, we should think about expanding it. E.g. there are clear security downsides in the sense that a new extension added to Tor Browser means a new attack vector and we would need to spend a considerable amount of time to review the code every new release contains and as we want to get away from automatic extensions updates anyway we would start to monitor upstream libraries for security fixes to the locally shipped libraries. That could easily result in quite some effort from our side...

Note: See TracTickets for help on using tickets.