Double opt-out, legitimate interest and GDPR etc

Bloke · 2020-10-30 16:29:06

Thinking in terms of subscribing to content, I presume that double opt-in is pretty much mandatory now, right? I’m putting together some background info to help me build a flexible subscription plugin for Txp (bab/mem_postmaster but way better) and making the assumption that double opt-in is the de facto standard for a) subscribing, and b) when altering a subscription to different channels.

Following on from this:

Are there any situations anyone can think of where I need to offer the ability to override this default and allow single opt-in? Or should double opt-in be enforced?
If someone unchecks all the boxes (or hits a button to clear them, or clicks a dedicated unsubscribe link in an email/site) and submits it – i.e. intent to unsubscribe – what are your feelings on having to confirm this action (double opt-out)? Is this required by law anywhere? Is it likely to become law anywhere? Should it be single opt-out by default but with an option to enable double opt-out? i.e. your unsubscription is only actioned if you follow the confirmation link.
What about an email to confirm your unsubscription has been successful, either a result of the single opt-out or (perhaps overkill) after you’ve actioned it from a double opt-out? Are there any laws being broken anywhere if an email such as “Sorry to see you go. If you’ve unsubscribed by mistake or something, then you can easily resubscribe or alter your interests here… {link}” is sent out? These sort of messages often contain disclaimers like “it might take up to N days for your subscription to be cancelled, so don’t sue us if you receive something within that time”. Is that a reasonable thing to send out so people have a record of the company policy on unsubscriptions, and/or confirmation that your request has been actioned, or is that information only usually displayed on the website form/newsletter footer smallprint. Thus, if the user wants a record of the action, they’ll need to take a screenshot?
In layman’s terms, what is “legitimate interest” and does it apply to any of the above? I’m so far baffled by a lot of the legales info I’ve tried to comprehend. I’ve seen a lot of cookie notices recently have two sliders per ‘use’: one for “alow this content yes/no” and a separate one for “legitimate interest” of this content. I’m unsure what that means and just routinely set these secondary sliders to ‘no’ (except on a site the other day where four ‘legitimate interest’ sliders were shown, but only two of the sliders could be toggled. The remaining two just slid back to ‘yes’ when I tried to alter the setting *shrug*).

In relation to the above, is sending out a ‘sorry to see you go’ email or presenting a ‘please tell us why you left, perhaps you’d like to reconsider and subscribe to these channels instead’ message classed as ‘legitimate interest’? Is it permissible by law? Or, once you’ve opted out, are we in legal hot water (everywhere in the world?) to even send out such a confirmation message?

Finally, what are your thoughts on companies that send out these ‘So long, and thanks for all the fish’ messages? Do you like knowing that your (single/double opt-out) request has been actioned, instead of being unsure whether it’s been passed onto the invisible typewriter in the cloud? Or does it annoy you to receive follow-ups like that because “I’ve unsubscribed, dammit. Why are you contacting me again”?

Just trying to set up sensible defaults and offer some potential flexibility for people to set the plugin up in various ways. But don’t want to bother going to the trouble of implementing something only to find it’s illegal or frowned upon as a practice!

Thanks for any insight.

Last edited by Bloke (2020-10-30 16:32:18)

colak · 2020-10-30 16:57:16

Are there any situations anyone can think of where I need to offer the ability to override this default and allow single opt-in? Or should double opt-in be enforced?

Off line registrations. We have some subscribers who subscribe to our newsletter by signingg a form in our space. This feature should exist for site admins.

What about an email to confirm your unsubscription has been successful, either a result of the single opt-out or (perhaps overkill) after you’ve actioned it from a double opt-out? Are there any laws being broken anywhere if an email such as “Sorry to see you go. If you’ve unsubscribed by mistake or something, then you can easily resubscribe or alter your interests here… {link}” is sent out?

Marketing overkill:) An on site message, which could appear after a user unsubscribes could say what the site owner wishes to say.

In layman’s terms, what is “legitimate interest” and does it apply to any of the above?

It becomes too complex I think. There is the “well meaning interests,” like wanting the area where you live to be peaceful and quiet, but in the case of newsletters, there is no such thing in question.

