Feeding your algorithm

The other day I included the phrase “stupid Instagram” in the caption for a photo on Instagram. I was quite proud of the photo, and figured it was a decent contribution to Mountain Monday. I was expecting a steady stream of likes, probably topping out around 30-40 or so (which is typical for me). So imagine my surprise when nothing happened. I got a couple of likes early on, then one or two more and finally another couple from followers whom I suspect have relatively short follower lists.

And that was it. A grand total of 9 likes in nearly 48 hours, none of which were from what I would describe as my “mutual admiration circle”; people with whom I tend to exchange likes. I was baffled, but then I began thinking about the fact that Instagram’s feed is now driven algorithmically and is not just a timestream (which I would prefer), and I wondered if the fact that I’d written “stupid Instagram” meant that Instagram’s algorithm significantly down-weighted my post to the point where almost none of my followers saw it? Could Instagram really be that sensitive to even the slightest perceived criticism?

Now, of course I realize that many of the people I follow have really long lists of others they follow, so it could simply be a numbers game. And I have seen that happen in the past, but I still usually rack up 20-30 likes. (By comparison, my latest photo is up to 35 likes in less than three hours.)

So I will try another experiment in the near future. I might even post the same photo, at the same time of day with all the same tags and caption, only with the perceived slight on Instagram’s part removed. And I’ll see what happens.

Advertisements

A passing encounter with ransomware

It all began with the most innocuous of actions: a click. One of those many articles on Facebook that pops up in the “Related stories” area when you “like” an article. Next thing we had a web page showing all manner of error codes along with advice on how to fix the “problem” that had been detected, pop-up dialogs galore and the computer began beeping, like the alarm system on a science-fiction spaceship. It was almost comical.

Until I realized what was happening.

Then I had the “Oh shit – ransomware” moment, and lunged for the power button. (In retrospect I should have just tried to shut down the web browser from the task manager but I didn’t want to delay shutting down the computer if it was about to start encrypting our hard drives.)

That done, I thought for a moment, trying to assess the damage in the worst case that the hard drives had been encrypted. We figured that we might lose the past two weeks of photos and any edits. That wasn’t too much of an issue, really as we hadn’t cleared the memory cards in our cameras for over a month. We would probably lose a few recent PDFs and text files – annoying but not disastrous.

Having weighed up the situation, I retrieved some cables for reading bare hard drives and then set about dismantling the computer. First I detached the external hard drive used for continuous backup of a few folders (more on that later). Then I opened the case and removed the 3-TB main hard drive that contains all our photos and documents.

I booted up the Linux box and plugged in the external backup drive. It mounted just fine and I could read the files on there – at least as much as you can read the files in a CrashPlan backup. There was no sign of any recent modifications to the file system, so I figured that if something had started the encryption process, it hadn’t got to that drive yet (after all, it was down the list at F:).

I breathed a sigh of relief: it looked like we’d actually have up-to-date copies of our documents. Yay!

Next step was to attach the 3-TB drive. That’s when my heart started to sink. It mounted as an empty volume. No partitions, nothing. Wait, that’s not quite true. In actual fact it didn’t even mount – it just showed up as empty in the disk utility. Oh crap. Was that it? Had we actually lost the contents of that drive? I didn’t dare hope it was just some quirk.

Unplugging that drive, I moved on to the main system drive. Plugging that in was immediately more hopeful: a partition called “System Restore” mounted, and then I got an error message saying that the main partition couldn’t be mounted because Windows had been put in hibernate mode. Another light bulb moment, this time a positive one – I think – as I remembered I’d configured the power switch to hibernate rather than power off. OK, so the drive had gone into hibernation correctly. I mounted it read-only and lo-and-behold I was in business.

Poking around on the C: drive it appeared that everything was in order. I couldn’t find any nefarious-looking files (not that I really knew what to look for) with the right timestamp. So I decided to make a local backup, just in case. I used the tried-and-tested rsync to make a copy on one of the drives in the Linux box, which gave me time to do a bit of research about ransomware…

What I found gave me hope. It seemed that a couple of the most common types were in fact browser-based and weren’t real ransomware at all. I looked at screenshots to compare with the picture in my memory from the brief glimpse I took before hitting the power button, and decided that – if I was lucky – we’d most likely been hit with the TechBrolo.C Trojan installer. Furthermore, Windows Defender seemed to know about them and could remove them.

