RE: GDPR Issues

 
From: "Doug Levey douglevey@PROTECTED [Dada Mail Developers]" <dadadev@PROTECTED>
In-Reply-To: (no subject)
Date: May 8th 2018

From:

Hi Justin from GDPR land!

I have been doing a mass of stuff with GDPR and I would say that it does need taking seriously, but on the other hand I would encourage you to make any changes from the perspective that requirements need to be highlighted to the list owner/maker when setting up The reason I say this is that I think you run the risk of busting a good product trying to cater for things that can only be implemented by the list owner/maker setting up Dada Mail

Example : The list owner must display or make accessible their Privacy Policy at point of consent Be that through a link or the actual text or maybe a downloadable document, the requirement is for consent to be 'informed' and that can only happen if the user has (theoretically) read the Privacy Policy Consent needs to be via a physical or specific action (signature/tick box etc ) and not implied (presumed consent - 'by using this website you agree ' is a no-no)

So my suggestion for this example would be to think in terms of having features such as being unable to complete subscription to a list until the consent check box is marked and then the Dada Mail database records that as a field only displayed to the list owner

Once consent is received, the importance shifts to needing to provide a means to be 'be forgotten' which should be no more complicated or obstructive than to give consent So again a check box(?) or an unsubscribe request

On another point, while there are things that certainly are becoming dis-allowed under GDPR, much remains hinged on each list owners Privacy Policy The policy has to include certain things such as the eight individual rights and which of the four permissible lawful reasons for holding data you are depending on (consent being the first and contract being the second - if any Dada Mail people charge a subscription fee or provide the mailing list as part of a wider membership this may be relevant) But the list owner/maker has control over the detail of the reasons and the timescales such as for how long personal data is held after clicking unsubscribe - in case of re-joining) The point being, if you have a published policy that the user agrees to, then as long as it doesn't limit or breach the individual's rights or not have a legal purpose, then in simple terms you are basically OK

So again my suggestion would be to develop Dada Mail in such a way as to include a process that walks through a multi-choice routine upon setting up a list whereby a standard paragraph or one of your own can be inserted Only when completed can the list be created

On this basis I can't agree that the profile fields need canning - if the user has consented then I cannot see why they wouldn't be fine AS LONG AS the Privacy Policy outlines the purpose for holding them, how long for and how they may be used beyond the individual's own use (if at all) Again this is something I don't think you Justin can control in every instance of Dada Mail So the better way would be to flag it as I have suggested above or by similar means

What would also be practical for list owner/makers would be a dedicated permissions screen containing ID, email, username, date of permission, date of permission withdrawn and a confirmation routine to ensure all personal data for any particular account is deleted (you would keep the date of permission withdrawal and a basic identifier so you can prove you have acted if asked) This last point is important withdrawal of consent does not automatically mean that you have to stop I mentioned earlier the possibility of contract You only have to stop including an individual who withdraws consent if that is the legal basis you depend upon So, if your Dada Mail list comes as part of subscription or other membership for example, then removal of consent alone may not require you to stop Similarly once someone has withdrawn consent, the list owner/maker is compelled to delete the data, but would need to retain something (date, list member number?) to demonstrate deletion

It would also be practical for reminders to list owners to be available I have a closed list where profiles are not used and users may cross-post to each other The list has an administrator who controls the data and it would be that person who would have to respond to any request for confirmation of data being held within 30 days So an alarm/countdown system may be of some practical use to list owners

Complaints requests, withdrawals all need to go to a specifically identified person (usually the data controller) which should be identified in the Privacy Policy Again something that can be templated

I will leave it there for now for fear of boring everyone to death! But my overall point is to encourage thinking about introducing compliance tools rather than hacking lumps out of the programme Although Dada Mail needs to meet the principals of GDPR compliance, it will always be the list owner/maker who is responsible That is why gun companies do not get sued in murder cases

All best,

Doug

-----Original Message----- From: dadadev@dadamailproject com dadadev@dadamailproject com Sent: 08 May 2018 02:00 To: Dada Mail Developers Subscriber douglevey@PROTECTED Subject: [dadadev] GDPR Issues

From: justin@dadamailproject com

Howdy everyone I'm actively tackling the GDPR monster It's a big issue, and I'm taking it very seriously I know some of you have questions about GDPR and Dada Mail Boy do I have some too

