AdGuard 연구: Apple의 시스템 전체 필터링 API

Apple의 시스템 전체 필터링 접근 방식은 최근 개발자들이 익숙해져 있던 방식과 크게 다른 API를 도입했습니다. 이로 인한 변화는 OS 수준에서 필터링을 구현하는 방법에 대한 여러 새로운 아이디어를 떠올리게 했으며, 이는 콘텐츠 차단 기술의 미래를 위한 흥미로운 사례 연구가 될 것입니다.

AFDS에서의 논의는 주로 대부분의 콘텐츠 필터링이 이루어지는 환경인 브라우저와 웹 확장 프로그램에 집중되지만, 시스템 전체 필터링은 더 광범위하고 점점 더 중요한 과제를 제시합니다. 애플의 새로운 API의 한계와 기능을 살펴보는 것은 브라우저 기반 필터링 개선에도 도움이 될 수 있는 통찰력을 제공합니다. 하지만 먼저, 시스템 전체 필터링이란 정확히 무엇을 의미하는지 살펴보겠습니다.

시스템 전체 필터링이란 무엇인가요?

시스템 전체 필터링은 기본적으로 브라우저 트래픽뿐만 아니라 모든 애플리케이션의 웹 트래픽을 가로채고 차단할 수 있는 기능을 의미합니다.

브라우저 내 트래픽 필터링은 브라우저 확장 프로그램 덕분에 항상 비교적 간단했습니다. Manifest V3가 도입된 지금도 브라우저는 콘텐츠 필터링을 위한 명확하고 잘 정의된 API를 제공합니다.

API(Application Programming Interface)는 서로 다른 소프트웨어 시스템이 상대방의 구조를 알 필요 없이 원활하게 소통할 수 있게 해주는 '공통 언어'입니다.

운영체제 수준으로 확대해 보면 사정이 완전히 달라집니다. 운영체제 중 어느 것도 콘텐츠 필터링 전용 API를 제공하지 않기 때문에, 광고 차단기 개발자들은 플랫폼별 기술에 의존해야 하며 각각 고유한 단점을 지닙니다.

시스템 전체 필터링이 왜 중요한지 의문이 들 수 있습니다. 브라우저에서만 광고를 차단하면 안 될까요? 최근 연구에 따르면 모바일 기기에서 브라우저 기반 트래픽은 전체 트래픽의 15% 미만을 차지합니다. 데스크톱에서는 여전히 브라우저가 전체 트래픽의 약 55~60%를 차지하며 우위를 점하고 있지만, 모든 플랫폼을 통틀어 보면 전체 인터넷 트래픽의 약 30%만이 브라우저에서 발생합니다. 나머지 70%는 앱에서 발생합니다.

그리고 바로 여기에 진정한 개인정보 보호 문제가 있습니다. 앱 내 추적은 웹사이트보다 훨씬 더 침습적입니다. 앱은 더 많은 개인 데이터에 접근할 수 있고, 기기 리소스와 직접 상호작용하며, 웹사이트가 절대 사용할 수 없는 지속적 식별자를 활용합니다. 이 때문에 기기 트래픽 전체를 필터링하는 작업이 더욱 중요해집니다.

시스템 전체 필터링은 항상 AdGuard의 핵심 강점 중 하나였습니다. 사실, 15년 이상 전에 출시된 최초 버전의 AdGuard는 네트워크 수준에서 광고를 차단하는 Windows 애플리케이션이었습니다. 시간이 지나면서 우리는 모든 주요 플랫폼으로 확장했으며, AdGuard DNS와 AdGuard Home이라는 두 가지 추가 제품을 출시함으로써 한 걸음 더 나아갔습니다. 이 제품들은 단일 브라우저 내 트래픽 필터링뿐만 아니라 전체 기기(심지어 전체 네트워크!)를 보호하는 것을 목표로 합니다.

이 점이 바로 저희에게 흥미로운 이유입니다. 아직도 개선의 여지가 많으며, 운영체제 공급업체 중 하나인 애플이 마침내 이에 주목하기 시작했다는 점이 기쁩니다.

