Preguntas Frecuentes

Preguntas reales de integraciones reales. Si la tuya no está aquí, la página de contacto recibe una respuesta real de alguien que conoce el producto.

¿Funciona esto con Tor?

Sí. El tráfico procedente de nodos de salida de Tor comienza con un nivel de riesgo moderado — es una ruta de anonimización conocida — pero seguimos leyendo el cuadro completo de la sesión. Si tu aplicación da la bienvenida explícitamente a usuarios de Tor — periodismo, búsquedas sensibles o flujos para sobrevivientes de abuso — puedes indicarle a Noxtica que deje de contar la señal de Tor en la puntuación mientras mantiene activas todas las demás señales. La señal sigue visible en el resultado de cualquier forma. Tú decides si cuenta.

Para el razonamiento completo sobre por qué los usuarios de Tor no se bloquean automáticamente, consulta Tratamiento de navegadores de privacidad en la documentación de categorías de amenazas.

¿Qué pasa con los navegadores centrados en la privacidad — Brave, LibreWolf, Tor?

Todos funcionan. Cada navegador de privacidad tiene una forma característica que reconocemos a partir de nuestros datos de población. Las funciones de prevención de rastreo no rompen la verificación; simplemente producen un perfil diferente pero igualmente coherente. Tratamos el nivel de protección como una señal honesta en lugar de penalizar al usuario en silencio por haberlo elegido.

Esto es el principio 03 (los falsos positivos no son pérdidas aceptables) en la práctica. Bloquear a un usuario de Brave te cuesta un cliente que eligió específicamente un navegador de privacidad. La contrapartida no vale la pena, y la calibración lo refleja.

¿Cuánto añade a mi página?

Muy poco. La primera carga es pequeña porque las mediciones pesadas solo se activan cuando la página solicita una puntuación. Todo se carga en segundo plano y nunca retrasa que la página sea usable. Los visitantes que regresan envían una señal aún más pequeña. En la práctica, el usuario nunca nota que está ahí.

¿Necesitamos ejecutar un backend?

Sí. El colector corre en el navegador y produce un resultado sellado; la verificación real ocurre en tu servidor a través de nuestra API. Dado que el cuadro completo viaja dentro de ese resultado sellado, verificarlo es rápido — no hay nueva recopilación de datos ni consultas de red adicionales mientras una solicitud está en vuelo. El resultado se verifica en unos pocos milisegundos.

La razón por la que el backend es necesario: un veredicto tomado puramente en el navegador es trivialmente falsificable. El resultado sellado es la garantía de que nada fue manipulado tras la recopilación, y verificar esa garantía en tu propio backend de confianza es lo que hace que todo el sistema sea confiable.

¿Cumplís con la normativa de privacidad?

Actuamos como subencargado del tratamiento bajo tu acuerdo de procesamiento de datos, y tenemos el nuestro propio disponible bajo solicitud. Tratamos los datos que manejamos como datos personales, porque podrían re-identificar a un visitante recurrente, y aplicamos el conjunto completo de controles que eso implica. La infraestructura permanece en la UE sin transferencias fuera de ella. La eliminación definitiva está disponible bajo solicitud a través del backoffice, y podemos firmar acuerdos en un día. Nuestra lista de subencargados está en /subprocessors.

Algunos detalles específicos que los responsables de protección de datos preguntan:

• Base legal: recomendamos la base de interés legítimo para la prevención del fraude en la mayoría de las integraciones. También se admiten flujos de consentimiento.
• Minimización de datos: lo que almacenamos es un resumen mezclado unidireccional, no valores en bruto. No podemos reconstruir las señales originales a partir de él.
• Derecho de supresión: la eliminación se aplica en la capa de almacenamiento, no como un indicador lógico. Una vez eliminados, los datos desaparecen definitivamente.
• Solicitudes de acceso de interesados: proporcionamos un mecanismo para devolver todo lo asociado a un visitante dado, acotado a tu cuenta.

¿Cuál es vuestra tasa de falsos positivos?

Depende de dónde fijes tu umbral. Con nuestros valores conservadores por defecto, nuestro benchmark interno contra millones de sesiones reales y verificadas mide bastante por debajo del medio por ciento. Si reservas la acción solo para el nivel más extremo, la tasa cae cerca de cero. Ambas cifras se mantienen actualizadas y son visibles en el panel del operador, desglosadas por familia de navegador y país para que puedas ver exactamente de dónde vienen los errores.

Cómo lo medimos: mantenemos un conjunto de referencia etiquetado de sesiones humanas reales y sesiones automatizadas conocidas, actualizado cada trimestre. Cada cambio en la puntuación se somete a benchmark contra el conjunto completo antes de publicarse.

