En realidad no contamos usuarios, sino solicitudes a los directorios que los clientes hacen periódicamente para actualizar su lista de repetidores y estimar números de usuario indirectamente desde allí.
No, pero podemos ver qué fracción de los directorios los reportaron, y luego podemos extrapolar el número total en la red.
Suponemos que el cliente promedio realiza 10 solicitudes de este tipo por día.
Un cliente tor que está conectado las 24 horas del día, los 7 días de la semana, hace unas 15 solicitudes por día, pero no todos los clientes están conectados las 24 horas del día, los 7 días de la semana, por lo que elegimos el número 10 para el cliente promedio.
Simplemente dividimos las solicitudes de directorio por 10 y consideramos al resultado como el número de usuarios.
Otra forma de verlo es que asumimos que cada solicitud representa a un cliente que permanece en línea durante una décima parte del día, es decir, 2 horas y 24 minutos.
Número promedio de usuarios concurrentes, estimado con datos recolectados a lo largo de un día. No podemos decir cuántos usuarios distintos hay.
No, los repetidores que reportan estas estadísticas agregan las solicitudes por país de origen, sobre un periodo de 24 horas.
Las estadísticas que necesitaríamos recolectar para el número de usuarios por hora serían demasiado detalladas, y podrían poner a los usuarios en riesgo.
Entonces contamos esos usuarios como uno. En realidad contamos clientes, pero es más intuitivo para la mayoría de las personas pensar en usuarios, por eso es que decimos usuarios y no clientes.
No, porque ese usuario actualiza su lista de repetidores tan frecuentemente como un usuario que no cambia la dirección IP a lo largo del día.
Los directorios resuelven direcciones IP a códigos de país, y reportan estos números en forma agregada. Esta es una de las razones de por qué tor viene con una base de datos de GeoIP.
Aún hay muy pocos puentes que reportan datos sobre transportes o versiones de IP, y por defecto consideramos solicitudes para usar el protocolo OR por defecto e IPv4.
Una vez que más puentes reporten estos datos, los números se tornarán más precisos.
Los repetidores y puentes reportan algunos de los datos en intervalos de 24 horas, los cuales pueden finalizar en cualquier momento del día.
Y luego de que se cumpla tal intervalo, los repetidores y puentes pueden tomar otras 18 horas para reportar los datos.
Descartamos los dos últimos días de los gráficos porque queremos evitar que el último punto de datos en un gráfico indique un cambio reciente en la tendencia, lo cual es de hecho solo una aberración del algoritmo.
La razón es que publicamos números de usuario una vez que tenemos la confianza suficiente de que no cambiarán significativamente.
Pero siempre es posible que un directorio reporte datos unas pocas horas después de que tuviéramos la confianza suficiente, lo cual cambió al gráfico levemente.
Tenemos archivos descriptores desde antes de ese momento, pero esos descriptores no contenían todos los datos que usamos para estimar el número de usuarios.
Por favor encuentra el siguiente archivo .tar para más detalles:
Archivo .tar
Para usuarios directos, incluimos todos los directorios, lo cual no hacíamos con el enfoque anterior.
También usamos historiales que solo contienen bytes escritos para responder a solicitudes de directorio, lo cual es más preciso que usar historiales de bytes generales.
Oh, esa es una historia completamente diferente. Escribimos un reporte técnico de 13 páginas explicando las razones para retirar la forma vieja.
resumiendo, en nuestro enfoque anterior medíamos la cosa equivocada, y ahora medimos la correcta.
Corremos un sistema de detección de censura basado en anomalías que contempla números estimados de usuarios sobre una serie de días y predice el número de usuarios en los días siguientes.
Si el número real es más alto o más bajo, esto podría indicar un posible evento de censura o disminución de la misma.
Para más detalles, mira nuestro reporte técnico.