Privacy Engineer
User Details
- User Since
- Apr 16 2019, 4:16 PM (91 w, 3 d)
- Availability
- Available
- IRC Nick
- jfishback
- LDAP User
- Jfishback
- MediaWiki User
- JFishback (WMF) [ Global Accounts ]
Thu, Jan 14
Mon, Jan 11
Pinged WMF-Legal for feedback.
Tue, Jan 5
@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
Mon, Jan 4
This looks awesome @Isaac! Can't wait to try it out.
Mon, Dec 21
Dec 16 2020
Hey @Dzahn:
Yes, just means a Privacy issue is probably implicated.
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.
Dec 14 2020
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.
Nov 16 2020
Nov 5 2020
Oct 21 2020
Oct 19 2020
@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.
Oct 5 2020
Oct 1 2020
Sep 29 2020
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.
Sep 28 2020
Sep 25 2020
Sep 21 2020
Sep 14 2020
Sep 9 2020
Aug 25 2020
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.
Aug 17 2020
Aug 10 2020
Jul 28 2020
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.
Jul 24 2020
@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.
Jul 20 2020
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.
Jul 16 2020
Hey @revi would you mind checking again? I think @CKoerner_WMF resolved these this morning.
Jul 14 2020
Jun 29 2020
@DannyS712 I'll take a look this week.
Jun 17 2020
@Varnent can you also please give access to me (jagspecx) for the privacy review. Thx.
Jun 13 2020
Jun 9 2020
@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!
Jun 6 2020
Jun 4 2020
Please feel free to reopen if needed, but seems like this has been fixed.
Looks like this has been resolved?
Jun 1 2020
May 31 2020
May 28 2020
May 26 2020
May 22 2020
The last things I see are:
May 21 2020
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.
May 11 2020
May 4 2020
Apr 30 2020
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.
Apr 27 2020
Apr 13 2020
Apr 11 2020
Apr 6 2020
Apr 3 2020
Mar 30 2020
Mar 27 2020
Mar 24 2020
@chasemp I've reviewed all of the tasks on the Privacy board now, so you can remove that.