Again, that is not relevant. An individual Discourse installation can address this problem, if they choose. The issue I’m raising is that the community of Discourse (the platform) installations will now, by default (and so most of the time) be phoning home to Discourse (the company).
That’s a bad dynamic for Discourse user privacy, and the fact that there’s a site setting switch to turn it off doesn’t change that.
That’s a great point – but also undermines the case for moving these to a CDN at all. If avatars.discourse.org isn’t actually going to be hit all that much, then why is it so necessary to integrate the service by default? You could do the same aggressive caching with avatars generated and hosted locally.
I hadn’t realized Cloudflare was fronting the site. Unfortunately, that makes the problem even worse, as now most Discourse users will be sharing their browsing information with Cloudflare and Discourse’s servers. This will be true whether or not the operator of the Discourse installation has a relationship with Cloudflare, or whether they’ve even heard of Cloudflare.
As you note, they place a cookie that tracks visitors across Cloudflare sessions. While Cloudflare’s support docs are clear that this doesn’t connect to anything personally identifiable, it nonetheless allows Cloudflare to connect the IP addresses of Discourse users with whatever else their browsing activity is that touches other Cloudflare-hosted sites.
@codinghorror, if it’s really so easy to flip the site setting switch, and the performance hit of avatar generation is a real problem, then site owners who are willing to trade privacy for performance should make that decision by opting in. That’s not a decision that Discourse should make for most of the community, which – whether you intend it this way or not – is what making it an opt-out does.