Specific to business CDN then? This is good info, keep it coming!
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
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
Confirmed in Firefox 44.0.2 on Windows with Privacy Badger 1.0.6:
Steps to Reproduce
- Start
firefox.exewith-pparameter - Create new profile
- Dismiss making Firefox default browser
- Close 2 content tabs
- Open this URL in current tab Privacy Badger | Electronic Frontier Foundation
- Click āInstall Privacy Badgerā button
- Confirm installation āAllowā, then āInstallā
- Close Privacy Badger tab.
- Open the following URLās in this order, pasting them into the URL bar.
- http://internals.rust-lang.org/
- http://users.rust-lang.org/
- https://discuss.atom.io/
- http://discourse.ubuntu.com/
- 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
Hmm so this appears to be a bug in Privacy Badger specific to Firefox?
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:
- Load http://internals.rust-lang.org/
- 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
- Load http://users.rust-lang.org/
- Requests https://cdn-business.discourse.org/stylesheets/desktop_5c7a8e85d36ed7e4259702ed84f91a38be84c76e.css?__ws=users.rust-lang.org
- Request sent 52 bytes of Cookie data:
__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx
- Requests another avatar
- Request sent 52 bytes of Cookie data:
__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx
- https://discuss.atom.io/
- 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
- Requests another avatar
- Request sent 52 bytes of Cookie data:
__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx
- Request sent 52 bytes of Cookie data:
__cfduid=dxxxxxxxxxcc191d5417fxxx36443d1efxxxxxxxxx
- Load https://discuss.atom.io/
- 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
totally agree here, will amend our nginx config to strip all cookies from cdn endpoints.
3 Likes
Right but how is a cookie getting set for *.discourse.org I am not following how that is even possible.
also all the pull zones are meant to be stripping cookies in max cdn, very strange ā¦ will try to repro
2 Likes
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.
4 Likes
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.
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.orgwas also pointed to as being blocked, but that may be because it sets suspicious E-Tags: letter-avatars/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
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
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
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
Confirmed.
PS. The logo on http://discourse.ubuntu.com/ is looking a bit odd regardless of hosts modification.
2 Likes
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
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
This is not really surprising given the various anti-privacy discoveries about CloudFlare lately, namely:
1 Like