Si quieres ejecutar el benchmark sobre tu propio tráfico, el panel del operador exporta tus sesiones con sus niveles de riesgo, las razones detrás de cada puntuación y tu propia etiqueta de resultado para que puedas calcular tu propia tasa.

¿Qué ocurre si vuestro servicio cae?

El colector sigue funcionando. Los resultados se ponen en cola localmente y se envían cuando se recupera la conexión. Si la verificación no está disponible pasado tu tiempo de espera, Noxtica devuelve un resultado seguro y neutro con un marcador claro de “no disponible”, para que tu código pueda recurrir a una política más suave — desafiar en lugar de bloquear, por ejemplo. Publicamos un objetivo de disponibilidad del 99,95 % y una página de estado pública en status.noxtica.com. La disponibilidad reciente ha superado ese objetivo.

El marcador de “no disponible” es la señal para tu alternativa de respaldo. Un formulario de registro podría aplicar un desafío suave, un formulario de pago podría bloquear, y una API de solo lectura podría simplemente permitir — el valor por defecto correcto depende de tu tolerancia al riesgo en esa superficie.

¿Puedo ejecutarlo en mis propios servidores?

Sí. El colector y el verificador se distribuyen como imágenes autocontenidas y firmadas para clientes Enterprise. El mismo formato de perfil, las mismas señales, los mismos niveles de riesgo, sin dependencia de la nube. Recibes las actualizaciones según tu propio calendario, y las instalaciones en entornos sin conexión a internet están soportadas con un paquete de actualización offline. Habla con nosotros al respecto.

Las instalaciones propias las suelen solicitar industrias reguladas — banca, sanidad, gobierno — donde las normas de residencia de datos descartan un verificador hospedado. La contrapartida es operativa: tú mantienes el verificador, extraes las actualizaciones y ejecutas los benchmarks de calibración. Nosotros proporcionamos el software y el manual de operaciones; tu equipo lo opera.

¿Cómo gestionáis los widgets embebidos e iframes?

El colector detecta cuando se ejecuta dentro de un iframe embebido y ajusta lo que mide — algunas señales siguen funcionando, pero con menos detalle. Presentamos el contexto embebido como una señal honesta, nunca como riesgo automático. Lo que sí importa es cuando el iframe embebido y la página principal se contradicen, porque eso es una señal conocida de automatización. Tú decides qué significan los iframes embebidos para tu aplicación.

El uso legítimo de iframes es habitual — widgets de pago, herramientas de terceros, vistas previas de contenido — y tratar los iframes como riesgo automático bloquearía a clientes reales. La contradicción es la señal que importa: un iframe genuino hereda un estado coherente de su página padre, mientras que uno controlado por automatización a menudo no.

¿Qué envía el colector por la red?

Cuando se puntúa la página: un resultado sellado, de unos pocos kilobytes, enviado a tu propio endpoint. Cuando tu servidor lo verifica: solo ese resultado. Sin telemetría adicional, sin balizas de analítica, sin fuentes cargadas desde otro sitio, sin llamadas a terceros en ningún punto del camino. El resultado sellado es la única carga útil — y puedes abrirlo localmente para ver exactamente qué contiene.

Puedes confirmarlo todo en el panel de red de tu navegador durante la integración. La única solicitud que el colector hace es a tu propio endpoint del mismo origen. Nada va a Noxtica desde el navegador durante la recopilación; la verificación ocurre después, de servidor a servidor, desde tu backend.

¿Puedo personalizar los umbrales de riesgo?

Sí. Los valores por defecto son conservadores a propósito (consulta el principio 03). Puedes ajustar dónde se activa cada nivel, por clave, en la consola del operador. El ajuste se hace a nivel de umbral, no en los componentes internos del modelo — no queremos que los clientes individuales remodelen el modelo de formas que se alejen del benchmark de calibración.

Si necesitas un ajuste más profundo, eso es una conversación Enterprise. Lo soportamos para instalaciones propias, donde el benchmark puede re-ejecutarse contra tu propio tráfico.

¿Cuál es la diferencia entre Noxtica y un CAPTCHA?

Un CAPTCHA le pide al usuario que demuestre que es humano. Noxtica le pide al navegador que describa lo que es y luego pondera esa descripción frente a la población general. Los dos son complementarios, no sustitutos.

Muchas integraciones usan Noxtica para decidir si mostrar un CAPTCHA. Una sesión sospechosa recibe el desafío; una limpia no. Esa combinación elimina el CAPTCHA para la gran mayoría de usuarios reales, que nunca llegan a verlo.

Lecturas relacionadas

• Primeros pasos — el recorrido de integración.
• Runtime del navegador — qué hace el colector en el momento de la recopilación.
• Integración con el backend — cómo funciona la verificación en tu servidor.
• Categorías de amenazas — qué detectamos y por qué.