Discourse CDNs are blocked by privacy badger

Site feedback
21

Specific to business CDN then? This is good info, keep it coming!

22

Looks like logging in is not important. Reproduced again (same firefox, fresh profile) just by visiting the sites (the list above + three last links from Wikpedia article).

1 Like
23

My guess is because cdn.discourse.org returns Not Found.

i.e. Badger goes there and doesnā€™t see a ā€œreal pageā€ so it thinks something is fishy

24

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 | Electronic Frontier Foundation
  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/
  11. http://users.rust-lang.org/
  12. https://discuss.atom.io/
  13. http://discourse.ubuntu.com/
  14. 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 are displayed in Chrome in Privacy Badger.

Firefox doesnā€™t seem to have any DNT indicators in Privacy Badger.

5 Likes
25

Hmm so this appears to be a bug in Privacy Badger specific to Firefox?

26

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/
  2. Requests 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/
  2. Requests 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/
  2. Requests 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/
  2. Requests 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/
  2. Requests 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

4 Likes
27

totally agree here, will amend our nginx config to strip all cookies from cdn endpoints.

3 Likes
28

Right but how is a cookie getting set for *.discourse.org I am not following how that is even possible.

29

also all the pull zones are meant to be stripping cookies in max cdn, very strange ā€¦ will try to repro

2 Likes
30

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-

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.

4 Likes
31

I opened a ticket to get the domain locked to yellow: https://github.com/EFForg/privacybadgerfirefox/issues/752

Iā€™m pretty sure that should fix the problem.

32

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

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.

3 Likes
33

Yes the Etag thing was a red herring. 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)

5 Likes
34

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 is setting a cookie on *.discourse.org which is then being reused by CDN

35

Just wondering if you can confirm ā€¦ does chucking avatars.discourse.org into your hosts file pointing at 127.0.0.1 resolve the issue?

1 Like
36

Confirmed.

PS. The logo on http://discourse.ubuntu.com/ is looking a bit odd regardless of hosts modification.

2 Likes
37

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.

9 Likes
38

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.

11 Likes
39

This is not really surprising given the various anti-privacy discoveries about CloudFlare lately, namely:

1 Like
40

A compliant from the a member of the Letā€™s Encrypt community.