읽는 데 6분
화이트리스트 모드: 신뢰하는 발신자에 받은편지함을 집중시키기
화이트리스트 모드는 신원별로 적용되는 CardanoWall 받은편지함 필터로, 신뢰하는 연락처의 레코드를 먼저 보여 줍니다. Label 309 레코드 형식을 바꾸지 않으며 Cardano에서 누구도 차단하지 않습니다.

화이트리스트(허용 목록) 모드는 신원별로 켤 수 있는 CardanoWall 받은편지함 필터입니다. 모드를 켜면 받은편지함은 기본적으로 "신뢰하는 발신자만" 보기로 설정되어, 이미 주소록에 있는 발신자가 서명한 레코드를 보여 주며, "모두 보기" 탭은 클릭 한 번이면 됩니다. 이는 권한 시스템이 아니라 보기 편의 기능입니다. Label 309 레코드 형식을 바꾸지 않으며, Cardano에서 누군가가 사용자를 수신자로 지정해 레코드를 게시하는 것을 막을 수도 없습니다.
블록체인 제어가 아니라 받은편지함 제어라고 생각하시면 됩니다.
받은편지함에 화이트리스트가 왜 필요합니까?
공개 수신 주소는 요청하지 않은 트래픽을 끌어들이기 때문입니다.
웹사이트나 공개 프로필, 지원 페이지에 수신 주소를 게시하면 누구나 그 주소로 레코드를 봉인해 보낼 수 있습니다. 그 개방성이야말로 핵심입니다. 계정 없이도 낯선 사람이 닿을 수 있는 방법이기 때문입니다. 하지만 그만큼 받은편지함은 한 번도 들어 본 적 없는 사람들이 보낸 레코드로 가득 찰 수 있습니다.
화이트리스트 모드는 다음과 같이 트래픽이 많거나 공개적인 맥락에서 사용하는 신원을 위해 깔끔한 작업 보기를 유지해 줍니다.
- 누구나 찾을 수 있는 공개 프로필 신원;
- 보도국이나 제보 접수용 신원;
- 법무 또는 컴플라이언스 팀 신원;
- 보안 취약점 공개용 신원;
- 고객 지원 증거용 신원;
- 대부분 파트너 트래픽만 봐야 하는 신원.
화이트리스트 모드는 정확히 무엇을 필터링합니까?
받은편지함 보기를 필터링할 뿐, 그 외에는 아무것도 건드리지 않습니다.
어떤 신원에 화이트리스트 모드를 켜면 받은편지함에 두 개의 탭을 가진 작은 전환기가 나타납니다. 신뢰하는 발신자만(기본값)과 모두 보기입니다. 신뢰하는 발신자 보기에는 발신자 서명이 주소록의 공개 키와 일치하는 레코드가 담깁니다. 나머지는 모두 클릭 한 번이면 닿는 모두 보기에 남습니다.
삭제되는 것은 없습니다. 온체인 레코드는 그대로 존재하고, 암호화된 페이로드도 손대지 않으며, 다른 신원도 영향을 받지 않습니다. 받은편지함은 단지 무엇을 먼저 드러낼지 고를 뿐입니다. 이 구분이 중요한 이유는 Cardano가 공개적이고 추가 전용이기 때문입니다. 애플리케이션은 당신이 보는 것은 바꿀 수 있어도, 이미 게시된 것은 결코 바꿀 수 없습니다.
보기 전환 자체는 일시적입니다. 한 세션 동안 "모두 보기"로 전환해도 화이트리스트 모드가 꺼지지는 않습니다. 신원별 설정은 유지되지만, 현재 보기는 유지되지 않습니다.
화이트리스트 모드는 블록체인에서 발신자를 차단합니까?
아니요. 차단할 수 없으며, 그러려는 기능도 아닙니다.
Cardano 트랜잭션을 제출할 수 있는 사람이라면 누구나, 아는 사이인지 여부와 상관없이, 사용자의 수신 키를 수신자로 지정해 규격에 맞는 Label 309 레코드를 게시할 수 있습니다. 화이트리스트 모드는 온체인 권한이나 허용 목록, 차단을 전혀 만들지 않습니다. 단지 계정에 속한 한 신원에 대해 CardanoWall이 받은편지함을 정리하는 방식을 바꿀 뿐입니다.
표준은 여전히 개방되어 있습니다. 다만 인터페이스가 조용해질 뿐입니다. (CardanoWall은 특정 서명 키를 보기에서 숨기는 별도의 "발신자 차단" 기능도 제공합니다. 이 또한 온체인 동작이 아니라 로컬 UX 선택입니다.)
주소록은 이 기능을 어떻게 뒷받침합니까?
화이트리스트 모드는 연락처가 갖춰진 만큼만 유용합니다.
주소록은 발신자의 서명 공개 키를 이름, 그리고 그 키를 확인한 맥락과 연결해 둡니다. 들어오는 각 레코드는 선택적인 작성자 서명(Ed25519 키에 대한 레코드 수준 COSE_Sign1 서명)을 담을 수 있습니다. 그 서명 키가 신뢰하는 연락처 중 하나와 일치하면, 받은편지함은 그 레코드를 알려진 발신자가 보낸 것으로 인식하고 신뢰하는 발신자 보기에 넣습니다.
따라서 주소록은 단순한 컴포저 단축 기능 이상입니다. 받은편지함 분류 역할도 함께 합니다. 그리고 이 일치 판정은 암호학적이므로, 필터의 품질은 전적으로 확인의 품질에 달려 있습니다. 그 키가 누구의 것인지 제대로 확인하지 않고 어떤 연락처의 키를 추가했다면, 화이트리스트 모드는 충실하게 엉뚱한 사람을 신뢰하게 됩니다.
서명되지 않은 봉인된 레코드는 어떻게 됩니까?
대개 일치시킬 발신자가 없으므로 "모두 보기"에 들어갑니다.
Label 309에서 작성자 서명은 설계상 선택 사항입니다. 발신자는 서명을 전혀 넣지 않고도 봉인된 레코드를 게시할 수 있는데, 출처 표기가 바람직하지 않은 민감한 공개에서는 이것이 실제로 유용합니다. 하지만 서명이 없으면 주소록과 대조할 키가 없으므로, 받은편지함은 그 레코드를 알 수 없는 발신자가 보낸 것으로 취급합니다.
이 기능에 의존하는 사람에게는 다음을 분명히 알려 주십시오.
- 알려진 키로 서명된 레코드는 신뢰하는 것으로 인식됩니다;
- 서명되지 않은 레코드, 또는 저장하지 않은 키로 서명된 레코드는 알 수 없음으로 표시됩니다;
- "알 수 없음"이 악의적이라는 뜻은 아닙니다;
- 그리고 "기본 보기에서 걸러졌다"는 것이 삭제를 뜻하는 일은 결코 없습니다.
이는 인터페이스 정책이지, 발신자에 대한 암호학적 판정이 아닙니다.
언제 켜야 하며, 언제 켜지 말아야 합니까?
도달 범위보다 신호가 더 중요할 때 켜십시오.
잘 맞는 경우:
- 대부분 알려진 파트너만 봐야 하는 내부 팀 신원;
- 알 수 없는 레코드를 기본적으로 드러내지 않아야 하는 임원 또는 법무 신원;
- 무관한 트래픽에 파묻힌 공개 프로필;
- 검증된 고객 키를 먼저 보고 싶은 지원 워크플로;
- 승인된 발신자 집합에 집중하는 감사인 신원.
발견 자체가 핵심일 때는 꺼 두십시오.
- 공개 내부고발자 또는 제보 접수;
- 낯선 사람의 자유 제출과 최초 접촉;
- 커뮤니티나 크리에이터 받은편지함;
- 알 수 없는 발신자가 들어올 것을 기대하고 환영하는 모든 워크플로.
화이트리스트 모드가 중요한 것을 숨길 수도 있습니까?
그렇습니다. 그것이 바로 절충점이며, 이에 대비해야 합니다.
중요한 발신자가 주소록에 없다면, 그의 레코드는 기본 "신뢰하는 발신자만" 보기에 나타나지 않습니다. "모두 보기"에는 여전히 있지만, 누군가가 들여다봐야만 보입니다. 중요한 신원이라면 다음과 같은 절차를 정해 두십시오.
- 신뢰하는 발신자 보기만이 아니라 "모두 보기"도 주기적으로 살핍니다;
- 발신자를 확인한 뒤 연락처에 추가해, 이후 레코드가 자동으로 드러나도록 합니다;
- 어떤 신원이 화이트리스트 모드로 운영되는지 기록해 둡니다;
- 절차가 이를 분명히 고려하지 않는 한, 개방형 접수 주소에는 켜지 마십시오.
필터링은 절차에 도움이 되어야 하며, 모르는 사이에 일을 그르쳐서는 안 됩니다.
화이트리스트 모드가 프라이버시를 향상합니까?
간접적으로만 그렇습니다. 이 부분은 정확하게 짚을 가치가 있습니다.
화이트리스트 모드는 공개 수신 주소를 숨기지도, 체인에서 무언가를 제거하지도, 게시를 비공개로 만들지도, 낯선 사람이 사용자에게 레코드를 봉인하는 것을 막지도 않습니다. 다만 예기치 않은 레코드를 열고 살펴보고 대응하는 빈도를 줄여 줄 수는 있는데, 이는 운영상의 실수 가능성을 낮춥니다.
진정한 기밀성은 여전히 콘텐츠 자체를 봉인하는 것, 신중한 키 취급, 그리고 메타데이터가 무엇을 드러내는지 고민하는 데서 나옵니다. 실제 프라이버시 경계가 어디에 있는지는 CardanoWall이 볼 수 있는 것을 참고하십시오.
요약
화이트리스트 모드는 한 신원에 국한된 받은편지함 제어입니다.
받은편지함을 기본적으로 "신뢰하는 발신자만" 보기로 설정함으로써, 어떤 신원이 직접 확인한 연락처의 레코드에 집중하도록 도와줍니다. Label 309 프로토콜을 바꾸지 않고, Cardano 트랜잭션을 차단하지 않으며, 알 수 없는 발신자가 신뢰할 수 없다는 것을 증명하지도 않습니다. 통제된 대량 워크플로에는 사용하고, 개방형 접수가 목표인 곳에서는 꺼 두십시오.
더 읽어 보기
- 개방형 표준: label309.org, 오픈 소스 코드는 github.com/cardanowall에 있으며, 제안은 Cardano CIP 절차에 제출되었습니다(PR #1205, CIP 편집자들이 검토 중).