[Mailman-Developers] GDPR

[noskcaJ leahciM]

GDPR  is  nearing  the  last  7  months  of  its  2  year   transitional
implementation  before  becoming  part of the law in EU countries (inc.,
despite Brexit, the UK),  affecting  0.5bn  citizens  together  with  US
enterprises  in under Privacy Shield (replacing Safe Harbour) as well as
enterprises in EEA member countries and, outside of the  EEA,  countries
whose  privacy laws have been assessed for adequacy.  Operators of lists
such as MM are as much called-to-account as are  the  vast  corporations
behind  popular  social media that currently absolve themselves as being
mere publishers.

Below is an initial impact assessment (vs.  MM 2.1.14) of high  priority
impacts  in  bullet-point  form  for immediate consideration based on my
current understanding.  Where changes are required,  they  are  required
for  continued use of MM in EU countries and in adequate countries (inc.
EU-US Privacy Shield) where one or more list members is an  identifiable
EU citizen.

1.  The term consent has a specific meaning within GDPR (i.e.  one of  a
    number  of  lawful  bases  on which personal data may be processed).
    The subscribe web flow and subscribe/confirm email exchanges  should
    be  edited  to  use  the  term "consent" rather than "confirm" where
    appropriate to make that consent explicit.

2.  The term restriction has a specific meaning within GDPR (in  general
    it  means  suspending any use (processing) or disclosure of personal
    data.  Nomail could usefully be renamed  as  "Restriction"  and  the
    Nomail  functionality  extended  made  to  operate  both  ways, i.e.
    restricting  members  from  posting  and  restricting   (suppresing)
    retrieval of a restricted member's details in a list of [subscribed]
    members.

3.  GDPR places strong record-keeping obligations on  data  controllers.
    It   implies   that  audit  trails  of  consent  be  maintained.   A
    per-subscriber report that shows how they were  subscribed,  keeping
    details  of  ip addresses of browser used if by web etc., log of all
    preference changes made  etc.   is  a  Should-Have  requirement.   A
    per-list-report   perhaps  showing  less  detail  (e.g.   method  of
    subscription and time  and  date  of  consent)  is  a  a  Could-Have
    requirement.

4.  GDPR provides that the right of erasure (that has coloquially become
    known  as  the "right to be forgotten) be provided upon request.  In
    addition ot unsubscribing from a list, a list subscriber  Should  be
    able  to  initiate  automated  erasure  from the site archive of all
    posts of and from a given subscriber.

    There seems no reason  for  erasure  to  be  moderated.   Using  the
    existing  password  authentication  or a confirm string, subscribers
    could be  provided  with  the  ability  themselves  to  erase  their
    personal  details  from  the  site,  including  all  archived posts,
    without administrative intervention or incurring the delays inherent
    with moderation.

    GDPR doesn't provide for selective erasure, for example in the  case
    of  a  non-factual,  inflamatory  or libelous post that a subscriber
    wishes to have removed; all-or-nothing will suffice  for  compliance
    with  GDPR.   Erasure  is  required  to  uphold  a  right  so  is  a
    Should-Have requirement.

5.  GDPR enshrines 7  principles  and  8,  legally-enforceable,  rights.
    While  "Privacy by Design and by Default" is not actually one of the
    principles it  is  a  mandatory  approach.   The  default  for  list
    settings should be to

      i)  to close lists, making posting to lists restricted to members;

     ii)  to hide or disguise identities in automatically-added elements
          of list members' posts (e.g.  in "From:");

    iii)  to hide or disguise identities inadvertently disclosed in list
          members'   posts   e.g.    from   quoting   others  etc.   (My
          interpretation is that no risk arises to the operator  of  the
          list  where  member  2 quoting text of member 1 where member 1
          intentionally included their contact details in  a  post,  for
          example  as  a phone number or as "me -at- here"; meaning that
          it  is  sufficient  to  suppres/disguise  headers  and   email
          addresses entered un-disguised by posters)

     iv)  either  to  disallow  retrieval  of  list  members  to  [even]
          subscribed members, or to hide/disguise addresses in retrieved
          lists;

      v)  to archive privately, requiring authentication and and keeping
          records  (logging)  of  to whom information on the archive was
          disclosed;

     vi)  on closed lists (the default), disallow the posting of HTML by
          which  otherwise  members might seek to obtain the identity of
          others through inclusion of web bugs/beacons.