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.

Hey @Dbrant - the documentation here seems to indicate data is a little more specific than just user-agent. Based on your reply does this mean that the vast majority of this data was suppressed at the app level? Since the SDK seems buggy, how certain do we feel that it wasn't leaking unintended data? Thanks for chasing all this down so quickly.

I still see a few left, on some really old posts... Looks like there is some thumbnail/lightbox function that was maybe removed? I would just delete those links altogether. That content is pretty long in the tooth.

@CKoerner_WMF If you run the site through missingpadlock.com it reports 11 passive mixed content issues (all look like images loaded via http). That should be pretty quick to fix I would think.

WMF-Legal confirmed that they approved this via email already, so @DannyS712 should be good to go. Thanks for your patience @DannyS712 .

I think this will be fine, but need to confirm with WMF-Legal. Will post back here as soon as I hear from them.

Hey @revi would you mind checking again? I think @CKoerner_WMF resolved these this morning.

@DannyS712 I'll take a look this week.

@Varnent can you also please give access to me (jagspecx) for the privacy review. Thx.

@EBernhardson I emailed the stakeholders with my updates to the privacy risk analysis. Please advise if you need anything else on this task or if I can resolve it. Thx!

Please feel free to reopen if needed, but seems like this has been fixed.

Looks like this has been resolved?

Looks good to me WRT Privacy. I think @Reedy also wanted to take a look at this for the appsec side.

The last things I see are:

Sorry for my delayed response here - I wanted to spend time really reviewing the disparate viewpoints and refining my own thoughts on the subject, so thank you for your patience. I appreciate the thoughtful discussion so far. Clearly, we all agree we want to respect the privacy of our users. Consistent with AGF, I think the disagreement here is how best to manifest this respect. Here's my attempt to frame the issue in terms of user expectations, along with my recommendation.

Hi @jcrespo the Security-Team reviewed this table and we're fine with making the data public with the caveat that anything where aft_hide = 1 is removed from the data (in other words, it can be permanently deleted). In most cases that hidden data appears to be spam, but in a few instances it looks like attempts to publish private data (phone number, physical address, etc.). From a review of the extension code it appears that most of the rest of the data was already public while the extension was live, and the UX clearly indicated to users that feedback would be made public. Please advise if you have any further questions/issues related to this table.

@chasemp I've reviewed all of the tasks on the Privacy board now, so you can remove that.