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?

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

A potential risk I see is "reputational harm". I.e. if it looks like our JS is doing something hinky (even if it's not), it might raise concern with users. For example, if we were to sniff the clipboard (just as an illustration) - even if we only recorded "ipCopied: yes", it still doesn't look very friendly. Reading between the lines, it looks as if folks here are already considering this, but thought I would raise the issue explicitly.

@Ottomata I think that might be the point of measuring copy/paste. To determine how much "legitimate" use there is of IP addresses? Specifically _because_ illegitimate use would likely be via bots/scrapers/etc.

Assigning back to @gmodena as author. I think my portion is done here, but please reassign back if I missed anything.

Based on the schemas in the description, privacy risk for this data is LOW. If the data is expanded at some point in the future to capture e.g. user match recommendations we should take another look.

From a privacy perspective, if this table is merely cached data, I would not recommend replicating it, in accordance with the principle of data minimization. If there is some compelling reason for replicating it, please feel free to ping me and I can conduct a privacy risk analysis, but for now I'm going to mark as completed for Privacy Engineering.

Untagging Security-Team for now, but please feel free to add back if there is something else needed.

I spoke with a member of WMF-Legal about this issue and the tl;dr is that we do not presently have a sufficiently low risk alternative to ssh for transferring files outside of the analytics cluster. At least not one that isn't equally or more difficult than configuring ssh. As @sbassett postulated above, WMF-Legal would be amenable to an alternative if one is proposed/developed/installed/configured/purchased/whatever, but I think that's not a quick ask. Since it sounds like this is a long-term, ongoing need, @nshahquinn-wmf I would reach out to ITS and/or SRE about a new permanent solution for getting data where you need it to go.

Pinged WMF-Legal for feedback.

@nshahquinn-wmf your question raises another - where are you looking to send the data to? If you're sending sensitive data to an insecure laptop, then securing it in transmission is only one facet of the issue.

+1 from me

This looks awesome @Isaac! Can't wait to try it out.

Hey @Dzahn:

"Privacy" (not a team but topic based?),

Yes, just means a Privacy issue is probably implicated.

"Privacy Engineering" (only 2 members and in status "watching" which sounds like waiting for others)

Yes - Privacy Engineering is just me at this point. Unfortunately, I can point out, like you, that this is not great optics, and I can suggest alternative solutions that are more privacy-respecting. But I don't get to make decisions about what gets hosted where.

Generally, the best practice is to minimize the data that is collected - especially high resolution data. That said, this data appears to be LOW risk, and per @jwang there is a countervailing interest in collecting the high resolution data in order to retain sequencing and other analytical uses.

Generally, the best practice is to minimize the data that is collected - especially high resolution data. That said, this data appears to be LOW risk, and per @jwang there is a countervailing interest in collecting the high resolution data in order to retain sequencing and other analytical uses.

@Jdlrobson and @Krinkle - what about hashing the IPs? A hashed IP would still tell you how many IPs are involved, without revealing any individual IP.

Hello @jwang same comment as here. Is it necessary to keep the dt field? What is the purpose of keeping this data long-term (please feel free to reply off-task if it is sensitive)? Thanks!

Hello @jwang thanks for reaching out. Is the purpose just to track usage long-term? Also, if you don't need high-precision time, I would remove dt from the schema as well. It looks like you can still track hourly precision without that field? Other than that, this looks fine to me.