In relation to the above, is sending out a ‘sorry to see you go’ email or presenting a ‘please tell us why you left, perhaps you’d like to reconsider and subscribe to these channels instead’ message classed as ‘legitimate interest’?

This is a good idea but it could also be achieved with a form after the unsubscription. It is less invasive. Something like the example in com_connect thanks_form="form_name".

And a question.

Will we be able to import our users and lists from postmaster?

Bloke · 2020-10-30 17:09:03

colak wrote #326608:

Off line registrations… This feature should exist for site admins.

Sure. That’s handled by being able to add subscribers by hand from the admin side. I’m talking about front-end requests, sorry if it wasn’t clear.

An on site message, which could appear after a user unsubscribes could say what the site owner wishes to say.

Noted. Along with the ‘thanks_form’. You’re right, that’s the correct place for ‘sorry to see you go’ and ‘please please reconsider by subscribing to these channels instead’ begging. Simpler to implement too!

Will we be able to import our users and lists from postmaster?

Of course, for the names and lists and mappings. But I don’t know how compatible the remainder of the table columns will be at the moment. mem_postmaster has a fixed set of 20 custom fields hard-coded for each subscriber. I’m not planning to do that in the same way.

Ideally, I’d like Txp’s unlimited custom fields to handle this, rather than being part of the plugin furniture. The planned custom fields implementation is flexible enough to be used by core and plugins who need supplemental data. But since that’s not in core yet, I don’t know how to handle it. Maybe this’ll give me/us impetus to actually finish it and push it to core :)

colak · 2020-10-30 18:08:05

Beyond lists, some fields will be good in order to encourage subscriptions but also to track them. I understand that the first 3 will be standard, the 4th helps to know, and sometimes cross check the subscriber, and the 5th to track when they subscribed.

Name
Surname
email
Website
Date of subscription.

I know this is not GDPR compliant but an option that indicates their IP, even in the email sent to the admin in order to cross check it in spam lists. ie. if we could use <txp:com_connect_serverinfo name="REMOTE_ADDR" label="IP number" />

Bloke · 2020-10-30 19:24:07

Subscription date is definitely going in. Very handy for purging lists or sending out “are you still interested?” messages.

Can’t you do the IP check already like that via body_form? It’s up to you what you collect in the admin email as long as you tell people your intent, but I’d be reticent to store that in the database. That does mean the IP goes to the user as well, I suppose. Maybe we should figure out a way of flagging certain fields as only going into the admin email instead of the customer email? In com_connect I mean, not postmaster.

Options include an attribute to ‘show’ fields in the various emails, e.g. show="admin" would stop that field being displayed in the customer email when it’s parsed for tags. And we could run the body form through a second time to create the admin email, if it’s required.

Alternatively, permit a pair of forms to be created – one for ‘customer’ and one for ‘admin’.

Finally, and this is the one I’m leaning towards, a conditional tag available inside body_form that you could wrap around fields or content you do/don’t want to be displayed by certain types of message.

This can also extend to ‘plain’ and ‘html’ versions of content so you could create a single email template but omit markup if the current message building step is “plain”. Essentially we read the message form twice and the conditional responds differently each time to build the messages.

Last edited by Bloke (2020-10-30 19:26:11)

colak · 2020-10-31 06:55:43

Bloke wrote #326612:

Subscription date is definitely going in. Very handy for purging lists or sending out “are you still interested?” messages.

Can’t you do the IP check already like that via body_form? It’s up to you what you collect in the admin email as long as you tell people your intent, but I’d be reticent to store that in the database. That does mean the IP goes to the user as well, I suppose. Maybe we should figure out a way of flagging certain fields as only going into the admin email instead of the customer email? In com_connect I mean, not postmaster.

Options include an attribute to ‘show’ fields in the various emails, e.g. show="admin" would stop that field being displayed in the customer email when it’s parsed for tags. And we could run the body form through a second time to create the admin email, if it’s required.

Alternatively, permit a pair of forms to be created – one for ‘customer’ and one for ‘admin’.

Finally, and this is the one I’m leaning towards, a conditional tag available inside body_form that you could wrap around fields or content you do/don’t want to be displayed by certain types of message.

This can also extend to ‘plain’ and ‘html’ versions of content so you could create a single email template but omit markup if the current message building step is “plain”. Essentially we read the message form twice and the conditional responds differently each time to build the messages.

