Consulta sobre los términos de uso de Wikimedia Labs - Primera ronda (2016)

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

Comment in this section

• 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.

What we really want to stop is embedding links to 3rd party resources (javascript, images, css, iframes) directly in the application pages. The problematic aspect of embedded 3rd party resources is that they compel the visitor's browser to interact directly with the 3rd party which exposes their IP address and allows cookies to be attached to their browsing session. This sort of behavior is "normal" on the modern Internet, but it is in reality a breach of privacy that we can and should avoid. A tool hosted in Labs/Tool Labs should be just as respectful for an individual's privacy rights as the production Wikipedia and sister projects are in my opinion. BDavis (WMF) (talk) 21:37, 20 May 2016 (UTC)

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.

Google's reCAPTCHA service is one of types of forced browser interactions I would most like to see avoided on the wmflabs.org domain. reCAPTCHA comes with Google's blanket privacy policy and has been documented as performing device fingerprinting and setting long lived cookies. As stated elsewhere, I understand that these practices are common on the Internet of 2016, but I personally believe that Wikimedia can be better than common. BDavis (WMF) (talk) 19:03, 21 May 2016 (UTC)

reCaptcha vastly outperforms opensource captcha implementations both in terms of difficulty to crack and ease of use. Given the choice, many users would willingly share private data to avoid the poor usability and waste of time that comes with the usual "try to beat a computer at recognizing horribly distorted letters" captchas. Also, how does reCaptcha compare with locally hosted alternatives in terms of difficulty of setting up? I think efforts should be focused instead on creating Labs' own captcha service that can be used by any Labs developer just by plugging in a few lines of javascript, and this proposal could be resumed afterwards. --Tgr (talk) 10:11, 22 May 2016 (UTC)

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)

• Replacing an externally hosted JS file with a locally hosted one is not too much effort and can be reasonably expected from a Labs developer. Replacing browser-initiated calls to third-party services with ones that are proxied through the Labs machine *is* much effort, and might not be possible at all. Tools that pass data to third-party sites should require a clear warning and allow users to leave before any data transfer happens; I'm not sure enforcing anything more than that via the TOU is a good idea. (Tools used on WMF sites should of course follow the WMF privacy policy. Arguably, tools linked from WMF sites should as well, although that sounds unfeasible in practice.) --Tgr (talk) 10:11, 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

We are generally very concerned about privacy issues with projects hosted on Tool Labs since they may be used as tools and extensions on our main Projects and end-users have no easy way to ascertain the privacy policy of these tools and extensions before they are used. To protect our end-users, we can clarify the Terms to require developers of Tool Labs projects to always ensure their projects adhere to the Wikimedia Foundation Privacy Policy. Our understanding is that this requirement has already been generally enforced by Labs administrators. On the other hand, if the Wikimedia Foundation Privacy Policy is too restrictive for application to all projects on Tool Labs, perhaps a custom Privacy Policy applicable to all Tool Labs projects could be used instead.

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.

Discuss Privacy Policy of Tool Labs

Comment in this section

Can you summarize what requiring the WMF privacy policy would actually mean for Labs tool owners? Not using third-party resources + keeping private data secret? --Tgr (talk) 09:53, 22 May 2016 (UTC)

• The WMF Privacy Policy is so vague that most Tool Labs applications already adhere to it except for "Identifying user-agent information of site visitors" in the Data retention guidelines (and it is unclear to me as NAL if those guidelines are binding or not). Who will counsel application developers on the details? Who will review applications if they actually comply with it? I think it is better not to raise the expectation that Labs applications by random strangers will be "good"; instead, (as said above) applications that are useful for a wider range of audience should be moved to extensions, gadgets or applications in a separate Labs with tighter oversight (no code not reviewed for privacy, etc.). --Tim Landscheidt (talk) 23:53, 23 May 2016 (UTC)

@Tgr: Some requirements from the Privacy Policy that might be applicable to a Tool Labs project include the following:

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.

Note currently some of the syntax and language in the WMF Privacy Policy, where they reference the main WMF sites, might need to adjusted in any version we provide for Tool Labs developers and end-users.

@Tim.landscheidt: Our understanding is that currently Tool Labs projects already adhere to the Privacy Policy, as enforced by Labs administrators. So in that respect, this will just be a documentation of existing policies. You are right though that by documenting this, we might be making a stronger representation to our end-users so we will have to figure out a better way to make this work for developers if we decide on this route. As for the data retention guidelines, we are open to hearing whether or not the terms of the guidelines would be workable for developers.--ZZhou (WMF) (talk) 07:26, 24 May 2016 (UTC)

Privacy Disclaimers

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

Comment in this section

• I think that making users write their own disclaimers will be a disaster as they're not lawyers and many of them aren't even native English speakers. At most, we could recommend a link to Labs' overall privacy policy. Max Semenik (talk) 21:20, 20 May 2016 (UTC)

  Must the disclaimers be in English? Where is this limitation coming from? --Base (talk) 07:21, 31 May 2016 (UTC)

  @Base: The Labs Terms of Use appears to indicate the specific disclaimer language (which is in English) must be published. If WMF were to provide the disclaimer language for developers, how do you propose we address the issue of other languages? --ZZhou (WMF) (talk) 20:56, 1 June 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

Comment in this section

• 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

Comment in this section

Discusión abierta

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.

Discusión abierta

Comment in this section