Kvifor ein VPN-katalog ikkje kan garantere for noden bak han
Ei oppføring skildrar ei sambinding og katalogen som publiserte henne. Innsamling og oppbevaring høyrer til operatøren, som kan vere ein annan part.
Katalogoppføringar som listar opp eit vertsnamn, eit land og eit sett protokollar , er prov om samband, ikkje om kva maskinen i andre enden registrerer. Avgjerda som tel her, er ikkje om ein skal stole på lister generelt. Ho er kva part som er i stand til å svare på spørsmålet du faktisk stiller.
Fire partar bak éi oppføring
Skil rollene før du les noko løfte. Katalogen publiserer oppføringa, programvareprosjektet leverer protokollimplementasjonen, vertsleverandøren leverer maskinen og nettet, og nodeoperatøren set opp tenesta. Kven som helst av dei fire kan vere ein annan organisasjon, og kvar kan berre snakke for sin eigen del.
Denne delinga forklarar kvifor ein påstand kan vere sann og likevel unyttig. Ein utviklar som dokumenterer at protokollen ikkje loggar innhaldet, seier ingenting om ein operatør som har slått på detaljert sambandslogging på ein relay. Begge påstandane kan eksistere side om side utan motsegn. Det er nettopp difor spørsmålet må rettast til ein namngjeven part.
Nokre tenester driv sine eigne endepunkt, og då kjem oppføringa og policyen frå same part. Det er ein sterkare posisjon, men han må framleis dokumenterast i staden for å bli antatt ut frå formatet på sida. Be om fråsegna, og kontroller at ho namngjev tenesta oppføringa peikar på.
Be om dokumentet som svarar til påstanden
Ein påstand om innsamling krev eit dokument som namngjev systemet, datakategorien og perioden. Ein påstand om oppbevaring krev eit tal og eit omfang. Ein påstand om sjølvstende krev ei skildring av kven som eig kva, ikkje eit adjektiv.
| 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 |
Frivillige prosjekt er ofte det tydelegaste dømet, fordi nokre publiserer uttrykkelege loggkrav for nodane dei tek imot. Det dokumentet er primærprov om reglane til prosjektet, og det er framleis ikkje prov om ein einskil operatør som ignorerte dei.
Revisjonar følgjer same logikken i ein annan målestokk. Ein rapport som undersøkte ei bestemt utrulling i eit bestemt tidsvindauge, er nyttig innanfor den grensa. Strekt ut over kvar sjølvstendig instans av same programvare blir han ein garanti som ingen har gjeve ut. Les avsnittet om omfang før du les konklusjonen.
Når personvernfråsegna til ein leverandør dekkjer tenesta hans eigen, les henne som fråsegna til den leverandøren om hans eigne system. Å bruke henne om att til å skildre ein relay frå tredjepart er ein kategorifeil, sjølv når protokollen er identisk.
Avgjer kva du kjøper med kvart alternativ
Ein offentleg node kjøper tilgjenge og variasjon for prisen av ansvarlegheit. Ein operatør som ikkje skuldar deg noko, kan forsvinne, endre konfigurasjonen eller halde på oppføringar utan varsel, og utvegen din er avgrensa til å bytte endepunkt. Den handelen er akseptabel for nokre oppgåver og ikkje for andre.
Ei betalt teneste kjøper ein motpart med ein publisert policy og noko å tape. Ho kjøper ikkje ein teknisk garanti og fjernar ikkje behovet for å lese policyen, men ein namngjeven organisasjon med ei oppbevaringsfråsegn er lettare å vurdere enn ein anonym relay.
Avgjerdsregelen som overlever begge tilfella, er å tilpasse provet til risikoen. Viss oppgåva toler eit roterande endepunkt, er katalogen eit effektivt verktøy. Viss ho er avhengig av eit bestemt løfte om databehandling, er berre den parten som kan gje det løftet relevant, og katalogen er ei rutemessig lettvintheit, ikkje ein garanti.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'
Den eine kommandoen ovanfor er verdt å køyre fordi han skil to spørsmål reint. Han viser adressa trafikken din faktisk brukte, noko som er eit sambandsfaktum, og han seier ingenting om kva operatøren av den adressa gjorde med sambandsmetadata.
Hald spørsmåla på klientsida åtskilde
Policyen til operatøren er eitt lag, og tryggleiken til det du gjer over tunnelen er eit anna. HTTPS ved destinasjonen, sesjonshandtering i nettlesaren og styrken til kontoen du logga inn på, blir verande dine kontrollar, og ein ettergjevande relay svekkjer dei ikkje, medan ein framifrå ikkje styrkjer dei.
Denne delinga hindrar to vanlege feil. Å sjå ein streng operatørpolicy som grunn til å hoppe over HTTPS er éin, og å sjå ei fungerande HTTPS-sambinding som grunn til å ignorere kven som driv relayen er den andre. Begge feila smeltar to lag til eitt og diskuterer deretter det gale.
Ei kort skriftleg vurdering handterer begge. Namngje parten som gir kvart løfte, legg ved dokumentet som støttar det, og noter datoen. Avgjer deretter om oppgåva treng den sterkare påstanden eller berre ein fungerande veg.
Oppføringa gjorde jobben sin då ho fortalde deg kvar du kunne kople til. Resten av spørsmålet høyrer til den som driv det endepunktet, og det ærlege svaret er ofte at du ikkje kan vite det og bør velje deretter.