Since we started using postmaster, we only had one person reporting us for spam. I found the email of his registration and sent it to webfaction as a proof. Thankfully his IP was static, and it was the same IP he used to report us. I understand privacy concerns but at the same e time it is also about the protection of the newsletter managers.

Some questions

Will the new plugin have any login for subscribers which would help them see/edit the lists they can subscribe to? If there will be such a thing, the IP could be made visible there for them. Subscribed on [Date] from [IP].
At NeMe, although we have a lot of lists (due to some server restrictions a few years ago), we basically use 3.
1. Default (send to all)
2. Cypriots (for locally relevant announcements)
3. us (sends test emails to me and my wife for final corrections)

By default everybody is registered in the default list, and I manually add the subscribers in the Cypriot one, based on their name, and/or IP.

Bloke · 2020-10-31 10:32:44

colak wrote #326618:

I understand privacy concerns but at the same e time it is also about the protection of the newsletter managers.

That’s a good point, hence I like the idea of managers being able to add the field to the admin-sent sign-up message themselves. It’s the ultimate opt-in for managers, without compromising the plugin by always collecting IPs and storing them. If you need the feature, collect the data and keep the email.

I’m not totally averse to storing IPs inside the plugin/database, I’d just rather not.

Will the new plugin have any login for subscribers which would help them see/edit the lists they can subscribe to?

This is interesting. As I may have mentioned, my plan is to make newsletter management more modular, in the sense that I’d like to harness the power of Textpattern and com_connect to permit very granular subscription channels.

In broad strokes, imagine allowing someone to subscribe to sections and/or categories. You could send out a single article inside a ‘gardening’ section and anyone who has subscribed to that ‘channel’ will get it. On a martial arts blog, you could write an article with a category of ‘judo’ and send it. Anyone who subscribes to that category will receive it.

Similarly, you could build a /newsletter/2020/10/31/october-roundup article, comprising a lot of other articles and send that newsletter out. When sending, each subscriber’s channels are checked and the content they don’t want is filtered out, so they only get the articles they want inside the newsletter (perhaps cached, so if more than one subscriber has the same subscription settings, the plugin doesn’t do unnecessary work).

If they click through to view the article in the browser, the same thing happens because their channels are tacked onto the URL and the /newsletter section can be coded smart enough to filter them out.

The key thing is that very little of this is native to the plugin. It’s just the way you set it up inside your site that makes the magic happen. My aim is to expose some tags that’ll make building newsletter and subscriber channels easy in your templates. Plus some admin goodness for building newsletter master articles and managing lists/subscribers. Everything else is up to your imagination.

Going back to your question, each user has a unique, long token that identifies them (a UID). This is currently used in mem_postmaster solely for unsubscribing. But there’s no reason why it can’t be used as a means of setting/altering your subscription channels. My theory:

You write a subscription management (com_connect) form using any tags that plugin offers, plus some from the newsletter plugin to help you iterate over a subscriber’s channels (a.k.a. lists). You could add ReCaptcha, third party integration (MailChimp, phplist.org, whatever), business logic in your own tables, anything you want here via com_connect modules to do whatever you need.
If the URL contains no UID then a conditional tag can help you switch between modes in your form. With no UID, it becomes a subscribe form. Shows the available channels as checkboxes or dropdowns or whatever you want, an email address field and a Subscribe button. An email is generated with their intent (double opt-in) and if they action it, the same subscribe form is called with a token in it that confirms their subscription.
If the URL contains a UID, the conditional tag can trigger resubscribe or unsubscribe mode. The UID is embedded as a hidden field in the form so when submitted, it affects that user’s account. You can, again, list all the channels available, with the ones related to this user displayed as checked (or whatever) and thus the person can change their preferences and resubmit to alter them. They receive an email with ther intent (double opt-in) and if they action it, the same subscribe form is called with a token in it that confirms their subscription.
If they untick everything (you could offer a single button to clear all checkboxes as a convenience if you wished) and submit, it’s an ‘unsubscribe’ action. That would trigger immediate deletion of their subscriber row as well.

So there’s no need for logins or anything messy like that because the UID is unique and random. The subscription handling and the way you manage it is entirely down to you and your clever use of the plugin tags to build your subscriber management form. If you want to expose the user’s subscription date, do so here. You won’t be able to display their IP unless we capture it in the database, though.

