https://bugzilla.wikimedia.org/show_bug.cgi?id=66450
--- Comment #16 from billinghurst <[email protected]> --- I am not certain why the privacy policy is coming into play as the priority, when the terms of use sit as equal level. At this point of time there is nothing to indicate which person is making the edits to identify against an IP, and could be considered no different from any normal standard IP edit, especially as we are not recording a username of the person editing, just the IP address and the TBL hit. Here we are talking about accounts that are hitting the TitleBlacklist, which is bigger than account usernames, and also includes numbers of keywords. So let us then explore a little more ... Do we chase someone down who uses a(n absolute)? vulgarity in a user name? Generally not, though we can. If we act, it is usually to block and to maybe block the IP for autoblock time. Do we chase down someone who successfully finds a new variation of a TBL keyword? Between sometimes and probably, and we update the TBL. Do we chase down an IP address of someone who is creating TBL-like pages with their IP address? No, we just block the IP address, and update the TBL. So we have the situations of Secnario A) — Limiting output to stewards and checkusers (both by default) that they they can see the IP address of someone who is 1) accidentally looking to circumvent the TBL, or 2) purposefully looking to circumvent the TBL. In situation 1) I doubt that we will know who the person is, nor care, nor would take any action. We will not know what other accounts exist unless the IP address is reverse checked, and there is no reason to do so, and for dynamic IP addresses would be pointless. In situation 2) Like with a revealed IP address, we won't necessarily know who they are or are not, than any other set of LTAs, and it won't really matter, we are more interested in terminating the abuse. If it is a known IP address for a vandal, CU normally familiar then, so nothing new anyway. Exceptions to this may be where a person's name has been added to the GLOBAL TBL where it has been abused xwiki and added by agreement. To the point at a new wiki that a person creating a new account would have their IP exposed. This alone may be reason to limit an IP address, though such Scenario B) — We have no IP addresses, and limited to Stewards and Checkusers. We have nothing of value for situations 1 or 2, beyond "gee look someone is maybe abusing ... sit. 1) silly beggars; sit. 2) I hope they don't find a way around ... what a PITA. Heads up in case they do. Scenario C) — We have no IP addresses and make it more visible to the advanced rights holders (admins +). Sit 1) Gee look! Sit 2) Gee look! Alert! (plus). So we have more vigilance, and probably a lot more people watching the page for not a lot of reason beyond reaction time. Not necessarily a lot of value. Scenario D) — We have IP addresses and make it more visible to the advanced rights holders (admin+). This has been addressed above as being bad as it could easily be (mis|ab)used by a poor addition. => not reasonable to have. So to me, it would seem that if we are going to judge this by effectiveness it would be along the lines of A >> C > B (not D) So how do I see that the privacy policy does come into play? That would be if we chose Scenario A) then we should only record that IP address temporarily, which would be up to three months (noting that the effectiveness of the IP address is probably only really good for a week to a month anyway). Though maybe as has been indicated above, that situation C is the case that we then have the ability to have recorded and discoverable through a CU search, though I am not sure what we would have to be able to search in that space. If there is no username created, or no edit, for what are we searching? At this stage the only other means to find something is through a global filter, and at this stage I am unaware of any filter that is limited to checkusers. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
