JS was updated to sanitize the name being injected.

@sbassett Did AppSec review the JS to ensure that any parameters are scrubbed before injecting on the page?

Sorry all - we're (Privacy Engineering ) running a little behind on this. Will be looking at it today in our team scrum and will post any updates back here.

Since I got pinged, I'll quickly weigh in with my thoughts, too. I like the approach of a "weighted" CPL. Also, I think @Htriedman is correct that DP is a valid mitigation that might obviate the need to use the CPL at all in some cases. When we first came up with the CPL years ago it was a stop-gap blunt instrument mitigation that worked at the time, but (thanks to Hal) we have better options now. And, to me, the increasingly widespread use of it lends support to the idea that we should have ONE version of it that we improve over time, rather than using a one-off every time (imho, and to the degree possible). FWIW I've also reached out to Legal a few times over the years to see if they have any feedback about improving the list, but it's not really been a high priority. Perhaps it should be since we seem to keep coming back to the well?

Privacy Engineering is triaging this.

Yep, priv_eng_sync is me. Please don't remove.

Hello @kostajh - we'll add this to our next sprint. Part of the team will be off for the upcoming holidays but I'll see if someone can review it in the meantime.

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.