-
Getting hacked
My father-in-law, M, had his Facebook account hacked recently. I don't know how it happened. My guess is that he reused a password that was leaked in a data breach, somewhere. Anyway the account was taken over by someone in Nigeria and promptly started spamming Bitcoin coaching services.
The posts were surprisingly sophisticated. One included a faked screenshot of the lock screen of his phone, with a bunch of notifications indicating that vast sums of sterling had been deposited into his Barclays account. M doesn't have a Barclays account, but his Facebook friends don't know that. As far as his friends know, he's just purchased a brand-new Audi with the earnings from trading Bitcoin under the tutelage of an Instagram account with an AI-generated avatar.
Getting the account back was surprisingly convoluted, and at no point involved another human from the support team at Facebook, with whom there appears to be basically zero recourse. The email address, phone number, and password on the account had all been changed, but Facebook allowed me to log in with a previous email+password combination and removed the attacker's email+password from the account. This is a great feature, but it doesn't prevent the attacker from using it the exact same way to take control back. The key to holding on to the account after a email+password reset was to quickly enable two-factor authentication. After that, I signed out all other locations and removed the various connected devices—mostly out-of-date iPhones located in Nigeria and Singapore—and accounts (his Instagram account, alas, remains hacked).
We got a bunch of failed login notifications shortly thereafter, presumably as the attacker tried to get the account back—but no new successful logins. It's been a few days now and he remains in control of his Facebook account. This feels like a rare success.
-
More cache busting
I wrote a little bit, a while ago, about my cache busting strategy for this website. The basic idea is to generate a unique identifier at the time of deploy, and then use that unique identifier as a query param for requests to static assets. So that if I haven't deployed in a while, and on the off chance that I have a repeat visitor to this website, that visitor gets the cached version of my (admittedly minimal) CSS and JavaScript. When I re-deploy the website, that visitor's browser will determine that something has changed and reload the files.
Previously, when this website was redeployed using GitHub Actions, I used the ID of the action's run as the unique identifier—on the basis of that identifier being incremented on every deploy.
Now that I deploy manually, I no longer have that identifier. So I use a random hexadecimal string instead:
VERSION=$(openssl rand -hex 4) grep -rl '{|{VERSION}|}' ./templates | xargs sed -i "s/{|{VERSION}|}/$VERSION/g"
This finds all files in my
templates
directory that have the{|{VERSION}|}
string in them (just a distinctive string that I likely won't be using anywhere else)—and then usessed
to replace that string, inline with my random identifier.I suppose I could be doing something clever like hashing each of the files, so the ID doesn't change unless the file does—but this works, and works well for a website of this scale.
-
Dockerise the website
tl;dr I didn't do it.
Take this all with a grain of salt. I am not a system administrator. I know the bare minimum necessary about Docker. If someone gives me a Dockerfile, I think I can get whatever service it's containerising up and running. I don't know what a Dockerfile is, and I don't know how it works. This is about finding the friction in containerising a small PHP+SQL-based blogging application (this one).
I recently declared bankrupcy on the server that ran this website and started over with a fresh one running an up-to-date OS and dependencies, and boy oh boy was it a headache. Ensuring that languages & compilers were installed, migrating data, writing
systemd
service configs. Wouldn't it be nice, I thought, if I could simply change some numbers in a configuration file somewhere, and some system or service would handle provisioning all the crap that the website needs? It would!So: Docker. But: Docker.
I spent the better part of a day faffing with
docker-compose
and trying to configure a Dockerfile, exposing the right ports and ensuring that the containerised services could all talk to each other. I configured a persistent volume and navigated conflicts with services running natively on my laptop. I researched hosts for containerised applications. I weighed the pros and cons of hosting my database separately from my application. I priced it up. I cringed.This all turned out to be more trouble than it was worth. More than it was worth for this crummy blog, anyway. It turns out that you can't deploy a container from a
docker-compose.yaml
anyway. Figures.I can see the shape of the problem that Docker solves. I can see how it abstracts away the fiddliness inherent in assurances about availability and reproduceability. If you need to spin up whole environments from nothing, and you need to do it more regularly than once a year, then Docker is probably pretty good solution. In fact it must be, or it wouldn't be such a Big Deal. But I don't have any of those problems.
I expect that this sort of Docker thinkpiece is like 8 or 9 years out of date anyway. But when I remigrate everything to another server like 3 years from now, I'm going to secondguess myself and give Docker another go, and I'm just trying to head myself off at the pass.
-
Battery on Arc
Just finished downloading the latest version of Arc and it looks like the issue that caused a background 5% CPU load on my crusty old MacBook has been expunged. In fact, I'm writing this very blog post on Arc, with nary a spun-up fan to be heard.
Arc is nice—and I'm glad that they're trying to do something new with the browser—but I'm not sure whether their take is enough to pull me away from my precious defaults. It's thoughtfully-designed, for sure. But is it thoughtfully-designed enough to make it worth switching to? To make it worth learning how to use a new app look at the internet inside of a rectangle?
-
Listen to Wikipedia
Listen to the sound of Wikipedia's recent changes feed. Bells indicate additions and string plucks indicate subtractions. Pitch changes according to the size of the edit; the larger the edit, the deeper the note. Green circles show edits from unregistered contributors, and purple circles mark edits performed by automated bots. You may see announcements for new users as they join the site, punctuated by a string swell. You can welcome him or her by clicking the blue banner and adding a note on their talk page.
This is fantastic. The noise—I hesitate to call it music, but I also hesitate to call it not music—is remarkably consonant. I've just left it running in the background.
What's more: the site is open-source, so you can have a nosey around at how it works. At its core is a websocket connection to a server that Hatnote manages, but which itself pulls from Wikipedia's Recent Changes. Also of note: no build step. Just a couple of vendored libraries in a
static/
folder. Take notes, folks.
Archive
Posts Stream Books Walks • Clear filters
2023
December 2023
November 2023
September 2023
May 2023
April 2023
February 2023
January 2023
2022
December 2022
Currently showing latest 20 posts