Discourse CDNs are blocked by privacy badger


(_Vi) #12

In general, when something goes wrong with Discourse loading process (due to PrivacyBadger, NoScript or another reason), I see the blank page. I think this is not good UX.

I have:

  • No JS - Limited nojs Discourse
  • Partial JS - blank (or almost blank) page
  • Full JS - Fully featured Discourse

I want:

  • No JS - Limited nojs Discourse
  • Partial JS - Limited nojs Discourse and/or error message explaining what asset could not be loaded (or another problem)
  • Full JS - Fully featured Discourse

(Jeff Atwood) #13

I don’t care. What I care about is why Privacy Badger doesn’t like our CDN.


(Dean Taylor) #14

For me - having a clean band new Google Chrome profile and installing Privacy Badger does not have any issues for meta:

EDIT:
Also tested in Firefox:


I also completed the sign up process on internals.rust-lang.org using the same clean Google profile:

Note that it lists “2 potential trackers”, although they are not blocked.


Be aware that Privacy Badger has no “Clear Settings” or “Reset Settings” option…
… so any adjustments or customisations you make currently cannot be undone in your profile.

Thus the only way to test the experience of other users is to create a clean fresh new Google Chrome profile.

However it’s also worth noting that Privacy Badger now includes heuristic based detection so there might be an event that happens to cause a domain to get flagged.


(_Vi) #15

As far as I know, PrivacyBadger is stateful. It judges the domain “behaviour” based on requests to it and can flip it’s green-yellow-red switch automatically in background based on heuristics.

Maybe to properly reproduce the issue one should try to use (and log in to) multiple independent Discourse deployments.


(Dean Taylor) #16

That’s what I have been testing…

So far the only thing that’s gone yellow is fonts.gstatic.com which occurred when I clicked to play a YouTube video.

EDIT:
And now when clicking to share that YouTube video to G+ a “red” for videos.google.com:

@vi0oss which Discourse instances do you visit?


(_Vi) #17

Something like that. Shall I try to reproduce the issue on purpose?


(Dean Taylor) #18

Usually the first step to solving a problem is reliably reproducing it.
It would be good to get a step-by-step reproduction of the issue.


(Dean Taylor) #19

After a while browsing several (5/6) instances and visiting talk.turtlerockstudios.com I noted the “DNT” indicators:


(_Vi) #20

The domain remained green.

No manual interactions with PrivacyBadger’s UI apart from opening it’s window, hovering there and inspecting settings was performed.


(Jeff Atwood) #21

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


(_Vi) #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).


(Mittineague) #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


(Dean Taylor) #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.


(Jeff Atwood) #25

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


(Dean Taylor) #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


(Sam Saffron) #27

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


(Jeff Atwood) #28

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


(Sam Saffron) #29

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


(Dean Taylor) #30

It looks to me like the cookie __cfduid is set by CloudFlare:

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.


(Kane York) #31

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

I’m pretty sure that should fix the problem.