It might even be possible to visit a /newsletter article and pass the UID here too. So instead of loading the URL with parameters, if a UID is present, the on-the-fly newsletter viewing template can look up the user’s subscription info via the UID and filter the articles accordingly.

Bottom line is that I’m planning for the plugin to provide tools to build one subscription form, or one per section, or however you want to manage it. I can provide examples in the plugin help of course, but it’s up to you how you do things.

As a further convenience, if you visit the subscription management form without a UID (e.g. you’ve lost the original email with your UID in it), then you can simply enter your email address and check some list/channel boxes to trigger an email to complete the process, or submit the form with nothing checked and be removed from the list (i.e. delete your subscriber row and list assignments).

This is partly the point of my original post. Anyone could visit the subscription management form and put someone else’s email address in and unsubscribe them and the person who has been unsubscribed will have no knowledge of this action. They’ll know if someone else tries to sign up on their behalf, because they’ll receive an email asking them to opt in. But they won’t know if someone unsubscribes on their behalf because the ‘sorry to see you go’ is part of the on-web experience (the thanks_form).

So in that regard, a ‘confirmation’ email that you’ve unsbscribed is a good thing. It guarantees that if someone (maliciously or not, perhaps a one character typo) unsubscribes you by mistake, at least you’ll get to hear about it and can do something about it.

But at the same time, if you’ve unsubscribed yourself, then a confirmation email does seem overkill and intrusive. Tricky. Thoughts welcome from anyone.

At NeMe, although we have a lot of lists (due to some server restrictions a few years ago), we basically use 3.

Sorry, is there a question here? :)

colak · 2020-10-31 11:26:38

Sorry, is there a question here? :)

Yes:) Will we be able to control who goes on which list? ie we could have all subscribers, subscribing to the default list, and then we can add them to another one if appropriate. Will this be possible?

Bloke · 2020-10-31 11:40:16

colak wrote #326624:

Will we be able to control who goes on which list? ie we could have all subscribers, subscribing to the default list, and then we can add them to another one if appropriate. Will this be possible?

Of course. You can add as many subscribers to as many different channels as you like.

phiw13 · 2020-10-31 12:01:29

Bloke wrote (among many other interesting things which I need to ponder before saying anything):

So in that regard, a ‘confirmation’ email that you’ve unsbscribed is a good thing. It guarantees that if someone (maliciously or not, perhaps a one character typo) unsubscribes you by mistake, at least you’ll get to hear about it and can do something about it.

But at the same time, if you’ve unsubscribed yourself, then a confirmation email does seem overkill and intrusive. Tricky. Thoughts welcome from anyone.

Here in Japan, one (popular) mailing list service – similar to mail chimp – includes an unsubscribe link in the mail (something like: mailing-list-name.mailservice.jp/unsubscribe?UID) that brings you to an unsubscribe page, with a basic form (a button… that is it). You then receive a confirmation mail with a link to re-subscribe and the bare minimum marketing junk. Even if you did the whole thing yourself, it is a good thing – a positive feed-back that the whole action went through correctly.

Yahoo Japan’s service requires you to log in (the lists are part of your account) and they send you a confirmation message (full of marketing junk, IIRC, it is Yahoo Japan after all). Again, positive feedback. Neither of the two services send you follow-up mail after that.

Bloke · 2020-10-31 13:43:27

Great info, thanks phiw13. So it seems in Japan at least, that sending a confirmation email after unsubscribing is okay and doesn’t contravene any laws. That’s enough of a reason to consider how we might implement it – even as an optional workflow. The positive feedback loop it creates is a worthy expenditure of effort.

Not sure how to do that yet but I’ll play with some ideas.

colak · 2020-11-01 08:39:28

I know I already said that opt-out confirmation is unnecessary but the method in Japan, /unsubscribe?UID, can only work if it is coupled with a confirmation opt-out email and another link, such as /unsubscribe_confirm?UIDhash.

As many of us rely on email forwarding, those kind of links can easily, knowingly or unknowingly, be abused. A hash representing the UID of the confirmation opt-out might be safer.

Textpattern CMS

Textpattern CMS support forum

#1 2020-10-30 16:29:06