[Mailman-Developers] GDPR

[noskcaJ leahciM]

| tl;dr

Too long: The regulation and articles are even longer.

Didn't Read: But you replied none-the-less ;-)

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

There will be installations and use cases that are not impacted. GDPR is
European law and failing to comply with it is not an option.  It's generally
recognised that for all impacted, work may be required to attain compliance.
Awareness-raising should not, however, result in messengers being shot.

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

Art.7, Rec.32,42.  Do not require that the word "consent" be used rather than
"confirm".  However, consent is one of the lawful bases and being unambiguous
that consent is being requested seemed a reasonable suggestion for the effort
required to make the change.

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

The separate nomain and moderation settings can be kept, along with their
traditional meaning.  However Art.18 and particularly Rec.67. imply that
a single "restriction" setting (that sets nomail + moderation) that shows
as "restriction" (and without the reverse implication) is required.

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

Please see clarification/compromise above.

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

Rec.13 to Art.30 provides for national for organisations under 250 persons.
Even Rec.82 does not refer to explicitly to "audit" trails so this need not
be over-egged.  However it does seem reasonable that MM maintain records of
the date and time of subscription/un-subscription and method (email/web).  A
record of subscription/un-subscription can be had as it stands from emails
notifying the list manager; it's just that this isn't as convenient.

| 
|  > 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. [Following text moved to below]

Art.17 (b) allows this right to be asserted at a whim; however it does refer
to taking account of available technology and the cost of implementation and
requiring (only) "reasonable" steps (which was reflected in what was said
below).

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

Where it is, then it should be provided.

| This also raises hairy issues about authentication.

The existing authentication should be good-enough.  It isn't envisaged that
authentication be improved *just* to protect against other people deleting
a subscriber's posts.

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

Please see above proportionate and reasonable measures.

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

Fortunately, anti-spam measures hapilly collide with "Privacy by Design and
by Default" -- see also below.

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

What was referred-to primarily was automatically-added elements.

Some effort to prevent address-harvesting is performed by other mailers/forum
software accepting that its scope goes beyond owned, automatically-added
elements to envelope and body owned by the subscriber.  Mailers/forum software
that does that already helps subscribers not-to leak personal data.  That
surely is the point rather than some technical distinction between which
elements are owned by whom.

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

Some already do this, but don't try to go-beyond replacing '@' signs etc.

There is precedent.  The practice is already accepted and collides with the
interests of anti-harvesting.

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

Changing the default is consistent with "Privacy by Design and by Default".
Art.25.

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

The reader's privacy is a valid counter-argument.  However data breaches
(think Equifax) are reportable within 72 hours to authorities (Art.33) and
possibly to those affected (Art.34).  It would be helpful to know to whom
data that should not have been disclosed had been disclosed.  In the absence
of information about accesses to an archive page before it was taken-down
that disclosed data that it should not have, and assuming the private archive
members and list members coincided, one would have to assume the entire list.
As this still allows the controller to give a reasonable report of to whom
data has been disclosed, your counter-argument should be accepted.

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

The existing detection measurement is proportionate and reasonable.  What
was said was that for closed lists, that the refuse-HTML measure be invoked
by default by virtue of the list being designated as closed.  No additional
difficult technology or patches required.

| 
| Steve

leahciM