Il test comincia con una frase che qualcuno vuole vera, e le prove sostengono o una versione ristretta di quella frase o nulla. Un controllo dell'indirizzo pubblico mostra quale uscita ha usato una richiesta. Non mostra cosa trattiene il fornitore, chi può leggerlo, né cosa accade a una sessione che non si completa mai. Percorrere il test come procedura documentata vi impedisce di affermare più di quanto la misura possa sostenere.

Scegliete un'asserzione osservabile

Scrivete l'asserzione come un'unica frase verificabile prima di aprire qualsiasi strumento: per questo profilo, su questa rete, le richieste verso un'eco di indirizzo pubblico escono dall'uscita dichiarata del fornitore. Quella frase nomina un soggetto, una condizione e un'osservazione, ed è ciò che la rende confutabile. Un'asserzione come la VPN protegge la privacy non ha forma osservabile, quindi nessuna misura può risolverla. Tenete una seconda frase per ciò che il test non coprirà, perché la conservazione, l'accesso di terzi e la correlazione del traffico restano tutti fuori da un test nel browser.

Scrivete quella seconda frase in anticipo, non dopo l'arrivo del risultato. È molto più facile essere onesti sull'ambito finché l'esito è ancora ignoto che dopo che uno screenshot rassicurante è atterrato nel ticket. Una nota sull'ambito aggiunta in seguito tende a descrivere il risultato invece della domanda.

Fatti di allestimento che un lettore deve conoscere per ripetere la misura

L'allestimento è ciò che rende riproducibile un risultato, ed è ciò che la gente salta quando la risposta sembra buona. Le stringhe di versione, i nomi dei profili, la rete di accesso e le famiglie di indirizzi appartengono alla nota, insieme a qualsiasi regola di suddivisione del tunnel che potrebbe portare traffico fuori dal tunnel. Nominate anche l'evento in prova, perché una connessione funzionante, un'interruzione inattesa, una disconnessione manuale e un passaggio di rete esercitano regole diverse. Un test che mescola questi eventi dimostra poco su ciascuno di essi.

Usate traffico non sensibile in un ambiente in cui siete autorizzati a fare test. Catturare pacchetti non correlati fa sembrare il record tecnico e aggiunge esposizione senza aggiungere prove. Indirizzate la cattura solo all'interfaccia del tunnel e fissate un limite di dimensione del file perché un'esecuzione lunga non riempia il disco. Fermate la cattura prima di cambiare qualcosa, così che il file corrisponda alla riga di allestimento che avete scritto.

Dite cosa è stato misurato e cosa significa

Registrate cosa ha stampato lo strumento e cosa lo strumento poteva vedere. Una risposta del resolver, un risultato dell'eco di indirizzo e una ricerca di rotta rispondono a domande diverse, e un'etichetta di posizione dentro una pagina web è un'inferenza su un database, non un fatto sull'uscita. Scrivete il comando che ha prodotto ogni riga accanto a essa, perché un valore senza il suo comando non si può riprodurre. Tenete la marca temporale nello stesso fuso orario del ticket di modifica, altrimenti la sequenza diventa illeggibile una settimana dopo.

curl -s https://icanhazip.com
curl -s https://ipinfo.io/ip; echo
resolvectl status --no-pager | head -15

Due servizi di eco indipendenti che concordano sono più forti di uno, e un disaccordo è di per sé un riscontro che vale la pena annotare. L'output del resolver mostra se il DNS ha seguito il tunnel o ha continuato a usare la rete locale, il che è un'asserzione separata dall'indirizzo di uscita. Salvate l'output grezzo con una marca temporale e conservate i risultati contrari invece dello screenshot più rassicurante. Quando una modifica sposta il risultato, applicate una variabile alla volta, perché cambiare server e client insieme vi lascia incapaci di dire quale abbia contato.

Cosa appartiene al record e cosa va rimosso

Conservate il metodo, l'output non segreto e i limiti, poi rimuovete il resto. I profili che portano credenziali, i nomi host privati e gli identificatori di account non devono viaggiare con le prove, e un record di test che li divulga ha danneggiato ciò che doveva dimostrare. I cinque campi qui sotto sono la forma più breve che sopravvive ancora a un passaggio di consegne.

FieldWhat to write
ClaimOne testable sentence naming the profile, the network and the observation
Observer and scopeWho could see the traffic or the record, and under which conditions
SetupClient and server versions, profile name, access network, address families, split-tunnel rules, event under test
Raw resultTool output with a timestamp, exit addresses from both echo services, resolver answer
What it does not supportRetention, third-party access, correlation, untested address families

Allegate la dichiarazione di politica con cui confrontate, con la sua data e il suo ambito. RFC 6973 inquadra l'analisi della privacy attorno a osservatori nominati e a un ambito definito, e questa cornice si adatta a un record di test: chi poteva osservare cosa, in quali condizioni e quali parti sono rimaste non esaminate.

Chiudete con un paragrafo che dichiara cosa sostengono le prove e cosa no. Quel paragrafo è il risultato finale, e tutto ciò che sta sopra esiste per renderlo onesto. Se non si può scrivere senza sfumare ogni clausola, il test ha misurato meno di quanto affermi il ticket.

Articoli correlati