프라이버시 퍼스트 설계: 메모 앱에 대한 편집증적인 고집
이 페이지는 일본어 원문을 기계 번역한 것입니다. 일본어 원문 보기
1. 왜 메모 앱에서 프라이버시가 중요한가
업무 아이디어, 개인 초안, 일일 기록. 메모 앱에는 사람에게 보여주기 전의 정보가 모여 있습니다. 빠르게 쓸 수 있는 것만큼, 어디에 저장되고 어디로 전송되는지를 이해할 수 있는 것이 중요합니다.
이 기사에서는 단말기 내 암호화, 통신 캐시, 화면 표시, 진단 로그 및 이용 분석을 구분하여 설명합니다. 하나의 보호가 다른 경로의 보호도 보장하는 것은 아닙니다.
2. 앱 스위처에서 메모를 자동으로 숨기는 기능이 활성화되어 있지 않습니다
iOS은 앱이 백그라운드로 이동한 후의 화면을 스냅샷으로 사용합니다. Apple은 화면에 기밀 정보가 있는 경우 배경으로 이동할 때 제거하도록 안내하고 있습니다.
확인한 5.8.17의 소스에서는 sceneWillResignActive과 sceneDidEnterBackground가 초안 저장을 수행하며, 프라이버시 오버레이 표시 처리를 호출하지 않습니다. 이전 표시용 함수는 남아 있지만, 유효한 보호로 작동하는 경로는 아닙니다.
표시 중인 메모가 앱 스위처 이미지에 남아 있을 가능성이 있습니다. Outbox을 암호화하고 있더라도 화면 이미지가 가려지는 것은 아닙니다. 이 기사의 구버전에 있던 “항상 메모 내용을 숨긴다”는 설명을 수정합니다.
3. 임시 URL 세션:통신 캐시의 디스크 저장을 억제
표준 URLSession은 캐시, 쿠키, 인증 정보를 디스크에 저장합니다. 일반적인 앱에서는 이것이 편리한 기능이지만, 메모 앱에서는 불필요하고 위험이 될 수 있습니다.
통신 캐시가 단말기에 남는다는 것은, 어느 URL에 언제 접속했는지에 대한 흔적이 디스크에 존재한다는 뜻입니다. 쿠키가 저장된다는 것은 세션 정보가 단말기에 남는다는 의미입니다.
이 앱에서는 URLSessionConfiguration.ephemeral을 사용합니다.
private let session: URLSession = {
let config = URLSessionConfiguration.ephemeral
config.httpCookieAcceptPolicy = .never
config.httpShouldSetCookies = false
config.urlCache = nil
return URLSession(configuration: config)
}()
- 디스크 캐시 없음:이 URL 세션의 캐시를 디스크에 저장하지 않음
- 쿠키 이용을 비활성화:이 URL 세션에서는 쿠키를 허용하지 않으며, 요청에도 설정하지 않습니다
- URL 캐시 비활성화:캐시 스토리지 자체를
nil로 설정 - 영구 스토리지를 사용하지 않는 구성:URLSession의 세션 정보를 디스크에 저장하지 않음
이는 URLSession의 캐시 등에 관한 보호이며, 앱이 별도로 저장·전송하는 이용 이벤트나 서버 측의 전송 기록을 없애는 기능이 아닙니다. 이용 분석의 식별자에 의한 연관도 이 설정과 별도로 수행됩니다.
4. 성능 측정 로그의 출력 범위
PerformanceLogger의 로그 출력은 #if DEBUG로 둘러싸여 있습니다. DEBUG가 정의되지 않은 빌드에서는 이 로거의 로그 출력 처리가 포함되지 않습니다.
이 로거의 logError은 오류 상세 문장이 아니라 유형을 기록합니다. 예를 들어 URLError이라는 종류를 사용하고, 파일 경로나 사용자 입력을 포함할 가능성이 있는 localizedDescription를 그대로 내보내지 않습니다.
한편, logEvent에 전달되는 이벤트 이름 및 추가 문자열을 자동으로 모두 무해하게 만드는 구조가 아닙니다. 호출원에서 이메일 주소·메모 본문·인증 정보를 전달하지 않아야 합니다.
이 설명을 앱·외부 SDK·OS 전체에 대한 “로그 제로”라는 보증에 확대하지 않겠습니다. 자사의 이용 이벤트 전송과 AppsFlyer는 별도의 시스템으로 활성화되어 있습니다. 획득 범위는 본 기사 이용 분석 FAQ와 개인정보 처리방침에서 설명합니다.
5. AES-GCM 암호화 Outbox의 보호 범위
전송 대기 메모는 단말기 내 Outbox이라는 큐에서 관리합니다. 저장 시에는 Apple의 CryptoKit을 사용하여 AES-GCM로 암호화합니다. 새로운 암호키는 256비트로 생성합니다.
키는 Keychain에 보관하고, kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly을 사용합니다. 이 설정에서는 재부팅 후 최초 잠금 해제부터 다음 재부팅까지 접근할 수 있으며, 다른 기기로의 백업 복원에서는 키가 이동되지 않습니다. 앱은 암호화 및 복호화를 위해 키를 읽어옵니다.
이는 저장 데이터 보호이며, 표시 중인 화면을 숨기거나 모든 단말기 침해로부터 안전을 보장하는 것이 아닙니다. 기기 교체 전에, 필요한 메모가 저장처에 도착했는지 확인해 주시기 바랍니다.
메일 전송을 사용할 경우, 본문은 당사의 Relay API와 배송 기반으로 처리되며, 받은 편지함에는 메일로 남습니다. 단말 내 암호화는 메일 전송의 엔드투엔드 암호화(E2EE)를 의미하지 않습니다. 자세한 내용은 개인정보 처리방침와 데이터 경로에서 설명하고 있습니다.
전송 대기 큐에 대해서는 Outbox 아키텍처의 해설을 참조하십시오.
6. 메모 본문의 보호와 외부 SDK의 역할
iOS 앱 내에서는 메모 본문 암호화에 CryptoKit을 사용하고, 키 보관에는 Keychain을 사용하며, 본문 전송에는 URLSession을 사용합니다. Network.framework은 연결 상태를 모니터링하고, BackgroundTasks는 백그라운드 전송 스케줄링을 담당합니다.
한편, 앱은 외부 SDK도 사용합니다. GoogleSignIn와 Firebase Authentication은 Google 계정에 의한 임의의 이메일 자동 입력에 사용되며, Firebase App Check는 실행 시 초기화되어 백엔드 API를 보호합니다. AppsFlyer는 획득·이용 분석에 사용되며, 자체 분석과 공통 설치 식별자를 설정합니다.
메모 본문을 이벤트 항목에 포함하지 않는 설계라도 식별자와 전송 기록의 연관이 남아 있습니다. SDK를 포함한 사용 분석 범위는 본문의 암호화와 별도로 확인해야 합니다. 항목과 용도는 개인정보 처리방침에 설명되어 있습니다.
7. 보호 범위를 명시한다
단말기 내 암호화, 통신 캐시의 처리, 이용 분석은 각각 다른 역할을 가지고 있습니다. Outbox의 암호화나 일시적인 URL 세션이 있더라도, 이용 이벤트의 수집이 사라지는 것은 아닙니다.
메모를 신속하게 남길 수 있는 것과, 획득하는 정보를 이해할 수 있는 것 모두를 중요하게 여깁니다. 이용 분석의 전송 대상, 식별자, 연관 범위를 설명하고, 앱 변경에 맞춰 검토합니다.
자주 묻는 질문
참고문헌
- Apple Developer — CryptoKit Documentation — AES-GCM 암호화에 의한 Outbox 데이터 보호 구현에 사용
- Apple Developer — URLSession Documentation — 일시적(일시적) 세션에 의한 네트워크 통신으로 프라이버시를 확보
- Apple 개발자 — 보안이 취약한 네트워크 연결 방지 (앱 전송 보안) — TLS 통신 강제에 의한 데이터 전송 시 보안 확보
- Apple 개발자 — Generating Log Messages from Your Code — 로그의 저장 범위와 기밀 정보의 취급
- Apple 개발자 — UI를 백그라운드에서 실행하기 위해 준비 — 앱 스위처용 스냅샷 및 화면상의 정보
- Apple 개발자 — 첫 잠금 해제 후 키체인 접근, 이 장치 전용 — 키 접근 조건 및 다른 단말기로의 이전 제한