Con el objetivo de proteger la seguridad y la soberanía de cada uno de los usuarios de Firefox, Mozilla solicita que todos los complementos cumplan con una serie de normativas sobre prácticas aceptables. El número exacto de normativas aplicables difiere en función de varias circunstancias, la más importante de las cuales trata de si el complemento se aloja en addons.mozilla.org (en lo sucesivo AMO) o no y la forma en que éste se distribuye al público.

Este documento describe las normativas que se espera que respeten las distintas clases de complementos. Independientemente de la clase de complemento de que se trate, estas normativas son aplicadas por medio de un proceso de revisión facilitado por AMO, así como por una comprobación de firma de código obligatoria, ejecutada por Firefox.

Vías de revisión de complementos

Catalogación en AMO

Los complementos catalogados en AMO están sujetos a revisión. Cuando esté a la espera de una revisión, un complemento será accesible a los usuarios que posean un enlace directo a su página del catálogo. No aparecerá en las páginas de categorías, en colecciones ni en los resultados de búsquedas. Una vez aprobados, estos complementos tendrán una página pública del catálogo que incluirá capturas de pantalla, descripciones y reseñas de los usuarios; asimismo, la página podrá aparecer en resultados de búsquedas, colecciones y promociones ocasionales. Los usuarios existentes recibirán automáticamente actualizaciones por cada versión nueva que se publique en AMO. Los complementos catalogados pueden quedar sujetos a revisiones de código completas y pruebas de funcionamiento. De estos complementos se exige un estándar de calidad alto.

Descatalogación

Los complementos descatalogados deben cargarse en AMO antes de su distribución pero, por lo demás, no son accesibles al público a través del sitio. Los propietarios de estos complementos deben distribuirlos de manera externa. En función de la manera de distribuirlos, los complementos descatalogados reciben una revisión completamente automatizada, con posibles revisiones de código posteriores a la firma de código.

Aunque estos complementos se firman automáticamente, también se espera que éstos cumplan con estándares semejantes a los aplicables a los complementos catalogados. La diferencia principal es que los descatalogados deben gestionar sus propias actualizaciones.

Normativas

La tabla siguiente perfila las normativas principales que se aplican por cada vía de revisión. Dichas normativas se exponen con más detalle más abajo. Los símbolos que aparecen después de cada clase de revisión denotan la forma en que cada requisito se aplica a los complementos de cada tipo, tal como se indica a continuación:

  El requisito no se aplica a esta vía de revisión.
Los complementos en esta vía de revisión tienen prohibido emprender estas acciones.
Los complementos en esta vía de revisión deben funcionar tal como se indica.
  Catalogados No catalogados
