메신저에서 친구를 찾는 것과 주소록을 비공개로 유지하는 것은 같은 문제가 아닙니다. 앱은 어떤 식별자가 서비스 가입자의 것인지 알아내야 하지만, 이 대조 작업의 방식에 따라 서비스에 전달되는 정보가 달라집니다. 전화번호를 해싱하는 것만으로는 그 번호를 식별할 수 없다고 보장할 수 없습니다.
해싱된 번호도 식별할 수 있는 이유
해시 함수는 입력을 고정 길이의 값으로 변환합니다. 하지만 전화번호의 가능한 범위는 제한되어 있고 구조화되어 있습니다. 공격자는 가능한 번호를 생성하고 해시를 계산해 일치하는 값을 찾을 수 있습니다. 이는 “해시를 복호화”하는 것이 아니라 추측할 수 있는 입력을 시험하는 것입니다.
Signal은 비공개 연락처 검색 문제에 관한 설명에서 다양성이 낮은 식별자의 이러한 한계를 정확히 설명합니다. 같은 글은 신뢰 실행 환경에 기반한 설계도 소개합니다. 버전과 최신 문서를 확인하지 않고 이 과거의 사례를 모든 메신저에 일반화해서는 안 됩니다.
따라서 “서버는 해시만 본다”는 말은 개인정보 보호에 대한 완전한 답이 아닙니다. 누가 대조를 계산할 수 있는지, 어떤 요청을 기록하는지, 데이터를 얼마나 오래 보관하는지 명확해야 합니다.
연락처 권한은 무엇을 허용하나요?
연락처 읽기 권한은 앱에 주소록 데이터에 대한 접근을 제공합니다. 권한 자체로는 앱이 그 데이터를 업로드하는지 알 수 없습니다. 연락처의 이름, 전화번호, 이메일, 메모는 민감할 수 있으며, 특히 서비스에 가입하지도 않은 사람의 정보를 포함할 때 그렇습니다.
Android Contacts Provider 문서는 주소록을 폭넓게 읽는 것과 시스템 인터페이스에서 연락처 하나를 선택하는 것을 구분합니다. 접근 범위는 구현 방식과 운영체제 버전에 따라 달라집니다.
| 연락처를 찾는 방법 | 가능한 이점 | 확인할 사항 |
|---|---|---|
| 사용자 이름이나 초대 링크 공유 | 주소록 전체를 읽을 필요가 없을 수 있음 | 식별자를 검색할 수 있는지, 다른 사람이 계정을 찾을 수 있는지 |
| 연락처 몇 개 선택 | 앱에 제공되는 데이터가 줄어듦 | 앱이 선택한 항목만 받는가? |
| 번호 또는 해시 목록 업로드 | 등록된 사용자와 대조하기 쉬움 | 번호 추측, 요청 기록, 목록 보관의 가능성 |
| 전용 비공개 검색 프로토콜 | 특정 위협 모델에서 정보 노출을 줄일 수 있음 | 신뢰 가정, 한계, 독립적 검토의 증거 |
메시지 암호화가 주소록에 관해 증명하지 못하는 것
종단간 암호화는 서버로부터 대화 내용을 숨길 수 있지만, 그 자체로는 연락처 권한, 사용자 검색 요청, 통신 관계 기록에 대해 아무것도 알려주지 않습니다. 주소록이 없어도 라우팅 정보가 통신 관계의 일부를 드러낼 수 있습니다.
Livara의 보안 페이지는 그룹 소속, 시간, 라우팅과 같은 운영 정보의 저장과 처리를 설명합니다. 이 문서만으로 주소록이 특정 방식으로 해싱된다거나, 기록이 전혀 남지 않는다거나, 소셜 그래프가 완전히 숨겨진다고 결론 내릴 수 없습니다. 이런 주장을 하려면 연락처 검색에 대한 별도의 설명이 필요합니다.
권한을 주기 전에 물어볼 다섯 가지 질문
- 연락처 권한 없이도 사용자 이름이나 직접 초대로 대화할 수 있나요?
- 정확히 어떤 필드가 기기를 벗어나나요? 번호뿐인가요, 이름과 다른 세부 정보도 포함되나요?
- 서비스에 가입하지 않은 사람의 정보는 어떻게 사용하고 삭제하나요?
- 권한 취소는 앞으로의 접근만 중단하나요, 아니면 이미 전송한 데이터를 삭제할 방법도 있나요?
- 기술 설명과 데이터 보관 정책이 현재 앱 버전과 일치하나요?
시스템 설정에서 앱 권한을 검토하고, 자동 친구 찾기가 필요 없다면 불필요한 접근을 제한하세요. 옵션 이름은 휴대전화마다 다릅니다. 권한을 취소하는 것을 이전에 업로드한 정보를 삭제하는 것과 동일시하지 마세요.
연락처 개인정보 보호는 데이터 최소화와 데이터 이동 경로의 명확성으로 평가해야 합니다. 전화번호 옆에 “해시”라는 단어가 있다는 사실만으로 평가할 수는 없습니다.
