Purging Apple's Secret Caches

This of course is something Apple should address if they really cared about your privacy.

Introduction

This is Comp Sci. It has to do with Apple computers. Those fabled machines that always put you and your privacy first.

Now most poor punters on the platform won't have encountered or seen this, as Apple engineers do their best to keep things hidden, and not only for your convenience either. Often they just don't want to be found out.

They have a directory in root called '.DocumentRevisions-V100'. It's a nasty bugger. We've mentioned this before. It needs looking into, not just to expose Apple's dirty underbelly, but to alert you to a tangible privacy risk and offer you a solution.

We've now performed the 'cure' on multiple machines and it seems to work well. But note: this is not a permanent cure. This issue requires your recurring attention.

Teaser

Here's a teaser for what you will find. Drop to a Terminal console and type in the following.

sudo cp "/.DocumentRevisions-V100/db-V1/db.sqlite-wal" .

sudo chown 501 *

strings * >strings.rtx

We use the extension 'rtx' because that's one of the extensions used by our own text editor Rixedit. You can of course use 'txt' if that suits you better. The most important thing is you open the strings file and see what's inside.

Lots of old friends you forgot about?

Basically it's like a 'Dear Diary' of everything you've downloaded off the Internet.

You don't need prodding to understand what a privacy risk this is.

But there's more in that cave. The best way to inspect is to do as we did. You fire up Xfile in superuser mode. Then you copy out the complete .DocumentRevisions-V100 hive to a neutral location in your own area.

Once you exit your superuser Xfile, you reset permissions and ownership on everything. And it's now you're going to discover just how much bad blood the Apple engineers have for you. Permissions are totally out of whack, with '111' all over the place. Flags are on everything too, often it's '000000012', and so forth. Then you have to make sure this copy is yours, ie 501:admin. But you'll likely have to do this as '501' because shells don't like wild cards when you're root. But yes, after that, you can look around.

If you copied .DocumentRevisions-V100 to a directory of its own in your home area, then you can use sudo chown -R 501:admin <directory> and then proceed with Xfile. And you'll have to do some extensive 'proceeding'.

You'll find the files db.sqlite and db.sqlite-wal in directory db-V1. One of those you've hopefully already seen.

You'll find ChunkStoreDatabase and ChunkStoreDatabase-wal in directory .cs.

Under a .cs subdirectory called ChunkStorage, you'll find a whole mess of files - on this new test machine we're using, they're more than 140 MB. 140 MB of, to you, pure unadulterated junk.

Here's the thing.

All those files can potentially contain privacy risks. Those files just build up and build up and Apple's engineers don't give a shit. They seriously didn't think that far. Hey, you're going to trade in that computer soon anyway, right? (And the new owner will learn so much about you.)

But you don't have to go along with that.

Here's what you do.

Go back into superuser Xfile.

Clean out all the extraneous stuff in .DocumentRevisions-V100 - all the files and extraneous '0' directories. Leave the actual directory structure intact.

Then reboot - and into single-user mode. And check your system integrity as you always should do on a cold boot (/sbin/fsck -fy). Then boot back into your Mac again.

Kick Xfile back into superuser mode, check what you have under .DocumentRevisions-V100, and you should see that everything's fine. Except you're 150+ MB lighter and have a lot fewer privacy risks.

This of course is something Apple should address if they really cared about your privacy. But they don't give a shit about your privacy and you've always known it.

But now you know how to take care of it yourself.

A Script!

Ideally you should have a script to take care of this regularly. CLIX is the perfect helper of course. You want to leave the basic directory structure of .DocumentRevisions-V100 intact but otherwise remove all the 'data files' - and you want to do this right before a cold boot.

As always, YMMV, but it works here like a charm.