시스템 전체 필터링 작동 방식

저희 관점을 이해하려면 먼저 시스템 전체 필터링이 어떻게 시작되었는지, 현재 어떻게 작동하는지, 그리고 광고 차단기 개발자들이 여전히 직면하고 있는 과제가 무엇인지 알아야 합니다. 간단한 옛날 방식 테스트: 광고 차단은 사실 광고 서버를 존재하지 않는 IP 주소로 리다이렉트하는 데 사용되던 HOSTS 파일에서 시작되었다는 사실을 알고 계셨나요? HOSTS는 DNS 서버와 마찬가지로 호스트명을 IP 주소에 매핑하는 일반 텍스트 파일입니다.

Peter Lowe의 차단 목록에서 발췌한 내용

물론 호스트 파일에는 한계가 있습니다: 정적이며 정확한 도메인만 차단할 수 있고, 업데이트가 어렵고 우회될 수 있습니다. 그럼에도 이것이 모든 것의 시작이었습니다. 또 다른 일반적인 접근법은 DNS 싱크홀링으로, 기본적으로 호스트 파일과 같은 개념이지만 DNS 수준에서 적용되어 여러 기기에서 동시에 작동합니다.

DNS 서버를 사용하여 도메인 접근을 차단하는 예시

일부 문제는 해결했지만 중요한 한계가 있었습니다. 여전히 도메인만 차단할 수 있었고 우회될 수 있었습니다. 따라서 DNS 싱크홀링은 많은 경우에 도움이 되지만 완벽한 해결책은 아닙니다.

다음으로 등장한 것은 프록시 서버였습니다. HTTP 트래픽을 위해 사용자의 기기와 인터넷 사이에서 중개자 역할을 하는 서버입니다. 이 접근 방식은 광고 차단 초기 시절에 매우 대중적이었습니다. Ad Muncher나 초기 버전의 AdGuard를 비롯한 많은 “클래식” 도구들이 이를 사용했습니다. 여기 보이는 스크린샷은 약 15년 전, AdGuard(당시에는 Adguard로 표기되었습니다!)가 기본적으로 HTTP 프록시처럼 작동하던 시절의 것입니다.

프록시의 주요 장점은 트래픽이 암호화되지 않은 경우 도메인 이름뿐만 아니라 전체 URL을 기반으로 트래픽을 필터링할 수 있다는 점입니다. 암호화된 경우에도 여전히 도메인 이름을 확인할 수 있습니다.

시스템 전체 필터링에 어떤 방법을 사용하든, 첫 번째 기술적 과제는 트래픽을 가로채서 DNS, 프록시 등 필터로 라우팅하는 것입니다. 플랫폼마다 다른 기술이 필요합니다:

• Android: 로컬 VPN
• iOS: 로컬 VPN, DNS 설정 확장 프로그램
• macOS: 네트워크 확장 프로그램(투명 프록시, DNS 프록시)
• Windows: WFP/TDI/WinSock/NDIS 드라이버

이 방법들 각각에 대해 자세히 설명하지는 않겠습니다. 이 모든 방법들이 구현하기 쉽지 않고, 실수하기 쉬우며, 호환성 문제에 자주 부딪힌다는 점만 알면 충분합니다. 그럼에도 시스템 수준에서 트래픽을 필터링하려면 우리가 감수해야 할 기본 요소들입니다.

앞서 언급한 모든 문제를 해결한다 해도 여전히 큰 문제가 하나 남습니다. 정확한 필터링을 위해서는 전체 URL 가시성이 필요하다는 점입니다. 왜 중요할까요? 두 가지 사례를 들어 설명하겠습니다.

1. 첫 번째는 페이스북의 광고 네트워크입니다. 페이스북은 동일한 도메인(graph.facebook.com)에서 합법적인 콘텐츠와 추적 요청을 동시에 제공합니다. 전체 URL에 접근할 수 없다면, 이 도메인을 차단하는 것은 페이스북 자체도 작동하지 못하게 만들 것입니다.
2. 두 번째 예시는 IAB의 새로운 제안인 ‘신뢰할 수 있는 서버(Trusted Server)’입니다. 여기서 세부 사항은 생략하겠지만, 간단히 말해 광고 경매를 서버 측으로 이동시키고 광고를 퍼블리셔 자체 도메인에서 전달하여 퍼스트 파티 콘텐츠처럼 보이게 합니다.

