Re: [Mailman-Developers] GDPR

| 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.
It's the law. Some of us have to deal with it; like it or not.
| | > 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?
GDPR merely calls for explicit consent (where appropriate). E.g.
"By replying or clicking this link, you are consenting to your email address being subscribed to the closed list xyz. You then receive emails sent by other members subscribed to the list and emails that you send to this list will be sent to the other subscribers of the list. Emails you send to the list will also be archived on a website to which you and other members of the list have a login and password to view."
| | > 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?
A picture is worth a thousand words:
digraph statechart { size="2.91,2.75"; // Produces 280x70 pixel image rankdir=LR; edge [splines="curved", fontname=Helvetica, fontsize=11 rotate=90]; node [fixedsize=true, style=filled, color=black, fillcolor="#CFE7F5", fontname=Helvetica, fontsize=11]; start [shape=doublecircle, style="filled,bold" color=black, fillcolor=white, width=0.45]; start -> idle; idle -> idle [label="rectify"]; idle -> erased [label="erase"]; end [shape=doublecircle, style="filled,bold" color=black, width=0.4]; erased -> end; idle -> restricted [label="challenge,\nobjection,\nDSAR"]; restricted -> erased [label="erase"]; restricted -> idle [label="rectify"]; restricted -> idle [label="stet"]; }
As the graphviz dot graph shows, restricted is a "holding bay" for people's data. As soon as any issue or query is raised about your processing of someone's data, you're supposed to restrict or suspend processing (using) it. You're not to delete it, just stop using it. (That implies send/receive). And, in your system it should show as restricted.
| > 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.)
You sound angry.
| | > 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).
Stephen, look at it another way. There have been, and continue to be be gross enfringements. Examples are deliberately confusing people by mixing opt-in and opt-out check boxes presented, and not declaring that details provided for one purpose will be used (or sold) for another.
The likes of mailchimp have reacted by pushing-back responsibility on their Customers. See this, written within three weeks ago:
https://kb.mailchimp.com/accounts/management/about-mailchimp-and-eu-safe-har...
I hope that you will come-round to seeing that there are changes that MM could make that are proportionate and reasonable.
| | > | > 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.
What was called-for was not token.
What was called-for was:
a) Never add-in stuff that could disclose
b) So far as is practical, reasonable and proportionate, help subscribers not to /inadvertently/ leak personal data, whether theirs or someone else's.
| | 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.
Sections 15,16 of the GNU GPL v3.0 state (in all caps) no warranty. MM's developers are neither the controller nor processor in respect of others' use of MM.
You can, however, have regard to law regulating use of personal data.
leahciM
| | Steve | | -- | Associate Professor Division of Policy and Planning Science | http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information | Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba | Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN |

noskcaJ leahciM writes:
It's the law. Some of us have to deal with it; like it or not.
GDPR merely calls for explicit consent (where appropriate). E.g.
A picture is worth a thousand words:
None of this is helpful to me; as far as I can tell it's not responsive to what I wrote or asked.
You sound angry.
Yup. You do not display an understanding of what I wrote, and presume that *I* misunderstand the need and oppose your program. I do understand privacy, and although my values differ from the EU's, I do not oppose dealing with GDPR "someday". The questions are "when" and "with what resources" and "what is an accurate specification of what needs to be done". Your answers are "soon" and "it's easy" and "don't worry about it", and I don't think any of those are valid or useful.
Stephen, look at it another way.
I'm already looking at it that way, and telling you it will be expensive to deal with it properly in Mailman, and in similar applications. Mailman currently likely does not have the resources to do so in the next two years.
You can, however, have regard to law regulating use of personal data.
Once again, I don't think that is a useful way to think about software development (don't we all just love DOD-STD-2167A?), and I suspect my feelings are pretty representative of OSS volunteer developers.
I assure you (and everybody else who worries about GDPR) that we *will* have regard for *our* (European) *users'* *needs* vs. the law, and *their* *preferences* vs. privacy that may not be defined by law.
The mere existence of a law? "Frankly, my dear, I don't give a damn."
We'll do what we do, and do it well, when the time comes that we believe it serves our users better than alternative tasks do. For example, better installation procedures and Mailman 2to3 migration automation are *definitely* going to come before GDPR mitigation. Without those, there won't be very many users in Europe (or anywhere) to care about GDPR. Almost certainly, better authentication for the core will come before, too. Otherwise we won't be able to protect from some important threats to privacy, and this is something we've been thinking about for quite a while. And so on.
So until GDPR's turn comes, "patches, real legal advice, and money welcome."
I REALLY would like to hear from a EU information rights lawyer who's active in the personal data privacy field, or somebody facing imminent application of the law at their Mailman site who can get precise information about how regulators are going to interpret these laws, from lawyers or regulators.
Steve
-- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN

noskcaJ leahciM writes:
It's the law. Some of us have to deal with it; like it or not.
GDPR merely calls for explicit consent (where appropriate). E.g.
A picture is worth a thousand words:
None of this is helpful to me; as far as I can tell it's not responsive to what I wrote or asked.
You sound angry.
Yup. You do not display an understanding of what I wrote, and presume that *I* misunderstand the need and oppose your program. I do understand privacy, and although my values differ from the EU's, I do not oppose dealing with GDPR "someday". The questions are "when" and "with what resources" and "what is an accurate specification of what needs to be done". Your answers are "soon" and "it's easy" and "don't worry about it", and I don't think any of those are valid or useful.
Stephen, look at it another way.
I'm already looking at it that way, and telling you it will be expensive to deal with it properly in Mailman, and in similar applications. Mailman currently likely does not have the resources to do so in the next two years.
You can, however, have regard to law regulating use of personal data.
Once again, I don't think that is a useful way to think about software development (don't we all just love DOD-STD-2167A?), and I suspect my feelings are pretty representative of OSS volunteer developers.
I assure you (and everybody else who worries about GDPR) that we *will* have regard for *our* (European) *users'* *needs* vs. the law, and *their* *preferences* vs. privacy that may not be defined by law.
The mere existence of a law? "Frankly, my dear, I don't give a damn."
We'll do what we do, and do it well, when the time comes that we believe it serves our users better than alternative tasks do. For example, better installation procedures and Mailman 2to3 migration automation are *definitely* going to come before GDPR mitigation. Without those, there won't be very many users in Europe (or anywhere) to care about GDPR. Almost certainly, better authentication for the core will come before, too. Otherwise we won't be able to protect from some important threats to privacy, and this is something we've been thinking about for quite a while. And so on.
So until GDPR's turn comes, "patches, real legal advice, and money welcome."
I REALLY would like to hear from a EU information rights lawyer who's active in the personal data privacy field, or somebody facing imminent application of the law at their Mailman site who can get precise information about how regulators are going to interpret these laws, from lawyers or regulators.
Steve
-- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
participants (2)
-
noskcaJ leahciM
-
Stephen J. Turnbull