Our computers, and the systems which they access, use caches almost everywhere.

From the CPU, which has local cache memory arrayed in different levels, to your browser and the sites to which it connects, caches are ubiquitous. Processor caches are faster to access than normal memory, and aim to anticipate the data which the CPU will need from, and provide an intermediate step for those data to be written to, main memory. Your browser’s caches save it from having to fetch a webpage and its elements which you have only just accessed. Although not only about speed, the main aim of most caches is to improve performance.

The term cache is oddly inappropriate. Derived from the French verb cacher, to hide, for most of the last couple of centuries its meaning has emphasised this aspect of concealment. Caches of hidden treasure were discovered in the nineteenth century, but inspired explorers – both of the American West and polar regions – to use the term for placements of stores and ammunition, typically in a hole in the ground (or snow).

When Scott headed for the South Pole in 1911 his team had placed depots (also French in origin, stemming back to deposit), but during the twentieth century cache has come into more general currency from the military. It finally made it to computers back in the late 1960s, as an alternative to buffer, by which time concealment had been largely forgotten.

Every so often we get caught, cached perhaps, by snags with caches not being as concealed as they should be. This was the problem at the root of the Steam data compromise at Christmas: all of a sudden, users started to see the cached data for other accounts.

Yesterday I too was caught by a cache problem relating to concealment.

My first article of the day contained a screenshot which unintentionally revealed one of my mail addresses; not a big issue, but as this was being broadcast to all and sundry on Twitter, and was about to go onto Facebook too, I preferred to replace the offending screenshot with a newer version in which that part was carefully blurred out.

I pulled my tweet, edited the screenshot, and put the new image in the article. When tweeted, it now just gave the link to the article, which was fine by me. But when I posted it on Facebook, I could read my email address as clearly as I could in the first, erroneous, image. I repeated the process, blurring the image a bit more in case it was a quirk of image reduction. The new Facebook post remained unchanged.

In the end, I just pulled the posting from Facebook, and left it at that; life is too short to faff around any longer. I am fairly certain that what was happening was that my WordPress announcement was being sent correctly, but that somehow Facebook still had that original image cached, and kept using it regardless of my insistence, and growing frustration.

If I am right, be careful what you post to Facebook in this way: don’t let it cache you out.