Progress of sorts, then. Once my local backup was done, I decided it was time to test those ideas, and got back down on my hands and knees to reattach the hard drives. Leaving the network cable unplugged, I tentatively hit the power switch. I was soon looking at a normal login screen – very promising, which told me we hadn’t been hit by real hard-drive-encrypting ransomware. I logged in and waited. Everything looked fine. I checked the 3 TB drive and was relieved to see that all our files were still there. I started up ACDSee to browse some photos just to be sure. All looked OK. Phew!

I restarted Firefox – which of course tried to load all the previously-open tabs. At least this time I was able to kill the tab with the offending payload, and looked through the history to see what website had spawned it. I copied the URL and deleted the entry from the history. I won’t give the URL as I would hate for someone else to click on it, but the site is in the .ml top-level domain (which is Mali, where Timbuktu is located).

Everything still looked fine, so I started up Windows Defender and set it to run a full scan. However, not long after it got under way, a warning sign did show up saying that a potential malicious file had been discovered.

When the scan ended (two-and-a-half hours later), the report did indeed show a single potential threat: the TechBrolo.E trojan, hiding in our Firefox cache. I clicked “Remove” and within moments it was gone. I re-ran a quick scan just to double check and it came back clean. Yay! I plugged in the network cable, started the task manager and waited. Nothing was happening: just an idle computer. Next up was Firefox again, and it too wasn’t doing anything out of the ordinary.

Now, remember that backup I did on my Linux box? Well, that included the Firefox cache, so I went in and had a look. Sure enough the file was a gzipped Javascript file with some stern warnings and more newlines than I’ve ever seen in my life! It looks like it tries to load a PHP file with an insane name, which I’m guessing is where the main payload is.

I wonder if the Javascript downloaded is country-dependent? I mean, showing a ransomware web page with a 1-8XX number won’t get you very far outside the US and Canada.

And so there I was a few hours later, and all was as well as it could be.

At the end of the day, all I can say is I’m glad I had that Linux computer, both as a second (and more importantly non-Windows) computer and as a backup for all the files we care about, as well as having the right cables to connect hard drives to a USB port. I’m also glad that I could shrug and say that at worst, we’d have lost only a couple of weeks’ documents and photos.

My take away from this? Have a backup of all the files you care about. And make sure that backup runs as often as you need it to. Every day, if necessary, though weekly is probably good enough. And watch what you click on…!

Terminal trees

A long time ago, back when I got my first Mac, I installed MacPorts to get a few extra packages that I used under Linux. Fast forward a few years (and a new laptop) and I’ve forgotten about all of this 🙂 When it came to looking for a way to get the tree command (which displays a directory listing in a tree format), one of the answers was to use MacPorts which prompted me to check and lo-and-behold, I did indeed have MacPorts installed.

A quick check showed that my installed version was waaaaay out of date so I needed to update that before going ahead with installing the package I was after. Thankfully, MacPorts has a nice little migration guide that helped me through the process. (This kind of documentation is vital to cover those instances of redoing something that you might only touch one or twice in the lifetime of a computer.)

Of course, I had to reinstall the Xcode command-line tools along the way… (Why they aren’t included by default I do not know.) I also trimmed my list of port installations to drop a couple I knew I wouldn’t need (such as Perl, which I manage separately with Perlbrew).

Then all I had to do was:
% sudo port install tree
refresh my path and I was good to go. Yay! (Ignore the spacing in the example below – it seems the preformatted text for this WP theme adds some extra padding which breaks up the connecting lines. It should look fine in the terminal.)

/Users/macports/
├── Desktop
├── Documents
├── Downloads
├── Library
│   ├── Keychains
│   │   └── ....
│   └── Preferences
├── Movies
├── Music
├── Pictures
└── Sites

It seems that folks tend to prefer HomeBrew over MacPorts but that’s something for another day.

TensorFlow installation

I found this helpful little intro to using Google’s TensorFlow machine learning library with Python. Next step: install TensorFlow on my laptop.

A quick check of the project docs shows how it easy it is to install – I used pip. For simplicity (and the fact that I’m not planning to do any heavy ML stuff just yet) I went with the CPU-only option for Mac OSX (aka macOS since I’m on Sierra), and since I use tcsh rather than bash I used setenv to point to the TF_BINARY_URL.

But then I hit the following error:

Cannot remove entries from nonexistent file /opt/anaconda/anaconda/lib/python2.7/site-packages/easy-install.pth

A search told me that this was an issue with setuptools, but – thankfully – there is a workaround: append --ignore-installed to the installation line and hey presto, all is well.

(Funnily enough, most of the top results when searching for this error are related to installing TensorFlow. Coincidence, Google?)

After that, the tutorial examples worked just fine. Step 1 on the TF/ML learning curve…