Hvorfor en VPN-katalog ikke kan garantere for noden bak den
En oppføring beskriver en forbindelse og katalogen som publiserte den. Innsamling og oppbevaring tilhører operatøren, som kan være en annen part.
Katalogoppføringer som lister opp et vertsnavn, et land og et sett protokoller , er bevis om tilkobling, ikke om hva maskinen i andre enden registrerer. Beslutningen som betyr noe her, er ikke om man skal stole på lister generelt. Den er hvilken part som er i stand til å svare på spørsmålet du faktisk stiller.
Fire parter bak én oppføring
Skill rollene før du leser noe løfte. Katalogen publiserer oppføringen, programvareprosjektet leverer protokollimplementasjonen, vertsleverandøren leverer maskinen og nettverket, og nodeoperatøren konfigurerer tjenesten. Enhver av de fire kan være en annen organisasjon, og hver kan bare snakke for sin egen del.
Denne delingen forklarer hvorfor en påstand kan være sann og likevel ubrukelig. En utvikler som dokumenterer at protokollen ikke logger innholdet, sier ingenting om en operatør som har slått på detaljert tilkoblingslogging på en relay. Begge påstandene kan eksistere side om side uten motsigelse. Det er nettopp derfor spørsmålet må rettes til en navngitt part.
Noen tjenester driver sine egne endepunkter, og da kommer oppføringen og policyen fra samme part. Det er en sterkere posisjon, men den må fortsatt dokumenteres i stedet for å antas ut fra formatet på siden. Be om erklæringen, og kontroller at den navngir tjenesten oppføringen peker på.
Be om dokumentet som svarer til påstanden
En påstand om innsamling krever et dokument som navngir systemet, datakategorien og perioden. En påstand om oppbevaring krever et tall og et omfang. En påstand om uavhengighet krever en beskrivelse av hvem som eier hva, ikke et 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 prosjekter er ofte det tydeligste eksempelet, fordi noen publiserer uttrykkelige loggkrav for nodene de godtar. Det dokumentet er primærbevis om prosjektets regler, og det er fortsatt ikke bevis om en enkelt operatør som ignorerte dem.
Revisjoner følger samme logikk i en annen målestokk. En rapport som undersøkte en bestemt utrulling i et bestemt tidsvindu, er nyttig innenfor den grensen. Strukket ut over hver uavhengig instans av samme programvare blir den en garanti som ingen har utstedt. Les avsnittet om omfang før du leser konklusjonen.
Når en leverandørs personvernerklæring dekker dens egen tjeneste, les den som den leverandørens utsagn om dens egne systemer. Å gjenbruke den til å beskrive en tredjepartsrelay er en kategorifeil, selv når protokollen er identisk.
Bestem hva du kjøper med hvert alternativ
En offentlig node kjøper tilgjengelighet og variasjon for prisen av ansvarlighet. En operatør som ikke skylder deg noe, kan forsvinne, endre konfigurasjonen eller beholde oppføringer uten varsel, og din utvei er begrenset til å bytte endepunkter. Den handelen er akseptabel for noen oppgaver og ikke for andre.
En betalt tjeneste kjøper en motpart med en publisert policy og noe å tape. Den kjøper ikke en teknisk garanti og fjerner ikke behovet for å lese policyen, men en navngitt organisasjon med en oppbevaringserklæring er lettere å vurdere enn en anonym relay.
Beslutningsregelen som overlever begge tilfellene, er å tilpasse beviset til risikoen. Hvis oppgaven tåler et roterende endepunkt, er katalogen et effektivt verktøy. Hvis den avhenger av et bestemt løfte om databehandling, er bare den parten som kan gi det løftet relevant, og katalogen er en rutemessig bekvemmelighet, ikke en garanti.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'Den ene kommandoen ovenfor er verdt å kjøre fordi den skiller to spørsmål rent. Den viser adressen trafikken din faktisk brukte, noe som er et tilkoblingsfaktum, og den sier ingenting om hva operatøren av den adressen gjorde med tilkoblingsmetadataene.
Hold spørsmålene på klientsiden atskilt
Operatørens policy er ett lag, og sikkerheten til det du gjør over tunnelen er et annet. HTTPS ved destinasjonen, sesjonshåndtering i nettleseren og styrken til kontoen du logget inn på, forblir dine kontroller, og en ettergivende relay svekker dem ikke, mens en utmerket ikke styrker dem.
Denne delingen forhindrer to vanlige feil. Å se en streng operatørpolicy som grunn til å hoppe over HTTPS er én, og å se en fungerende HTTPS-forbindelse som grunn til å ignorere hvem som driver relayen er den andre. Begge feilene smelter to lag til ett og diskuterer deretter det gale.
En kort skriftlig vurdering håndterer begge. Navngi parten som gir hvert løfte, legg ved dokumentet som støtter det, og noter datoen. Bestem deretter om oppgaven trenger den sterkere påstanden eller bare en fungerende vei.
Oppføringen gjorde jobben sin da den fortalte deg hvor du kunne koble til. Resten av spørsmålet tilhører den som driver det endepunktet, og det ærlige svaret er ofte at du ikke kan vite det og bør velge deretter.