Ediciones a través de IP: mejora de privacidad y mitigación de abusos
¿Qué es el enmascaramiento de IP y por qué lo está llevando a cabo la Fundación Wikimedia?
Las máscaras de IP ocultan las direcciones IP de los editores no registrados en los proyectos de Wikimedia, total o parcialmente, de todos, excepto de aquellos que necesitan acceso para combatir el spam, el vandalismo, el acoso y la desinformación.
Actualmente, cualquiera puede editar wikis de Wikimedia sin una cuenta de Wikimedia o sin iniciar sesión. MediaWiki, el software detrás de los proyectos de Wikimedia, registrará y publicará su dirección IP en su registro público. Cualquiera que busque su dirección IP la encontrará.
Los proyectos de Wikimedia tienen una buena razón para almacenar y publicar direcciones IP: desempeñan un papel fundamental para evitar el vandalismo y el acoso en nuestras wikis.
Sin embargo, su dirección IP puede indicar desde dónde está editando y puede usarse para identificarlo a usted o a su dispositivo. Esto es especialmente preocupante si está editando desde un territorio donde nuestros wikis se consideran controvertidos. La publicación de su dirección IP puede permitir que otros lo localicen.
Con los cambios en las leyes y estándares de privacidad (p. ej., el Reglamento general de protección de datos y la conversación global sobre privacidad que inició), el equipo legal de la Fundación Wikimedia ha decidido proteger la privacidad de los usuarios ocultando las direcciones IP del público en general. Sin embargo, continuaremos dando acceso a los usuarios que necesitan ver las direcciones para proteger las wikis.
Somos conscientes de que este cambio afectará los flujos de trabajo antiabuso actuales. Estamos comprometidos a desarrollar herramientas o mantener el acceso a herramientas que puedan identificar y bloquear vándalos, títeres de calcetines, editores con conflictos de intereses y otros malos actores después de que se enmascaren las IP.
Actualizaciones técnicas y de producto
Estrategia de implementación y próximos pasos (25 de febrero de 2022)
Hola a todos. Tenemos una actualización sobre la estrategia de implementación de IP Masking.
First off, thank you to everyone who arrived on this page and offered their feedback. We heard from a lot of you about how this page is not easy to read and we are working on fixing that. We genuinely want to thank you for taking the time to go through the information here and on the talk page. We took every comment on the talk page into consideration before the decision about the implementation plan was made.
We want to preface this also by saying that there are still a lot of open questions. There is a long road ahead of us on this project and we would like you to voice your opinion in more of these discussions as they come up. If you haven’t already, please go through this post about who will continue to have IP address access before reading further.
We received mixed feedback from the community about the two proposed implementation ideas without a clear consensus either way. Here are some quotes taken from the talk page:
- For small wikis, I think the IP based approach is better because it is unlikely that two anonymous users will have the same IP, and for a vandal modifying its Ip is most difficult that erasing cookies.
- The session-based system does seem better, and would make it easier to communicate with anonymous editors. I'm an admin on English Wikipedia, and my main interaction with IP editors is reverting and warning them against vandalism. In several cases recently I haven't even bothered posting a warning, since it seems unlikely the right person would receive it. In one case I was trying to have a conversation about some proposed change, and I was talking to several different IP addresses, and it was unclear that it was actually the same person, and I had to keep asking them about that.
- As an admin in German-language Wikipedia, of the two paths described here (IP based identity vs. session-based identity) I clearly prefer the IP based approach. It's just too easy to use a browser's privacy mode or to clear the cookies (I'm doing it myself all the time); changing your IP address at least requires a bit more effort, and we have already a policy against using open proxies in place. I agree with Beland that the session-based identity approach could probably make communication with well-meaning unregistered editors easier, but it just doesn't seem robust enough.
- I prefer the session-based approach. It provides more value in being able to identify and communicate with legitimate anonymous editors. However, at the same time, we need abuse filter options to be able to identify multiple new sessions from a single IP. These could be legitimate (from a school, for example), but will most likely represent abuse or bot activity. One feature I haven't seen mentioned yet. When a session user wants to create an account, it should default to renaming the existing session ID to the new name of their choice. We need to be able to see and/or associate the new named user with their previous session activity.
- I am leaning towards the IP-based identities, even if encrypted, as cookies seem more complicated to deal with and very bothersome to keep shutting their annoying pop-ups (very standard in Europe). I have to mention that I prefer that till this day, one could use Wikipedia without cookies, unless he wants to log in to edit with his username.
- The ability to perform purely session-based blocks in addition to the existing IP+session blocking would be an interesting upgrade. Being able to communicate with IPv6 users through their session instead of their repeatedly changing IP address would also be a benefit.
In summary, the main argument against the session-based approach was that cookies are easy to get rid of and the user may change their identity very easily.
And the main arguments against the IP-based approach were:
- the encryption method can be compromised, hence compromising the IP addresses themselves
- this approach does not provided the benefit of improved communication with the unregistered editors
- does not allow for session-based blocking (in addition to IP based blocking)
In light of the above and the discussions with our technical team about the feasibility and wide-ranging implications of this implementation, we have decided to go with the session-based approach with some important additions to address the problem of users deleting their cookies and changing their identity. If a user repeatedly changes their username, it will be possible to link their identities by looking at additional information in the interface. We are still working out the details of how this will work - but it will be similar to how sockpuppet detection works (with some automation).
We are working out a lot of the technical details still and will have another update for you shortly with more specifics. This includes LTA documentation, communication about IPs, AbuseFilters, third-party wikis, gadgets, user-scripts, WMF cloud tools, restrictions for IP-viewer rights etc. We appreciate your input and welcome any feedback you may have for us on the talk page.