How Not To Manage Email Subscriptions - Apple

As with most tasks in life, there are two paths you can go by - the easy way, or the right way. Sadly, many of us choose the easy way which, in the long run, means more work for us all.

Take, for example, the seemingly dull task of email unsubscription. A developer wants to make it easy for a user to unsubscribe from an email newsletter. They want to place an unsubscribe link at the bottom of an email, a user can click on it, be taken to a web page, then confirm her unsubscribe.

Let us assume - for a moment - that the developer isn't so sadistic as to make the user manually type in her email address. We are left with an interesting problem: how do we tell the website which email address to display?

The easy way is very simple - example.com/unsubscribe?email=sjobs@apple.com

This is bad. Very bad. Let's take, for example, Apple's developer portal.

As you can see - Apple use this anti-pattern when asking developers to unsubscribe from their marketing efforts. There is no requirement to be logged in, no double checking that the user is the owner of the email address, and there is no email confirmation of unsubscription. If a malicious user hits that button....

And that's that.

Apple have deliberately configured their systems in such a way that they - potentially - leak information about subscribers. Or, rather, they let you confirm whether an email address exists on their system.

Knowing that an email address is subscribed to a developer marketing list is useful if you're a spammer - those are the addresses you may want to target - and useful if you're trying to hack in to someone's account - the email used for developer marketing is likely to be the same as their developer account credentials. So, perfect for a spear-phishing vector.

Finally, what happens if your rivals see that you are subscribed to this mailing list? Would removing you - or your boss - from it cause your business any issues?

The Right Way

So, we can hopefully see why the "easy" way causes problems in the long run. What's the right way?

Generally speaking, we want to minimize the damage that any one individual can do while still making it easy to unsubscribe.

Rather than:

example.com/unsubscribe?email=sjobs@apple.com

The email should be given a unique ID which the website can then examine and validate - for example:

example.com/unsubscribe?email=ed263e3881d6ae44d258eda63a1fbda1

If the ID is found in the database, the website can return and display the correct email address. It is impractical for a malicious user to input random unique ID's until they find a valid one.

There is no additional inconvenience for the user, no risk from malicious use, and only a minuscule amount of work for the designer of the system.