system_server가 높은 네트워크 권한으로 동작하고 VPN 라우팅 제한에서 제외된다면, Android에서 VPN은 사실상 VPN이 아닌 것 아닌가 싶음
이 버그와 별개로, 다른 잠긴 운영체제들도 같은 식으로 동작하는지 궁금함
iOS도 동일하며, 우회하려면 250대 이상 기기용 엔터프라이즈 라이선스가 필요한 것으로 알고 있음
Mullvad 등도 오래전에 이 문제를 다뤘음
“private”나 “trust” 같은 용어는 컴퓨터 세계와 인간의 관습에서 의미가 다름
사람들이 같은 철자의 단어를 보고 맥락 차이를 못 알아채서, 인간적 신뢰를 컴퓨터의 신뢰 모델로 잘못 확장하는 점이 걱정됨
macOS도 자체 앱이 상시 VPN을 우회할 수 있었던 사례가 있음
임의 목적지로 트래픽을 직접 보낼 수 있는 취약점이나 빈틈이 있었는지는 잘 모르겠음
system_server와 다른 우회 경로를 고치는 일이 얼마나 어려운지 궁금함
Manifest V3와 비슷하게, 엿보기를 막는 건 Google의 이익에 맞지 않음
그런 제한은 사업 모델에 손해가 됨
이 문제가 심각한 기술적 이유는 누수가 권한 있는 프로세스인 system_server 에서 발생한다는 점임
Android의 자체 잠금 모드는 어떤 트래픽도 VPN을 우회하지 않는다고 명시적으로 약속함. 시스템 자체가 물리 인터페이스로 패킷을 보내면, 그 약속은 사용자 공간이 아니라 커널 수준에서 깨지는 것이라 “보안 공지급이 아니다”라고 하기는 어렵다
Google이 4월 29일 공개를 허가했다면, 그 시점에도 엠바고를 지키고 수정 배포를 5월까지 미룬 게 놀라움
왜 바로 공개하지 않았는지 모르겠음
공급업체로서 Google과의 관계를 해치지 않으려 한 가능성이 큼
좋든 싫든 GrapheneOS는 Google이 통제하는 Android에 의존하고 있음
나쁜 사업적 이유가 있다는 건 알지만, VPN 누수를 보안 이슈가 아니라고 분류하면서 자존심을 유지할 수 있는지 모르겠음
VPN의 역할을 어떻게 보느냐에 달림
원래 VPN은 다른 네트워크를 통해 사설망이나 업무망에 접근하기 위한 것이었고, 사무실 간 연결이나 집에서 사무실로 접속하는 용도였음. 나중에야 일종의 보안 도구처럼 변했음
VPN 코드를 “휴대폰이 5G로 사무실 프린터에 접근할 수 있으면 된다” 정도로 보면, QUIC 연결이 제대로 닫히지 않는 작은 버그일 수 있음. 반대로 “이 WireGuard 터널이 무슨 일이 있어도 내 신원을 지켜야 한다”거나 “인터넷에서 오간 모든 트래픽의 정확한 복사본이어야 한다”고 보면 큰 문제임
Android VPN이나 사실상 어떤 VPN도 개인정보 보호·보안 수단으로 설계된 적은 없다고 봄. 특히 기기에서 코드를 실행할 수 있는 앱을 상대로는 더 그렇고, 기기 자체도 모뎀 칩 내부를 포함해 다양한 네트워크 상호작용을 함
Google이 버그를 닫은 건 실수였지만, 버그 바운티 프로그램에서 보안 버그로 보지 않는 이유는 이해할 수 있음
지킬 자존심이 있다고 가정해야 가능한 질문임
Google 입장에서는 버그가 아니라 기능임
Google은 광고 회사이자 공격 계약업체라서, VPN 사용자가 패킷을 누수하는 게 두 이유 모두에서 이득임
그렇게 하라고 돈을 받는 것임
개인 정보의 원치 않는 공개를 보안 이슈로 여기면서 Google에서 일할 수는 없을 것 같음
Meta가 종단간 암호화를 제거하는 것과도 비슷함
“아니, 우리는 네가 말하고 행동하는 걸 전부 보고 싶어”에 가까움
GrapheneOS 휴대폰을 구하는 좋은 방법이 궁금함
GrapheneOS를 써보고 싶었지만 Pixel을 실제로 사는 건 망설여짐. 중고도 “a” 시리즈조차 보통 300달러를 넘고, 몇 세대 전으로 내려가야 함. 부트로더 잠금 해제가 가능한지도 문제임. 새 Pixel 10a에 449달러를 쓰기는 아직 어려움
당장은 도움이 안 되겠지만, GrapheneOS가 최근 Motorola와 파트너십을 발표했으니 1년쯤 뒤에는 일부 Motorola 기기 지원이 나오기 시작할 것 같음
참고로 Google Fi 출시 때 Pixel 10a를 약 300달러에 샀음
Pixel 10a는 사지 않는 게 좋음 Pixel 9a가 거의 같은 기기이고 아직 신품으로 판매 중임
Pixel 8 시리즈 이상을 권장함
통신사 매장이 아닌 일반 매장이나 Google Store에서 신품으로 사는 편이 확실함
중고는 OEM 잠금 해제 처리 문제 때문에 도박에 가까우니, 반품 정책이 좋은지 확인하고 구매 전에 OEM 잠금 해제가 접근 가능한지 검증해야 함
다른 스레드에서 답했음: https://news.ycombinator.com/item?id=48076522
기본적으로 부트로더 잠금 해제가 확실히 가능한 Pixel 6 이후 기기를 사면 됨. 다만 Pixel 6는 곧 최소 지원만 남을 테니 Pixel 7 이후를 추천함. 대부분의 중고 매물은 부트로더 잠금 해제가 안 됨
즉 Google에서 직접 사거나, 이미 GrapheneOS/CalyxOS/LineageOS가 설치된 eBay 매물을 사거나, 판매자가 명시적으로 부트로더 잠금 해제가 가능하다고 밝힌 기기를 사는 게 좋음
개인적으로는 판매자가 이미 말하지 않았다면 부트로더 확인을 요청해도 소용없었음. 거의 아무도 확인 절차를 거치려 하지 않고, 답은 대개 “안 됨”일 가능성이 높으며, 질문을 오해해서 그냥 “언락폰”이라고 답할 수도 있고, 그런 질문에 지쳐 있을 수도 있음
조금 기다리는 방법도 있음
더 많은 휴대폰 하드웨어를 지원하는 작업이 진행 중이고, 어느 브랜드인지는 한동안 추측 대상이었음
GrapheneOS를 써보려고 중고 Pixel 6를 싸게 샀지만 별로 마음에 들지 않았음 LineageOS의 사용자 경험이 훨씬 낫다고 느낌. 패키지 관리자 구조가 러시아 인형처럼 이상함. 기본 “App Store”에는 몇 가지 기본 프로그램만 있고, 그중 하나가 또 다른 패키지 관리자인 Accrescent인데, 앱 수가 여전히 매우 부족해서 또 다른 패키지 관리자가 필요함. GrapheneOS 쪽은 F-Droid보다 Obtainium을 선호하는 듯한데 이것도 이상한 결정으로 보임
완전한 오픈소스 패키지 관리자를 훨씬 선호하고, GitHub 패키지를 신뢰하는 대신 외부에서 소스에서 빌드하고 가능하면 재현 가능하게 빌드하는 데는 실제 가치가 있음. GrapheneOS의 보안 모델은 묘하게 중앙집중적으로 보임. 보고된 개인정보 보호와 보안상의 이점은 직접 판단하기 어려움
그냥 F-Droid를 직접 내려받으면 됨
왜 확정적이고 사전 탑재된 앱 스토어가 꼭 있어야 한다고 집착하는지 모르겠음
앱 스토어를 운영하는 건 Android 포크를 유지하는 것만큼이나 일이 많고, 이미 F-Droid, Play Store와 Aurora Store, Obtainium 등 여러 선택지가 있는 상황에서 GrapheneOS 개발자들이 막대한 노력을 들이지 않는다고 탓하기는 어려움
App Store는 앱을 어디서 받을지 결정하기 위한 최소한의 출발점에 가까움
기본 상태에는 런처와 최소 운영체제만 있고, 미니멀리스트에게 필요한 전부임
더 필요하면 사용자가 어디로 갈지 정하면 됨. 나는 이것을 사용자에게 권한을 주는 방식이라고 부르고, 당신은 불편함이라고 부르는 듯함. 그렇다면 그 운영체제가 당신에게 맞지 않을 수도 있음
어떤 소프트웨어가 자유·오픈소스라고 해서 본질적으로 더 안전하거나 더 사적인 것은 아님
“오픈소스”는 기본적으로 라이선스 용어일 뿐임
GrapheneOS의 “App Store”는 일반 사용에 필요한 가장 기본적인 앱을 제공하기 위한 것임. Accrescent가 거기 배포되는 이유는 실제 앱 저장소로서 Android의 보안 기준선을 따르기 때문이고, F-Droid와 Aurora Store는 그렇지 않기 때문임
F-Droid처럼 제3자가 앱을 빌드해 악성 동작을 확인하는 방식에는 큰 가치가 없다고 봄. 이런 검사는 신뢰성이 낮고 우회된 적도 있음. WireGuard가 더 이상 F-Droid에 없는 이유 중 하나도 그것임. 개발자에게서 직접 받을 만큼 앱을 신뢰하지 못한다면, 그 앱은 쓰지 않는 게 맞음
GrapheneOS의 개인정보 보호와 보안 이점은 평균 사용자에게 거의 보이지 않도록 설계되어 있음. 예로 메모리 손상 버그를 막기 위한 강화 메모리 할당기와 메모리 태깅 확장, 그리고 Google이 기기 전체를 통제하지 못하게 하면서 Google 서비스를 쓰도록 샌드박스된 Google Play를 설치할 수 있는 기능이 있음
GrapheneOS는 Android Open Source Project의 사용자 인터페이스를 물려받았고, Pixel의 기본 운영체제와 다른 여러 제조사 Android 포크도 이를 기반으로 함
GrapheneOS의 App Store는 AOSP가 요구하는 1차 앱 스토어 역할을 채우기 위해 존재함. 또한 1차 앱을 운영체제 업데이트와 별도로 갱신하고, 경우에 따라 앱을 미러링하는 역할도 함
Accrescent는 개인정보 보호와 보안에 초점을 두기 때문에 미러링됨. 현재 알파 상태이고 앱 제출은 닫혀 있지만 곧 열릴 예정임
Google Play는 Google Play가 필요한 앱과의 호환성, 그리고 Play Store 접근을 위해 미러링됨
GrapheneOS 커뮤니티가 Obtainium을 선호하는 이유는 GitHub 같은 곳에서 개발자가 서명한 앱을 가져올 수 있기 때문임. F-Droid는 메인 저장소의 거의 모든 앱을 오래된 빌드 인프라와 부실한 조정 체계로 서명하고 빌드함
GrapheneOS의 보안 모델은 AOSP 보안 모델을 계승하고 그 위에 추가로 강화한 것임
CalyxOS가 다시 활발해지고 있어 정말 반가움
GrapheneOS에는 멋진 기술적 구현이 많지만, Calyx 쪽이 더 단순하고 순정 Android에 가까운 방식으로 처리하는 부분이 많아 보임
GrapheneOS는 “VPN 누수 수정”을 위해 registerQuicConnectionClosePayload 최적화를 비활성화했고, 지원 Pixel 기기에서 공격 벡터를 사실상 무력화했다고 함
즉 GrapheneOS는 최적화를 끄는 방식으로 누수를 “수정”한 것임
예전에 HN에서는 QUIC을 칭찬하고, QUIC이 누구에게 가장 이득인지 묻는 댓글을 낮게 평가한 적이 있었음. QUIC 사용은 다른 이들의 이익에 맞을 수 있지만 나에게는 절충이 맞지 않아 QUIC 트래픽을 차단함
QUIC은 Android처럼 Google이 배포하는 소프트웨어에서 기본으로 켜져 있는 경우가 있고, 어떤 경우에는 끌 방법도 없음
GrapheneOS에서도 QUIC 자체는 여전히 잘 동작함
GrapheneOS가 제거한 것은 앱이 죽는 등의 상황에서 운영체제에 QUIC 연결을 자동으로 닫아 달라고 요청하는 방법뿐임. 서버 관점에서는 연결이 열린 것으로 남아 리소스를 잡고 있다가 유휴 시간 제한 뒤 종료 절차를 거치는 일을 피할 수 있으니 최적화지만, 클라이언트 관점의 최적화는 아님
GrapheneOS는 이 외에도 약 5개의 VPN 누수를 수정했고 추가 수정도 진행 중임. Android의 현재 VPN 구현은 프로필별 VPN이지만 프로필이 아직 자체 네트워크 네임스페이스를 쓰지 않고, DNS 해석기와 여러 중앙 서비스가 VPN 지원을 올바르게 처리해야 해서 누수에 취약함
앞으로 VPN 구조를 개선해 누수에 매우 강하게 만들 계획이 있음. 앱이나 앱 그룹을 가상 머신에서 실행하는 지원도 들어갈 예정이며, 이는 더 강한 보호를 제공할 수 있음
이것은 QUIC 연결을 우아하게 닫는 경로가 부적절하거나 악용 가능한 호출을 통해 노출된 것이지, GrapheneOS가 QUIC 전체를 비활성화한 것은 아님
QUIC 자체는 훌륭하고, 이건 프로토콜의 기능이 아니라 감시 운영체제인 Google Android의 기능에 가까움
게다가 최신 릴리스 전 운영체제에서 확인했을 때도 제대로 동작하지 않았음
순정 Android는 스파이웨어이자 애드웨어임
예전 같으면 이런 소프트웨어를 악성으로 부르고 제거했겠지만, 이제는 기본값이 됨
다들 동의하지만 해결책이 뭔지 모르겠음
사용자 99%가 신경 쓰지 않는다는 걸 알고 있으니 압박할 수 있는 지점은 휴대폰 제조사뿐임. 이 분야에서 의미 있는 영향력을 가진 누구에게도 영향을 줄 힘이 없어 무력함 느껴짐
Hacker News 의견들
system_server가 높은 네트워크 권한으로 동작하고 VPN 라우팅 제한에서 제외된다면, Android에서 VPN은 사실상 VPN이 아닌 것 아닌가 싶음이 버그와 별개로, 다른 잠긴 운영체제들도 같은 식으로 동작하는지 궁금함
Mullvad 등도 오래전에 이 문제를 다뤘음
사람들이 같은 철자의 단어를 보고 맥락 차이를 못 알아채서, 인간적 신뢰를 컴퓨터의 신뢰 모델로 잘못 확장하는 점이 걱정됨
임의 목적지로 트래픽을 직접 보낼 수 있는 취약점이나 빈틈이 있었는지는 잘 모르겠음
system_server와 다른 우회 경로를 고치는 일이 얼마나 어려운지 궁금함Manifest V3와 비슷하게, 엿보기를 막는 건 Google의 이익에 맞지 않음
그런 제한은 사업 모델에 손해가 됨
이 문제가 심각한 기술적 이유는 누수가 권한 있는 프로세스인
system_server에서 발생한다는 점임Android의 자체 잠금 모드는 어떤 트래픽도 VPN을 우회하지 않는다고 명시적으로 약속함. 시스템 자체가 물리 인터페이스로 패킷을 보내면, 그 약속은 사용자 공간이 아니라 커널 수준에서 깨지는 것이라 “보안 공지급이 아니다”라고 하기는 어렵다
Google이 4월 29일 공개를 허가했다면, 그 시점에도 엠바고를 지키고 수정 배포를 5월까지 미룬 게 놀라움
왜 바로 공개하지 않았는지 모르겠음
좋든 싫든 GrapheneOS는 Google이 통제하는 Android에 의존하고 있음
나쁜 사업적 이유가 있다는 건 알지만, VPN 누수를 보안 이슈가 아니라고 분류하면서 자존심을 유지할 수 있는지 모르겠음
원래 VPN은 다른 네트워크를 통해 사설망이나 업무망에 접근하기 위한 것이었고, 사무실 간 연결이나 집에서 사무실로 접속하는 용도였음. 나중에야 일종의 보안 도구처럼 변했음
VPN 코드를 “휴대폰이 5G로 사무실 프린터에 접근할 수 있으면 된다” 정도로 보면, QUIC 연결이 제대로 닫히지 않는 작은 버그일 수 있음. 반대로 “이 WireGuard 터널이 무슨 일이 있어도 내 신원을 지켜야 한다”거나 “인터넷에서 오간 모든 트래픽의 정확한 복사본이어야 한다”고 보면 큰 문제임
Android VPN이나 사실상 어떤 VPN도 개인정보 보호·보안 수단으로 설계된 적은 없다고 봄. 특히 기기에서 코드를 실행할 수 있는 앱을 상대로는 더 그렇고, 기기 자체도 모뎀 칩 내부를 포함해 다양한 네트워크 상호작용을 함
Google이 버그를 닫은 건 실수였지만, 버그 바운티 프로그램에서 보안 버그로 보지 않는 이유는 이해할 수 있음
Google은 광고 회사이자 공격 계약업체라서, VPN 사용자가 패킷을 누수하는 게 두 이유 모두에서 이득임
Meta가 종단간 암호화를 제거하는 것과도 비슷함
“아니, 우리는 네가 말하고 행동하는 걸 전부 보고 싶어”에 가까움
GrapheneOS 휴대폰을 구하는 좋은 방법이 궁금함
GrapheneOS를 써보고 싶었지만 Pixel을 실제로 사는 건 망설여짐. 중고도 “a” 시리즈조차 보통 300달러를 넘고, 몇 세대 전으로 내려가야 함. 부트로더 잠금 해제가 가능한지도 문제임. 새 Pixel 10a에 449달러를 쓰기는 아직 어려움
참고로 Google Fi 출시 때 Pixel 10a를 약 300달러에 샀음
Pixel 9a가 거의 같은 기기이고 아직 신품으로 판매 중임
통신사 매장이 아닌 일반 매장이나 Google Store에서 신품으로 사는 편이 확실함
중고는 OEM 잠금 해제 처리 문제 때문에 도박에 가까우니, 반품 정책이 좋은지 확인하고 구매 전에 OEM 잠금 해제가 접근 가능한지 검증해야 함
기본적으로 부트로더 잠금 해제가 확실히 가능한 Pixel 6 이후 기기를 사면 됨. 다만 Pixel 6는 곧 최소 지원만 남을 테니 Pixel 7 이후를 추천함. 대부분의 중고 매물은 부트로더 잠금 해제가 안 됨
즉 Google에서 직접 사거나, 이미 GrapheneOS/CalyxOS/LineageOS가 설치된 eBay 매물을 사거나, 판매자가 명시적으로 부트로더 잠금 해제가 가능하다고 밝힌 기기를 사는 게 좋음
개인적으로는 판매자가 이미 말하지 않았다면 부트로더 확인을 요청해도 소용없었음. 거의 아무도 확인 절차를 거치려 하지 않고, 답은 대개 “안 됨”일 가능성이 높으며, 질문을 오해해서 그냥 “언락폰”이라고 답할 수도 있고, 그런 질문에 지쳐 있을 수도 있음
더 많은 휴대폰 하드웨어를 지원하는 작업이 진행 중이고, 어느 브랜드인지는 한동안 추측 대상이었음
GrapheneOS를 써보려고 중고 Pixel 6를 싸게 샀지만 별로 마음에 들지 않았음
LineageOS의 사용자 경험이 훨씬 낫다고 느낌. 패키지 관리자 구조가 러시아 인형처럼 이상함. 기본 “App Store”에는 몇 가지 기본 프로그램만 있고, 그중 하나가 또 다른 패키지 관리자인 Accrescent인데, 앱 수가 여전히 매우 부족해서 또 다른 패키지 관리자가 필요함. GrapheneOS 쪽은 F-Droid보다 Obtainium을 선호하는 듯한데 이것도 이상한 결정으로 보임
완전한 오픈소스 패키지 관리자를 훨씬 선호하고, GitHub 패키지를 신뢰하는 대신 외부에서 소스에서 빌드하고 가능하면 재현 가능하게 빌드하는 데는 실제 가치가 있음. GrapheneOS의 보안 모델은 묘하게 중앙집중적으로 보임. 보고된 개인정보 보호와 보안상의 이점은 직접 판단하기 어려움
왜 확정적이고 사전 탑재된 앱 스토어가 꼭 있어야 한다고 집착하는지 모르겠음
앱 스토어를 운영하는 건 Android 포크를 유지하는 것만큼이나 일이 많고, 이미 F-Droid, Play Store와 Aurora Store, Obtainium 등 여러 선택지가 있는 상황에서 GrapheneOS 개발자들이 막대한 노력을 들이지 않는다고 탓하기는 어려움
기본 상태에는 런처와 최소 운영체제만 있고, 미니멀리스트에게 필요한 전부임
더 필요하면 사용자가 어디로 갈지 정하면 됨. 나는 이것을 사용자에게 권한을 주는 방식이라고 부르고, 당신은 불편함이라고 부르는 듯함. 그렇다면 그 운영체제가 당신에게 맞지 않을 수도 있음
“오픈소스”는 기본적으로 라이선스 용어일 뿐임
GrapheneOS의 “App Store”는 일반 사용에 필요한 가장 기본적인 앱을 제공하기 위한 것임. Accrescent가 거기 배포되는 이유는 실제 앱 저장소로서 Android의 보안 기준선을 따르기 때문이고, F-Droid와 Aurora Store는 그렇지 않기 때문임
F-Droid처럼 제3자가 앱을 빌드해 악성 동작을 확인하는 방식에는 큰 가치가 없다고 봄. 이런 검사는 신뢰성이 낮고 우회된 적도 있음. WireGuard가 더 이상 F-Droid에 없는 이유 중 하나도 그것임. 개발자에게서 직접 받을 만큼 앱을 신뢰하지 못한다면, 그 앱은 쓰지 않는 게 맞음
GrapheneOS의 개인정보 보호와 보안 이점은 평균 사용자에게 거의 보이지 않도록 설계되어 있음. 예로 메모리 손상 버그를 막기 위한 강화 메모리 할당기와 메모리 태깅 확장, 그리고 Google이 기기 전체를 통제하지 못하게 하면서 Google 서비스를 쓰도록 샌드박스된 Google Play를 설치할 수 있는 기능이 있음
GrapheneOS의 App Store는 AOSP가 요구하는 1차 앱 스토어 역할을 채우기 위해 존재함. 또한 1차 앱을 운영체제 업데이트와 별도로 갱신하고, 경우에 따라 앱을 미러링하는 역할도 함
Accrescent는 개인정보 보호와 보안에 초점을 두기 때문에 미러링됨. 현재 알파 상태이고 앱 제출은 닫혀 있지만 곧 열릴 예정임
Google Play는 Google Play가 필요한 앱과의 호환성, 그리고 Play Store 접근을 위해 미러링됨
GrapheneOS 커뮤니티가 Obtainium을 선호하는 이유는 GitHub 같은 곳에서 개발자가 서명한 앱을 가져올 수 있기 때문임. F-Droid는 메인 저장소의 거의 모든 앱을 오래된 빌드 인프라와 부실한 조정 체계로 서명하고 빌드함
GrapheneOS의 보안 모델은 AOSP 보안 모델을 계승하고 그 위에 추가로 강화한 것임
GrapheneOS에는 멋진 기술적 구현이 많지만, Calyx 쪽이 더 단순하고 순정 Android에 가까운 방식으로 처리하는 부분이 많아 보임
GrapheneOS는 “VPN 누수 수정”을 위해
registerQuicConnectionClosePayload최적화를 비활성화했고, 지원 Pixel 기기에서 공격 벡터를 사실상 무력화했다고 함즉 GrapheneOS는 최적화를 끄는 방식으로 누수를 “수정”한 것임
예전에 HN에서는 QUIC을 칭찬하고, QUIC이 누구에게 가장 이득인지 묻는 댓글을 낮게 평가한 적이 있었음. QUIC 사용은 다른 이들의 이익에 맞을 수 있지만 나에게는 절충이 맞지 않아 QUIC 트래픽을 차단함
QUIC은 Android처럼 Google이 배포하는 소프트웨어에서 기본으로 켜져 있는 경우가 있고, 어떤 경우에는 끌 방법도 없음
GrapheneOS가 제거한 것은 앱이 죽는 등의 상황에서 운영체제에 QUIC 연결을 자동으로 닫아 달라고 요청하는 방법뿐임. 서버 관점에서는 연결이 열린 것으로 남아 리소스를 잡고 있다가 유휴 시간 제한 뒤 종료 절차를 거치는 일을 피할 수 있으니 최적화지만, 클라이언트 관점의 최적화는 아님
GrapheneOS는 이 외에도 약 5개의 VPN 누수를 수정했고 추가 수정도 진행 중임. Android의 현재 VPN 구현은 프로필별 VPN이지만 프로필이 아직 자체 네트워크 네임스페이스를 쓰지 않고, DNS 해석기와 여러 중앙 서비스가 VPN 지원을 올바르게 처리해야 해서 누수에 취약함
앞으로 VPN 구조를 개선해 누수에 매우 강하게 만들 계획이 있음. 앱이나 앱 그룹을 가상 머신에서 실행하는 지원도 들어갈 예정이며, 이는 더 강한 보호를 제공할 수 있음
QUIC 자체는 훌륭하고, 이건 프로토콜의 기능이 아니라 감시 운영체제인 Google Android의 기능에 가까움
게다가 최신 릴리스 전 운영체제에서 확인했을 때도 제대로 동작하지 않았음
순정 Android는 스파이웨어이자 애드웨어임
예전 같으면 이런 소프트웨어를 악성으로 부르고 제거했겠지만, 이제는 기본값이 됨
사용자 99%가 신경 쓰지 않는다는 걸 알고 있으니 압박할 수 있는 지점은 휴대폰 제조사뿐임. 이 분야에서 의미 있는 영향력을 가진 누구에게도 영향을 줄 힘이 없어 무력함 느껴짐