Perché una directory VPN non può garantire per il nodo che le sta dietro
Una scheda descrive una connessione e la directory che l'ha pubblicata. La raccolta e la conservazione spettano all'operatore, che può essere un'altra parte.
Le voci di directory che elencano un nome host, un paese e un insieme di protocolli sono prove sulla connettività, non su ciò che registra la macchina dall'altra parte. La decisione che conta qui non è se fidarsi degli elenchi in generale. È quale parte è in grado di rispondere alla domanda che state davvero ponendo.
Quattro parti dietro una voce
Separete i ruoli prima di leggere qualsiasi promessa. La directory pubblica la voce, il progetto software fornisce l'implementazione del protocollo, il provider di hosting fornisce la macchina e la rete, e l'operatore del nodo configura il servizio. Ciascuna delle quattro può essere un'organizzazione diversa, e ciascuna può parlare solo per la propria parte.
Questa separazione spiega perché un'affermazione può essere vera e comunque inutile. Uno sviluppatore che documenta che il protocollo non registra il carico utile non dice nulla di un operatore che ha attivato la registrazione dettagliata delle connessioni su un relè. Entrambe le affermazioni possono convivere senza contraddizione. È proprio per questo che la domanda va rivolta a una parte nominata.
Alcuni servizi gestiscono i propri punti di uscita, e allora la voce e la politica provengono dalla stessa parte. È una posizione più solida, ma va comunque dimostrata invece di presunta dal formato della pagina. Chiedete la dichiarazione e verificate che nomini il servizio verso cui punta la voce.
Chiedete il documento che corrisponde all'affermazione
Un'affermazione sulla raccolta richiede un documento che nomini il sistema, la categoria di dati e il periodo. Un'affermazione sulla conservazione richiede un numero e una portata. Un'affermazione sull'indipendenza richiede una descrizione di chi possiede cosa, non un aggettivo.
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
I progetti volontari sono spesso l'esempio più chiaro, perché alcuni pubblicano requisiti espliciti di registrazione per i nodi che accettano. Quel documento è una prova primaria sulle regole del progetto, e non è ancora una prova su un singolo operatore che le abbia ignorate.
Gli audit seguono la stessa logica su un'altra scala. Un rapporto che ha esaminato un'implementazione specifica in una finestra specifica è utile entro quel confine. Steso su ogni istanza indipendente dello stesso software, diventa una garanzia che nessuno ha rilasciato. Leggete il paragrafo sulla portata prima di leggere la conclusione.
Quando l'informativa sulla privacy di un fornitore copre il suo stesso servizio, leggetela come la dichiarazione di quel fornitore sui propri sistemi. Riusarla per descrivere un relè di terzi è un errore di categoria, anche quando il protocollo è identico.
Decidete cosa acquistate con ogni opzione
Un nodo pubblico acquista raggiungibilità e varietà al prezzo della responsabilità. Un operatore che non vi deve nulla può sparire, cambiare configurazione o conservare registri senza preavviso, e il vostro rimedio si limita a cambiare punto di uscita. Questo scambio è accettabile per alcuni compiti e non per altri.
Un servizio a pagamento acquista una controparte con una politica pubblicata e qualcosa da perdere. Non acquista una garanzia tecnica e non elimina la necessità di leggere la politica, ma un'organizzazione nominata con una dichiarazione di conservazione è più facile da valutare di un relè anonimo.
La regola decisionale che sopravvive a entrambi i casi è adeguare la prova al rischio. Se il compito tollera un punto di uscita mutevole, la directory è uno strumento efficiente. Se dipende da una promessa precisa sul trattamento dei dati, conta solo la parte che può fare quella promessa, e la directory è una comodità di instradamento, non un'assicurazione.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'Il comando qui sopra vale la pena di eseguirlo perché separa nettamente due domande. Mostra l'indirizzo che il vostro traffico ha effettivamente usato, il che è un fatto di connettività, e non dice nulla su ciò che l'operatore di quell'indirizzo ha fatto con i metadati della connessione.
Tenete separate le domande lato client
La politica dell'operatore è uno strato, e la sicurezza di ciò che fate nel tunnel è un altro. HTTPS a destinazione, la gestione della sessione nel browser e la robustezza dell'account con cui siete entrati restano i vostri controlli, e un relè permissivo non li indebolisce mentre uno eccellente non li rafforza.
Questa separazione evita due errori comuni. Considerare una politica rigorosa dell'operatore come motivo per saltare HTTPS è uno, e considerare una connessione HTTPS funzionante come motivo per ignorare chi gestisce il relè è l'altro. Entrambi gli errori fondono due strati in uno e poi discutono di quello sbagliato.
Una breve valutazione scritta affronta entrambe le cose. Nominate la parte che fa ogni promessa, allegate il documento che la sostiene e annotate la data. Poi decidete se il compito ha bisogno dell'affermazione più forte o solo di un percorso funzionante.
La voce ha fatto il suo lavoro quando vi ha detto dove potevate connettervi. Il resto della domanda appartiene a chi gestisce quel punto di uscita, e la risposta onesta è spesso che non potete saperlo e dovreste scegliere di conseguenza.