현재 전체 URL을 검사하는데 유일한 신뢰할 수 있는 방법은 TLS 가로채기 기능을 갖춘 프록시를 실행하는 것입니다. 이는 매우 복잡한 작업이지만, 여전히 수행해야 할 일입니다.

프록시 + TLS 가로채기 다이어그램

따라서 필터링이 작동하려면 누군가가 사용자의 트래픽을 관찰해야 합니다. 브라우저 확장 프로그램, VPN, 안티바이러스 프로그램 등 어떤 형태로든 말이죠. 이는 피할 수 없는 사실입니다. 이상적으로는 이 처리가 사용자의 기기에서 로컬로 이루어져야 합니다. 데이터가 기기를 벗어나지 않기 때문에 더 안전합니다. 따라서 로컬 필터링이 바람직하지만, 프라이버시를 보장하지는 않습니다. 사용자는 여전히 필터를 운영하는 주체에게 신뢰를 두어야 합니다.

그렇다면 이상적인 시스템 전체 필터링 솔루션은 어떤 모습이어야 할까요? 충족해야 할 몇 가지 기준이 있습니다.

1. 첫째, 정확한 필터링을 위해 완전한 URL 필터링을 지원해야 합니다.
2. 다음으로 광범위한 필터링 기능을 제공해야 합니다. 단순히 요청을 차단하는 것만으로는 부족합니다. 때로는 요청을 수정하거나 리디렉션하거나 응답을 검사해야 할 때도 있습니다.
3. 매우 방대한 차단 목록도 처리할 수 있어야 합니다.
4. 그럼에도 업데이트는 빠르고 효율적이어야 합니다.
5. 물론 설계상 익명이어야 합니다. 즉, 콘텐츠 차단기가 사용자가 방문하는 웹사이트를 알 필요가 없어야 하며, 규칙을 로컬에서 적용하기만 하면 됩니다.
6. 그럼에도 시스템은 관찰 가능하고 유용하도록 최소한 기본 통계나 차단된 항목 확인 같은 피드백을 제공해야 합니다.
7. 마지막으로, 적절한 디버깅 도구가 존재해야 합니다. 우리 같은 개발자들과 규칙들을 효과적으로 문제 해결해야 하는 필터 관리자 모두를 위해 말이죠.

이 목록을 염두에 두고 Apple의 URL 필터를 살펴보겠습니다.

Apple의 URL 필터

약 10년 전, 애플은 전용 콘텐츠 차단 API를 도입한 최초의 브라우저 개발사가 되었습니다. 이제 10년이 지난 지금, 그들은 또 다른 큰 발걸음을 내디뎠습니다. 이번에는 운영체제 수준에서 말이죠. 애플은 사상 처음으로 시스템 전체 URL 필터링을 위한 공식 API를 제공하고 있습니다. 문서상으로 이는 매우 반가운 소식입니다. 솔직히 말해, 저희는 오랫동안 기다려온 것이기도 합니다. 프라이버시 및 네트워크 필터링 분야에서 일하는 모든 이들에게 흥미로운 기회가 될 것입니다.

이 API가 실제로 어떻게 작동하는지 살펴보겠습니다. 아주 높은 수준의 개요부터 시작하겠습니다.

1. 먼저, 앱이 운영 체제 내에 특별한 URL 필터를 등록합니다. 이는 iOS와 macOS 모두에 적용됩니다.
2. 그런 다음 이를 활성화하기 위해 시스템은 인증 단계를 수행합니다. 구성과 자격 증명을 확인하기 위해 서버와 통신합니다.

