In realtà non contiamo gli utenti, ma contiamo le richieste alle directory che i client fanno periodicamente per aggiornare il loro elenco di relay e stimiamo il numero di utenti indirettamente da lì.
No, ma possiamo vedere quale frazione di directory li ha segnalati e quindi possiamo stimare il numero totale nella rete.
Abbiamo ipotizzato che il client medio faccia 10 di queste richieste al giorno.
Un client tor che è connesso 24 ore su 24, 7 giorni su 7 fa circa 15 richieste al giorno, ma non tutti i client sono connessi 24 ore su 24, 7 giorni su 7, quindi abbiamo scelto il numero 10 per il client medio.
Dividiamo semplicemente le richieste di directory per 10 e consideriamo il risultato come numero di utenti.
Un altro modo di vedere la cosa è assumere che ogni richiesta rappresenti un client che rimane online per un decimo della giornata, quindi 2 ore e 24 minuti.
La media degli utenti simultanei, stimata dai dati raccolti durante il giorno. Non possiamo sapere quanti utenti distinti si sono.
No, i relay che riportano queste statistiche aggregano le richieste per paese di origine e su un periodo di 24 ore.
Le statistiche che dovremmo raccogliere per il numero di utenti all'ora sarebbero troppo dettagliate e potrebbero mettere a rischio gli utenti.
Poi contiamo questi utenti come un unico utente. Contiamo davvero i client, ma è più intuitivo per la maggior parte delle persone pensare agli utenti, ecco perché diciamo utenti e non client.
No, perché l'utente aggiorna l'elenco dei relays con la stessa frequenza di un utente che non cambia l'indirizzo IP nel corso della giornata.
Le directory risolvono gli indirizzi IP in codici paese e riportano questi numeri in forma aggregata. Questo è uno dei motivi per cui tor viene fornito con un database GeoIP.
Pochissimi bridge riportano dati sui trasporti o sulle versioni IP, e di base consideriamo che le richieste usino il protocollo predefinito OR e IPv4.
Quando più bridge riporteranno questi dati, i numeri saranno più accurati.
I relay e i bridge riportano alcuni dei dati a intervalli di 24 ore che possono terminare in qualsiasi momento della giornata.
E dopo un tale intervallo, i relay e i bridge potrebbero impiegare altre 18 ore per riportare i dati.
Abbiamo tagliato gli ultimi due giorni dai grafici, perché vogliamo evitare che l'ultimo punto di dati di un grafico indichi un cambiamento di tendenza recente che è in realtà solo un artefatto dell'algoritmo.
Il motivo è che pubblichiamo i numeri degli utenti quando siamo abbastanza sicuri che non cambieranno più in modo significativo.
Ma è sempre possibile che una directory riporti dati alcune ore dopo che eravamo sicuri, ma che poi abbiano leggermente cambiato il grafico.
Abbiamo archivi descrittivi prima di quella data, ma non contengono tutti i dati che usiamo per stimare il numero di utenti.
Vedi la seguente tarball per maggiori dettagli:
Tarball
Per gli utenti diretti, includiamo tutte le directory che non avevamo incluso nel vecchio approccio.
Utilizziamo anche storici che contengono solo i byte scritti per rispondere alle richieste di directory, il che è più preciso rispetto all'uso degli storici generali dei byte.
Oh, è tutta un'altra storia. Abbiamo scritto un report tecnico di 13 pagine che spiega i motivi del ritiro del vecchio approccio.
tl;dr: nel vecchio approccio misuravamo la cosa sbagliata, invece ora quella giusta.
Gestiamo un sistema anonimo di rilevazione censure che controlla il numero stimato di utenti in una serie di giorni e prevede il numero di essi nei giorni successivi.
Se il numero effettivo è più alto o più basso, potrebbe indicare un possibile evento di censura o un'attenuazione di essa.
Per maggiori dettagli, vedi il nostro report tecnico.