Page MenuHomePhabricator

Security and compliance with the Privacy Policy review of Extension:StopForumSpam to consider deployment on WMF wikis
Closed, ResolvedPublic

Description

Please review the code's security and compliance of Ext:StopForumSpam with WMF's privacy policy, so we can consider a future deployement on WMF wikis.

See also:

  • {T125132}

Event Timeline

MarcoAurelio raised the priority of this task from to Needs Triage.
MarcoAurelio updated the task description. (Show Details)
Restricted Application added subscribers: JEumerus, StudiesWorld, Aklapper. · View Herald TranscriptJan 31 2016, 3:20 PM

As extension creators.

(Onlookers' comment) That function allows one (through a checkbox) to submit some private data (IP addresses and email, for example) of an account to stopforumspam.com. Seems like this one would be the biggest privacy concern with using this extension on Wikimedia, when users with the permission to submit may use it (if at all) - and who receives that permission. Can't speak of the blocking function itself.

(Onlookers' comment) That function allows one (through a checkbox) to submit some private data (IP addresses and email, for example) of an account to stopforumspam.com. Seems like this one would be the biggest privacy concern with using this extension on Wikimedia, when users with the permission to submit may use it (if at all) - and who receives that permission. Can't speak of the blocking function itself.

Yes, data submission is my main concern as well hence this bug. I don't think we want to enable that. As for IP blocking, if what the extension does is to regularly download a list of IPs or ranges flagged as toxic, and such list is stored on our sites; I'd say there's no problem with that. I think that's the expected behaviour by reading the extension description.

getConfidenceInternal also seems problematic from a privacy prespective (If I read it right. I only skimmed)

I suspect the feature that we want to use at Wikimedia would be the IP blacklist. Technically the featureset is similar to TorBlock (that's where I got the idea and modeled some of it after).

There should be no privacy issues since we're just downloading a list and applying it I think.

I can help with the technical side of deployment if it gets that far, but have no time to do the social stuff.

getConfidenceInternal also seems problematic from a privacy prespective (If I read it right. I only skimmed)

Agreed, and it's probably too slow to use anyways.

Using $wgSFSEnableConfidenceVariable to rate the user/ip in abuse filter would definitely be a violation of our privacy policy. Just using the (ipv4) blacklist would be fine by the privacy policy, although the implementation would probably need a little work.

I would be a little uncomfortable with the whole extension being deployed when half of it is a violation of our privacy policy, but might be ok in the short-term.

MarcoAurelio added a comment.EditedFeb 10 2016, 2:53 PM

I think that regularly downloading the IPv4/IPv6 blacklists from SFS to restrict so called 'toxic' IPs and ranges without sending any user data to SFS is what might help us better. If it's not the whole extension, at least the blacklists could be implemented. Doesn't MediaWiki-extensions-TorBlock work that way?

Yes, that's basically how torblock works too.

@Legoktm, it looks like Ex:SFS expects the format of the "listed.." csv files, not the toxic list [https://www.stopforumspam.com/downloads/toxic_ip_cidr.txt]. Would you propose we use the lists that are constantly updated (I'm guessing use either the 7-days or 24-hour list)? Or would we update the way these are stored to include blocking the toxic ip ranges too?

Krinkle renamed this task from Investigate compliance with the Privacy Policy of Extension:StopForumSpam and consider deployement on WMF wikis to Investigate compliance with the Privacy Policy of Extension:StopForumSpam and consider deployment on WMF wikis.Apr 7 2016, 10:21 PM
ZhouZ moved this task from Backlog to Assigned on the WMF-Legal board.Apr 14 2016, 12:45 AM
ZhouZ added a subscriber: APalmer_WMF.
ZhouZ added a subscriber: ZhouZ.
MarcoAurelio renamed this task from Investigate compliance with the Privacy Policy of Extension:StopForumSpam and consider deployment on WMF wikis to Security and compliance with the Privacy Policy review of Extension:StopForumSpam to consider deployment on WMF wikis.Sep 18 2016, 11:13 AM
MarcoAurelio updated the task description. (Show Details)
MarcoAurelio removed a subscriber: LuisV_WMF.

Hello. Any progress on this one? Thanks.

Legoktm closed this task as Resolved.Dec 14 2016, 7:29 AM
Legoktm claimed this task.

Well I suspect this ticket isn't on anyone's radar because it has two tasks combined into one, not clearly scoped about what functionality is requested, etc.

In general the usage of the external IP blacklists is OK, and assuming that's the functionality being requested here, I'll close this as resolved. If you want to pursue this for deployment (and believe using SFS blacklists is going to help), please let me know and I can assist with that.

Hi @Legoktm. Yes, I think it'd be positive to have SFS on Wikimedia wikis for toxic IP/IP addresses restrictions. SFS is a regular source for our spambot checks. If you think it'll help as well, I'd like to see this code and security reviewed. Thanks in advance. Regards.

Just adding this e-mail snippet from @Legoktm from Dec. 14th as a reminder to myself (or whomever) that this still needs to go through formal review:

It'll still need to go through a formal security review, that was just an informal investigation task.

Just adding this e-mail snippet from @Legoktm from Dec. 14th as a reminder to myself (or whomever) that this still needs to go through formal review:

It'll still need to go through a formal security review, that was just an informal investigation task.

I'll create a task for that if that's what's needed. But I don't know what to ask the devs to look at specifically.

Restricted Application added a project: User-MarcoAurelio. · View Herald TranscriptAug 26 2017, 9:39 AM