구글 크롬, *.google.com에서만 접근 가능한 API 제공

 (twitter.com/lcasdev)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Google Chrome은 *.google.com 사이트에만 시스템/탭 CPU 사용량, GPU 사용량, 메모리 사용량, 상세 프로세서 정보, 로깅 백채널 접근을 허용하는 API를 제공함
  • 다른 사이트에는 같은 API가 노출되지 않아, 브라우저 벤더가 자사 웹사이트에 특별 권한을 부여해도 되는지 논란이 됨
  • DMA는 인터넷 게이트키퍼인 브라우저 벤더가 모두에게 같은 기능을 제공해야 한다는 아이디어를 법으로 명문화하며, 해석에 따라 Google 속성에만 추가 정보를 노출하는 행위가 DMA 위반이 될 수 있음
  • Zoom은 Google Meet과 같은 CPU 디버깅 기능을 제공받지 못해 경쟁상 불리한 위치에 놓일 수 있음
  • 이 기능은 비활성화할 수 없고 확장 프로그램 패널에도 나타나지 않는 내장 Chrome 확장으로 구현되며, Microsoft Edge와 Brave에서도 *.google.com 도메인에만 동일한 기능이 제공됨

*.google.com 전용 API가 노출하는 정보

  • Chrome은 *.google.com 사이트에만 시스템 상태와 디버깅에 가까운 정보를 제공함
    • 시스템 및 탭의 CPU 사용량
    • GPU 사용량
    • 메모리 사용량
    • 상세 프로세서 정보
    • 로깅 백채널
  • 같은 API는 다른 사이트에는 노출되지 않고, *.google.com 도메인에서만 사용할 수 있음

구현 방식과 Chromium 파생 브라우저 동작

  • 이 기능은 비활성화할 수 없고 확장 프로그램 패널에도 표시되지 않는 내장 Chrome 확장으로 구현됨
  • 소스 코드는 Chromium의 hangout_services 경로에 있음
  • 같은 확장이 다른 Chromium 파생 브라우저에도 포함되는지는 불분명했지만, 이후 업데이트에서 다음 동작이 확인됨
    • Microsoft Edge에서도 이 기능이 *.google.com 도메인 전용으로 제공됨
    • Brave에도 Google이 *.google.com에서만 이 정보를 가져올 수 있게 하는 확장이 사전 설치되어 있으며, Chrome 및 Edge와 같은 동작을 보임

