# Discourse CDNs are blocked by privacy badger
**URL:** https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127
**Category:** Site feedback
**Created:** [Julho 2, 2014, 8:03pm UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127 "2014-07-02T20:03:36Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [Março 25, 2016, 2:52am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/21 "2016-03-25T02:52:28Z")
Specific to business CDN then? This is good info, keep it coming!
---
### Author:  [@vi0oss](https://meta.discourse.org/u/vi0oss)
#### Post date: [Março 25, 2016, 3:03am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/22 "2016-03-25T03:03:53Z")
Looks like logging in is not important. Reproduced again (same firefox, fresh profile) just by visiting the sites (the list [above](https://meta.discourse.org/t/blank-page-unless-i-start-a-new-session/17127/17) + three last links from Wikpedia article).
---
### Author:  [@Mittineague](https://meta.discourse.org/u/Mittineague)
#### Post date: [Março 25, 2016, 3:26am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/23 "2016-03-25T03:26:23Z")
My guess is because [cdn.discourse.org](http://cdn.discourse.org) returns Not Found.
i.e. Badger goes there and doesn’t see a “real page” so it thinks something is fishy
---
### Author:  [@DeanMarkTaylor](https://meta.discourse.org/u/DeanMarkTaylor)
#### Post date: [Março 25, 2016, 3:33am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/24 "2016-03-25T03:33:09Z")
Confirmed in Firefox 44.0.2 on Windows with Privacy Badger 1.0.6:
### Steps to Reproduce
1. Start `firefox.exe` with `-p` parameter
2. Create new profile
3. Dismiss making Firefox default browser
4. Close 2 content tabs
5. Open this URL in current tab [Privacy Badger](https://www.eff.org/privacybadger)
6. Click “Install Privacy Badger” button
7. Confirm installation “Allow”, then “Install”
8. Close Privacy Badger tab.
9. Open the following URL’s in this order, pasting them into the URL bar.
10. [http://internals.rust-lang.org/](http://internals.rust-lang.org/)
11. [http://users.rust-lang.org/](http://users.rust-lang.org/)
12. [https://discuss.atom.io/](https://discuss.atom.io/)
13. [http://discourse.ubuntu.com/](http://discourse.ubuntu.com/)
14. [https://discuss.atom.io/](https://discuss.atom.io/)
### Expected Result
- Site to render correctly
### Actual Result
- Mostly white page with a few bullet points in top left
* * *
Same sequence tested in Chrome does not cause the problem in Chrome.
The [DNT indicators](https://meta.discourse.org/t/blank-page-unless-i-start-a-new-session/17127/19) are displayed in Chrome in Privacy Badger.
Firefox doesn’t seem to have any DNT indicators in Privacy Badger.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [Março 25, 2016, 5:17am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/25 "2016-03-25T05:17:02Z")
Hmm so this appears to be a bug in Privacy Badger specific to Firefox?
---
### Author:  [@DeanMarkTaylor](https://meta.discourse.org/u/DeanMarkTaylor)
#### Post date: [Março 25, 2016, 5:17am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/26 "2016-03-25T05:17:13Z")
There appear to be several cases where a cookie is included in a CDN response…
… there should never be cookies set by a CDN.
The general premise is that:
- if you respond with a cookie it will then have to be sent for every other request to that domain
- bytes on wire
- session lookup delays
- caching misses
Process kinda looks like this from a clean session:
1. Load [http://internals.rust-lang.org/](http://internals.rust-lang.org/)
2. Requests [https://avatars.discourse.org/v2/letter/b/a88e57/25.png](https://avatars.discourse.org/v2/letter/b/a88e57/25.png)
- Response sent 130 bytes of Cookie data: `Set-Cookie: __cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx; expires=Sat, 25-Mar-17 04:51:44 GMT; path=/; domain=.discourse.org; HttpOnly`
1. Load [http://users.rust-lang.org/](http://users.rust-lang.org/)
2. Requests [https://cdn-business.discourse.org/stylesheets/desktop\_5c7a8e85d36ed7e4259702ed84f91a38be84c76e.css?\_\_ws=users.rust-lang.org](https://cdn-business.discourse.org/stylesheets/desktop_5c7a8e85d36ed7e4259702ed84f91a38be84c76e.css?__ws=users.rust-lang.org)
- Request sent 52 bytes of Cookie data:`__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx`
1. Requests another avatar
- Request sent 52 bytes of Cookie data:`__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx`
1. [https://discuss.atom.io/](https://discuss.atom.io/)
2. Requests [https://cdn-business.discourse.org/site\_customizations/7e202ef2-56d7-47d5-98d8-a9c8d15e57dd.css?target=desktop&v=eacb1549fa961df385239301295cbb2b&\_\_ws=discuss.atom.io](https://cdn-business.discourse.org/site_customizations/7e202ef2-56d7-47d5-98d8-a9c8d15e57dd.css?target=desktop&v=eacb1549fa961df385239301295cbb2b&__ws=discuss.atom.io)
- Request sent 52 bytes of Cookie data:`__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx`
1. Requests another avatar
- Request sent 52 bytes of Cookie data:`__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx`
1. Load [http://discourse.ubuntu.com/](http://discourse.ubuntu.com/)
2. Requests [https://avatars.discourse.org/v2/letter/n/439d5e/25.png](https://avatars.discourse.org/v2/letter/n/439d5e/25.png)
- Request sent 52 bytes of Cookie data:`__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx`
1. Load [https://discuss.atom.io/](https://discuss.atom.io/)
2. Requests [https://cdn-business.discourse.org/stylesheets/desktop\_5c7a8e85d36ed7e4259702ed84f91a38be84c76e.css?\_\_ws=discuss.atom.io](https://cdn-business.discourse.org/stylesheets/desktop_5c7a8e85d36ed7e4259702ed84f91a38be84c76e.css?__ws=discuss.atom.io)
- Request sent 52 bytes of Cookie data:`__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx`
I believe heuristics are picking up on a high entropy cookie being passed between the sites effectively tracking the user across all of them.
* * *
## I would recommend using a completely separate root domain i.e. `example-discourse-CDN.com` for CDN activity and ensure you NEVER set a cookie on it. Perhaps use varnish or some other proxy in front of it to ensure cookies are removed.
For the moment just stop sending the cookie in response to an Avatar request like this one:
[https://avatars.discourse.org/v2/letter/b/a88e57/25.png](https://avatars.discourse.org/v2/letter/b/a88e57/25.png)
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Março 25, 2016, 6:23am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/27 "2016-03-25T06:23:53Z")
totally agree here, will amend our nginx config to strip all cookies from cdn endpoints.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [Março 25, 2016, 6:26am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/28 "2016-03-25T06:26:07Z")
Right but how is a cookie getting set for `*.discourse.org` I am not following how that is even possible.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Março 25, 2016, 6:27am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/29 "2016-03-25T06:27:24Z")
also all the pull zones are meant to be stripping cookies in max cdn, very strange … will try to repro
---
### Author:  [@DeanMarkTaylor](https://meta.discourse.org/u/DeanMarkTaylor)
#### Post date: [Março 25, 2016, 2:02pm UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/30 "2016-03-25T14:02:10Z")
It looks to me like the cookie `__cfduid` is set by CloudFlare:
[https://support.cloudflare.com/hc/en-us/articles/200170156-What-does-the-CloudFlare-cfduid-cookie-do-](https://support.cloudflare.com/hc/en-us/articles/200170156-What-does-the-CloudFlare-cfduid-cookie-do-)
The last line states:
> This cookie is strictly necessary for site security operations and can’t be turned off.
This makes me wonder how many other CloudFlare hosted CDN sites are going to fall into this trap.
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [Março 27, 2016, 12:06am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/31 "2016-03-27T00:06:44Z")
I opened a ticket to get the domain locked to yellow: [Multi-site CDN blocked due to CloudFlare cookie - lock to yellow? · Issue #752 · EFForg/privacybadgerfirefox-legacy · GitHub](https://github.com/EFForg/privacybadgerfirefox/issues/752)
I’m pretty sure that should fix the problem.
---
### Author:  [@DeanMarkTaylor](https://meta.discourse.org/u/DeanMarkTaylor)
#### Post date: [Março 27, 2016, 12:08am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/32 "2016-03-27T00:08:54Z")
You are also going to want to get `avatars.discourse.org` added too as well as any other domains that might be used by multiple 3rd party sites.
* * *
**EDIT**
Noted your update to the ticket
> `avatars.discourse.org` was also pointed to as being blocked, but that may be because it sets suspicious E-Tags: [letter-avatars/lib/letter\_avatar\_app.rb at main · discourse/letter-avatars · GitHub](https://github.com/discourse/letter-avatars/blob/master/lib/letter_avatar_app.rb#L51)
Actually ~~whilst the ETags element might be true,~~ `avatars.discourse.org` is the domain that sets the initial suspicious cookie to the root domain `.discourse.org`.
I couldn’t see any mention of ETags in the source code for either Firefox or Chrome. Although I might be using the wrong search terms.
The way that the heuristics / plugin works is that `*.discourse.org` ultimately gets blocked because of multiple flags against it.
Also regarding the statement:
> blocking cookies is fine, it’s a CDN so it doesn’t need them.
This isn’t exactly true, for `avatars.discourse.org` or any other site if it is hosted at ClouldFlare.
ClouldFlare will require their cookie, as they state:
> This **cookie is strictly necessary** for site security operations and can’t be turned off.
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [Março 27, 2016, 6:43am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/33 "2016-03-27T06:43:13Z")
Yes the Etag thing was a red herring. [avatars.discourse.org](http://avatars.discourse.org) is getting the Cloudflare cookie set.
* * *
I wrote more comments on the issue. There is a “yellowlist policy” in place, but…
CloudFlare _ **is** _ performing pervasive tracking here.
This is a policy decision, really - **what’s the Privacy Badger policy for sites using Cloudflare as a CDN that are not themselves performing tracking?**
Here’s an idea - use `cookieblock` for any 3rd party cookie named `__cfduid` UNLESS the ResourceType is “main\_frame” or “sub\_frame”, in which case use normal processing rules.
Wait, I think that fails for domains using the “strict ddos protection” thing where you have to view an interstitial before viewing the page. _(This is where the strictly necessary part is, which DOES NOT APPLY to discourse as that’s not turned on)_
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Março 27, 2016, 11:05pm UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/34 "2016-03-27T23:05:59Z")
I think the correct thing to do here @mpalmer and @codinghorror is buy a standalone domain for avatars, so the cloudflare cookie does not infect all the rest of the requests.
That is basically what is happening here… [avatars.discourse.org](http://avatars.discourse.org) is setting a cookie on \*.discourse.org which is then being reused by CDN
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Março 27, 2016, 11:08pm UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/35 "2016-03-27T23:08:39Z")
Just wondering if you can confirm … does chucking [avatars.discourse.org](http://avatars.discourse.org) into your hosts file pointing at 127.0.0.1 resolve the issue?
---
### Author:  [@DeanMarkTaylor](https://meta.discourse.org/u/DeanMarkTaylor)
#### Post date: [Março 27, 2016, 11:26pm UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/36 "2016-03-27T23:26:04Z")
> [@sam](#):
>
> Just wondering if you can confirm … does chucking [avatars.discourse.org](http://avatars.discourse.org) into your hosts file pointing at 127.0.0.1 resolve the issue?
Confirmed.
* * *
PS. The logo on [http://discourse.ubuntu.com/](http://discourse.ubuntu.com/) is looking a bit odd regardless of hosts modification.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Março 27, 2016, 11:30pm UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/37 "2016-03-27T23:30:03Z")
The level of dodge here from the cloudflare department is far beyond ridiculous.
It is one thing to be setting a “tracking” cookie on `avatars.discourse.org` but setting it on `*.discourse.org` when you visit `avatars` is pretty evil. This infects all our subdomains, even ones that are not served from cloudflare.
This kind of practice (if not merely a bug they need to correct) would give me enough reason to push for us to move all our stuff off cloudflare.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [Março 28, 2016, 12:52am UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/38 "2016-03-28T00:52:19Z")
Speaking entirely for myself, I find Cloudflare’s addition of a top-of-zone tracking cookie to be appalling behaviour. I thought they were one of the good guys, but this… not so much.
With my Discourse hat on, I’ve made the necessary changes to have `avatars.discourse.org` served via an alternate CDN (MaxCDN). I’ve verified that the responses now come back with no cookies whatsoever. If anyone sees any issues, or even if the Privacy Badger problems don’t abate, please respond in this topic.
---
### Author:  [@downey](https://meta.discourse.org/u/downey)
#### Post date: [Março 28, 2016, 12:24pm UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/39 "2016-03-28T12:24:08Z")
This is not really surprising given the various anti-privacy discoveries about CloudFlare lately, namely:
- [https://trac.torproject.org/projects/tor/ticket/18361](https://trac.torproject.org/projects/tor/ticket/18361)
- [Reddit - Please wait for verification](https://www.reddit.com/r/privacy/comments/41cb4k/be_careful_with_cloudflare/)
---
### Author:  [@saper](https://meta.discourse.org/u/saper)
#### Post date: [Julho 17, 2016, 8:03pm UTC](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127/40 "2016-07-17T20:03:43Z")
A compliant from the [a member of the Let’s Encrypt community](https://community.letsencrypt.org/t/privacy-badger-blocks-this-site/17976).
[Página anterior](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127.md?page=1)
[Próxima página](https://meta.discourse.org/t/discourse-cdns-are-blocked-by-privacy-badger/17127.md?page=3)