Wandering Thoughts archives

Why LinkedIn's 'you must join to unsubscribe' is evil

Recently I got a '<X> would like to add you to their professional network' email message from LinkedIn (from what I'm certain is a spammer). I'm not a LinkedIn user, so in an excess of optimism I went to the 'unsubscribe' link in the email. And, well, let me quote my own Tweet summarizing things:

@thatcks: I see. To get LinkedIn to stop emailing me connection invitations, I have to actually join LinkedIn. That makes those emails clear spam.

Perhaps you think that this behavior on LinkedIn's part is relatively harmless and no big deal. After all, all I have to do is join, right?

There are two things that make this wrong and one thing that makes this actively evil. Let's cover the two things first. To start with, this is not actually an unsubscribe link. 'Unsubscribe' links that don't actually function are known by many names, including 'bait and switch'. They are never a friendly act; they demonstrate that the sender intends to throw obstacles in your way because they very much object to you unsubscribing and want to make it hard.

Beyond that, well, 'fool me once, shame on you; fool me twice, shame on me'. Why should I believe or trust that LinkedIn will let me actually (permanently) unsubscribe if I sign up? They've already lied once; I'm sure they can find a way to lie again, either now or in the future when it's convenient to them. As above, they've already demonstrated that they are not actually interested in letting people unsubscribe.

But all of that pales next to the actively evil bit: to sign up for LinkedIn, I must agree to their Terms of Service. It is absolutely guaranteed that LinkedIn's ToS contains objectionable things that no one in their right mind would agree to if they had a choice, because essentially all terms of service for large websites contain such terms. And it's all but certain that agreeing to their ToS is a binding legal agreement. Evil things in Terms of Service are usually excused with the rubric 'well, if you don't like them don't use the service, it's being offered for free'. Here I have no interest in using the service, I just want to unsubscribe. Effectively LinkedIn is giving me no choice; it is agree or suffer their continued spam.

Fundamentally what has happened here is that LinkedIn has turned unsubscribing from a right into a privilege, extended on LinkedIn's terms and at their whims. I do not have the 'right' to unsubscribe from LinkedIn's email, or they would have just done so with no fuss or muss. Instead I have only the privilege to ask to (maybe) be unsubscribed, under whatever terms LinkedIn feels free to dictate.

This is no genuine unsubscribe option. This is a sham, and I hope that recent Canadian legislation winds up seeing LinkedIn called on this.

(Yes, yes, as evil goes it is very small evil on the global scale of things.)

Another piece of my environment: running commands on multiple machines

It's my belief that every sysadmin who has a middling number of machines (more than one or two and less than a large fleet) sooner or later winds up with a set of tools to let them run commands on each of those machines or on subsets of those machines. I am no exception, and over the course of my career I have adopted, used, and built several iterations of this.

(People with large fleets of machines generally never run commands on them by hand but have some sort of automated fleet management system based around Puppet, Chef, CFEngine, Salt, Ansible, or the like. Sometimes these systems come with the ability to do this for you.)

My current iteration is based around simple shell scripts. The starting point is a shell script called machines; it prints out the names of machines that fall into various categories. The categorization of machines is entirely hand maintained, which has both problems and advantages. As a result the whole thing looks like:

mach() {
  for i in "$@" do
    case "$i" in
    apps) echo apps0 apps1 apps2 apps3 testapps;;
    ....
    ubuntu) echo `mach apps comps ...` ...;;
    ....
    *) echo $i;;
    esac
  done
}

mach "$@" | tr '\012' ' '; echo

(I put all of the work in a shell function so that I could call it recursively, for classes that are defined partly in terms of other classes. The 'ubuntu' class here is an example of that.)

So far we have few enough machines and few enough categories of machines that I'm interested in that this approach has not become unwieldy.

(There is also a script called mminus for doing subtractive set operations, so I can express 'all X machines except Y machines' or the like. This comes in handy periodically.)

The main script for actually doing things is called oneach, which does what you might think: given a list of machines it runs a command line on each of them via ssh. You can ask it to run the command in a pseudo-tty and without any special output handling, but normally it runs the command just with 'ssh machine command' and it prefixes all output with the name of the machine; you can see an example of that in this awk-based reformatting problem (an oneach run produced the input for my problem). Because I like neat formatting, oneach has an option to align the starting column of all output and I usually use that option (via a cover script called onea, because I'm lazy). The oneach script doesn't try to do anything fancy with concurrent execution or the like, it just does one ssh after the other.

Finally, I've found it useful to have another script that I call replicate. Replicate uses rsync to copy one or more files to destination machines or machine classes (it can also use scp for some obscure cases). replicate is handy for little things like pushing changes to dotfiles or scripts out to all of the machines where I have copies of them.

As a side note, machines has become a part of my dmenu environment. I use its list of machines as one of the the inputs to dmenu's autocompletion (both for normal logins and for special '@<machine>' logins as root), which makes it really quick and convenient to log into most of our machines (this large list of machines is part of the things I hide from dmenu's initial display of completion in a little UI tweak that turned out to be quite important for me).

Note that I don't necessarily suggest that you adopt my approach for running commands on your machines, which is one reason I'm not currently planning to put these scripts up in public. There are a lot of ways to solve this particular problem, many of them better and more scalable than what I have. I just think that you should get something better than manual for loops (which is what I was doing before I gave in and wrote machines, oneach, and so on).