Re: [Mailman-Developers] GDPR
Barry Warsaw wrote: | noskcaJ leahciM wrote: | > 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. | | GDRP may be well-intentioned, and may even be a good idea, but I know | for a fact that many organizations both commercial and volunteer are | struggling mightily to comply within the required timeframe. I suspect | that many such organization will simply not be able to comply. No disagreement there then. (I've written a paper predicting it based on an estimate of current non-compliance with the existing Data Protection Act in the UK, 20 years after it came onto the UK's statute book. German-speaking countries have had existing tighter rules so will be in better-shape, though I haven't attempted an international comparison.) | Realistically, there is no way the GNU Mailman project can comply given | our available resources. One outcome could be that our downstream | consumers take over that responsibility. Another is that volunteers in | our community step up with offers to provide us with their expertise, | guidance, Well, hopefully I've provided a little input and am happy to continue to. | and code. We will welcome such volunteers and help ensure | that the legal requirements align with project goals, sensibilities, and | timelines. | | So, if you want to see a GDPR compliant GNU Mailman, please find some | people to help us. I'm less pessimistic. For those that have seen the requirements for the first time, it's entirely understandable to react to it coming-in left-of-field and see it as daunting. However some of the changes required may, with a little consideration, be seen to be not as extensive as first feared; and others, to be a good idea. | | Cheers, | -Barry | leahciM ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GDPR
noskcaJ leahciM wrote: > 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. GDRP may be well-intentioned, and may even be a good idea, but I know for a fact that many organizations both commercial and volunteer are struggling mightily to comply within the required timeframe. I suspect that many such organization will simply not be able to comply. Realistically, there is no way the GNU Mailman project can comply given our available resources. One outcome could be that our downstream consumers take over that responsibility. Another is that volunteers in our community step up with offers to provide us with their expertise, guidance, and code. We will welcome such volunteers and help ensure that the legal requirements align with project goals, sensibilities, and timelines. So, if you want to see a GDPR compliant GNU Mailman, please find some people to help us. Cheers, -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GDPR
| 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
