Hvorfor et VPN-katalog ikke kan garantere for noden bag det
En post beskriver en forbindelse og det katalog, der offentliggjorde den. Indsamling og opbevaring tilhører operatøren, som kan være en anden part.
Katalogposter, der angiver et værtsnavn, et land og et sæt protokoller , er bevis om forbindelse, ikke om hvad maskinen i den anden ende registrerer. Beslutningen, der betyder noget her, er ikke, om man skal stole på lister generelt. Den er, hvilken part der er i stand til at svare på det spørgsmål, du faktisk stiller.
Fire parter bag én post
Adskil rollerne, før du læser noget løfte. Kataloget offentliggør posten, softwareprojektet leverer protokolimplementeringen, hostingudbyderen leverer maskinen og netværket, og nodeoperatøren konfigurerer tjenesten. Enhver af de fire kan være en anden organisation, og hver kan kun tale for sin egen del.
Den opdeling forklarer, hvorfor et udsagn kan være sandt og alligevel ubrugeligt. En udvikler, der dokumenterer, at protokollen ikke logger indhold, siger intet om en operatør, der har aktiveret detaljeret forbindelseslogning på en relay. Begge udsagn kan eksistere side om side uden modsigelse. Det er netop derfor, spørgsmålet skal stilles til en navngivet part.
Nogle tjenester driver deres egne endepunkter, og så kommer posten og politikken fra samme part. Det er en stærkere position, men den skal stadig dokumenteres i stedet for at blive antaget ud fra sidens format. Bed om erklæringen, og kontroller, at den navngiver den tjeneste, posten peger på.
Bed om den registrering, der passer til påstanden
En påstand om indsamling kræver et dokument, der navngiver systemet, datakategorien og perioden. En påstand om opbevaring kræver et tal og et omfang. En påstand om uafhængighed kræver en beskrivelse af, hvem der ejer hvad, ikke et tillægsord.
| 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 projekter er ofte det tydeligste eksempel, fordi nogle offentliggør udtrykkelige logningskrav til de noder, de accepterer. Det dokument er primært bevis om projektets regler og er stadig ikke bevis om en enkelt operatør, der ignorerede dem.
Revisioner følger samme logik i en anden målestok. En rapport, der undersøgte en bestemt udrulning i et bestemt tidsrum, er nyttig inden for den grænse. Strukket ud over hver uafhængig instans af samme software bliver den en garanti, som ingen har udstedt. Læs afsnittet om omfang, før du læser konklusionen.
Når en leverandørs privatlivserklæring dækker dens egen tjeneste, skal du læse den som den leverandørs udsagn om dens egne systemer. At genbruge den til at beskrive en tredjepartsrelay er en kategorifejl, selv når protokollen er identisk.
Beslut, hvad du køber med hver mulighed
En offentlig node køber tilgængelighed og variation for prisen af ansvarlighed. En operatør, der ikke skylder dig noget, kan forsvinde, ændre konfigurationen eller gemme registreringer uden varsel, og din mulighed er begrænset til at skifte endepunkter. Den handel er acceptabel for nogle opgaver og ikke for andre.
En betalt tjeneste køber en modpart med en offentliggjort politik og noget at miste. Den køber ikke en teknisk garanti og fjerner ikke behovet for at læse politikken, men en navngivet organisation med en opbevaringserklæring er lettere at vurdere end en anonym relay.
Den beslutningsregel, der overlever begge tilfælde, er at matche beviset til risikoen. Hvis opgaven tåler et roterende endepunkt, er kataloget et effektivt værktøj. Hvis den afhænger af et bestemt løfte om databehandling, er kun den part, der kan give det løfte, relevant, og kataloget er en rutemæssig bekvemmelighed, ikke en garanti.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'Den ene kommando ovenfor er værd at køre, fordi den rent adskiller to spørgsmål. Den viser den adresse, din trafik faktisk brugte, hvilket er et forbindelsesfaktum, og den siger intet om, hvad operatøren af den adresse gjorde med forbindelsens metadata.
Hold spørgsmålene på klientsiden adskilt
Operatørens politik er et lag, og sikkerheden af det, du gør over tunnelen, er et andet. HTTPS ved destinationen, sessionshåndtering i browseren og styrken af den konto, du loggede ind på, forbliver dine kontroller, og en eftergivende relay svækker dem ikke, mens en fremragende ikke styrker dem.
Den adskillelse forhindrer to almindelige fejl. At betragte en streng operatørpolitik som grund til at springe HTTPS over er én, og at betragte en fungerende HTTPS-forbindelse som grund til at ignorere, hvem der driver relayen, er den anden. Begge fejl smelter to lag sammen til ét og diskuterer derefter det forkerte.
En kort skriftlig vurdering klarer begge. Navngiv den part, der giver hvert løfte, vedlæg det dokument, der understøtter det, og noter datoen. Beslut derefter, om opgaven har brug for den stærkere påstand eller blot en fungerende vej.
Posten gjorde sit arbejde, da den fortalte dig, hvor du kunne forbinde. Resten af spørgsmålet tilhører den, der driver det endepunkt, og det ærlige svar er ofte, at du ikke kan vide det og bør vælge derefter.