[Mailman-Developers] GDPR

[Stephen J. Turnbull]

noskcaJ leahciM writes:

 > | tl;dr
 > 
 > Too long: The regulation and articles are even longer.
 > 
 > Didn't Read: But you replied none-the-less ;-)

I read EVERYTHING.  Above is advice to my readers: "I read, so you
don't have to". ;-)

I feel sorry for anyone who hangs out in places where "executive
summary" is not the normal semantics of "tl;dr"!

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

Of course failing to comply is an option.  Whether that leaves our
European users with the option to use Mailman is another matter.

 > Awareness-raising should not, however, result in messengers being
 > shot.

I took aim at the message, which is based on legislation that seems to
be difficult to comply with, not at the messenger.

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

If and when we comply, "this is fine".  I worry that it looks like an
easy change we could do now, but until we are in compliance, which I
would suppose includes making it clear at subscription time what the
users are "consenting" to, it's a bad idea.  At minimum it's
unethical, at worst there could be legal liability if users thought
they were "consenting" to a GDPR-compliant list configuration.  No?

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

I have no idea what that means?  As implemented in Mailman, "nomail"
means the list functions as usual but the user gets no mail, and
"moderation" means the list functions as usual but the user can't
post.  Neither protects the user's private data in any way that I
understand.  Could you explain what is mandated here again?

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

You miss the point.  We don't care what the law mandates, except
insofar as our users do.  Our responsibility is to our users (the list
admins of several flavors) and to their users (the subscribers and
posters).  Given the guarantees the law describes as its goals, if we
say we comply with the law, our users will expect us to implement it
as *they* want, not to whatever the minimal level the law prescribes.
(Of course if the minimal level exceeds what users expect, then we
have to do it anyway, but that's unusual in my experience.)

 > Please see above proportionate and reasonable measures.

Nothing about GDPR is proportionate or reasonable in the context of
email and mailing lists.  GDPR fails both on grounds of what is
reasonable to implement in email, and on grounds of actually
protecting users' privacy, as far as I can tell from your description.

 > That surely is the point rather than some technical distinction
 > between which elements are owned by whom.

It's not "some technical distinction."  It's "you can expect that many
features of the mailing list will fail to work as they should" --
including the new privacy features mandated by the law.  This is what
I mean by "nothing is proportionate or reasonable."  I don't know
about other communication systems that will be affected by this
legislation, but as described the folks who wrote the law did not
understand or care how it would work with mailing lists and similar
protocols (netnews, for example).

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

Just so.  But this does not satisfy "hide or disguise identity" as I
understand it.  Then there are things like ".signatures" -- but many
MUAs and/or users use this feature in a "technically incorrect" way,
and of course they are frequently hidden -- and munged -- in quoted
passages and the like.  I think that users will reasonably expect more
than a token effort to implement a hide-or-disguise requirement.

>From the point of view of mailing list implementers, GDPR is a hot
mess.  I agree with Barry, that some of the features that actually
protect privacy are going to require a lot of effort to implement.

In any case, to serve our users (and theirs) well, specification and
implementation should be done by somebody with access to a lawyer to
figure out (1) what the regulatory requirements are and (2) whether
there might be liability over and above regulation if personal
information is leaked in a way that is compliant with the regulation
but not expected by the user who "consented" to having their personal
data added to the application's database, or if personal information
is deleted without the permission of the person involved.

IMO "security" means anticipating what can go wrong as far as our
expertise permits, and then designing the system to prevent or
mitigate it, or warn the user that we were unable to prevent or
mitigate.  This is going to be difficult at best given the
difficulties that even commercial shops are having, according to
Barry.

Steve

-- 
Associate Professor              Division of Policy and Planning Science
http://turnbull/sk.tsukuba.ac.jp/     Faculty of Systems and Information
Email: turnbull at sk.tsukuba.ac.jp                   University of Tsukuba
Tel: 029-853-5175                 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN