iOS용 비밀번호 관리자 Strongbox의 인앱 구매 버전은 실행할 때마다 구독 여부와 관계없이 RevenueCat과 Superwall에 연결하고, 기기 프로필을 포함한 수십 건의 이벤트를 Superwall로 보낸다. 조사 당시 개인정보 처리방침은 외부 업체나 분석 제공업체를 사용하지 않는다고 밝혔지만, 제작사는 조사 질의를 받은 뒤 2026년 10월 15일 방침을 바꿨다.
조사에서 확인된 데이터 전송
termsapply가 Strongbox 1.65.2(빌드 152)를 2026년 10월 1일부터 8일까지 세 대의 iPhone에서 시험했다. 기기 A에는 활성 연간 Pro 구독이 있었고, B는 가족 공유 구독이 만료됐으며, C는 구매 이력이 없었다. 총 24회 실행을 관찰했고, 이 중 21회는 복호화된 HTTP 로그(HAR)에 기록됐다. 나머지 세 번은 패킷 캡처만으로 확인했다. Strongbox Pro, Strongbox Zero, macOS 버전은 조사 범위에 포함되지 않았다.
HAR에 기록된 21회의 콜드 스타트마다 다음 다섯 호스트에 연결됐다.
api.revenuecat.com: 구매 처리. 모든 요청에 기기 식별자 IDFV가 포함됐고, 최초 실행 때는 영수증과 광고 기여 토큰도 전송됐다.api.superwall.me: 구매 화면 설정을 가져왔다.collector.superwall.me: 실행마다 41~73건의 이벤트와 기기 프로필을 보냈다.enrichment-api.superwall.com: 기기 프로필을 보내고 IP 주소에서 추정한 위치와 구매 가능성 점수를 받았다.subscriptions-api.superwall.com: 매 실행마다 접속했다. 최초 실행과 S18에서는redeem요청도 관찰됐다.
기기 A·B·C 모두에서 구독이 활성 상태인지, 만료됐는지, 구매 이력이 없는지와 무관하게 연결이 발생했다. Superwall 이벤트에는 기기 식별자(IDFV), App Store 거래 식별자, 기기 모델, 운영체제, 언어, 지역, 통화, 시간대, 다크 모드, 연결 유형 등이 포함됐다. device_attributes 이벤트 하나에는 50~61개 필드가 있었다. Superwall은 IP 기반 위치와 demandScore를 반환했고, 앱은 이후 이벤트에 이 값들을 다시 담았다. 보고서에 따르면 이 점수는 앱을 열 때마다 사용자에게 1~100으로 부여된다.
최초 설치 후 첫 실행에서는 RevenueCat으로 Apple AdServices 기여 토큰(560자)과 App Store 영수증을 보냈다. 이 SDK 버전에서는 토큰 수집이 기본적으로 꺼져 있어 앱이 직접 켜야 한다. 조사된 6회의 최초 실행 모두에서 토큰 전송을 확인했다. 영수증 요청의 App Tracking Transparency 동의 상태는 22건 모두 denied였지만, 제작사는 ATT 동의를 요청하지 않으며 이 값은 모든 사용자에게 그대로 남는다고 답했다. 따라서 denied가 사용자의 거부를 뜻하지는 않는다고 보고서는 설명한다. IDFA는 관찰되지 않았다.
Superwall로 보낸 $appTransactionId는 앱을 재설치한 뒤에도 같은 계정의 기록을 연결할 수 있는 값이었다. IDFV가 바뀐 뒤에도 같은 값이 유지됐고, Apple 문서에 따르면 기기 간에도 연결될 수 있다. 같은 IDFV는 RevenueCat 요청과 Superwall 이벤트 양쪽에서 확인됐다. 제작사는 사용자 기록을 추가로 병합하지 않는다고 답했지만, 서비스 운영자가 실제로 식별자를 열람하거나 어떻게 활용하는지는 이 조사로 알 수 없다.
앱은 최초 실행 때 구매 화면 리소스도 내려받았다. user-content.superwalleditor.com, Google Fonts 호스트와 Stripe 스크립트 등에서 127~206건의 요청이 발생했고, 이후 실행에서는 HAR에 실행당 0~1건이 기록됐다. 유료 구독이 활성화된 기기에서도 리소스가 내려왔다. 제작사는 구독 권한이 실행 중 사라질 수 있어 구매 화면을 미리 불러온다고 설명했다. Stripe.js가 웹뷰에서 어떤 데이터를 전송하는지는 확인되지 않았다.
설정에는 database-unlock과 Settings 등 구매 화면을 띄울 수 있는 지점이 있었지만, 모든 표시 규칙은 활성 구독 권한이 없는 경우에만 작동하도록 돼 있었다. 사용자가 이벤트 수집을 끌 수 있는 기능은 없었다고 제작사도 답했다. 데이터베이스를 연 6회 관찰에서는 데이터베이스 내용이나 관련 이벤트가 전송되지 않았다. 다만 한 번 Nudge 이벤트가 발생해 구매 화면 표시 판정을 받았다. 보고서는 데이터베이스 목록의 ‘Upgrade to Pro’ 배너를 누른 결과일 가능성이 크다고 보지만, 당시 배너를 눌렀는지는 확정하지 못했다.
24회 실행 중 실제 구매 화면은 기기 C에서 한 번 관찰됐다. 최초 설치 후 Onboarding, trigger_fire, paywall_open, paywall_page_view가 전송됐고, 9초 뒤 paywall_decline과 paywall_close가 기록됐다. 보고서에 따르면 사용자가 화면을 닫았다. Superwall의 실행·종료 이벤트는 데이터베이스가 열린 동안에도 전송됐지만, 이벤트에는 데이터베이스 상태나 내용이 담기지 않았다.
방침과 앱스토어 표시의 변경
조사 당시 적용 중이던 2024년 5월 9일자 개인정보 처리방침은 앱이 외부 업체나 분석 제공업체를 사용하지 않으며 위치 관련 데이터를 수집하지 않는다고 밝혔다. 2026년 10월 8일판 네트워크 연결 안내에도 RevenueCat과 Superwall은 목록에 없었다. 제작사의 과거 공개 설명은 Superwall 전송을 주로 구매 화면 이벤트로 한정했고, 식별자를 추적하지 않는다고 설명했다.
질의를 받은 뒤 제작사는 10월 15일 개인정보 처리방침을 바꾸고, 14~16일 사이 네트워크 안내도 수정했다. 새 방침은 RevenueCat과 Superwall, 기기 식별자, IP 주소에서 추정하는 대략적 위치, 구매 가능성 추정치, 활성 구독 중에도 작동할 수 있다는 점을 명시했다. 광고 기여와 충돌 보고 기능도 새 문서에 설명됐다. Google Fonts, Stripe, $appTransactionId는 새 문서에 이름이 나오지 않았다.
제작사는 10월 14일 방침이 갱신되지 않은 것은 실수였다고 답했다. AdServices 토큰은 Apple Search Ads의 광고 기여를 위해 쓰며, IP 기반 위치와 구매 점수는 사용하지 않는다고 밝혔다. Superwall 이벤트는 구매 화면 전환을 보고하는 데 쓰고, 현재 사용자가 이벤트 수집을 끌 수 없다고도 답했다. 일부 질문에는 답하지 않았으며, 서비스가 데이터를 보관하거나 활용하는 방식과 전송 국가 등은 확인되지 않았다.
앱스토어 개인정보 라벨에는 ‘구매 내역’ 한 종류만 ‘사용자와 연결되지 않음’으로 표시됐고, 목적은 ‘분석’이었다. 조사팀은 실제 트래픽이 Apple의 정의상 기기 ID, 대략적 위치, 제품 상호작용에 해당하는 데이터를 포함한다고 판단했지만, 해당 세 유형은 라벨에 표시되지 않았다고 지적했다. 라벨은 2026년 1월 8일 이후 Superwall 추가 뒤에도 바뀌지 않은 것으로 관찰됐다. 제작사는 제공업체 지침을 확인해 라벨을 갱신했다고 답했지만, 세 데이터 유형에 대한 구체적 설명은 하지 않았다.
방법과 한계
조사에는 세 대의 iPhone과 Proxyman, Wireshark, rvictl이 사용됐다. 일부 연결은 TLS 복호화가 적용된 HAR로, 일부는 전체 패킷 캡처(PCAP)에서 호스트 이름만 확인했다. Apple 도메인은 복호화하지 않았다. 공개된 로그에서는 식별자·토큰·주소·구매 날짜와 가격을 가명으로 바꾸고, 실행별 시간도 무작위 상수만큼 이동했다. 따라서 파일 간 시각을 직접 비교할 수 없다.
관찰 표본은 기기 3대, 실행 24회, 데이터베이스 잠금 해제 6회, 시험일 4일이다. HIBP, SimpleLogin, 동기화 옵션을 켠 상태는 시험하지 않았다. m.stripe.com, m.stripe.network, 파비콘과 Apple 호스트 연결의 내용은 복호화하지 않았다. HAR는 완전한 기록이 아니며, 프록시 사용 여부에 따라 캡처에서 보이는 연결이 달라질 수 있다. HTTP/2 연결 병합으로 일부 호스트가 별도로 보이지 않았다는 설명도 가설로 남았다.
공개 코드는 시험한 앱보다 두 패치 버전 뒤인 1.65.0 상태였고 완전하지 않았다. 코드에서는 두 SDK가 StoreKit 버전 설정을 제외하면 기본값으로 구성됐으며, 데이터 수집을 제한할 수 있는 몇몇 옵션은 사용되지 않았다. 다만 이 SDK 버전에서 대부분의 관찰된 전송을 끌 방법은 없었다. 조사팀은 이 방법으로 제작사가 대시보드에서 데이터를 읽는지, 두 서비스가 데이터를 결합하는지, 각 서비스가 데이터를 어떻게 처리하는지 확인할 수 없다고 밝혔다. 제작사의 데이터 사용 목적도 트래픽만으로 검증할 수 없다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요