Seguridad  
Provocar perjuicios a los datos, los sistemas o las identidades virtuales de los usuarios
Crear o exhibir vulnerabilidades de seguridad
Interferir con los sistemas de actualización de la aplicación o de los complementos, o bien, con el sistema de lista de bloqueo
Ejecutar código remoto¹  
Degradar la seguridad de sitios HTTPS
Instalar complementos adicionales o aplicaciones de sistema sin el consentimiento del usuario  
Incluir su propio mecanismo de actualizaciones  
Privacidad y consentimiento de usuario  
Realizar cambios inesperados al navegador o al contenido web
Impedir a los usuarios que reviertan los cambios hechos por el complemento
Impedir que el complemento aparezca en el Gestor de complementos
Impedir a los usuarios que desactiven o desinstalen el complemento
Enviar información confidencial a servidores remotos sin protecciones
Almacenar datos de navegación provenientes de ventanas privadas  
Filtrar información identificatoria al contenido web en ventanas de navegación privada  
Modificar preferencias de Firefox sin el consentimiento del usuario  
Divulgar de forma clara todo el manejo de datos de usuarios en un aviso de privacidad  
Experiencia de usuario  
Dañar o desactivar funcionalidades básicas de la aplicación
Realizar cualesquier cambios que persistan tras desactivar o desinstalar el complemento
Ser fácil de utilizar y brindar una experiencia de usuario coherente  
Solicitar pagos para hacer uso de funciones básicas del complemento (inmediatamente o tras un período de prueba)  
Contenido  
Contravenir las Condiciones de uso de Mozilla  
Estar destinado a usos internos empresariales, personales o de pruebas  
Aspectos técnicos  
Compartir el código fuente completo con los revisores ²
Emplear bibliotecas o marcos de terceros no supervisados  
Contener errores de programación obvios  
Entrar en conflicto con otros complementos que funcionen correctamente³  
Utilizar API conocidas por causar problemas de rendimiento o de estabilidad  
¹ Se puede ejecutar código remoto en documentos cuyo origen sea el mismo que el del código por ejecutar, o bien, en circunstancias especiales, bajo un confinamiento cuidadoso. No se permite jamás la ejecución de código remoto en entornos con privilegios.
² Los creadores de complementos descatalogados deben proporcionar su código fuente cuando se solicite explícitamente. Lo contrario podría resultar en un bloqueo del complemento.
³ Puede que resulte imposible que todos los complementos puedan evitar entrar en conflicto con el resto. A los complementos que, por su naturaleza, no pueden coexistir, se les puede permitir entrar en conflicto. Empero, no se tolerarán conflictos debidos a prácticas técnicas deficientes.
⁴ En los complementos no se deberían emplear API que se hayan descontinuado por motivos de rendimiento o de estabilidad, incluidos los procesos de escucha de sucesos de mutación de DOM, las solicitudes sincrónicas XMLHttpRequests y las llamadas a la API Storage, así como código que reingrese al bucle de sucesos principal. Todo ello podría permitirse en situaciones muy puntuales, en las que las alternativas resulten imprácticas, o bien durante un período de gracia para la reimplementación, pero tales excepciones son raras y, como regla general, se han de evitar estas API.
⁵ Es necesario enviar por separado el código fuente completo si el complemento utiliza ofuscación, minificación o trascompilación para generar código fuente JavaScript, o bien si se emplean archivos binarios ejecutables, incluidos los ejecutables y las bibliotecas de sistema. Asimismo, podrían solicitarse instrucciones y herramientas necesarias para reproducir la ofuscación. Aquellos complementos que incluyan únicamente código en JavaScript en lenguaje natural no necesitan enviar su código por separado.
⁶ Los usuarios deben ser capaces de desactivar y desinstalar el complemento mediante la interfaz del Gestor de complementos. Proveer métodos secundarios de desinstalación (tales como desinstaladores a nivel sistema) a la vez que se impide realizar este proceso con el Gestor de complementos no satisface este requisito.

Seguridad

Como los complementos se ejecutan en un entorno de privilegios elevados con relación a las páginas web comunes y corrientes, ellos plantean una gama de consideraciones de seguridad muy importantes. Los complementos tienen el potencial de abrir brechas de seguridad no solo sobre sí mismos, sino también en el navegador, en las páginas web y, en casos particularmente inquietantes, en la totalidad del sistema operativo en que se ejecuta el navegador. Por ende, nos tomamos muy en serio nuestas normativas de seguridad y aplicamos la mayoría de ellas a todos los complementos, se alojen en AMO o no. Se espera que todos los complementos sean seguros, no solo con respecto al manejo de sus propios datos, sino además con respecto a todas sus interacciones con la Web, el navegador y el sistema operativo.

Privacidad y consentimiento de usuario

Nos tomamos muy en serio la soberanía y la privacidad de los usuarios. Exigimos que todos los complementos, alojados o no en AMO, respeten las elecciones de los usuarios y sus expectativas razonables de privacidad. En particular, esto significa que los complementos no pueden limitar el control que los usuarios ejercen sobre sus navegadores, por ejemplo, al imposibilizar realizar cambios permanentes de configuración (como la página de inicio y el buscador), impedir que los usuarios los desinstalen, ocultar su presencia de ellos o instalar botones u otros elementos en la interfaz de usuario que no puedan eliminarse de forma perenne mediante el proceso de personalización.

