비밀 메시지를 보내는 방법

계정을 만들지 않는 편이 나은 이유

계정을 만들면 많은 사람이 생각하는 것보다 더 많은 정보가 남습니다. 일반적인 서비스는 이메일 주소, 사용자 이름, 로그인 기록, 기기 정보, IP 주소, 활동에 대한 메타데이터를 저장할 수 있습니다.

장기적인 협업이라면 그것은 충분히 합리적일 수 있습니다. 기밀 메시지 하나를 공유하는 일이라면, 보통은 그렇지 않습니다.

목표가 단순히 “이 한 사람이 이 메시지를 한 번 읽게 하고 싶다”라면, 계정은 보안을 높이지 않으면서 복잡함만 더하는 경우가 많습니다. 그 패턴에는 일회용 비밀 링크가 보통 더 잘 맞습니다.

보내기 전에 암호화하십시오

중요한 질문은 웹사이트가 HTTPS를 쓰는지가 아닙니다. 오늘날 거의 모든 웹사이트가 HTTPS(TLS)를 쓰며, 그것은 데이터가 인터넷을 이동하는 동안 보호합니다. 암호화와 안전한 파일 공유 안내에서는 전송 암호화만으로는 종단간 프라이버시와 같지 않은 이유를 설명합니다.

더 중요한 질문은 이것입니다. 메시지가 서버에 도착한 뒤, 누가 그것을 읽을 수 있습니까?

전통적인 웹 서비스

많은 메시징 플랫폼은 암호화된 연결(HTTPS/TLS)로 메시지를 보냅니다. 메시지가 서버에 도착하면, 저장하거나 처리하기 전에 기술적으로 그 내용에 접근할 수 있습니다.

서비스에 따라 메시지는 스팸이나 악용 여부를 검사당하고, 검색용으로 색인되고, 클라우드 시스템에서 처리되고, 백업에 남거나, 관리자가 접근할 수 있습니다.

TLS는 브라우저와 서비스 사이의 연결을 보호합니다. 서비스 자체가 메시지를 읽는 것까지 반드시 막지는 않습니다.

브라우저 암호화

더 프라이버시에 가까운 방식은 업로드하기 전에 브라우저 안에서 메시지를 암호화하는 것입니다.

이 모델에서는 다음과 같습니다.

1. 1

   메시지를 작성합니다

   브라우저에서 비밀을 작성합니다. 아직 아무것도 전송되지 않습니다. 또는 Private AI와 Private AI로 작성을 써서, 암호화하기 전에 기기에서 초안을 잡으십시오.

2. 2

   고유 키를 로컬에서 생성합니다

   브라우저가 기기에서 암호화 키를 만듭니다.

3. 3

   업로드 전에 암호화합니다

   메시지는 로컬에서 암호화됩니다. 서버에는 암호문만 업로드됩니다.

4. 4

   키를 링크에 담아 공유합니다

   복호화 키는 보낸 사람에게 남고, 보안 링크의 일부로 공유됩니다. 보통은 URL 프래그먼트에 있으며, 브라우저는 그것을 웹 서버로 보내지 않습니다.

서비스는 암호화된 데이터만 저장하고 중계 역할만 합니다. 복호화 키가 없으면 암호문은 사실상 쓸모가 없습니다.

같은 원칙이 파일에도 적용됩니다. 보안 파일 전송은 문서와 압축 파일을 업로드 전에 브라우저에서 암호화합니다. 수신자는 계정 없이 링크를 열 수 있지만, 보내려면 무료 PrivateNote 계정에 로그인해야 합니다.

그래서 계정이 필요 없는 이유

서비스가 메시지를 읽을 필요가 전혀 없으면, 보낸 사람이 누구인지 알 이유도 거의 없습니다. 그래서 브라우저에서 암호화하는 메모 공유 서비스는 가입 없이도 작동하는 경우가 많습니다. 전체 흐름은 일회용 비밀 링크의 작동 방식을 보십시오.

계정을 만드는 대신, 메시지를 작성하고 보안 링크를 생성한 뒤 그 링크를 수신자에게 보내면 됩니다. 사용자 이름도 없습니다. 기억할 비밀번호도 없습니다. 확인 메일로 가득 찬 받은편지함도 없습니다.

비밀번호로 한 층을 더하십시오

매우 민감한 정보라면, 암호화된 메시지를 추가 비밀번호로 보호할 수 있습니다.