경쟁과 규제 쟁점

  • 브라우저가 특정 자사 도메인에만 시스템 정보를 제공하면, 다른 웹서비스는 같은 수준의 진단 기능을 구현하기 어려움
  • Zoom은 Google Meet과 같은 CPU 디버깅 기능을 제공받지 못하는 사례로 거론되며, 이는 브라우저 벤더의 자사 서비스 우대 문제로 이어질 수 있음
  • DMA 관점에서는 게이트키퍼가 기능 접근을 동등하게 제공해야 하는지가 핵심 쟁점으로 남아 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • hangout_services라는 이름을 보면 Google Hangouts 개발을 쉽게 하려고 만든 오래된 기술부채성 해킹처럼 보임
    Hangouts 팀에 원격 측정 데이터를 직접 흘려주려던 용도였을 듯함. Hangouts는 브라우저에서 화상 통화를 구현한 첫 앱이고, 이것이 나중에 WebRTC가 됐음. 이 모듈은 앱이 원래는 볼 수 없는 CPU/GPU/RAM 사용량과 하드웨어 정보를 노출함. Google은 이 Twitter 스레드를 보고 그냥 삭제할 것 같음. Hangouts는 이미 죽은 제품이고, 서버 쪽 코드가 아직 쓴다 해도 지금은 WebRTC 사용 범위가 훨씬 넓으니 Chrome 팀이 다중 사이트 방식으로 성능을 직접 모니터링하고 있을 것임

    • 아니고, 이건 지금 Google Meet에서 쓰고 있음. Chrome에서 meet.google.com의 "Troubleshooting" 패널을 열면 시스템 전체 CPU 사용량이 실시간으로 보임 :)
    • 개인정보 침해를 떠나서, 이건 명백한 반독점 이슈 아닌가 싶음. Google이 브라우저 지배력을 남용해서 화상회의 시장에서 자기 제품에 우위를 주고 있음
    • CPU/GPU 사용량 등을 추적해서 어떤 품질의 영상 스트림을 쓸지 미세 조정하는 용도일 수도 있지 않을까 싶음
      비표준이긴 하지만, 네이티브 앱이라면 이런 일을 충분히 할 것 같음

  • 이 부분에 대해 조금 설명할 수 있을 듯함. 참고로 전 Google 직원임
    한때 Google 내부 화상회의 플랫폼인 GVC에서 일했음. 2010~2011년 당시 회사의 많은 화상회의 장비는 Cisco Tandberg 같은 독점 장비였고, 가격이 비싸서 수천 개 회의실에 배포하기도 비용이 컸음. 비슷한 시기에 다른 팀이 Hangouts를 개발 중이었고, 당시 이름이 Google Meet이었는지 나중에 그렇게 된 건지 기억이 흐림. Hangouts라는 이름은 Google+가 나오면서 제품에 통합될 때 채택된 것 같음. GVC 구성은 여러 가지였지만 가장 흔한 건 All-in-One(AIO) 모니터/컴퓨터 조합이었고, 완전한 Intel PC였음. 그래서 GVC 플랫폼은 커스텀 Linux 배포판이었고, Google 서비스와 통신하고 소프트웨어 업데이트를 배포하도록 설계됐음. 부팅 실패에 대비해 오래된 배포판도 보관했고, 장비 이름 지정 등 여러 문제가 있었음. 터치 패널, 대형 PTZ 카메라, 여러 마이크 같은 다양한 하드웨어 지원도 필요했음. 결국 Hangouts가 GVC의 기반 스택이 됐고, 거의 모든 Tandberg를 대체해 큰돈을 절약했음. 이 시스템은 2017년까지는 확실히 쓰였고 이후는 모름. 모니터링도 그 일부였기 때문에, *.google.com 전용 API가 보인다면 정확히 봐야 함. Google이 전 세계 모든 Chrome 인스턴스를 조회할 수 있는지, 아니면 google.com에서만 가능한지 Tweet만으로는 알 수 없음. 다만 hangouts_services라는 이름과 도메인 제한을 보면 GVC용 임베디드 Chrome 모니터링 지원일 가능성이 높아 보임. 틀릴 수도 있음

    • 이건 그게 아닌 것 같음. 방금 Firefox에서 Meet 통화를 해봤는데, 문제 해결 버튼을 누르면 CPU 차트가 비활성화돼 있고 "CPU 사용량을 보려면 Chrome을 사용해보라"는 문구가 나옴
      Chrome에서는 Meet이 쓰는 CPU인지 시스템 전체인지 모르겠지만 CPU 사용량을 볼 수 있고, 어느 쪽이든 일반 API로 가능한 건 아닌 듯함. yes 백그라운드 작업 몇 개로 확인해보니 확실히 시스템 전체임. 덧붙이면 이름 혼동은 항상 생기는데, GVC는 정말 명확하고 좋은 이름임
    • 흥미로운 이야기지만, 이 건과 원격으로라도 연결될 가능성은 없어 보임. 커스텀 Linux 배포판으로 GCV 플랫폼을 운영하는 사람들이 머신 통계를 보고하는 방법으로 “우리가 만든 커스텀 확장을 전 세계 모든 Chrome 설치본에 넣자”를 택했을 리는 없음
      아무 *.google.com 페이지에서 직접 해볼 수 있음:
      chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });
    • “Google이 전 세계 모든 Chrome 인스턴스를 조회할 수 있느냐, 아니면 google.com에서만 가능하냐”의 구분을 잘 모르겠음
      API가 *.google.com에서 실행되는 콘텐츠에만 노출되는 것 같긴 하지만, 그래도 “Google이 자기 사이트를 방문한 모든 Chrome 인스턴스를 조회할 수 있다”와 거의 같음. Google 서비스를 안 써도 Chrome은 기본적으로 새 탭 페이지 콘텐츠를 Google에서 가져오니 사실상 거의 100%에 가까움. 악의적으로 쓰인다고 보진 않지만, Google은 이런 방식으로 문제를 진단할 수 있고 같은 영역의 경쟁사는 못 한다면 여전히 문제임. Zoom에는 이런 API가 없지 않나?
    • Google에서 일한 적은 없지만, 이 설명은 납득이 잘 안 됨
      내부 화상회의 플랫폼의 내부 어플라이언스에서 CPU 사용량을 관찰하려고, 일반 사용자용 Google Chrome에 이 번들 플러그인을 넣었다는 말인가?
    • 흥미롭다. 어쩌면 Google 대부분도 지금까지 이게 가능하다는 걸 몰랐을 수 있음
      이제 수십 명의 제품 관리자가 자기 제품의 기술 리드에게 “자, 일단 들어봐…”라고 접근하고 있을 듯함

  • 이 기능은 2013년 10월에 추가된 것으로 보임: https://github.com/chromium/chromium/commit/422c736b82e7ee76...
    Chrome에 Hangouts Services 확장을 번들링한다는 커밋임. BUG=291271, 리뷰 URL: https://codereview.chromium.org/35873003. 해당 리뷰 URL은 https://codereview.chromium.org/35873003임

  • 이 API가 정확히 무엇이고 왜 있는지는 모르겠지만, Firefox도 비슷한 일을 함
    확장 설치나 첫 실행 경험 보조처럼 Mozilla 및 Firefox 도메인에서만 쓸 수 있는 특수 API가 있음. 12개월도 안 전에 관련 블로그 글이 Hacker News에 올라왔는데 찾기가 어렵다

    • 거의 같은 일이 아님
      API는 공개돼 있고 문서화돼 있으며, 도메인 허용 목록도 UI와 about:config에 들어 있음. Android Play Store 버전은 브라우저를 순수한 쓰레기로 만들려는 건지 모든 걸 숨겨놔서 예외임. 그리고 훌륭한 사용 사례를 들고 Bugzilla에서 정중히 요청하면 개발자들이 기본 도메인 추가를 최소한 검토는 해줄 것 같음
    • 그건 브라우저 운영과 직접 관련된 웹사이트를 위한 것임. 반면 Chrome은 Google Meet 같은 별도 Google 제품에서 쓰는 API를 노출하고 있음
      한 시장, 즉 브라우저에서의 독점을 이용해 다른 시장인 화상회의에서 이점을 얻는 것이므로 반독점법 위반일 수도 있음
    • 오래전에 UITour 부분에 대해 글을 쓴 적이 있음: https://www.mkelly.me/blog/content-uitourjs/
      브라우저들 사이에서는 꽤 표준적인 방식임. 위험도는 브라우저가 소프트웨어 업데이트를 내려받는 도메인을 누군가 위조하는 것과 비슷한 수준이어야 하고, 정말 싫다면 환경설정에서 끌 수 있음
    • 지난달 WebKit의 Quirks.cpp 커밋이 공유됐음 [0]. 아마 찾던 건 아니겠지만 비슷한 느낌이 있음
      [0] https://news.ycombinator.com/item?id=40631439
    • 그런 API들은 브라우저 기능과 온보딩에 관련된 것임. Mozilla의 다른 제품을, 다른 회사의 유사 제품보다 유리하게 만들려고 들어간 게 아님

  • 참고로 Google에서 일하지만 Chrome이나 이 API 담당은 아님
    설명은 꽤 평범하다고 봄. 예를 들어 Google Meet을 열고 빈 회의, 즉 “즉석 회의”를 시작한 뒤 “…” 메뉴에서 “문제 해결 및 도움말”을 누르면 CPU 사용률을 포함한 여러 통계 그래프가 나옴. Meet 통화 중 머신에 부하가 걸리면 탭을 닫으라고 친절하게 제안하기도 하는 것 같음. 꽤 유용해서 가끔 확인함. 다시 생각해보니 탭을 닫으라는 제안이 실제로 있는지는 확실치 않고, 실제로 써본 건 통계 화면뿐임

    • “꽤 평범하다”는 설명과 달리, 이건 전혀 평범하지 않음. 자기 제품에 불공정한 경쟁 우위를 주는 완벽한 예임
      Meet 사용자는 회의가 왜 제대로 안 되는지 안내받지만 Zoom, Teams, Slack은 같은 일을 못 한다면 Meet 사용 경험이 더 좋아질 수밖에 없음. 다른 모든 회의 서비스가 데스크톱 앱을 적극적으로 쓰라고 밀어붙이는 것도 이상하지 않음. Google Meet의 데스크톱 앱은 곧 Chrome임
    • 오히려 그게 핵심임. 다른 화상회의 도구는 이런 디버깅 옵션을 제공할 수 없고, 방금 말했듯 그 기능은 유용함
    • 경쟁자인 Zoom에는 브라우저 버전이 있음. 성능 문제를 진단하려고 이 API를 쓸 수 있나? 못 쓴다면 유럽 규제 당국이 관심을 가질 수 있음
      어쩌면 Meet은 브라우저에서 잘 작동하고 Zoom은 그렇지 않아서, 특히 회의 참석자가 많을 때 Zoom 사용자가 적절한 성능을 원하면 네이티브 앱을 쓰게 되는 이유 중 하나일 수도 있음
    • Google이 자기들한테만 유용한 기능을 제공하는 반경쟁적 브라우저를 만든 게 아주 멋지다
      Google 직원이 조용히 넘어갈 부분을 직접 말해줘서 고맙다
    • 독점력 전이는 평범한 일이 아니라 불법임

  • 제출 제목을 원문에서 바꾸는 과정에서 조금 잘못된 것 같음. 내가 이해한 바로는 이렇다
    Chrome에는 다른 Chrome 확장도 쉽게 쓸 수 있는 공개 Chrome API를 사용하는 내장 확장이 있음. 문제는 이 확장이 Google 자체 도메인과 통신할 때 해당 정보를 공유하지만, 다른 웹사이트는 그렇게 할 수 없다는 것임. “특별한 숨은 API”는 없음

    • “특별하다”는 건 다른 확장처럼 사용자가 설치한 게 아니라 Chrome 내장이라는 의미임
      “숨겨져 있다”는 건 chrome://extensions에 가도 목록에 보이지 않는다는 의미임. 그리고 이미 말했듯 Chrome API이기도 함
    • Google 사이트의 Chrome DevTools 콘솔에 이걸 붙여넣어보면 특수 API처럼 보임:
      chrome.runtime.sendMessage( 'nkeimhogjdpnpccoofpliimaahmaaome', { method: 'cpu.getInfo' }, response => { console.log('CPU Info:\n', JSON.stringify(response, null, 2)); } );
    • “내장 확장”이라도 비활성화할 수 없다면 여전히 브라우저의 일부임
    • 무해하고 단순한 설명도 가능함. 브라우저 기능 일부가 컴파일/링크된 C++가 아니라, google.com 서명 웹앱으로 구현돼 있다고 상상해볼 수 있음
      PWA로 구현된 브라우저 코드가 시스템 정보에 접근하려고 별도 권한을 요구해야 한다면 이상할 것임. 브라우저 기능 자체의 일부이기 때문임. 오래전부터 존재하던 비공개 API의 또 다른 용도는 Chrome Web Store처럼 핵심 기능을 제공하는 Google 전용 웹사이트와 Chrome 브라우저를 통합해, 웹페이지에서 확장 설치와 제거를 허용하는 것임
    • 기능적으로는 같은 일임

  • 이건 "system.cpu" 권한이 있으면 어떤 확장도 접근할 수 있는 chrome.system.cpu API를 쓰는 것처럼 보임
    https://developer.chrome.com/docs/extensions/reference/api/s...
    이 확장이 요청하는 모든 권한은 여기서 볼 수 있음:
    https://source.chromium.org/chromium/chromium/src/+/main:chr...

    • 맞고, 바로 그게 문제임. Google이 브라우저 자체 동작과 무관한 확장을 Chrome에 번들로 넣어서, 다른 제품인 Hangouts에 특권 접근을 주고 있음
      다른 화상회의 앱은 사용자가 별도 확장을 수동으로 설치하는 큰 단계를 거치지 않는 한 이런 접근 권한이 없음

  • 별로 놀랍지 않음. 매우 Google다운 행동임. 문제는 다른 Chromium 브라우저에도 이게 있느냐임. Edge, Brave, Chromium, Ungoogled Chromium은 어떤가?

    • 나머지는 모르겠지만, ungoogled chromium은 이런 걸 피하려고 코드 안의 "google" 문자열이 나오는 모든 부분을 일부러 뒤섞기 때문에 아마 없을 것임
    • Edge에는 활성화돼 있음. Edge에서 Google Meet 문제 해결을 열면 시스템 CPU를 볼 수 있음
      Firefox에서 해보면 “CPU 사용량을 보려면 Google Chrome을 사용해보라”고 나옴

  • Safari에도 Apple 전용 기능이 있음. 예를 들어 Apple 계정으로 다른 웹사이트에 로그인할 때, 패스키나 비밀번호 자동완성과 다르게 동작하는 특수 대화상자를 띄울 수 있음
    다른 브라우저에는 리다이렉트 기반 흐름을 거치게 함. 이게 JavaScript에서 어떻게 구현되는지 늘 궁금했음. 독자 인자를 넣은 WebAuthn 같은 건가?

  • Google은 예전에도 이런 일을 한 적이 있음. 세부 사항은 흐릿하지만, Native Client가 도메인 수준 허용 목록으로 Hangouts에서만 동작하게 돼 있었거나 그런 식이었던 것 같음

답변달기