다음을 나열하는 디렉터리 항목은 호스트 이름, 국가, 프로토콜 집합 연결성에 대한 증거이며, 반대편 기계가 무엇을 기록하는지에 대한 증거는 아니다. 여기서 중요한 결정은 목록을 일반적으로 신뢰할지 여부가 아니다. 실제로 던지는 질문에 답할 수 있는 위치에 있는 쪽이 어느 당사자인지다.

한 항목 뒤의 네 당사자

어떤 약속을 읽기 전에 역할을 분리하라. 디렉터리는 항목을 게시하고, 소프트웨어 프로젝트는 프로토콜 구현을 제공하며, 호스팅 제공자는 기계와 네트워크를 제공하고, 노드 운영자는 서비스를 설정한다. 넷 중 어느 하나라도 다른 조직일 수 있고, 각자는 자기 몫에 대해서만 말할 수 있다.

이 분리가 설명하는 것은, 어떤 진술이 참이면서도 쓸모없을 수 있는 이유다. 프로토콜이 내용을 기록하지 않는다고 문서화하는 개발자는 릴레이에서 상세 연결 로그를 켠 운영자에 대해 아무 말도 하지 않는다. 두 진술은 모순 없이 함께 존재할 수 있다. 질문을 이름이 붙은 당사자에게 보내야 하는 이유가 바로 여기에 있다.

일부 서비스는 자체 엔드포인트를 직접 운영하며, 그때는 항목과 정책이 같은 당사자에게서 나온다. 더 강한 위치지만, 페이지 형식에서 추정하지 말고 확인해야 한다. 진술을 요구하고, 그것이 항목이 가리키는 서비스를 명시하는지 점검하라.

주장에 맞는 기록을 요구하라

수집에 관한 주장에는 시스템, 데이터 범주, 기간을 명시한 문서가 필요하다. 보관에 관한 주장에는 숫자와 범위가 필요하다. 독립성에 관한 주장에는 누가 무엇을 소유하는지에 대한 설명이 필요하며, 형용사로는 부족하다.

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

자원봉사 프로젝트가 흔히 가장 분명한 예인데, 일부는 자기가 받아들이는 노드에 명시적 로깅 요건을 공개하기 때문이다. 그 문서는 프로젝트 규칙에 관한 일차 증거이며, 그 규칙을 무시한 개별 운영자에 관한 증거는 여전히 아니다.

감사는 다른 규모에서 같은 논리를 따른다. 특정 배포를 특정 기간에 조사한 보고서는 그 경계 안에서는 유용하다. 같은 소프트웨어의 모든 독립적 인스턴스로 확장하면, 아무도 발행하지 않은 보증이 된다. 결론을 읽기 전에 범위 문단을 읽어라.

공급자의 개인정보 보호 진술이 자사 서비스를 다룬다면, 그것을 그 공급자가 자기 시스템에 관해 한 진술로 읽어라. 그것을 제삼자 릴레이 설명에 재사용하는 것은 범주 오류이며, 프로토콜이 동일하더라도 마찬가지다.

각 선택지로 무엇을 사는지 결정하라

공개 노드는 책임성의 대가로 도달성과 다양성을 산다. 당신에게 아무 빚도 없는 운영자는 사라지거나, 설정을 바꾸거나, 예고 없이 기록을 보관할 수 있으며, 당신의 대응은 다음으로 제한된다: 엔드포인트를 바꾸는 것. 그 교환은 어떤 작업에는 받아들일 만하고 다른 작업에는 그렇지 않다.

유료 서비스는 공개된 정책과 잃을 것을 가진 상대방을 산다. 기술적 보증을 사는 것은 아니며 정책을 읽을 필요를 없애지도 않지만, 보관 진술이 있는 이름 있는 조직은 익명 릴레이보다 평가하기 쉽다.

두 경우 모두에서 살아남는 결정 규칙은 증거를 위험에 맞추는 것이다. 작업이 변동하는 엔드포인트를 견딜 수 있다면 디렉터리는 효율적인 도구다. 특정한 데이터 처리 약속에 의존한다면 그 약속을 할 수 있는 당사자만 관련이 있으며, 디렉터리는 보증이 아니라 경로 편의일 뿐이다.

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

위의 명령 하나는 실행할 가치가 있다. 두 질문을 깔끔하게 분리하기 때문이다. 그것은 당신의 트래픽이 실제로 사용한 주소를 보여주며, 이는 연결성의 사실이고, 그 주소의 운영자가 연결 메타데이터로 무엇을 했는지에 관해서는 아무 말도 하지 않는다.

클라이언트 측 질문은 분리해 두라

운영자 정책은 하나의 층이고, 터널 안에서 당신이 하는 일의 보안은 또 다른 층이다. 목적지의 HTTPS, 브라우저의 세션 처리, 로그인한 계정의 강도는 여전히 당신의 통제이며, 관대한 릴레이가 그것을 약화시키지 않고 뛰어난 릴레이가 그것을 강화하지도 않는다.

이 분리는 흔한 실수 두 가지를 막는다. 엄격한 운영자 정책을 HTTPS를 건너뛸 이유로 보는 것이 하나이고, 작동하는 HTTPS 연결을 릴레이를 누가 운영하는지 무시할 이유로 보는 것이 다른 하나다. 두 실수 모두 두 층을 하나로 녹인 뒤 잘못된 층을 두고 논쟁한다.

짧은 서면 평가로 둘 다 처리할 수 있다. 각 약속을 하는 당사자를 명시하고, 그것을 뒷받침하는 문서를 첨부하고, 날짜를 적어라. 그다음 그 작업에 더 강한 주장이 필요한지, 아니면 작동하는 경로만으로 충분한지 결정하라.

항목은 어디에 연결할 수 있는지 알려 준 순간 제 역할을 다했다. 질문의 나머지는 그 엔드포인트를 운영하는 사람의 몫이며, 정직한 답은 흔히 알 수 없으므로 그에 맞게 선택해야 한다는 것이다.

관련 글