Puede que se exija que funciones tales como la provisión de publicidad y el seguimiento de las actividades del usuario deban configurarse como de adhesión explícita (y no activarse subrepticiamente), o por lo menos ofrecer una opción para inhabilitarlas, en función del impacto en la privacidad y la seguridad y de la valoración que se realice sobre si la función es crucial para el funcionamiento del complemento. Como por lo general estas funciones son destinadas a la monetización y no tienen relación con el propósito del complemento, normalmente a los complementos catalogados se requiere la provisión de una interfaz de adhesión explícita a dichas funciones, y una función de inhabilitación para los complementos no catalogados. Algunos métodos de seguimiento, como la recolección de los URL visitados, están prohibidos aun para los complementos no catalogados. La decisión de activar o desactivar estas funciones y sus implicaciones ha de exponerse de manera clara al usuario.

Experiencia de usuario

Esperamos que todos los complementos funcionen sin impactar demasiado la experiencia del usuario con el navegador. En particular, los complementos no deben afectar negativamente el rendimiento, descomponer funcionalidades incorporadas o dañar la interfaz de usuario. Con los complementos catalogados en AMO, esperamos igualmente una experiencia consistentemente positiva para cualquier función provista por el complemento.

Contenido

Mientras que no tenemos ningún interés en controlar los tipos de funcionalidades ofrecidas por los complementos existentes, hay algunas clases de contenidos que addons.mozilla.org no puede alojar. En concreto, todo lo que aloje el sitio debe conformarse a las leyes de los Estados Unidos y las Condiciones de uso de Mozilla.

Aspectos técnicos

En la medida de lo posible, tratamos de no restringir la libertad de los programadores de dar mantenimiento a sus complementos tal como lo deseen. Sin embargo, por motivos de seguridad y para conservar nuestra capacidad de revisar código eficazmente, contamos con algunos requisitos técnicos. En concreto, las API potencialmente dañinas, como las que evalúan HTML y JavaScript, deben utilizarse solo en formas cuya inocuidad esté demostrada, y cualquier código que no podamos verificar para probar su comportamiento seguro y correcto quizá deba recibir una refactorización.

Envío de código fuente

Tanto los complementos catalogados como los no catalogados pueden contener código fuente binario, ofuscado o minificado, pero se debe permitir a Mozilla revisar una copia del código en lenguaje natural si así lo solicitare. En estos casos, el autor recibirá un mensaje de Mozilla en el que se pedirá su cooperación para la revisión. El código fuente recibirá una revisión por parte de un administrador y no se redistribuirá de ninguna manera. Solamente se utilizará el código con el objeto de revisar el complemento.

Asimismo se necesitan instrucciones para reproducir la ofuscación utilizada. Consúltense los detalles de esta directriz para garantizar una revisión ágil.

Si su complemento contiene código que no es suyo o del cual no puede obtener la fuente, puede ponerse en contacto con nosotros para recibir información sobre cómo proceder.

Revisores

El equipo de revisores de AMO se encargará de revisar su complemento. Éste es un grupo de desarrolladores experimentados de complementos que se ofrecen como voluntarios para ayudar al proyecto Mozilla para garantizar una experiencia estable y segura para los usuarios. La Guía de revisión pormenoriza cómo los revisores evalúan los complementos presentados para su revisión. Se trata de una versión ampliada de la tabla anterior. Los programadores recibirán un mensaje de correo electrónico con cualquier novedad sobre el proceso de revisión. Los tiempos de revisión pueden variar según la disponibilidad de revisores y la complejidad del complemento en evaluación. En el  blog de complementos se publican puestas al día periódicas sobre el estado de la cola de revisión.

Bloqueo

Aquellos complementos que no cumplan con las expectativas de calidad para pertenecer al repertorio «No publicados» podrían clasificarse en la lista de bloqueo, según la magnitud de sus problemas. El equipo de Complementos hará su mejor esfuerzo para contactar a los desarrolladores del complemento y ofrecerán un plazo razonable para que se corrijan los problemas detectados antes de que se emita un bloqueo. Si se considera que un complemento es malicioso o sus creadores se han vuelto inubicables o dejan de responder, o bien, en casos de infracciones reiteradas, los bloqueos podrán ser inmediatos.

Se debe dar parte de cualquier transgresión a las directrices a través de Bugzilla (en inglés), en la categoría «Tech Evangelism» → «Add-ons». Para realizar preguntas, utilice el canal #addons de IRC.

Etiquetas y colaboradores del documento

 Colaboradores en esta página: fitojb
 Última actualización por: fitojb,