이 과정이 완료되면 필터는 실행 상태(Running state)로 전환되며, 이때부터 시스템은 요청 URL을 검사하기 위해 해당 필터를 사용하기 시작합니다. URL 필터가 활성화된 상태에서는 시스템 내 모든 앱이 수행하는 웹 요청을 하나하나 검사합니다.

앱이 https://example.org/test로 요청을 보내려고 할 때 어떤 일이 발생하는지 살펴보겠습니다.

Apple의 URL 필터 개요, 필터링

1. 시스템은 URL을 하위 URL로 분할합니다.
2. 이 하위 URL들은 로컬 프리필터에 대조되어 안전하다고 분류될 수 있는 URL을 신속하게 결정합니다.
3. 나머지 URL은 추가 검증을 위해 원격 서버로 전송됩니다.
4. 서버 응답에 따라 시스템은 요청을 차단하거나 허용합니다.

이제 이 방식이 단순하게 구현될 경우 어떻게 개인정보 보호의 악몽으로 변할 수 있는지 쉽게 알 수 있습니다. 이를 해결하기 위해 애플은 효과적인 필터링을 유지하면서도 사용자 개인정보를 보호하기 위한 몇 가지 영리한 설계 방안을 도입했습니다.

전체 URL 필터 API는 여러 현대적인 개인정보 보호 기술을 기반으로 구축되었습니다.

1. 첫째, 사용자 인증에 사용되는 프라이버시 패스가 있습니다.
2. 다음으로 개인정보 검색(PIR) 서비스가 있습니다. 서버 조회에 사용되며, 로컬 사전 필터 역할을 하는 블룸 필터가 함께 제공됩니다.
3. 마지막으로 Oblivious HTTP가 있습니다.

이 모든 기술들은 상당히 새롭고 최첨단입니다. 따라서 애플이 단순히 이를 도입하는 데 그치지 않고 실제 시스템에 통합하는 모습을 보는 것은 매우 흥미롭습니다. 이제 각 구성 요소와 이들이 어떻게 함께 작동하는지 자세히 살펴보겠습니다.

프라이버시 패스

첫 번째 구성 요소는 프라이버시 패스입니다. 이는 현대적인 프라이버시 보호 인증 시스템으로, 클라이언트가 신원이나 행동을 노출하지 않고도 정당한 권한을 증명하는 익명 토큰을 획득할 수 있게 합니다.

프라이버시 패스 플로우 차트. 출처: Cloudflare 블로그

다이어그램 예시:

1. 클라이언트가 오리진 서버에 요청을 보낼 때 유효한 토큰을 요청할 수 있습니다.
2. 클라이언트는 자격을 확인하기 위해 어테스터에 연락합니다. 승인되면 발행자가 프라이버시 패스 토큰을 제공합니다.
3. 클라이언트는 토큰을 오리진에 전송하며, 오리진은 발행자의 공개 키로 이를 검증한 후 요청을 수락합니다.

개인정보 보호의 핵심 개념은 역할 분리입니다: 원본(Origin)과 발급자(Issuer)가 독립적으로 유지되면 인증은 익명으로 이루어집니다. 서버는 토큰이 유효하다는 사실만 알 뿐 사용자가 누구인지는 알 수 없습니다. 이론상 프라이버시 패스(Privacy Pass)는 이렇게 작동하지만, Apple이 실제로 자사 시스템에서 이를 어떻게 활용하는지 살펴보겠습니다.

프라이버시 패스, Apple의 PIR

1. 클라이언트는 먼저 지속적 ID(예: 사용자 계정)를 사용하여 인증을 수행한 후 단기 프라이버시 패스 토큰을 획득합니다.
2. 각 PIR 요청은 이러한 토큰 중 하나를 사용해 합법성을 증명합니다.

원래 아이디어와 유사해 보입니다. 하지만 핵심은 이렇습니다. 이상적인 프라이버시 패스 설계와 달리, 애플 시스템에서 발행자(Issuer)와 원본(PIR 서비스) 모두 동일한 주체, 즉 개발자에게 속합니다. 개발자가 양쪽을 모두 통제하므로 토큰이 사용자와 연결될 가능성이 있습니다. 따라서 진정한 익명성은 전적으로 개발자의 구현 방식에 달려 있습니다. 이제 PIR, 즉 개인정보 검색(Private Information Retrieval, PIR)에 더 집중해 보겠습니다.

