Záznamy v adresáři, které uvádějí název hostitele, zemi a sadu protokolů , jsou dokladem o konektivitě, nikoli o tom, co zaznamenává stroj na druhé straně. Rozhodnutí, které je tu důležité, není, zda věřit výpisům obecně. Je to, která strana je v pozici odpovědět na otázku, kterou skutečně kladete.

Čtyři strany za jedním záznamem

Oddělte role dřív, než začnete číst jakýkoli slib. Adresář zveřejňuje záznam, softwarový projekt dodává implementaci protokolu, poskytovatel hostingu dodává stroj a síť a provozovatel uzlu konfiguruje službu. Kterákoli ze čtyř může být jiná organizace a každá může mluvit jen za svou část.

Toto rozdělení vysvětluje, proč může být tvrzení pravdivé a přesto neužitečné. Vývojář, který dokumentuje, že protokol nezaznamenává obsah, neříká nic o provozovateli, který na relayi zapnul podrobné protokolování spojení. Obě tvrzení mohou existovat vedle sebe bez rozporu. Právě proto je třeba otázku adresovat pojmenované straně.

Některé služby provozují vlastní koncové body a pak záznam i politika pocházejí od stejné strany. To je silnější pozice, ale stále ji musíte prokázat, ne odvodit z podoby stránky. Vyžádejte si prohlášení a zkontrolujte, že jmenuje službu, na kterou záznam ukazuje.

Vyžádejte si dokument, který odpovídá tvrzení

Tvrzení o sběru potřebuje dokument, který jmenuje systém, kategorii dat a období. Tvrzení o uchovávání potřebuje číslo a rozsah. Tvrzení o nezávislosti potřebuje popis, kdo co vlastní, ne přídavné jméno.

Field in a listingWhat it evidencesWhat it cannot evidence
Hostname or addressA reachable endpoint existed when the entry was publishedWho runs it, or what it stores
Protocols offeredWhich client configurations should interoperateWhether logging was disabled on that deployment
CountryWhere the endpoint claims to be locatedWhich legal process could reach the operator
Availability scoreHow often the entry answered a probeAnything about data handling

Dobrovolnické projekty jsou často nejjasnějším příkladem, protože některé zveřejňují výslovné požadavky na protokolování pro uzly, které přijímají. Tento dokument je prvotním dokladem o pravidlech projektu a stále není dokladem o jednotlivém provozovateli, který je ignoroval.

Audity sledují stejnou logiku v jiném měřítku. Zpráva, která zkoumala konkrétní nasazení v konkrétním období, je užitečná v rámci této hranice. Roztažená na každou nezávislou instanci téhož softwaru se stává zárukou, kterou nikdo nevydal. Přečtěte si odstavec o rozsahu dřív než závěr.

Když prohlášení poskytovatele o soukromí pokrývá jeho vlastní službu, čtěte je jako prohlášení tohoto poskytovatele o jeho vlastních systémech. Opětovné použití k popisu relaye třetí strany je chyba kategorie, i když je protokol totožný.

Rozhodněte, co s každou možností kupujete

Veřejný uzel kupuje dosažitelnost a rozmanitost za cenu odpovědnosti. Provozovatel, který vám nic nedluží, může zmizet, změnit konfiguraci nebo uchovávat záznamy bez oznámení, a vaše možnosti se omezují na přepnutí koncových bodů. Tato výměna je pro některé úkoly přijatelná a pro jiné ne.

Placená služba kupuje protistranu se zveřejněnou politikou a s něčím, co lze ztratit. Nekupuje technickou záruku a neodstraňuje potřebu politiku si přečíst, ale pojmenovanou organizaci s prohlášením o uchovávání se hodnotí snáz než anonymní relay.

Pravidlo rozhodování, které obstojí v obou případech, zní: sladit důkaz s rizikem. Pokud úkol snese měnící se koncový bod, je adresář účinný nástroj. Pokud závisí na konkrétním slibu o zpracování dat, je relevantní jen ta strana, která tento slib může dát, a adresář je pohodlím pro směrování, nikoli zárukou.

curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'

Jeden příkaz výše stojí za spuštění, protože čistě odděluje dvě otázky. Ukazuje adresu, kterou váš provoz skutečně použil, což je fakt o konektivitě, a neříká nic o tom, co provozovatel této adresy udělal s metadaty spojení.

Otázky na straně klienta držte oddělené

Politika provozovatele je jedna vrstva a bezpečnost toho, co děláte tunelem, je jiná. HTTPS na cíli, práce se session v prohlížeči a síla účtu, do kterého jste se přihlásili, zůstávají vašimi kontrolami, a benevolentní relay je neoslabuje, zatímco vynikající je neposiluje.

Toto oddělení brání dvěma častým chybám. Považovat striktní politiku provozovatele za důvod přeskočit HTTPS je jedna a považovat funkční HTTPS spojení za důvod ignorovat, kdo relay provozuje, je druhá. Obě chyby slévají dvě vrstvy v jednu a pak se hádají o tu nesprávnou.

Krátké písemné posouzení zvládne obojí. Pojmenujte stranu, která dává každý slib, přiložte dokument, který jej podporuje, a poznamenejte datum. Pak rozhodněte, zda úkol potřebuje silnější tvrzení, nebo jen fungující cestu.

Záznam udělal svou práci ve chvíli, kdy vám řekl, kam se můžete připojit. Zbytek otázky patří tomu, kdo tento koncový bod provozuje, a poctivá odpověď často je, že to nemůžete vědět a měli byste podle toho volit.

Související články