Thanks @Majavah I think they can be closed. Thanks for jumping on these so quickly!

@sguebo_WMF Agreed - I think it's fine to make public.

@sbassett LGTM!

@Urbanecm Your question is, I think, really a WMF-Legal question. I'll reach out to them as they don't routinely monitor Phab.

Hey @LSobanski - I haven't reviewed this task in any detail yet. I can add this to our current sprint and take a look in the next couple of weeks. Does that work?

Hey @mforns! @sguebo_WMF has been working on this for the Privacy Engineering team and filled me in on the details so far. I concur with his analysis - since the likelihood of http://p.c.g appearing seems pretty low in the first place. And since, AIUI, even with a potentially problematic hostname, there is not a high level of additional detailed information with which to reidentify someone, this seems like a LOW risk to me. @sguebo_WMF is finalizing our risk review sheet right now (he might actually be done already, but I'm not sure yet), but please let us know if you think we've missed something. It seems like even with language and country being included in the schema, the likelihood of being able to track hostname back to an individual user is pretty low. Are there other properties that concern you that we maybe missed?

I concur with @sbassett. Looks low risk to me.

Thanks @nshahquinn-wmf !

If @Urbanecm is correct that

IIRC, we don't use the gender property for anything that's visible only to the user

and we warn users that their answer to the gender question will be made public. And the default behavior is to default to "no answer" (i.e. MW does not assume a particular gender). Then it seems like there is very little incremental risk in exposing the gender response in the replicas. N.B. making already public data easier to access may still be considered a privacy violation, but it seems like, in this case, there is probably not much additional harm.

Anything else that needs to be done on this?

@nshahquinn-wmf How did you end up resolving this? We should document it somewhere, so we can point to it for future requests like this. I recall you mentioning that this issue comes up not infrequently.

@mforns thanks for adding me! If this isn't a huge rush, we'll add this to the next Privacy Engineering scrum.

@Ladsgroup Thanks - that would be great! Presumably this problem goes away with migration to Mailman3? Do we need to set up any kind of log rotation there to prevent this from happening again?

FWIW I like the idea of using PRIVACY in small caps instead of E. It communicates a significant amount of information in a few letters.

@Htriedman

Hello all, I've completed the privacy risk analysis and shared it with the original requester: Due to the low impact of harm and low probability of malicious use of this data, coupled with the mitigation described above, the residual risk of collecting and retaining this data is considered LOW so the risk is automatically accepted by WMF under current policy.