Right now, I'm working on the "record of consent" part of all this, and also just what constituted "consent"

So good part:

Dada Mail, since way back in the day, has kept records on things like requests to subscribe, confirming subscriptions, unsubscriptions - stuff like that That information can be teased into a better format, so that it's documented a little nicer I can write something that migrates that data over really easily That way, when people request this data, you can show it to them Easy!

So, if you're running a closed-loop opt-in mailing list (rather than just subscribing someone straight up WITHOUT confirmation), you're probably in a good place I think The idea of, "consent" is not an easy pill to swallow

What I'm trying to figure out is, if clicking the confirmation link in the confirmation email is enough "consent" under GDPR If so, things will be pretty easy in this brave new world! If not, it's going to be a little tougher, unfortunately

Any opinions about that, out there?

Unfortunately, I'm not a lawyer, and don't have a hot-shot legal team, myself :(

Right at this moment I'm reading this (although I've read more on GDPR than what's in the Simulacrum, that's for sure!)

https://litmus
com/blog/5-things-you-must-know-about-email-consent-under-gdpr

Where they give an example of granting consent with a double-opt-in form (that's the same as what I'm calling closed-loop opt-in)

Moving forward, it would behoove us to have a checkbox for each of the specific things that we'd like our subscribers to grant "consent" for To speed this along, this may be something pretty simple like,

"I give my consent to occasionally email me with news and announcements about your business" (link to privacy policy)

(roughly) and then allow customization per list from there (of course this initial one CAN be customized, as well)

Removing consent is basically unsubscribing from a list So that one's easy, too The change for unsubscription is the option to unsubscribe from ALL mailing lists at the same time

Some bad news:

Profile field information is one of those things that really needs consent on what you're going to do with it So, to be GDPR clean, you can't use them For anything That may affect some/a lot of people

Things like using email addresses for tracking purposes is another thing you'll need consent for (I think?) So, I'll be disabling that on new mailing lists I can't see a problem with tracking anonymous data, so we can still do that, I guess!

Anyways, just a start Floor is open for more questions/answers/discussion

Please, feel free!

--

Justin J: Lead Dadaist url: http://dadamailproject com email: justin@dadamailproject com twitter: @dadamail skype: leaddadaist

Dada Mail Announcements: http://dadamailproject com/cgi-bin/dada/mail cgi/list/dada_announce/

--

  • Post: mailto:dadadev@dadamailproject com

  • Manage Your Subscription: http://dadamailproject com/cgi-bin/dada/mail cgi/profile_login/douglevey/mind2design co uk/

  • Unsubscribe http://dadamailproject com/cgi-bin/dada/mail cgi/t/REMOVED/


This email has been checked for viruses by Avast antivirus software https://www avast com/antivirus

  • This mailing list is a public mailing list - anyone may join or leave, at any time.
  • This mailing list is a group discussion list (unmoderated)
  • Start a new thread, email: dadadev@dadamailproject.com

This is the developer discussion mailing list for Dada Mail.

If you are just looking for support Dada Mail, consult the message boards at:

https://forum.dadamailproject.com

Documentation for Dada Mail:

https://dadamailproject.com/d

Specifically, see the Error FAQ:

https://dadamailproject.com/d/FAQ-errors.pod.html

To post to this list, send a message to:

mailto:dadadev@dadamailproject.com

All subscribers of this list may post to the list itself.

Topics that are welcome:

  • Constructive critiques on the program (I like, "x", but, "y" needs some work - here's an idea on how to make this better...)
  • Bug/Error reports
  • Bug fixes
  • Request For Comments on any changes to the program
  • Help customizing Dada Mail for your own needs
  • Patches
  • Language Translations
  • Support Documentation/Doc editing, FAQ's, etc.
  • Discussion of any changes that you would like to be committed to the next version of Dada Mail -

Dada Mail is on Github:

https://github.com/justingit/dada-mail/

If you would like to fork, branch, send over PRs, open up issues, etc.

Privacy Policy:

This Privacy Policy is for this mailing list, and this mailing list only.

Email addresses collection through this mailing list are used explicitly to work within this email discussion list.

We only collect email addresses through our Closed-Loop Opt-In system.

We don't use your email address for any other purpose.

We won't be sharing your email address with any other entity.

Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.

All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.

All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.