A Smashed Computer Monitor. Photo by Олег Мороз via Unsplash. Photo by Олег Мороз on Unsplash

Introduction

Michael Harley wrote a piece called How I make my blog posts more resilient a couple of days ago. There are a lot of good ideas and principles that he covers for maintaining a blog, or just about any website. Reading his article made me think back to a situation from nearly ten years ago where I went through a fairly major incident with one of my sites.

While I documented the issues broadly at the time, I only partly talked about one of the issues that I had to deal with: broken third-party embeds. I thought a discussion about the issue(s) I ran into, and how I handle them would be appropriate as a companion piece to Michael’s article.

Inciting Incident

In 2018, I had to make a number of changes to The CerebralRift. (You can read all about these changes in the articles I posted back in 2018: CerebralRift Goes KABOOM!, Extreme Website Cleaning, The Long Grind Aftermath, and A Pair Of Post Cleanup Rants. But I don’t recommend it. They’re long, kinda ranty, and still somehow boring.) I’m going to focus on one part of those changes in more detail here than I did in the original articles.

While making the changes, I found there were a number of issues with the site. Those issues only got worse as I made more changes. (A lot of these changes included relocating and / or removing content, so things getting worse seemed counterintuitive.) I soon knew the situation called for a deeper investigation to resolve the issues.

What I Found

One of the issues that I found concerned my use of embeds on the site. In most of the reviews I had written (approximately 350) I would try to embed the release as part of the review. This was mostly a courtesy: I wanted my readers to be able to listen to, or see, what they were reading a review about.

However, what I found was when the original recording either moved, or disappeared from the internet, several of these embeds did not fail gracefully. What do I mean by fail gracefully?

When called, an embed should be able to check that the URL or URI it is passed is valid. If it is not valid, the embed should fail. That isn’t what happened with several of these embeds. Instead, one of two things would happen:

  1. The embed would continuously try to load, keeping the web page from ever being completely loaded.
  2. The embed would load, but it would have 12-16 malformed URIs.

This impacted the performance of my site, and the scoring that many search engines do when looking at a site (yes, I was involved with SEO principles at this time — but I’m feeling better now). The hung embed would score as an extremely long load time. And the malformed URIs would look like broken links. Basically, these broken links were wreaking havoc not just with SEO scoring, but honest technical benchmarks that need to be watched when running a site.

But, I had another concern: was it possible that these misbehaving embeds could be used as an attack surface? My gut said that wouldn’t be an issue for my server, however, it could be a vulnerability for users of my site. So, being the paranoid person I am, I considered these broken embeds as a security issue. (I honestly went back and forth on this a lot, sometimes thinking that maybe there was a way to use a broken embed to get back to my server. Just a symptom of my paranoia.)

What I Did

I think it’s pretty obvious (especially if you read through the articles I mention above): I methodically worked my way through 400+ articles that were posted on my site. (More articles than just the reviews were affected.) During this process, I updated / refreshed all the articles that needed it.

This was a long process. It took literally days of work to clean everything. Along the way I put a lot of thought into how I was going to proceed moving forward.

The New Policy

Third-party embeds are no longer welcome on my sites, unless there was some rare super-specific reason that I needed to use one. Nearly ten years later, I don’t recall finding a reason to use one.

There is also something else that, while I hadn’t considered it at the time, seems relevant now. We’ve always known that many of these embeds need to use cookies in order to track their state on our systems. But, do any of us really know what these embeds are doing? It’s certainly probable that they could be dropping beacon cookies, or other cross-site accessible bits of data on our systems.

And, to the best of my knowledge (please correct me if I am wrong), there is no GDPR equivalent regulating what an embed can do. That thought leaves me a little on edge.

This doesn’t mean you won’t find media on my sites. The CerebralMix Archive is a perfect example of a site where most of the pages have a media player on it. But, that media player is pure HTML5 code. It’s encoded in such a way that if it fails for some reason it produces an error message. And there are still standalone links to download the media directly, so users can still access it even if the media player fails.

In this age where having rich media on websites is more the norm than not, this policy might seem backwards. But, honestly, it’s made the maintenance of my sites easier. And, I’ve been able to sleep a little more easily knowing that I don’t have a ticking time bomb on my websites.