개인정보 검색(PIR)

간단히 말해, PIR(Private Information Retrieval, 개인정보 검색)은 클라이언트가 서버로부터 데이터를 검색할 때 서버가 어떤 특정 항목이 요청되었는지 알지 못하도록 하는 암호화 프로토콜 군입니다. 이 개념은 새로운 것이 아닙니다. 1990년대부터 연구되어 왔습니다. 널리 사용되는 PIR 유사 시스템의 가장 오래된 예는 20년 전에 도입된 Google SafeBrowsing입니다. 이는 복잡한 암호화 기술 없이도 유사한 원리를 따릅니다.

Apple의 프라이빗 정보 검색 구현은 훨씬 정교한 시스템으로, 진정한 암호학적 프라이버시 설계를 구현합니다. 작동 방식에 대한 개요는 다음과 같습니다.

Apple의 PIR 구현

1. 서버는 데이터베이스(본질적으로 해시 테이블)를 준비합니다. 각 항목은 암호화되고 인덱싱됩니다.
2. 그런 다음 클라이언트가 서비스와 상호작용하는 방법을 설명하는 구성 정보를 공개합니다: 해시 테이블 구조, 암호화 매개변수 및 기타 메타데이터.
3. 클라이언트가 특정 URL을 확인하고자 할 때, 해당 해시 테이블 내의 대응하는 인덱스를 결정합니다.
4. 클라이언트는 “항목 X를 원합니다”라는 쿼리를 생성하지만, 쿼리는 암호화되어 있어 서버는 항목 X가 실제로 무엇을 가리키는지 알 수 없습니다.
5. 서버는 동형 암호화를 사용하여 이 암호화된 쿼리를 평가하고, 여러 가능한 항목을 포함하는 암호화된 응답을 생성합니다.
6. 클라이언트는 응답을 로컬에서 복호화하고 X가 해당 결과에 포함되어 있는지 확인합니다.
7. X가 발견되면 요청은 차단된 것으로 표시됩니다.

보시다시피, 이는 진정한 사적인 정보 검색처럼 보이며 목표는 달성된 것으로 보입니다.

하지만 성능에 대해 이야기해 보겠습니다. 애플의 PIR 시스템은 자원을 많이 소모합니다.

• 각 쿼리는 약 30KB에 달할 수 있으며, 이는 단일 API 요청으로서는 상당히 큰 크기입니다.
• 이상적인 조건에서도 단일 조회에 100밀리초 이상이 소요될 수 있습니다.

예상할 수 있듯이 데이터베이스가 클수록 각 조회 작업은 더 느려집니다. 이 문제를 해결하기 위해 Apple의 PIR API는 샤딩(sharding)을 허용합니다. 즉, 메인 데이터베이스를 더 작은 부분으로 분할하는 것입니다. 서버는 여러 샤드를 정의하며, 클라이언트는 URL을 확인할 때 함수를 사용하여 해당 샤드 번호를 계산하고 요청에 포함시킵니다. 이는 쿼리 속도를 높이지만 잠재적인 개인정보 유출 위험을 초래합니다: 샤드가 충분히 많을 경우, 특정 샤드가 단일 URL에 대응될 수 있어 사용자가 확인하는 내용을 노출시킬 수 있습니다.

이 위험을 완화할 수 있을까요? 네, 가능하다고 생각합니다. 애플은 최소 샤드 크기나 최대 샤드 수를 강제 적용함으로써 이를 완화할 수 있으며, 그렇게 고려해 주길 바랍니다. 하지만 클라이언트가 모든 URL을 서버에 전송해야 한다면 샤딩만으로는 충분하지 않습니다. 그래서 애플은 또 다른 최적화 단계인 프리필터(기본적으로 블룸 필터)를 추가했습니다.

블룸 필터 다이어그램. 출처: bytedrum.com

