Bienvenido a la ronda 1 de la opinión de la comunidad de Wikimedia Labs y sus Condiciones de Uso ("Términos"). El equipo legal Wikimedia está interesado en la revisión, actualización, y aclarar las condiciones existentes que rigen los desarrolladores y sus proyectos de Wikimedia laboratorios.
En términos de proceso y el momento, esta ronda de solicitud de realimentación se pretendía conocer las ideas de usted, como miembro de la comunidad Labs, sobre cómo revisar mejor las condiciones. Vamos a tratar de responder lo mejor que puede, pero el principal propósito de esta ronda es escuchar todos sus pensamientos. Después de las votaciones ronda, vamos a preparar un proyecto de revisión de las condiciones en base a que la retroalimentación y otras revisiones menores para aclarar las declaraciones en existencia las condiciones. a continuación, participarán en una discusión de la comunidad acerca los términos revisados.
Hemos identificado tres áreas importantes donde queremos oír vuestra retroalimentación. Además, para otras áreas de discusión o aporte, por favor envía tus ideas en el área de “discusión abierta” más abajo.
Tenemos la intención de dejar esta discusión abierta hasta el 9 de junio de 2016. Gracias por toda su ayuda y retroalimentación.
Nota: Debido a la naturaleza única de Wikimedia Labs, los desarrolladores que utilizan los laboratorios en general no se rigen por las políticas que gobiernan nuestros otros sitios, como la Fundación Wikimedia y sus condiciones de uso. Los programadores que desarrollan proyectos en los laboratorios se adhieren condiciones de uso de Wikimedia Labs. Además, los sitios web mantenidos por la Fundación Wikimedia en los laboratorios deben cumplir con la política de privacidad de la Fundación Wikimedia.
Le pedimos a los participantes que respeten las expectativas de espacios amistosos cuando discutan estos temas.
Uso de Recursos de Terceros
Los términos actuales no indican si los desarrolladores pueden utilizar o integrar recursos alojados en servidores de terceros (p. ej. bibliotecas, guiones, hojas de estilos, imágenes, etc…). El uso de esos recursos de terceras partes podrían ser considerados problemáticos para las siguientes razones:
- Algunos usuarios pueden considerar el rastreo de terceros como intrusivo de su intimidad.
- Algunos usuarios pueden no estar avisados y algunos proyectos pueden no tener aviso adecuado de estas prácticas.
- Usuarios de los proyectos que involucran recursos de terceros pueden estar sujetos a riesgos más altos de asuntos de seguridad o ataques intencionales.
Estas preocupaciones se acentúan en los casos de Laboratorios hospedados, las herramientas y extensiones están instalados o disponibles para su uso en nuestros otros proyectos.
Para proteger a los usuarios y redes, los laboratorios de Términos de Uso podrían revisarse para no permitir explícitamente el uso de recursos de terceros. Los desarrolladores pueden seguir utilizando los recursos externos por primera subirlos para alojar en su proyecto Labs.
On the other hand, it sometimes might be easier for developers to link to third-party resources rather than uploading them first. Some external services also might be not easily uploadable to or hosted on Labs. Furthermore, it is likely there are already some projects on Labs which use third-party resources; this is particularly problematic when such usage is undisclosed to end-users. Finally, perhaps a distinction should be made between loading third-party resources that will directly interact with an end-user and the loading of third-party resources on the back-end of a service. The latter practice is usually less intrusive to user privacy than the former since it does not result in the automatic transmission of user information to a third-party (of course this information may still be forwarded, perhaps inadvertently, to a third-party resource on the back-end).
Any policy change will ideally provide a flexible way to address existing project usage and behavior as well as avoid unnecessarily hinder the development of new projects. Revisions may also want to reflect the technical capability of enforcing such a TOU and providing the end-user with the ability to consent to the use of third-party resources.
Por último, esta discusión no se trata de no permitir que une a sitios de terceros desde una página laboratorios. Los hipervínculos son bloques de construcción fundamentales de una web abierta y debemos evitar que prohíbe esto.
Please share your thoughts below about how we might (or might not) want to revise the Terms to address the use of third party tools:
Discuss Use of Third Party Resources
- What about the use of third party API's like that of Google? I used the Google API to check the channel id of a YouTube account based on someone entering the userid or channel name in the Wikidata field for YouTube channel ID. And what about the change I made by fetching the page of a YouTube account and gathering the channel id from the metatags? Mbch331 (talk) 19:32, 20 May 2016 (UTC)
- Calling out to a 3rd-party service from your backend code is generally fine. You should not be sharing personal information about your user (e.g. on-wiki username, IP address, etc) with that 3rd-party unless you have warned the user before and received their consent.
- ZZhou (WMF) could you clarify here and/or in the main document that the concerns for "use or integrate resources hosted on third-party servers" are specifically scoped to such uses that expose sensitive data to the third-party and have not been explicitly agreed to by the end user? The ticket I filed at T129936 which in part led to this discussion was specifically about forced browser interactions. I think an over broad interpretation of disallowing all third-party interactions from the backend or of disallowing consensual browser interactions with third-party servers would be harmful rather than helpful. BDavis (WMF) (talk) 18:37, 21 May 2016 (UTC)
- You are right that perhaps we should be more lenient towards third-party interaction on the back-end or allow users to opt-in to third-party tracking. I have revised the discussion section. --ZZhou (WMF) (talk) 22:40, 23 May 2016 (UTC)
- Hosting or mirroring on labs has the disadvantage of possible duplicate downloading and possible duplicate caching on the client side. --Purodha Blissenbach (talk) 07:43, 21 May 2016 (UTC)
- If a CDN is used, and the user has visited a site that used the same CDN with the same file (e.g. MaxCDN with Bootstrap), then it will be cached in the user's browser and not downloaded again. This has potential speed benefits, and uses less storage on labs because everyone does not have to download and copy the files into their individual tools. Also, other services such as reCAPTCHA are useful to prevent spam, because locally hosted services are often less effective. Tom29739 (talk) 18:26, 21 May 2016 (UTC)
- Tool Labs itself has the cdnjs and static tools designed to host widely used resources. I personally don't believe that any particular third-party CDN is so commonly used that there can be a guarantee of a high rate of local browser cache hits. Even if that can be proven false, trading an IP address, cookies, and HTTP referrer information for a small data download is not a decision that I feel Wikimedia should be forcing on it's visitors.
- I'm creating such an API. The trouble with such a service is that it will be a traditional, unreadable text one. reCaptcha has a risk detection engine which makes it much more effective. The ConfirmEdit extension page on MediaWiki wiki says that unreadable text captchas are ineffective and reCaptcha is very effective. We shouldn't have to reinvent the wheel and go back to the dark ages for captchas. Most users would probably thank us for letting them use an easy checkbox rather than unreadable text. By disallowing reCaptcha, you are effectively giving spammers free access to tools. Tom29739 (talk) 21:44, 22 May 2016 (UTC)
- +1 (if I understand you correctly). Labs is for experiments, and those may (initially) require integrating third-party services. If a user has previously agreed to that I don't see harm, and I also think that in the long term, if a tool/application is useful for a wider range of audience, it should be cleaned up to not depend on any third-party services (and turned into an extension/gadget). But that should not be a prerequisite for starting to develop something. --Tim Landscheidt (talk) 23:30, 23 May 2016 (UTC) P. S.: Proxying requests is often as bad if the third party can correlate requests to their service with actions on Wikipedia.
I completely agree. I think the essential point here is consent. As long as the user explicitly consents ('Yes, I agree that some personal information will be shared with [host X, host Y]'), I think it is reasonable to allow this -- not unlike the current 'By using this project, you agree that any private information you give to this project may be made publicly available and not be treated as confidential.' message requirement. Valhallasw (talk) 08:20, 27 May 2016 (UTC)
- Currently, I'm using Google Analytics for one of my tool, but this change will disallow me from using it anymore. Hence, is there any service from WMF that can be used to collect some analytics on tools (e.g. number of visitor on pages over a time period)? Kenrick95 (talk) 09:02, 29 May 2016 (UTC)
- Hits can probably be measured manually, can't they? Not sure if it's possible to count hosts. But just putting a placeholder answer in expectancy that smarter guys will elaborate :) --Base (talk) 08:31, 31 May 2016 (UTC)
Clearer privacy disclaimers and privacy statements to provide end-users with useful information
La privacidad es importante para los usuarios finales y desarrolladores por igual, y queremos asegurarnos de que información clara y útil es proporcionado en relación con el tratamiento de la información recogida por los proyectos en los laboratorios.
Normativa de privacidad de Tool Labs
Por favor comparta sus pensamientos a continuación en exigir que los proyectos en los laboratorios de herramientas para adherirse a la política de privacidad de la Fundación Wikimedia o una política de privacidad personalizada. Además, por favor comentar si hay mejores maneras para que los desarrolladores de proyectos en los laboratorios de herramientas para notificar a los usuarios finales de sus prácticas de privacidad.
- 1) Private information must be secured.
- 2) Private information can only be retained for a short period of time.
- 3) Private information can generally not be shared with third parties except with user consent.
We are interested in revising the end-user disclaimers to have all developers better notify end-users of the specific privacy practices applicable to projects on Labs. Currently, these disclaimers are only for projects that allow for account creation, collect private information, or contain beta or test wikis.
In addition to clarifying these existing disclaimers, it might be helpful for even Labs projects that do not collect private information to publish a disclaimer assuring end-users that private information is not being collected.
Please share your thoughts below on how we might want to change the current disclaimers or ask existing projects to revise their disclaimers.
Discuss Privacy Disclaimers
- Must the disclaimers be in English? Where is this limitation coming from? --Base (talk) 07:21, 31 May 2016 (UTC)
- Не бачу там нічого про мову. Я вважаю що люди можуть писати дисклеймер будь-якою мовою. Хоча, звісно, багатомовність є більш бажаною. --Base (talk) 22:01, 1 June 2016 (UTC)
- @Base: You are right - it does not state the disclaimer language (although the disclaimer as written on that page is itself in English). We do not want to force developers to write disclaimers in languages they do not understand. At the same time, the purpose of disclaimers is to inform end-users and that purpose is defeated if a disclaimer is published in a language they also do not understand. Thus, the provision of the disclaimer on the Terms provides a way for developers who do not speak English to still publish a disclaimer to their end-users. Are you aware right now of many translated disclaimers (based on the one in the Terms) being published in other languages on Labs today? If so, is there still a way we can better ensure end-users will understand the language of any disclaimers they come across on Labs? --ZZhou (WMF) (talk) 17:23, 7 June 2016 (UTC)
- This is useful for users, but may also 'scare' people off because the disclaimers may make the user think they are giving away loads of private info by using a tool. Tom29739 (talk) 18:26, 21 May 2016 (UTC)
- Instead of lots of boilerplate text no one is going to ever read, maybe the WMF could create some sort of easily-recognisable visual identity (like privacy icons). --Tgr (talk) 10:14, 22 May 2016 (UTC)
Declaraciones de Privacidad
The TOU currently contains a section entitled “What can and can’t be done with user information?” This section provides details regarding the types of data can be collected from end-users, and the ways in which it must be stored and handled. We would like to ensure that developers understand the requirements -- are these parameters clear, and helpful when planning a project?
If you are collecting private information, you are required to inform end-users of that fact, and to tell them how you will use it and how long you will retain it. Is it easy for developers to create notices for end-users detailing this information? Do you use the list in this section of the TOU as guidelines for this notice?
A notice that specifically details how data will be used or handled in regard to a certain project is called a privacy statement. We are considering setting baselines for the information that must be provided to end-users in these privacy statements — e.g., the type of information that the project collects, whether the information is expressly shared with third parties outside of the Wikimedia Foundation, how long you will retain the information, etc. Would guidelines of this sort be useful to you when you write privacy statements for your projects?
Please comment below on whether or not the “What can and can’t be done with user information?” section is helpful; if not, please suggest what sort of information would be useful for you. Additionally, please comment on the suggestion that all projects provide a privacy statement including certain baseline information about their data collection and handling practices.
Discuss Privacy Statements
- Technically speaking, every tool or instance that's web accessible collects user information, at least in form of webserver logs. I would advise to create a "standard" set of what's being typically collected, and recommend/require a separate disclosure if information beyond that is being collected. Max Semenik (talk) 21:16, 20 May 2016 (UTC)
- Applications hosted on Tool Labs do not have access to the end user's IP address. This information is stripped from the request by the proxy server that also terminates the HTTPS connection and routes to the appropriate backend web server. The proxy server for other Labs projects relays the original IP address in an X-Forwarded-For header. User-Agent is available to both as is some level of information on the on-wiki user if OAuth is used by the application.
- The XFF header is truly only needed by a very small number of applications in Labs and it would be nice to change the proxy so that this is an explicit grant that must be asked for rather than a default privilege. For Labs hosts which have a public IP address, there is no intervening proxy that can anonymize access. Projects requiring this direct access to their clients should also in my opinion be required to both justify their need and be subject to some disclosure and retention policy for the data they do collect and retain. BDavis (WMF) (talk) 21:55, 20 May 2016 (UTC)
- Pretty much anything wanting to expose a network service to the world that isn't HTTP/HTTPS needs it's own public IP. What sort of disclosure and retention policy do you have in mind? --Krenair (talk • contribs) 22:10, 20 May 2016 (UTC)
- A listing of the data collected that could be considered sensitive (IP addresses, usernames, etc) and the duration for which that collected data is archived by the service. There may be some common classes of services that could be covered by a shared policy to make things easier for the people running the service. One example of a common class is irc bots which log content for the channels they join. BDavis (WMF) (talk) 22:18, 20 May 2016 (UTC)
Requirir la publicación de los códigos fuente de los proyectos de Labs
Although we ask developers in the Terms to “not use or install any software unless the software is licensed under an Open Source license,” many open source licenses do not require the publication of the source code where such software is used exclusively on the server side of a web service, as the case is for many projects hosted on Labs.
We are interested in whether we should have some sort of requirement (or encouragement) in the Terms for developers to publish their source code, except for perhaps security sensitive code. We are also interested in what type of processes we should set up to allow developers to easily do so. Requiring the publication of source code alleviates problems with abandoned projects, as tracked on Phabricator here. At the same time, we should think how we should handle enforcement on existing projects.
Por favor, comparta usted pensamientos acerca de si debemos exigir la publicación del código fuente en nuestros Términos y, en caso afirmativo, cuáles son los procesos sugeridos para permitir una fácil cumplimiento:
Discutir publicación de código fuente
Contribuir con una nueva idea, o hablar acerca de problemas a nivel de meta - ir a por ello!
Algunas preguntas abiertas son 1) hasta dónde queremos que Labs sea un servicio de alojamiento donde el trabajo esté en el desarrollador para comprometer apropiadamente a sus usuarios finales y 2) hasta dónde debería la Fundación Wikimedia desarrollar directrices, consistentes con nuestras políticas principales, para proteger directamente a los usuarios finales de los proyectos de Labs.
Muchas gracias por su tiempo, reflexión y sabiduría.