요약
MicroG는 구글의 Play Services를 자유 소프트웨어로 다시 구현해 구글 앱 없는 안드로이드에서도 앱이 돌아가게 합니다.
MicroG GmsCore 프로젝트의 GitHub 위키 첫 페이지입니다. 구글의 독점 API에 기대는 앱을 LineageOS 같은 AOSP(구글 앱이 빠진 안드로이드 오픈소스 원판) 기반 롬에서도 쓸 수 있게 하는 것이 목표입니다.
왜 중요한가
- 구글 서비스를 걷어 내려는 사용자가 앱 호환성을 크게 잃지 않고 AOSP 기반 롬으로 옮길 수 있는 길입니다.
- 다만 완전한 탈구글은 아닙니다. 위키도 앱이 MicroG와 통신하려면 독점 라이브러리가 여전히 필요할 수 있다고 밝힙니다.
핵심 내용
- 롬이 서명 위조(앱이 공식 Play Services인 것처럼 서명을 내보이는 기능)를 지원해야 쓸 수 있습니다.
- 구글 서비스 사용은 사용자가 직접 켜는 옵트인 방식이고, 위치 서비스는 온라인과 오프라인 모두 지원합니다.
- 배터리·메모리·CPU를 적게 쓰도록 설계했고 군더더기 앱이 없다고 내세웁니다.
- 앱이 구글 네트워크 위치 제공자를 부르면 UnifiedNlp 모듈이 대신 처리합니다.
- 제대로 쓰려면 microG Companion 같은 Play Store 대체 앱도 함께 설치해야 합니다.
HN 반응
- 서명 위조가 안드로이드 보안 모델을 깬다는 지적에, 내 기기에서 도는 검증 가능한 오픈소스라 괜찮다는 반론이 맞섰습니다.
- GrapheneOS 쪽은 MicroG가 구글 비공개 코드(DroidGuard)를 높은 권한으로 돌리고 위치 정보 결함을 몇 년씩 방치했다고 비판해 언쟁이 길어졌습니다.
MicroG를 쓰는 사람들은 SNCF-Connect 같은 앱을 쓸 수 있는데 저는 왜 못 쓰는지 도무지 이해가 안 갑니다.
SNCF-connect는 프랑스에서 가장 큰 온라인 판매 업체입니다. 6월부터 "결제" 버튼을 누를 수가 없게 됐습니다. Pay with Google이라는 새 기능이 들어온 시점과 맞물립니다.
그러니까 e/OS 기기에서는 MicroG가 구글 서비스 호출을 허용하는데 제 LineageOS는 거부해서 그런 걸까요? 아니면 MicroG가 이 호출을 try catch로 감싸 놓았고 실제로는 구글 서버를 호출하지 않아서일까요?
/e/os가 App Lounge [1]도 같이 배포하기 때문인 것 같습니다. App Lounge는 구글 스토어에 연결해서 (대부분의 경우) 결제를 처리할 수 있습니다.
[1] https://doc.e.foundation/os/apps/app-lounge/
플레이 스토어에 연결된다면 Aurora와 똑같은 거 아닌가요? 그러면 계정이 정지될 수도 있나요? 돈 내고 산 걸 구글이 계정을 막아서 잃어버리면 진짜 최악일 텐데요 ㅋㅋ
Aurora 소스 코드를 씁니다.
저는 GrapheneOS에 구글 관련 건 아무것도 설치하지 않았는데 SNCF Connect가 잘 됩니다.
확실한가요? 제 건 로그인이 안 되고, 왜 그런지 모르겠는데 언어도 영어로 고정돼 있습니다.
Play 서비스 호출 중 일부는 아무 일도 하지 않는 빈 함수(no-op)로 대체돼 있고, 나머지는 완전히 자유로운 대체물로 다시 구현했거나(예: 내비게이션) 구글의 독점 원격 엔드포인트를 호출하는 방식(예: firebase)으로 구현돼 있습니다.
MicroG를 쓰더라도, 시중에는 방대한 독점 소프트웨어(그것도 대개 특권을 가진 소프트웨어) 없이 작동하는 안드로이드 기기가 없다는 점은 짚어 둡니다.
https://news.ycombinator.com/item?id=50154624 때문에 올라온 거겠죠?
왜 최근 커밋이 전부 "Merge commit from fork"라고만 되어 있고, 무슨 변경인지도 어떤 포크인지도 설명이 없나요?
GitHub 보안 권고(Security Advisories)용으로 만든 비공개 보안 포크에서 온 PR을 병합하면서 생성된 머지 커밋입니다.
이 커밋들은 3주 전에 공개된 권고와 대응됩니다.
https://github.com/microg/GmsCore/security
대충 만든 머지 커밋이에요. 변경 내용 설명은 병합된 브랜치의 커밋들에 들어 있습니다.
그래서 저는 늘 git이 벌거벗은 임금님이라고 생각합니다. 이런 중간 잡동사니 커밋을 히스토리에서 숨기는 데, 다 같이 쓰는 분산 히스토리를 다시 쓰고 깨뜨려야 해서는 안 됩니다. 제 생각에 맞는 해법은 기존 커밋에 메타데이터(추가 서명, 숨김 플래그, 사후 주석 등)를 붙일 수 있는 태그 비슷한 계층, 아니면 아예 두 번째 DAG를 두는 것이지만, 뭐 어쨌든 git은 히스토리에 주석 달기를 못하는데, 히스토리에 주석 다는 건 git의 핵심 워크플로입니다.
제대로 된 해법은 머지 커밋에 무엇을 왜 병합했는지를 정확히 적는 것입니다. git이 "Merge branch-X into branch-Y"라는 기본 메시지를 미리 채워 주는 건 에디터를 빨리 닫고도 DAG가 멀쩡히 유지되게 하려는 것이죠. 그대로 두는 게 이상적이지 않을 뿐이고, 바로 이런 이유 때문입니다.
Fossil( https://fossil-scm.org/home/doc/trunk/www/index.wiki )은 기본 메시지를 채워 주지 않습니다. 가끔 그게 귀찮았지만, 덕분에 지금 무슨 일을 하는지 생각하게 됩니다. Fossil과 SQLite 트리를 보면 거의 모든 병합에 그 병합이 무엇이고 왜 했는지가 충실히 적혀 있습니다. 또 Fossil은 브랜치의 전체 히스토리(어느 커밋에서 갈라져 나왔는지 포함)를 잊지 않는다는 장점도 있습니다.
git notes에 관심이 있으실 것 같습니다. 말씀하신 부족한 부분을 해결해 주는 기능입니다.이걸 대안으로 쓰려면 서명 위조(signature spoofing)에 의존해야 한다는 게 아쉽습니다(이유는 물론 이해합니다). LineageOS에서는 위조 범위가 좁게 한정돼 있는 것 같지만, 일반적으로는 위험을 만들 거라고 생각합니다.
스톡 안드로이드에서 구글 앱을 지울 수 없는 것처럼, 그런 핵심 앱들에만 서명 위조를 허용하고 설치·삭제는 막으면 안 되나요?
서명 위조는 안드로이드 보안 모델을 위반합니다. microG에 특권 접근을 준다는 뜻이고, 그건 곧 구글에 특권 접근을 준다는 뜻입니다. 프라이버시를 내세우는 프로젝트가 제3자에게 특권 접근을 주는 건 용납할 수 없습니다.
MicroG는 제3자가 아닙니다. 제 기기에서 돌아가는, 감사할 수 있는 FLOSS 코드입니다. microG가 용납 안 된다면 "apt install"로는 아무것도 설치하면 안 됩니다.
microG는 구글의 비공개 소스 서비스를 상당수 그대로 쓰고, 구글 접근 권한을 가진 비공개 소스 Google Play 바이너리를 내려받아 실행하며, 앱이 쓰는 비공개 소스 구글 라이브러리와의 호환성을 제공하려고 존재합니다. microG를 쓴다고 해서 클라이언트 쪽에서도, 많은 서비스에서는 서버 쪽에서도 비공개 소스 구글 코드를 쓰고 있다는 사실이 달라지지 않습니다. 게다가 microG 자체도 여전히 비공개 소스 Google Play 코드를 쓰는데, 심하게 난독화돼 있고 주기적으로 동적으로 바뀌는 droidguard를 내려받아 실행하는 것도 거기 포함됩니다. 그 코드는 microG에 부여된 모든 권한과 특권 접근(위치 권한 포함)을 얻게 됩니다. GrapheneOS에서 샌드박스 처리된 Google Play를 설치할 때는 이런 접근이 주어지지 않습니다.
microG는 프라이버시와 보안 이력이 좋지 않습니다. 심각한 프라이버시·보안 문제가 공개적으로 발견되고도 몇 년씩 고쳐지지 않은 일이 여러 번 있었습니다. 접근 권한이 없어야 할 앱에 위치 데이터가 새는 문제가 그중 하나였는데, 자기들 위키에 문서화까지 해 놓고도 몇 년간 해결하지 않았습니다. 가장 심각한 문제는 고쳐졌지만 위치 구현에는 아직도 프라이버시 구멍이 있습니다.
GrapheneOS는 위치를 포함한 Google Play API의 오픈 소스 재구현을 제공합니다. 별도 서비스가 아니라, 그것을 쓰는 앱 안에서 돌아가는 OS 라이브러리로 제공합니다. 그래서 위치 데이터 접근은 표준 샌드박스와 권한 모델로 제한되며, 이를 서비스 안에서 다시 구현할 필요가 없습니다. 서비스로 다시 구현하면 실수를 하거나 최신 권한 모델을 따라가지 못해 프라이버시 구멍이 생길 수 있고, microG의 위치 서비스에서 실제로 여러 번 그런 일이 있었으며 해결에 몇 년이 걸렸습니다.
GOS의 안타까운 점은, 기술적 장점이 실제로 얼마나 있든 간에 그 커뮤니티의 지독한 독성 하나만으로 관심 있던 사용자 상당수를 멀리 쫓아내기에 충분하다는 겁니다.
좋은 예가 바로 "grapheneos"가 단 이 댓글입니다. 예상대로 MicroG를 아주 자세히 맹비난하더니, 아무런 아이러니도 없이 GOS가 "올바른" 방식으로 하고 있다고 자화자찬하네요.
한 번쯤은 메시지가 어떻게 전달되는지를 생각해 보면 훨씬 멀리 갈 겁니다.
수정: 이 스레드에서 댓글 형태의 에세이를 몇 개 더 봤는데, 제 생각이 맞다는 게 더 확실해졌습니다.
GrapheneOS 프로젝트 구성원과 커뮤니티는 우리 프로젝트와 팀을 향한 부정확한 공격에 정확한 정보로 대응하고 있을 뿐입니다. 당신은 지어낸 이야기와 거짓을 퍼뜨려 사람들이 GrapheneOS를 오해하게 만들고 해를 끼치고 있습니다.
다음은 microG 뒤에 있는 주요 기업 중 하나가 보안 강화 기기를 범죄자와 소아성애자용이라고 깎아내린 사례로, 이들은 이런 짓을 반복해 왔습니다.
https://www.clubic.com/actualite-604786-murena-e-os-interview.html
https://grapheneos.social/@GrapheneOS/116353973732143171
이건 극히 일부입니다. microG 개발자들과 이를 후원하는 여러 기업이 벌인 일이 이것 말고도 엄청나게 많고, 여기에는 Murena CEO를 비롯해 관련된 여러 사람의 악랄한 인신공격과 괴롭힘 콘텐츠 유포도 포함됩니다.
우리는 GrapheneOS를 공격하는 사람들 때문에 이 대화에 끌려 들어왔습니다. 이 대화에 참여하고 싶지 않았습니다. GrapheneOS는 microG를 추천하지도 지원하지도 않습니다. 이 글 전체의 주제는 우리와 아무 상관이 없습니다.
ForHackernews의 댓글을 보시면 우리가 왜 반박하는지 이해하실 겁니다.
GrapheneOS를 공격하는 사람들에게 대응하는 게 뭐가 독성입니까?
문제의 이 댓글만 놓고 보면 쉽게 반증됩니다. 최상위 댓글은 서명 위조에 관한 것이었고 Graphene 얘기는 아예 없었습니다.
제 요점을 스스로 증명해 주시네요. 분명히 말하자면, 저는 GrapheneOS가 성공하길 바라기 때문에 이게 안타깝고, 이런 태도가 그 성공을 크게 가로막고 있습니다.
이 스레드에서 우리가 대응하는 건 당신이 한 것을 포함해 GrapheneOS 프로젝트에 대한 부정확한 공격 때문입니다. microG 개발자들과 이를 후원하는 기업들은 오래전부터 사람들에게 GrapheneOS에 대해 거짓 정보를 퍼뜨리고 우리 팀을 괴롭혀 왔습니다. 이들의 지지자들은 우리 팀원을 물리적으로 해치려는 스와팅 공격을 포함해 수시로 괴롭힘을 벌였습니다. microG를 후원·지원하는 주요 회사 중 한 곳의 CEO는 괴롭힘에 직접 가담했고 괴롭힘 사이트의 콘텐츠를 링크했습니다. 프로젝트 리드 개발자는 우리에 대한 날조와 인신공격을 퍼뜨리는 데 가담했습니다. 그런 게 독성이고, 우리에 대해 거짓말하는 당신의 댓글도 독성입니다.
아무도 당신들을 "공격"하지 않았습니다. 저는 당신들이 (이 스레드의 주제인) MicroG를 추천하지 않는다는 점, 그리고 기기 루팅을 말리고 MicroG 같은 자유 소프트웨어 대신 독점 GApps를 설치하라고 권한다는 점을 말했을 뿐입니다.
자기 의견을 정확하게 요약한 게 왜 공격입니까?
우리가 한 말을 정확히 요약한 게 아닙니다. 당신은 이 스레드 내내, 그리고 이전에도 여러 번 그랬던 것처럼 왜곡과 오해를 부르는 주장, 명백한 거짓으로 GrapheneOS 프로젝트를 공격하고 있습니다. 지금 우리가 답하고 있는 당신의 최신 댓글에서도 또 그랬습니다. 이 스레드에서 당신이 한 주장 대부분은 이미 반박됐습니다. 이에 정확한 정보로 답하는 것은 공격성도 독성도 아닙니다. 우리는 이 플랫폼에서 GrapheneOS에 대한 부정확한 주장을 바로잡고 있으며, 다른 곳에도 긴 반박문을 올릴 것입니다.
아, 그럼 제가 잘못 이해했나 보네요. 사실은 microG를 추천하고, 사용자가 자기 기기의 루트 권한을 갖는 것도 지지한다는 거죠?
사용자가 그 접근 권한을 갖는 것과, OS가 최소한의 구성 요소를 넘어 그 권한을 쓰고 심지어 요청 프롬프트에 따라 앱에 넘겨주는 것은 다릅니다. GrapheneOS를 설치하려면 사용자에게 그 이상의 접근 권한이 필요합니다. 그렇다고 해서 실사용 기기에서 OS의 상당 부분을 루트로 돌리고 애플리케이션에 제공해야 한다고 생각한다는 뜻은 아닙니다. GrapheneOS에는 이미 하드웨어 기반 가상화가 있어서, 전체 OS 보안을 해치지 않고도 사용자가 루트 권한을 가진 개발 환경을 쓸 수 있습니다. 로컬에서 개발용 에이전트를 돌릴 때처럼 아무것도 직접 접근하게 두지 않고 신뢰하지도 않으려면, 여러 가상 머신을 돌리는 것이 그런 대부분의 일에 맞는 접근입니다.
당신이 묘사하는 것과 달리 우리의 자체 호환성 계층은 전적으로 오픈 소스 소프트웨어입니다. microG는 비공개 소스 구글 라이브러리를 쓰는 앱과의 호환성을 제공하려고 존재합니다. 우리의 호환성 계층은 비공개 소스 구글 앱, 그리고 비공개 소스 구글 코드를 쓰는 앱과의 호환성을 제공하려고 존재합니다. 둘 다 오픈 소스 프로젝트입니다. 앱들이 구글의 비공개 소스 라이브러리를 쓰지 않는다면 둘 다 현실에서 의미 있는 쓰임이 거의 없을 겁니다. 우리는 이미 독립형 네트워크 기반 위치, 지오코딩 같은 기능을 갖추고 있습니다. 이런 기능은 Google Play API와의 호환성이 필요하지 않으며, 둘이 강하게 묶여 있는 것에 우리는 동의하지 않습니다.
GrapheneOS는 구글의 비공개 소스 앱·라이브러리와 무관한 구글 서비스 기능의 독립 재구현과, 그들의 비공개 소스 앱·라이브러리를 위한 호환성 계층을 둘 다 제공합니다. 이 모든 것의 코드는 전부 오픈 소스입니다. microG는 우리가 만들었고 지금도 확장하고 있는 것의 오픈 소스 대안이 아닙니다. 둘 다 오픈 소스이며, 우리가 제공하고 만들고 있는 것에 대해 사람들을 계속 오도하는 것은 잘못입니다.
의미 없네요. 우리는 제자리를 맴돌고 있고, 당신은 제 요점에 답하지 않고 자기 입장만 되풀이하고 있습니다.
VM 안에서 루트를 갖는 것은 루트를 갖는 것과 같지 않습니다. 당신도 잘 알고 있을 거라고 생각합니다.
microG가 당신들의 샌드박스의 대안이라고 주장하는 사람은 아무도 없습니다. 당신들이 샌드박스에 설치하라고 권하는 GApps의 대안입니다. 이것도 분명 알고 계시죠.