[Mailman-Developers] GDPR

[Stephen J. Turnbull]

tl;dr I don't think this is worth thinking about until we get a
request from users who actually are threatened with liability for
their Mailman installations.

Suggestions from where we can obtain funding to do this stuff?
The harder parts are non-trivial.

noskcaJ leahciM writes:

 > 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.

I don't think this is something we should do blindly.  If a list owner
or site affected by GDPR wants to consult a lawyer and contribute that
knowledge, I think we should follow up with changes, but I can see
issues that would involves potential liability for our users if we use
a word that has legal meaning and our procedures aren't up to the
standard.

 > 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

No, it can't.  I see no good reason to include both nomail and privacy
protection in a single option.  Nomail is very useful without being tied
to privacy options.

 >     Nomail  functionality  extended  made  to  operate  both  ways, i.e.
 >     restricting  members  from  posting

This is not what nomail does.  That's moderation.  Nomail prevents a
subscriber from receiving posts, and is primarily intended as a user
option, not an admin option.

 >     and restricting (suppresing) retrieval of a restricted member's
 >     details in a list of [subscribed] members.

There's a separate user option for this, IIRC, as well as a global
option restricting availability of lists to the list and site admins.
I don't see a strong argument for combining these options, or
combining retrieval suppression with moderation.

 > 3.  GDPR places strong record-keeping obligations on  data  controllers.
 >     It   implies   that  audit  trails  of  consent  be
 >     maintained.

Patches welcome.  I don't think this is reasonable to ask of most
sites at present, and the security implications of "audit"
(identifying and authenticating users and crypto signing said "trails"
etc) seem daunting.

 > 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.

This is simply not feasible to guarantee in Mailman 3, since we
deliberately separated the archiver and sites (even individual lists)
may supply their own.  This also raises hairy issues about
authentication.

 >     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,

This is not necessarily under control of Mailman.

 >     including all archived posts, without administrative
 >     intervention or incurring the delays inherent with moderation.

I don't think the existing authentication features are sufficiently
reliable for this.  Specifically, I would imagine that the rights
embodied in GDPR inhere in *human persons*, not in email mailboxes.
Yet in fact in all current authentication done by Mailman only
mailboxes are identified, not persons.

 >     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;

This is something we should do anyway, since restricting posting to
members is generally a regrettable but necessary spam-control
practice.

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

That's not reasonable.  The list does not "own" or add From (or To or
Cc, for that matter); the author does.  In the general case, identity
can be concealed by the poster if they want to by acquiring an
additional mailbox.  Some effort to prevent address harvesting from
archives by spammers is reasonable, but hiding identity is another
matter entirely.

 >     iii)  to hide or disguise identities inadvertently disclosed in list
 >           members'   posts   e.g.    from   quoting   others  etc.

That's not reasonable.  As above, we don't own the text, the poster
does.  Again, discouraging harvesting is reasonable, but hiding
identities in text is not a reasonable requirement.

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

Options are present.  Changing defaults if necessary is not a big deal.

 >       v)  to archive privately, requiring authentication

I don't like this (in my use cases, public archives are usually
desirable), but it might be reasonable as a default.

 >           and and keeping records (logging) of to whom information
 >           on the archive was disclosed;

This is unreasonable.  Of course HTTP accesses are logged, and with
access limited to authenticated subscribers the relevant list user is
known, but in general there is no *identification*.  Furthermore, this
is invading the *reader's* privacy in any case where personal
information intended to be closely held is not 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.

We already have an option to refuse HTML.  But users don't like that.
Accurately restricting what can be posted sounds difficult to me, but
patches welcome.

Steve