블룸 필터의 작동 원리에 대해 깊이 들어가지는 않겠지만, 알아야 할 사항은 다음과 같습니다:

• 매우 빠르고 공간 효율적입니다
• 블룸 필터는 “이 URL이 데이터셋에 존재하는가?”라는 간단한 질문에 답하도록 설계되었습니다.
• 가능한 답변은 다음과 같습니다.
  • 확실히 아님
  • 아마도 있음 (즉, 차단 목록에 있을 수 있으므로 PIR을 사용하여 재확인해야 함)

결과적으로 대부분의 조회 작업은 기기 외부로 나가지 않습니다.

Oblivious HTTP

URL 필터 API의 마지막 구성 요소는 Oblivious HTTP입니다. 요약하자면, 프라이버시 패스는 익명 인증을 보장하고, PIR은 쿼리를 숨기며, OHTTP는 최종 식별자인 사용자의 IP 주소를 제거합니다. OHTTP는 네 가지 주체를 통해 클라이언트와 서버를 분리합니다.

• 클라이언트 (사용자 기기)
• 중계 서버(Apple)
• 게이트웨이(개발자)
• 대상 서버(최종 서버, PIR 또는 프라이버시 패스)

Apple의 PIR에서 Oblivious HTTP

클라이언트는 게이트웨이에 대한 요청을 암호화하여 릴레이를 통해 전송하며, 릴레이는 이를 단순히 전달합니다. 게이트웨이는 요청을 복호화하고 처리한 후 응답을 암호화하여 릴레이를 통해 클라이언트에게 다시 전송합니다. 핵심은 릴레이가 사용자를 알지만 전송 내용을 알지 못하며, 게이트웨이는 요청을 알지만 사용자를 알지 못한다는 점입니다.

하지만 모든 기능을 정상적으로 구현했다 하더라도 마지막 단계인 애플의 심사 절차가 남아 있습니다. 앱이 새 API를 사용하려면 PIR 서비스와 Oblivious HTTP 게이트웨이 모두 애플의 심사를 거쳐 승인을 받아야 합니다. 심사 기간이 상당히 오래 걸릴 수 있으니, 이 API를 기반으로 개발할 계획이라면 미리 준비하시기 바랍니다.

요약

Apple의 URL 필터는 얼마나 효과적일까요? 첫 장에서 시스템 전체에 적용되는 이상적인 필터링 솔루션이 갖춰야 할 특성 목록을 제시한 바 있습니다. 이제 그 목록을 다시 살펴보고 Apple의 새로운 URL 필터링 API가 이러한 기대치에 얼마나 부합하는지 평가해 보겠습니다.

✅ 전체 URL 필터링

문제없습니다.

🚫 광범위한 필터링 기능

안타깝게도 이 방법은 테스트를 통과하지 못합니다. 애플 시스템은 요청 차단만 가능할 뿐입니다. 여기에 더해 몇 가지 중요한 제한 사항이 있습니다.

• 개별 도메인 차단 해제는 불가능합니다. 전부 아니면 전무입니다. 차단 목록 전체가 활성화되거나 완전히 비활성화됩니다.
• 여러 차단 목록을 전환할 수 없습니다. 각 앱은 단일 목록만 제공할 수 있습니다.

이론적으로는 몇 가지 우회 방법이 존재하지만, 이러한 접근법은 적절한 해결책이라기보다는 해킹에 가깝습니다.

✅ 대규모 차단 목록 지원

이 부분은 확실히 체크 표시를 받을 만합니다. API는 처음부터 대규모 차단 목록을 염두에 두고 설계되었습니다.

✅ 빠른 차단 목록 업데이트

여기서도 애플은 체크 표시를 받습니다. API는 자동 업데이트를 지원하며, 최소 업데이트 간격은 45분으로 상당히 우수한 수준입니다.

❔ 설계상 사생활 보호

