potiuk commented on PR #2: URL: https://github.com/apache/comdev/pull/2#issuecomment-4318843481
> My point is that PII may appear in private lists, and should not be distributed beyond them. > Unless you can somehow ensure that any messages with PII are somehow excluded from the analysis, I don't see how that is not a violation of Privacy. Not excluded from analysis - but in some cases (like security@ mailing list) - there is no PII to care about. I spend about half an hour discussing it with Christian yesterday, I understand that you might have that opinion - but not's that Christian said - when it comes to `security@` and similar mailing list. I really wanted to understand how it works and why things are defined like that - rather than base it on my own - or other people who have no authority or any role related to priavacy - necessary limited and narrow knowledge. The point of Christian (not mine - so you would have to discuss it with him if you disagree) in our discussion was that security@ are a "work" focused mailing lists - where sole purpose of those is to work on "disclosing security features" Those kind of communications (especially when they are opt-in - by the fact of deciding to send the report - do not have the same PII expectations as regular "discussions". But you can talk about it to Christian - feel absolutely free. He is going to work on a new policies - he promised to share it with me when they are drafted so that I can have a saying, I am sure if you talk to him he will also share it with you - and quite for sure there will be ASF-wide discussion about it As side comment. I am extremely happy about it - this was a fantastic news for the ASF that the whole heated privacy discussion will lead to a policy that will be well defined and not prone to sometimes not grounded in true knowledge about it - statements that are "definitive" and "obvious" (a side comment I find quite interesting how one can think they know better about something than real experts - that never ceases to amase me). Also - just to clarify it even further - in the security team we are already planning - once those policies are clalrified - to make it even more explicit - including letting know the reporters that their reports WILL be made public eventually after fixing the issues https://github.com/apache/security-site/pull/54 - this is absolutely necessary move now in the world where we MUST share information about both - identities of the reporters and content of their reports - to protect from AI generate flood of the issues. This has been already legal (as Christian explained) - but we want to even make it explicit. I even told Christian about Ponymail - and he asked me whether we can protect access selectively for that purpose and it's then when the idea where ponymail MCP donated to ASF could be a model example where this is **actually done** and he loved that idea. So my PR to Rich's MCP was a direct result of me agreeing with Christian that we should do it. Again - you can talk to Christian and check all that I told you - if you have any doubts if what I am writing above is wrong - it's not my interpretation this time - it's what Christian is going to propose in the new policies. My point is that PII may appear in private lists, and should not be distributed beyond them. Unless you can somehow ensure that any messages with PII are somehow excluded from the analysis, I don't see how that is not a violation of Privacy. > It would help to link to it. As Rich helpfully stated above - the PR of mine is already merged and present in this PR (see the last commit). I am also going to add a fixup to do "privacy by default" - i.e. make sure that all private lists are excluded by default - currently I excluded only foundation-wide, but I think better approach will be to exclude all the private lists **AND** security - and you will be able to opt-in to enable particular security lists as opt-in when you will configure the Ponymail MCP locally. There is a bit of heuristics to it for now - because not all private lists in the ASF have `private` in the name. But maybe there is a way ? Maybe your energy and knowledge @sebbASF could be used to help us to find out an "Exact" way of knowing that. Is there an LDAP or other place we can get the information whether the list is private or no? How should we do it @sebbASF ? Can you help us ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
