Test af en VPN-privatlivspåstand: gem beviser, der holder
Skriv påstanden, observatøren og opsætningen ned, før du ser på et resultat. En routingtest viser en udgang; den viser aldrig, hvad operatøren beholder.
Testen begynder med en sætning, som nogen ønsker skal være sand, og beviserne understøtter enten en snæver version af den eller intet. En kontrol af den offentlige adresse viser, hvilken udgang én anmodning brugte. Den viser ikke, hvad udbyderen beholder, hvem der kan læse det, eller hvad der sker med en session, som aldrig fuldføres. Når du gennemfører testen som en dokumenteret procedure, påstår du ikke mere, end målingen kan bære.
Vælg én observerbar påstand
Skriv påstanden som én enkelt testbar sætning, før du åbner noget værktøj: for denne profil, på dette netværk, forlader anmodninger til et ekko af en offentlig adresse gennem udbyderens angivne udgang. Den sætning navngiver et emne, en betingelse og en observation, og det er, hvad der gør den falsificerbar. En påstand som at VPN beskytter privatlivet har ingen observerbar form, så ingen måling kan afgøre den. Gem en anden sætning til det, testen ikke vil dække, for opbevaring, tredjepartsadgang og trafikkorrelation ligger alle uden for en browsertest.
Skriv den anden sætning på forhånd, ikke efter resultatet kommer. Det er meget lettere at være ærlig om rækkevidden, mens udfaldet stadig er ukendt, end efter at et beroligende skærmbillede er landet i billetten. En note om rækkevidde, der tilføjes bagefter, beskriver tendentielt resultatet snarere end spørgsmålet.
Opsætningsfakta, som en læser har brug for for at gentage målingen
Opsætningen er det, der gør et resultat reproducerbart, og det er den, folk springer over, når svaret ser godt ud. Versionsstrenge, profilnavne, adgangsnetværk og adressefamilier hører i noten sammen med enhver regel om tunnelopdeling, som kunne føre trafik ud af tunnelen. Navngiv også hændelsen under test, fordi en fungerende forbindelse, et uventet afbrud, en manuel afbrydelse og en netværksoverlevering udøver forskellige regler. En test, der blander disse hændelser, beviser lidt om nogen enkelt af dem.
Brug ikke-følsom trafik i et miljø, du har tilladelse til at teste i. Optagelse af urelaterede pakker får optegnelsen til at se teknisk ud og tilføjer eksponering uden at tilføje beviser. Ret optagelsen mod tunnelgrænsefladen alene, og sæt en filstørrelsesgrænse, så en lang kørsel ikke kan fylde disken. Stop optagelsen, før du ændrer noget, så filen svarer til den opsætningslinje, du skrev.
Sig, hvad der blev målt, og hvad det betyder
Noter, hvad værktøjet udskrev, og hvad værktøjet kunne se. Et resolver-svar, et resultat af adresseekko og et ruteopslag besvarer forskellige spørgsmål, og en placeringsetiket inde i en webside er en slutning om en database snarere end en kendsgerning om udgangen. Skriv kommandoen, der frembragte hver linje, ved siden af den, fordi en værdi uden sin kommando ikke kan gengives. Hold tidsstemplet i samme tidszone som ændringsbilletten, ellers bliver rækkefølgen ulæselig en uge senere.
curl -s https://icanhazip.com
curl -s https://ipinfo.io/ip; echo
resolvectl status --no-pager | head -15To uafhængige ekkotjenester, der er enige, er stærkere end én, og en uenighed er i sig selv et fund, der er værd at skrive ned. Resolverens output viser, om DNS fulgte tunnelen eller fortsatte med at bruge det lokale netværk, hvilket er en påstand adskilt fra udgangsadressen. Gem det rå output med et tidsstempel, og behold modstridende resultater i stedet for det mest beroligende skærmbillede. Når en ændring flytter resultatet, anvend én variabel ad gangen, fordi at skifte server og klient sammen efterlader dig ude af stand til at sige, hvilken der betød noget.
Hvad hører i optegnelsen, og hvad skal fjernes
Behold metoden, det ikke-hemmelige output og begrænsningerne, og fjern så resten. Profiler med legitimationsoplysninger, private værtsnavne og kontoidentifikatorer behøver ikke rejse med beviserne, og en testoptegnelse, der lækker dem, har skadet det, den skulle demonstrere. De fem felter nedenfor er den korteste form, der stadig overlever en overdragelse.
| Field | What to write |
|---|---|
| Claim | One testable sentence naming the profile, the network and the observation |
| Observer and scope | Who could see the traffic or the record, and under which conditions |
| Setup | Client and server versions, profile name, access network, address families, split-tunnel rules, event under test |
| Raw result | Tool output with a timestamp, exit addresses from both echo services, resolver answer |
| What it does not support | Retention, third-party access, correlation, untested address families |
Vedlæg den politikudtalelse, du sammenligner med, med dens dato og dens omfang. RFC 6973 rammesætter privatlivsanalyse omkring navngivne observatører og et defineret omfang, og den ramme passer til en testoptegnelse: hvem kunne observere hvad, under hvilke betingelser, og hvilke dele der forblev uundersøgt.
Afslut med et afsnit, der angiver, hvad beviserne understøtter, og hvad de ikke gør. Det afsnit er leverancen, og alt ovenover findes for at gøre det ærligt. Hvis det ikke kan skrives uden at forbeholde hver enkelt klausul, målte testen mindre, end billetten hævder.