이제 다음 내용은 좀 더 복잡합니다. 저희에게 “설계상 사생활 보호”란 앱이 이 API를 사용할 때 사용자가 완전히 익명 상태를 유지하며, 개발자가 사용자의 신원을 파악할 방법이 전혀 없다는 의미입니다. 이는 분명 애플의 목표입니다. 전체 시스템이 사용자 프라이버시 보호를 중심으로 설계되었으니까요? 하지만 실제로는 개발자가 이를 악용해 사용자를 재식별하거나 활동을 추적할 수 있는 몇 가지 허점이 보입니다. 애플이 향후 업데이트에서 이러한 문제점을 해결하고 익명성 보장을 더욱 강력하게 만들기를 바랍니다.

🚫 API는 피드백을 제공하지 않습니다

그렇다면 API는 실제 작동 방식에 대해 개발자에게 어떤 피드백을 제공할까요? 아닙니다. 전혀 없습니다. 앱은 URL 필터가 무언가를 차단했는지, 심지어 특정 URL을 확인했는지조차 알 방법이 없습니다. 즉, 완전히 불투명한 상자입니다.

🚫 디버깅 도구

안타깝게도 개발자나 필터 관리자가 내부에서 무슨 일이 벌어지고 있는지 파악할 수 있도록 도와주는 내장 도구는 존재하지 않습니다. 그리고 예상하시다시피 URL 필터의 문제 해결은 매우, 매우 어려운 작업입니다.

✅✅✅ 마지막으로, 지금까지 논의한 모든 단점에도 불구하고 긍정적인 결론을 내리고 싶습니다. 이 API는 아예 없는 것보다 훨씬 낫습니다. 이는 큰 진전입니다 — 운영체제 공급업체가 시스템 전체 필터링을 안전하면서도 프라이버시를 보호하는 방식으로 구현하려는 첫 번째 진정한 시도입니다. Apple이 이 같은 주도권을 잡고 이 사용 사례를 진지하게 고민한 첫 번째 기업이 되어준 점에 진심으로 감사드립니다. 아직 완벽하지는 않지만 매우 유망한 시작이며, 앞으로 어떻게 발전해 나갈지 기대됩니다.

추가로 말씀드리자면, 저희도 자체적인 PIR 구현을 개발했으며 현재 애플의 검토를 받고 있습니다(한 달 넘게 진행 중입니다). 조속히 검토를 통과하여 AdGuard 제품에 이 기능을 추가할 수 있기 바랍니다.

Apple의 PIR 시스템을 실험해 보기로 결정했다면, 시작하는 데 도움이 될 수 있는 몇 가지 도구와 리소스를 소개합니다:

• PIR 서비스 + 프라이버시 패스: Apple은 PIR 및 프라이버시 패스 서비스의 예제 구현을 제공합니다. 실제 운영 환경에 바로 적용할 수 있는 수준은 아니지만, 모든 구성 요소가 어떻게 함께 작동해야 하는지 이해하는 데 훌륭한 참고 자료입니다.
• PIR 및 프라이버시 패스 테스트: 테스트를 용이하게 하기 위해 PIR 및 프라이버시 패스 흐름을 시뮬레이션할 수 있는 작은 명령줄 도구를 만들었습니다. 이 도구는 오픈소스로 GitHub에서 이용 가능합니다.
• Bloom 필터: 애플은 이를 구축하기 위한 공식 코드를 공개하지 않았으며, 관련 문서도 초기에는 상당히 모호했습니다. 그래서 저는 애플의 URL 필터링 API와 완벽히 호환되는 블룸 필터를 생성할 수 있는 Swift 라이브러리를 만들었습니다.
• Oblivious HTTP 게이트웨이: Oblivious HTTP의 경우, Cloudflare는 참조 라이브러리와 즉시 사용 가능한 서버 구현체를 모두 제공합니다.
• GoCurl, Oblivious HTTP 테스트: 마지막으로, OHTTP 설정을 테스트해야 한다면 저희 장기적인 부업 프로젝트인 GoCurl을 사용할 수 있습니다. 기본적으로 Go 기반의 curl 재구현체로, Oblivious HTTP에 대한 내장 지원 같은 추가 기능을 제공합니다.