# Defaulting to discourse.org CDN for avatars is a privacy and security risk

**URL:** <https://meta.discourse.org/t/defaulting-to-discourse-org-cdn-for-avatars-is-a-privacy-and-security-risk/33731>\
**Category:** Feature\
**Tags:** privacy\
**Created:** [Septembre 25, 2015, 3:35 UTC](https://meta.discourse.org/t/defaulting-to-discourse-org-cdn-for-avatars-is-a-privacy-and-security-risk/33731 "2015-09-25T03:35:51Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![konklone](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/konklone/32/116763_2.png) [@konklone](https://meta.discourse.org/u/konklone)\
**Post date:** [Septembre 25, 2015, 7:28 UTC](https://meta.discourse.org/t/defaulting-to-discourse-org-cdn-for-avatars-is-a-privacy-and-security-risk/33731/11 "2015-09-25T07:28:00Z")

</div>

> [@codinghorror](#):
>
> Sure, just flip the site setting switch, and you have 100% local avatars like before. Not sure what all the fearmongering is about.

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.

> [@riking](#):
>
> This is also different from Gravatar in the sense that the images are cached aggressively, as opposed to Gravatar’s 5-minute invalidation.

That’s a great point – but also undermines the case for moving these to a CDN at all. If [avatars.discourse.org](http://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.

> [@riking](#):
>
> Looks like Cloudflare is adding a cookie. But that’s nothing you weren’t already getting on every single other Cloudflare site out there.
> 
> Also, that request was a Cloudflare hit so it didn’t even reach the Discourse servers.

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](https://support.cloudflare.com/hc/en-us/articles/200170156-What-does-the-CloudFlare-cfduid-cookie-do-) 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.

---

_[View the full topic](https://meta.discourse.org/t/defaulting-to-discourse-org-cdn-for-avatars-is-a-privacy-and-security-risk/33731)._