Posts filed under “Tech”

Your deactivated Facebook account really is reactivating itself

There are a lot of posts & questions & other things in various places online wherein people are complaining about this happening to them. Usually there's someone to tell them that nope, it's something you did. I can guarantee that it is not, in fact, necessarily something you have done. Because it happened to me (which totally changed my opinion about Facebook being an awful company), and I went to specific lengths to ensure that Facebook would not reactivate my account when I deactivated it. Specifically:

  • I did not sign in from any other devices. I do not have the Facebook app on any of my phones, and never have. Only two things have accessed it: my desktop computer and my laptop. After deactivating my account, I cleared the cookies on my laptop to be sure.
  • I do not have any apps that could have reactivated it, because there are NO apps connected to my account.
  • It is entirely implausible that anyone could have logged into my account with my credentials. My password is extremely long and complex (it is "hunter2"[1]). In the unlikely event that someone guessed a 28-character password, they decided to...do absolutely nothing with my account. But I'll reiterate, nobody guessed my password.
  • From what I have read, according to some rando on Quora, there is a "This is temporary, I will get back soon" checkbox?! Hmm... I'm not actually saying this is impossible. But when I deactivated my account I specifically checked for sneaky things like this because Facebook is an awful company staffed with terrible people, and if I trust them with anything it is that they will reliably do whatever thing gives nice values on the "Engagement" axis on a graph.

So...either Facebook does in fact randomly reactivate your account, or Facebook is doing some sneaky shit in which you have "agreed" to randomly reactivate your account. They are either betraying you, or they are using dark patterns during account deactivation such that someone who is actively looking for dark patterns is tricked into "agreeing" that they will reactivate it. Either way, it is being reactivated without your consent. Anyone that tells you otherwise is gaslighting you.


[1] Kidding.

On "whitelisting" and "blacklisting"

As a straight white guy from middle-of-nowhere Tory Brexitland I'm sure I am supposed to say something about political correctness gone mad, but this is worth a read and makes some fine points. Upshot:

It's fairly common to say whitelisting and blacklisting to describe desirable and undesirable things in cyber security. For instance, when talking about which applications you will allow or deny on your corporate network; or deciding which bad passwords you want your users not to be able to use.

However, there's an issue with the terminology. It only makes sense if you equate white with 'good, permitted, safe' and black with 'bad, dangerous, forbidden'. There are some obvious problems with this.

I agree.

From now on, the NCSC will use 'allow list' and 'deny list' in place of 'whitelist' and 'blacklist' on our website.

I propose not referring to notional "lists" at all. This will invariably make your writing clearer.

Let's take an example from the article. "An allow list of applications" is clumsy (let alone the alternative form, "an allow listed application"). It is much terser and accurate to refer to "trusted applications" for ones you know to be good, and "malicious" for ones you know to be bad. No lists required! (Adjust the terminology to your use case as required.)

For the example of passwords, of course you only ever check against a list of known-compromised ones; you certainly don't have a list of ones that are safe to use. Again, you can almost always get rid of notional "lists". Some examples:

  • This password is blacklisted 🡒 This password is known to be weak
  • This function checks the given password against a blacklist 🡒 This function checks if the given password is known to be weak

It is fine to refer to lists when there are actual lists; if your program is supplied with or downloads a set of textual rules for allowing & denying access to something, for example. Here again, though, you are discussing an implementation detail rather than what actually happens, which is generally not good form in anything but documentation dedicated to discussing implementation details.

I am reminded of a ticket from a few months ago in the Django project:

We'd like to add aliases for the trans and blocktrans template tags which do not have connotations to the transgender community. An initial proposal would be to add translate and blocktranslate as aliases.

The lazy counter to this would be that "translate" shares the same "trans" root as "transgender", and who is to say that it's only a valid contraction of one of them?

I say "lazy", because the reporter handed the Django a great opportunity for improvement: why pick a tag name like trans when it could cause confusion with something else? Even when there is no scope for confusion, we're not limited to MS-DOS filenames these days (and don't get me started on "i18n"). You can and should use whole English words; {% translate %} makes for better and clearer code than {% trans %}.

You should definitely improve your terminology to be more inclusive - it's a low-effort way of making the world a little bit better. And do use that opportunity to write stronger and more clearly while you are there.