흔한 방법은 암호화된 링크는 한 통신 채널로, 비밀번호는 다른 채널로 보내는 것입니다. 예를 들어 전화, SMS, 메시징 앱입니다. 공격자가 메시지를 복호화하려면 둘 다 필요합니다.

자동으로 사라지는 메시지

기밀 정보는 보통 온라인에 영원히 남아 있으면 안 됩니다. 많은 보안 메모 서비스는 메시지가 첫 열람 뒤 자동 파기되거나, 선택한 시간 뒤 만료되거나, 자동으로 삭제되게 합니다.

그러면 온라인에 계속 남아 있는 민감한 정보의 양이 줄어듭니다. 직장 문자와 채팅 기록이 일회용 비밀을 두기 나쁜 장소인 이유와 비슷합니다. 어떤 기술도 수신자가 메시지를 연 뒤 스크린샷을 찍거나 내용을 복사하는 것까지 막지는 못합니다. 다만 자동 만료는 장기 노출을 크게 줄입니다.

익명 비밀 메시지는 언제 쓰면 좋습니까?

계정을 만들지 않고 암호화된 메시지를 보내는 일은 다음을 공유할 때 유용합니다.

• 비밀번호와 복구 코드 — 또는 공유하기 전에 비밀번호 생성기를 사용하십시오
• API 키와 소프트웨어 라이선스 키
• 비공개 링크와 기밀 업무 메모
• 금융 정보와 Wi-Fi 비밀번호
• 이메일이나 채팅 기록에 영원히 남으면 안 되는 일시적인 개인 메시지

안전한 서비스에서 볼 점

모든 “비공개 메시징”이나 “비밀 메모” 서비스가 같은 수준의 보호를 제공하지는 않습니다. 다음과 같은 서비스를 찾으십시오.

• 업로드 전에 브라우저에서 메시지를 암호화합니다
• 평문을 절대 받지 않습니다
• 계정을 요구하지 않습니다
• 자동 만료를 지원합니다
• 선택적으로 비밀번호 보호를 허용합니다
• 현대적인 인증 암호화를 사용합니다

이런 설계 선택은 서비스 자체에 두어야 하는 신뢰를 줄입니다. 비밀번호, 인증, 안전한 공유를 포함한 더 넓은 보안 기준은 “충분히 안전함”이라는 보안의 신화를 보십시오.

PrivateNote가 이 원칙에 맞는 방식

PrivateNote는 바로 이 생각을 중심으로 만들어졌습니다. 메모를 만들면, 무엇이든 업로드되기 전에 암호화가 전적으로 브라우저 안에서 일어납니다. 서버는 암호화된 암호문만 저장하고, 보낸 사람과 수신자 사이의 중계 역할만 합니다. 메시지 평문은 절대 받지 않습니다.

이 설계 때문에, 비공개 메모를 보내려고 계정을 만들 필요가 없습니다. 메시지를 작성하고, 보안 링크를 생성하고, 선호하는 통신 채널로 공유하면 됩니다.

추가 보호를 위해 메모를 비밀번호로 보호하고, 만료 시점을 고르고, 첫 열람 뒤 자동 파기되게 하고, 암호화된 파일을 첨부하고, 선택적으로 전달 알림을 받을 수 있습니다. 알림은 메모가 열렸거나 만료되었는지만 알려 주며, 메시지 내용은 드러내지 않습니다.

목표는 단순합니다. 기밀 정보를 보내는 일을 링크를 공유하는 것만큼 쉽게 하면서, 서비스에 두어야 하는 신뢰는 최소화하는 것입니다.

마무리

비밀 메시지를 보낸다고 또 다른 계정을 만들거나, 불필요한 개인 정보를 넘겨야 하는 것은 아닙니다.

브라우저 기반 암호화를 쓰면 메시지가 기기를 떠나기 전에 암호화할 수 있어서, 서비스는 실제 메시지 대신 암호화된 암호문만 저장합니다. 만료되는 링크와 선택적 비밀번호 보호를 더하면, 기밀 정보를 공유하는 단순하고 실용적인 방법이 됩니다.

비밀번호를 보내든, 복구 코드를 보내든, 개인 메모를 보내든, 브라우저에서 데이터를 암호화하고 계정을 요구하지 않는 서비스를 고르면 마찰은 줄고 프라이버시는 커집니다.