With the decline of X/Twitter and the proliferation of other social platforms with more open APIs, I've noticed many developers sharing social widgets and components to embed in blog posts. Mainly to display conversation and reactions.
Most of the social media widgets I've come across share a common issue that, in my opinion, should be prioritized: privacy and security, especially related to the media used in these components.
I will go one step further and say this: If you're creating your own comments or likes section based on platforms like Mastodon or Bluesky, reconsider your strategy, and avoid directly linking to avatars hosted on external social platforms. Instead, route them through your backend server.
The Privacy Issue
This may sound like a "tinfoil hat" moment, but it's an important consideration. Using images hosted on social media platforms allows those platforms to track your visitors. With enough data points, they can build a profile of the sites a person visits, and potentially identify them.
We don't know whether platforms like Bluesky use this data for tracking... but the potential exists. Even if they're privacy-conscious today, future changes in policy or ownership could alter that. Is Bluesky a reliable and safe company to have access to your visitors' data? Maybe, maybe not. But why take the risk, especially when they don't need that data in the first place?
The same applies to Mastodon. You may trust some instances, but anyone can spin up their own, and that poses some risks. Especially if you are serving content directly from them. What if a malicious actor likes your post and you unknowingly link to their avatar which now behaves as a "tracking pixel" on your site?
A court in Austria ruled that the use of Google Analytics is a breach of GDPR, and another court in Germany found that linking directly to Google Fonts instead of hosting the fonts "locally" also violates GDPR. Using social media-hosted avatars directly on your web may have similar legal implications related to GDPR compliance, and you may find yourself in a sticky situation.
It gets even worse if multiple sites use similar widgets. Then, the social media platforms not only get the person's information, but they can also build a browsing behavior map for that user.
So, what can you do?
Good news: there are at least a couple of solutions, and they are (relatively) easy to implement.
Get Permissions from Your Users
The simplest option is to request prior consent. Just like you would do with cookies and those infamous GDPR banners. Let your visitors know that parts of your site may include embedded content from Bluesky or Mastodon. Ask for consent, and honor their choice: don't load the widget if they opt out!
If they opt in, you are covered. You will not be protecting their privacy, but they made that decision themselves. From a compliance adn liability perspective, you will have done your part.
However, this approach brings other challenges: with many Mastodon instances, do you need consent for each of them individually? Do you even know which ones you will fetch avatars from in advance?
More importantly, this solution protects you, but not your visitors' privacy. What if you want to do both?
Route Images Through the Backend
Even better: proxy the images through your server. Create a backend route to fetch and serve the image assets. This gives you more control and offers your users more privacy.
By routing the images through your backend, Bluesky or Mastodon only see requests coming from your server. They will know someone visited your site, but they won't know who accessed the content, what content they viewed, or from where they accessed the content. And with proper caching, they may not even know when the content was accessed either.
This solution has some trade-offs:
- It requires some backend pre-work, to create the routing.
- Proxying the images adds server-side load and potential latency.
With proper fetching and caching techniques, the impact on the server-side load could be minimal and manageable. But it is something to take into consideration.
Both solutions come with pros and cons. Personally, I lean towards the second option as it protects both the developer and the end users.
Final Thoughts
Creating cool features is awesome, but we need to consider more than how usable or practical/good it looks. While we may be well-intentioned in sharing code and components, others may not. There are bad actors who will exploit those tools to collect data or compromise users' privacy. And they will take advantage of our solutions.
Don't let this discourage you from building. Keep experimenting, learning, and improving. Have fun with your code, but always remember to make it safe for everyone.
And that's me and my rant. Have a great day, and happy coding!