구글 대 개방 웹

 (interpeer.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Google의 Web Environment Integrity(WEI) 제안은 웹사이트가 브라우저 환경의 증명을 요구하고, 승인되지 않은 클라이언트를 차단할 수 있게 해 개방 웹을 사일로화된 앱처럼 만들 수 있음
  • 구조의 핵심은 외부 attestation agent가 브라우저와 플러그인을 검사하고, 웹사이트가 그 결과로 접근 허용 여부를 결정하는 데 있음
  • 명시된 사용 사례에는 Google Play가 증명 제공자로 등장하며, 광고가 자동화 프로세스가 아닌 합법적 사용자에게만 제공되도록 하는 광고 노출·봇 차단 시나리오가 포함됨
  • 브라우저 선택, 광고 차단기, 오래된 기기, 보조기술 의존 사용자가 배제될 수 있어 접근성·포용성과 개방 웹의 생성성이 함께 흔들림
  • Google 저장소의 이슈·댓글 차단, Mozilla의 반대, Apple Private Access Tokens와 IETF PrivacyPass의 attester 불명확성까지 이어지며 표준화와 규제 대응 문제가 남아 있음

WEI가 개방 웹을 위협하는 방식

  • Web Environment Integrity(WEI) 는 웹사이트가 브라우저 환경의 “무결성” 증명을 요청할 수 있게 하는 제안임
  • 웹사이트는 특정 기기나 브라우저에서만 페이지를 표시하고, 다른 클라이언트에는 서비스를 거부할 수 있음
  • 이 구조는 클라이언트 측 소프트웨어를 특정 웹사이트에 묶어 사일로화된 앱을 만드는 효과를 냄
  • 선호되는 클라이언트 소프트웨어를 사용할 수 없는 플랫폼과 사용자는 불이익을 받음
    • 충분히 최신 기기를 보유하기 어려운 사용자
    • 특수 브라우저나 보조기술이 필요한 사용자
    • 스크린 리더 성능이나 오래된·저가 기기 호환성이 중요한 사용자
  • 이런 배제 가능성 때문에 WEI는 웹의 설계 원칙에 반하는 반사회적 제안으로 비판받음

브라우저 증명 메커니즘

  • WEI는 브라우저가 자신의 “무결성”에 관한 attestation을 외부 agent로부터 받아 웹사이트에 전달하는 구조임
  • agent는 브라우저와 플러그인을 검사하고, 검사를 통과한 경우에만 승인을 발급하는 것으로 상정됨
  • 웹사이트는 이 승인 결과를 보고 서비스 제공 여부를 결정할 수 있음
  • 겉으로는 사용자를 위해 환경이 변조되지 않았음을 보장하는 기능처럼 보이지만, 실제 사용 사례는 사업자 보호에 더 가깝게 배치돼 있음
  • 제안에는 Google Play가 증명 제공자가 될 수 있다는 내용과, 광고가 자동화 프로세스가 아닌 합법적 사용자에게만 제공되도록 하는 예시가 포함됨

광고, 봇, 광고 차단기

  • 제안의 배경에는 광고 노출과 봇을 둘러싼 이해관계가 있음
    • 광고주는 비용을 줄이고 싶어 함
    • 웹사이트 운영자는 광고를 표시하고 싶어 함
    • Google 광고 네트워크는 impression 단위로 비용을 청구함
    • 봇은 impression을 생성함
  • WEI는 봇을 증명으로 배제해 Google Play에 로그인한 사용자에게만 광고 노출이 발생하도록 하는 해법으로 읽힘
  • 봇은 일반적으로 user agent 문자열 등 로그 정보만으로도 구분되는 경우가 많지만, user agent는 위조될 수 있음
  • 충분히 동기부여된 봇은 더 강한 보안 조치도 우회할 수 있으며, Selenium WebDriver 같은 도구로 합법적 브라우저를 이용해 요청할 수도 있음
  • 핵심 약점은 attester에 있음
    • 공격자가 attester를 설득해 클라이언트를 합법적으로 보이게 할 수 있음
    • 또는 합법적 클라이언트를 attester가 문제 삼지 않는 방식으로 사용할 수 있음
  • 결국 봇은 실제 브라우저만큼 정교해져 attestation을 통과할 수 있고, WEI는 봇보다 광고 차단기를 겨냥한 것으로 해석됨

남용 가능성과 브라우저 전쟁의 재현

  • attestation agent가 어떤 방식으로 브라우저를 승인하거나 거부할지는 자유롭게 정할 수 있음
  • 이 구조는 임의 남용의 문을 열 수 있음
    • 웹사이트가 독점적 데이터 수집 agent 설치를 요구할 수 있음
    • 특정 브라우저를 쓰지 않으면 서비스를 거부할 수 있음
    • 1990년대 후반의 브라우저 전쟁이 재현될 수 있음
  • 광고 네트워크의 사용자 추적은 점점 더 비판받고 있으며, 광고 차단기는 보안 수단으로도 권장됨
  • 광고는 합법적 웹사이트에 악성코드를 사이드로드하는 경로가 될 수 있어, 보안 전문가들이 광고 차단기 사용을 권장하는 경우가 있음
  • WEI가 수용되면 개방 웹이 수십 년 후퇴한다는 비판으로 이어짐

생성적 시스템에서 어플라이언스로

  • Jonathan Zittrain의 『The Future of the Internet -- And How to Stop It』는 전화망을 출발점으로 어플라이언스와 생성적 시스템을 구분함
  • 어플라이언스는 토스터처럼 하나의 주 기능을 중심으로 작동하고, 다른 기능은 그 변형에 가까움
  • PC와 인터넷은 특정한 주 목적 없이 기본 기능을 제공하고, 목적을 사용자가 정하는 생성적 시스템으로 분류됨
  • 개방 웹은 사용자 개발 비독점 프레임워크들의 모음이며, 상호운용성과 제공자·최종 사용자 사이의 데이터 접근 및 소유 균형을 강조함
  • agent의 임의 판단에 따른 attestation은 웹을 어플라이언스로 바꾸고, 더 정확히는 브라우저를 어플라이언스형 웹사이트의 확장으로 만듦
  • 웹사이트 운영자는 이미 어플라이언스를 만들 수 있지만, 이런 변화가 누적되면 생성적 개방 웹의 유용성이 줄어듦

접근성과 규제 논점

  • WEI가 원칙적으로 접근성 문제를 직접 “발생”시키는 것은 아니지만, 비용 효율성은 브라우저 시장의 20%에 집중해 80% 사용자를 확보하는 방식으로 작동할 수 있음
  • 나머지 20% 사용자는 지원 비용이 크다는 이유로 무시될 수 있음
    • 특수 브라우저가 필요한 사용자
    • 스크린 리더 성능이 중요한 사용자
    • 저가·구형 기기에서 동작하는 브라우저가 필요한 사용자
  • 접근 문제는 규제로 해결해야 한다는 반론도 있음
  • 좋은 규제 프레임워크는 드물고, 기술은 법보다 빠르게 움직임
  • 단기적으로는 기술 자체의 위험을 다루고, 장기적으로는 규제 대응까지 이어가야 함

기업 이익 보호와 개방 웹의 충돌

  • 기업이 이익을 보호하려는 행위라도 사람들에게 해를 끼친다면 정당화되기 어려움
  • 인터넷과 개방 웹은 사람들이 사용 방식을 결정할 수 있기 때문에 긍정적 영향을 갖는 생성적 시스템임
  • 이 결정권이 줄어드는 순간 시스템은 어플라이언스 쪽으로 이동함
  • 기업이 이익 보호를 위해 생성적 시스템을 어플라이언스로 줄이면, 그 자체로 사람들에게 해가 됨
  • Google은 생성적 시스템 위에서 성장한 기업이 이제 같은 시스템을 자사 필요에 맞는 어플라이언스로 바꾸려 한다는 비판을 받음

W3C, 저장소, Mozilla의 반응

  • WEI 제안에 대해 W3C 행동강령 위반 문제가 제기됐고, 담당 그룹은 자신들의 관할이 아니라고 답함
  • 이후 W3C ombudspeople에게 WEI 제안과 참여자 행동에 대한 우려가 전달됨
  • 우려에는 GitHub 저장소 maintainers가 커뮤니티 이슈를 닫고 있다는 점이 포함됨
  • 2023년 7월 22일 Google은 저장소에서 이슈 제기와 댓글을 포함한 기여 기능을 닫음
  • Mozilla는 WEI에 반대하며, 이 제안이 웹에 대한 Mozilla의 원칙과 비전에 반한다고 밝힘
  • Chromium에는 WEI 관련 commit이 이미 존재하며, 사양이 굳어지기 전에 더 빨리 나올 수 있다는 우려가 있음

Apple Private Access Tokens와 PrivacyPass

  • Apple은 약 1년 전부터 유사한 API인 Private Access Tokens를 제공해 왔음
  • Apple 개발자 블로그의 Private Access Tokens는 WEI와 거의 같은 메커니즘을 구현함
  • 다만 Apple 문서는 “토큰 challenge를 보낼 때 메인 페이지 로드를 막지 말고, 토큰을 지원하지 않는 클라이언트도 웹사이트에 접근할 수 있게 하라”고 안내함
  • Apple 문서의 어조는 WEI의 동기와 대비되며, Private Access Tokens는 CAPTCHA 같은 더 방해가 큰 인증 수단 대신 쓰이는 메커니즘으로 제시됨
  • token issuer는 사용자 기기에서 동작하는 불투명한 프로세스가 아니라 외부 웹 서비스로 설명되며, CDN이 원본 서버에 대한 요청을 인증하는 메커니즘으로 읽힘
  • 프로토콜은 IETF PrivacyPass Working Group에서 정의함
  • PrivacyPass protocol draft에 따르면 클라이언트가 issuer에 보내는 데이터는 서버 challenge를 난독화된 해시 형태로 보낸 것뿐임
  • 이 경우 issuer 관점에서는 개인 데이터가 유출되지 않고, 브라우저와 플러그인 환경 검사가 없어 특정 브라우저가 attestation을 받지 못하게 막기 어려움

PrivacyPass의 미완성 부분과 차별 가능성

  • PrivacyPass를 issuer 프로토콜만으로 분석하면 불완전함
  • 빠진 부분은 클라이언트와 attester가 어떻게 상호작용하는지임
  • issuer는 개인식별정보를 알지 못하지만, 어떤 attester를 사용할지에는 영향을 줄 수 있음
  • attester는 구체적 동작이 명시되지 않은 미지의 요소로 남아 있음
  • 명세의 여러 부분은 가능한 방식만 언급하고, 구체적 절차는 비워둠
  • 클라이언트가 민감한 속성을 attester에 보내지 않을 가능성은 있지만, 그 경우 어떤 결과가 생기는지는 다뤄지지 않음
  • 이 개방성 때문에 WEI와 같은 모델과 같은 문제가 구현될 수 있음
  • PrivacyPass architecture 문서도 section 5.1 “Discriminatory Treatment”에서 차별적 처리 가능성을 인정함

반독점, 개인정보, 표준화 대응 경로

  • GitHub에서 Google에 항의하는 것만으로는 효과가 없다는 Hacker News 댓글이 공유됨
  • 해당 댓글은 미국, EU, 영국, 인도, 캐나다의 반독점 기관 연락처를 제시함
  • 반독점은 한 가지 경로일 뿐이며, PrivacyPass와 Apple Private Access Tokens도 유사한 문제가 있음
  • EU에서는 다음 기관에 우려를 제기할 수 있음
  • PrivacyPass에 대해서는 IETF PrivacyPass working group 메일링 리스트에 참여해 우려를 제기하고, draft 채택 단계에서 반대할 수 있음

Google 내부 프로세스에 대한 추가 우려

  • Google/Chrome/Blink의 Alex Russell은 WEI를 웹을 위해 좋은 일을 하려던 사람들이 “할 수 있는 일”에 휩쓸려 “해야 하는 일”을 놓친 사례로 재구성하려 했음
  • 그 설명에는 Google이 “해야 하는가”를 묻도록 강제하는 계층 구조가 없다는 취지가 포함됨
  • 즉각적인 우려는 두 가지임
    • Google이 프로세스 차원에서 “해야 하는가”를 묻지 않는다는 점
    • 개별 Googler도 Google 프로세스와 무관하게 그 질문을 하지 않는다는 점
  • 두 요소가 함께 놓이면 도덕적 파산 선언에 가깝다는 비판으로 이어짐
  • 해당 시점에는 Google의 공식 반응이 아직 없는 상태였음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이게 진심인가?

    • 이 글쓴이는 이 주제에 대해 민망할 정도로 모르는 상태임
      봇에는 두 종류가 있음. 정상적인 봇은 사이트 운영자에게 대체로 긍정적인 교환을 제공하고, 사용자 에이전트로 자신을 밝히며, 예측 가능한 IP 대역에서 요청하고, robots.txt를 따름. 검색엔진 크롤러 대부분, WhatsApp 같은 앱의 링크 미리보기 봇, RSS 리더가 여기에 들어감
      반면 악성 봇은 비싸고 가치 있는 정보를 담은 리소스를 노리고, robots.txt를 따르지 않으며, IP 차단을 피하려고 주거용 IP 봇넷을 쓰고, 정상 트래픽처럼 보이도록 사용자 에이전트부터 바꿈. 가짜 계정을 만들려고 사람을 고용하기도 함
      그래서 글쓴이의 방식은 순환논리임. 사용자 에이전트로 봇을 식별한 뒤, 구분되는 사용자 에이전트를 가진 봇이 있으니 나머지 트래픽은 봇이 아니라고 선언한 셈임. 게다가 악의적으로 긁어갈 만한 데이터가 없는 서버 로그를 본 것도 문제임. Ocean's 11이 동네 가게가 아니라 카지노를 털듯, 전문 봇 운영자는 개인 블로그가 아니라 방어 중인 곳에서 가치 있는 정보를 긁어감
    • 여기서 바로 신뢰를 잃었음
      Google에서 일하지만 광고, 브라우저, 광고 사기 탐지와는 전혀 무관한 입장에서 말하면, Google과 광고주에게서 돈을 빼먹고 먹고사는 공격자들이 이 글쓴이처럼 무능하기만 했다면 좋겠다고 바랄 정도임
    • 악용 방지 분야에서 일하는 수만 명에게 사용자 에이전트 문자열 얘기를 알려줘야겠네

  • 다른 WEI 스레드에서도 말했지만 여기서도 다시 말함
    사악한 기업을 욕하며 다 같이 팔만 휘젓는 대신, 이 제안의 반경쟁적 영향에 대해 FTC나 인도 CCI 같은 경쟁 당국에 실제로 연락한 사람이 있는지 궁금함

    • 정확히 같은 생각임. GitHub 항의는 감정적으로는 만족스럽지만 효과가 없음. Google은 신경 쓰지 않고 이미 독점 권력에 취해 있음
      반독점 당국 연락처는 다음과 같음
      미국: https://www.ftc.gov/enforcement/report-antitrust-violation / antitrust@ftc.gov
      EU: https://competition-policy.ec.europa.eu/antitrust/contact_en / comp-greffe-antitrust@ec.europa.eu
      영국: https://www.gov.uk/guidance/tell-the-cma-about-a-competition... / general.enquiries@cma.gov.uk
      인도: https://www.cci.gov.in/antitrust/
      CCI에 민원을 넣는 쉬운 연락 방법은 못 찾았지만 절차는 이쪽으로 보임: https://www.cci.gov.in/filing/atd
      캐나다: https://www.competitionbureau.gc.ca/eic/site/cb-bc.nsf/frm-e...
      다른 사람들이 템플릿으로 쓰고 싶다면 FTC에 보낸 내용을 공유할 수 있음
    • 영국에 있다면 Competition and Markets Authority에도 연락할 수 있음
      의회 청원도 만들었고, 검토 및 게시에 필요한 최소 지지자 5명을 모았음. 게시되면 HN에 공유하겠음
      지금은 청원 링크를 제거했지만, 게시된 뒤 다시 올릴 예정임
    • 공식 기관에 연락하는 건 좋은 생각임. 다른 스레드에서 썼던 행동 촉구를 인용하고 확장해 보겠음
      개인 생활에서 Google을 완전히 배제하셈. Chrome 금지, 변명 금지. 헛소리 그만하거나 이 업계를 떠나야 함. 검색은 Startpage, DuckDuckGo든 뭐든 쓰면 됨
      Firefox와 그 계열만 대상으로 개발하고, Chrome에는 사용성 문제를 넣으셈
      Google이 했던 전술을 그대로 쓰면 됨. 배포하는 소프트웨어에 Firefox를 묶고, Google처럼 사용자 기기에서 경쟁자를 제거하셈. npm 모듈이나 웹사이트를 Chrome에서 느리게 만들고, 비 Chrome 사용자에게 서비스가 더 싸다고 알려주셈. 돈은 사람을 움직임
      사용자에게 Firefox 다운로드를 권하는 팝업을 띄우고 링크나 설명 페이지를 제공하셈. 현재 Chrome에서 보안·개인정보 위험을 감지했으며 즉시 조치하길 권한다고 말하면 보통 사용자는 쉽게 겁먹고 움직임
      Google을 망치기 위한 온갖 방법을 떠올리셈. 검색 결과를 망치고, 저장소를 /dev/random으로 채우고, 상상 가능한 걸 하셈. 다들 똑똑하다고 말해 왔으니 보여주면 됨
      Google의 자본은 데이터임. 그걸 때리면 짐승은 죽음
    • 이미 여러 주가 Google의 이전 계획을 두고, 웹을 자기들만의 폐쇄 정원으로 만들려 했다는 이유를 포함해 반독점 소송을 냈다는 점을 기억해야 함
      Project NERA는 열린 인터넷을 닫힌 생태계로 만들려는 Google의 원래 계획이었음. Google 문서에는 “열린 웹 전반에서 폐쇄 정원을 성공적으로 모방해 마진을 보호한다”는 동기가 드러남
      내부 문서에 따르면 이 전략으로 Google은 더 높은 중개 수수료를 뽑아낼 수 있었고, 한 직원은 Project NERA의 야망을 “자산을 ‘소유’하지 않고 새 소비자 제품을 만드는 어려움도 겪지 않으면서, 자산을 촘촘히 ‘운영’하는 이점을 확보하는 것”이라고 표현함
      이를 위한 핵심 전략은 인기 브라우저 Chrome을 활용해 사용자가 브라우저에 로그인된 상태로 머물게 하고 추적하는 것이었음. Gmail이나 YouTube 같은 Google 서비스에 로그인하면 브라우저에도 로그인시키고, 브라우저에서 로그아웃하면 서비스에서도 로그아웃시키는 방식이었음
      https://mspoweruser.com/project-nera-state-attorneys-general...
      https://storage.courtlistener.com/recap/gov.uscourts.nysd.56...
    • 이미 했음. 몇 번이나 함
      Google은 작년부터 이런 방향을 강하게 신호해 왔음. 다만 작년에는 기술 버블이 터지기 전이라 아무도 믿고 싶어 하지 않았음. 이제 Google이 예전만큼 대단해 보이지 않으니 더 많은 사람이 대표자들에게 연락할지도 모름

  • 이런 이유로 Google을 적극적으로 혐오하고, YouTube 말고는 Google 제품을 피함
    2010년까지 거슬러 올라감. Chrome을 열어 시험해 봤는데, Firefox에서는 문제없이 되던 YouTube 채널 배경 우클릭 다운로드 옵션이 없었음. 왜 사용자가 우클릭해서 쉽게 다운로드하는 걸 일부러 막을까? 웹을 자기들이 소유한다고 믿기 때문임
    Chrome은 써 본 적도 없고 앞으로도 안 쓸 것임. Chrome을 쓰면 나중에 Google이 충분히 나쁜 정책을 구현해 거의 누구도 제한을 우회하기 어렵게 만들 때, 결국 스스로의 미래를 더 나쁘게 만드는 일임

  • Yoav Weiss 블로그 링크가 좋았음
    “웹 플랫폼 제안이 마음에 들지 않을 때 … 여러분의 통찰과 경험이 플랫폼이 큰 실수를 하지 않도록 돕는 데 가치 있을 수 있다고 느낄 수 있습니다. 좋습니다!! 웹 플랫폼 논의에 참여하는 건 모두를 위해, 모두에 의해 만들어지게 하는 데 필수입니다 … 논쟁적인 브라우저 제안에서 선의로 보이는 사람들이 수십, 수백 개의 댓글로 팀의 마음을 바꾸려는 경우가 드물지 않습니다. 제가 웹 플랫폼에서 일한 수년 동안, 이게 효과를 낸 걸 본 적이 없습니다. 단 한 번도요”라는 식임
    “모두가 논의에 참여하는 걸 정말 좋아합니다. 그리고 그건 우리의 결정에 단 한 번도 영향을 주지 않습니다”처럼 들림

    • 여기에는 사실 두 측면이 있음
      첫째, 피드백이 완전히 엉뚱한 주소로 가는 일이 잦음. Google이 Google다운 일을 하는 걸 그런 방식으로 막을 수는 없음
      둘째, 웹 표준 논의가 이루어지는 깊이와 수준이 대부분의 사람을 소외시킴. 그래서 사람들은 “표준 만들기”에 참여하는 대신 다른 곳으로 향함
      웹은 훌륭하고, 처음 15년 동안 웹 주체를 운영하는 일이 실제로 매우 단순했기 때문에 훌륭해졌음. 하지만 성공은 점점 큰 회사와 복잡한 이해관계를 불러왔고, 지금은 웹을 더 접근 가능하게 만들려는 작업과 동시에 Web Environment Integrity, DRM 같은 것도 같이 보임
      대중의 감시를 요구하는 절차는, 대중이 자신을 대신해 전업으로 감시할 사람을 임명할 수 없다면 결국 실패하게 됨
    • 개인 블로그치고는 홍보 문구가 꽤 많음
    • 이런 일의 유일한 해결책은 실제로 팔을 걷어붙이고 대안을 만드는 것임
      하지만 대부분은 그럴 기술이나 시간이 없으니 자전거 창고 색깔 논쟁만 하게 됨
    • 분명한 함의는 HN에서 읽은 논쟁적 제안에 대해 소리치려고 전문 논의에 뛰어드는 방식으로는 이해관계자들을 설득할 수 없다는 것임. 영향력을 원하면, 영향을 주고 싶은 공동체 안에서 신뢰를 쌓아 시간을 들여 키워야 함. 이건 논란거리도 아님
      특히 WEI처럼 웹 콘텐츠를 위한 봇 방지·치팅 방지 프레임워크로 의도된 비교적 건조한 제안을 가져다가 “Google vs. the Open Web” 같은 낚시성 제목으로 포장하면, 어려운 문제를 매일 깊이 고민하는 사람들에게 호감을 사기는 어려움
      좋은 제안인지는 솔직히 모르겠음. 다만 해결하려는 문제는 실제로 존재하므로, 조롱성 글을 쓰는 사람들보다 선의로 풀려는 사람들에게 일단 의심의 이익을 주고 싶음

  • 상황은 이렇게 전개될 것 같음
    WEI 검사는 기술에 밝은 사람이나 해커가 쉽게 우회할 수 있을 정도로 단순하게 설계될 것임. 비판이나 반대는 “브라우저를 이 50가지 설정으로 시작하기만 하면 됩니다” 같은 말로 잠재워질 수 있음
    반대로 일반 사용자는 우회할 수 없을 만큼 복잡해서 광고를 보도록 강제될 것임
    이렇게 해커들은 “열린” 웹 접근을 유지하고, 대다수 99%는 “Google” 웹을 돌아다니게 되는 윈윈 구조가 됨

    • WEI는 이미 기술자에게도 우회가 골치 아픈 Play Protect로 가는 프록시임
    • Google Play Services를 대체하려고 https://microg.org/를 써 보면, 이게 평균적인 기술 지식 수준이 아니라는 걸 알 수 있음

  • 그냥 Google이 모든 것과 모든 사람을 운영하고 소유하며, 우리가 수확물의 50%를 바쳐야 하는 단계로 바로 넘어가면 안 되나?

    • Google판 “초야권”은 어떤 모습일지 궁금함

  • 곧 웹사이트가 치트가 설치되어 있지 않은지 확인하려고 커널 접근 권한을 요구하겠네. 물론 비꼬는 말임

    • 이건 이미 WEI의 사용 사례 중 하나로 올라와 있음. 의도된 WEI 구현은 Play Protect이고, ARM TrustZone 안에 있어 커널보다 위에서 실행됨[0]. 그러니 커널 수준 안티치트보다 더 침습적인 무언가를 갖게 되는 셈임
      [0] ARM 용어로 커널 모드는 EL1, 하이퍼바이저 모드는 EL2, TrustZone 모드는 EL3임. 각 예외 수준은 더 높은 권한 수준임
    • 그 정도로 극단적이지는 않지만, Android의 일부 은행 앱은 한때 루팅 여부를 확인하고 실행을 거부했으니 전례가 있을 수 있음
    • SecuROM은 루트킷을 설치하는 PC 게임용 DRM임. 15년 전 Spore에 쓰였을 때 처음 알게 됐고, 내 Windows 설치가 망가졌음
    • 많은 온라인 게임은 이미 그걸 요구함. Valve가 특히 악명 높음

  • 이건 Google의 약함을 보여주는 분명한 신호임. 독점을 잃어가고 있고, 필사적으로 인터넷을 붙잡으려 함
    최근 몇 주 동안 광고 차단기가 설치되어 있으면 YouTube 동영상 시청 같은 탐색을 막으려 한다고 발표했음
    Fuchsia도 또 다른 예임. Android에 대한 통제력을 잃어가니 새 프로젝트를 시작한 것임
    내 처방은 AdGuard Home, Brave 브라우저(폰·태블릿·데스크톱), Bromite(폰), Firefox(데스크톱)와 uBlock Origin, 데스크톱의 FreeTube임. 폰에서 Brave만 써도 광고와 추적기를 모두 죽이기에 충분함
    오픈소스 공동체에는 언제나 Google이 생각하는 것보다 똑똑하게 관문을 우회할 사람이 있음. 며칠 전 Kevin Mitnick이 세상을 떠나 슬프지만, 언제나 또 다른 Kevin Mitnick은 나올 것임
    Google은 공동체의 존중을 모두 잃고 조만간 무너질 것임

    • Fuchsia에서 일하고 있는데, 솔직히 무슨 말인지 모르겠음. Fuchsia와 Android는 경쟁 관계라기보다 상호 보완에 가까움
      정보가 부족할 때 사람들이 자기 서사에 맞는 이야기를 지어내는 경향이 있는데, 그건 정말 위험한 습관임
    • HN 전체, 적어도 목소리 큰 다수가 사는 작은 거품이 재밌음. Google은 조만간 무너지지 않을 것이고, 전 세계 수백만에서 수십억 사용자에게 제품이 사랑받고 있음
      Google이 독점을 잃고 있다는 것도 아님. Brave Browser는 Google의 Chromium 위에서 돌아가고, Firefox는 Google 돈 위에서 돌아감. 검색 우위도 곧 사라질 것 같지 않음. 전 세계 거의 모두가 Google을 검색엔진으로 쓰는 데는 이유가 있고, YouTube로 영상을 보는 데도 이유가 있으며, 전화 사용자 70%가 Google 운영체제를 쓰는 데도 이유가 있음. Gmail이 개인 이메일에서 압도적 선두인 데도 이유가 있음
      광고 차단 사용자를 YouTube에서 막는 것도 정당하게 할 수 있음. YouTube를 쓸 의무는 없고, 쓴다면 광고를 보거나 YouTube Premium을 결제해서 비용을 내야 함
      HN이 Google을 아무리 욕해도, Google은 인터넷을 진짜 인터넷답게 만든 몇 안 되는 회사 중 하나임. 인류 전체에 대한 영향은 지금까지 분명 순긍정에 가깝고, 누구도 Google 제품을 쓸 의무는 없음. Gmail의 무료 티어나 Android의 개방성처럼, Google이 제공하는 제품에서 선두인 데는 이유가 있음
    • 광고를 보여주거나 정보를 수집하는 것에 이렇게 편집증적이라면, Brave가 최선의 선택은 아닐 수 있음. 과거에 두 손을 쿠키 항아리에 넣은 채 걸린 전력이 있으니까
      게다가 이미 다른 곳에서는 Firefox를 쓰고 있음. 참고로 Mozilla도 정보를 수집함
    • “독점을 잃어가고 있다”, “Android 통제력을 잃고 있다”는 게 무슨 뜻이고, Android가 인터넷을 붙잡으려는 것과 어떤 관련이 있는지 모르겠음
    • Bromite는 1년 동안 유지보수되지 않았음. 비공식 빌드를 쓰는 게 아니라면 사용하는 건 나쁜 생각임

  • 지난 몇 년간 Google이 이 방향으로 몰려가는 걸 보니 슬픔
    Google은 2000년대~2010년대에 열린 웹을 밀어붙인 주요 동력 중 하나였음. 검색을 위한 데이터가 필요했고, 모든 것이 열려 있으면 모든 것에 접근할 수 있었기 때문임
    하지만 Facebook 같은 새로운 웹 2.0 회사들이 인터넷을 사일로로 만들면서 상황이 바뀌기 시작함. Facebook에 반대해 온 이유도 데이터 채굴 때문이 아니라, 회사들이 웹사이트 대신 Facebook 페이지를 만들고 로그인하지 않으면 데이터에 접근할 수 없게 만든 변화의 원인이었기 때문임

    • 맞음. Google은 PWA를 밀어붙인 주요 세력 중 하나 아니었나? 웹앱이 네이티브 앱과 네이티브 API와 경쟁할 수 있게 하려고 WebUSB까지 포함해 많은 새 웹 API를 도입했음
      이 모순을 풀려면 Google 전체가 열린 웹에 “찬성” 또는 “반대”한다고 말할 수 없음. 악명 높은 내부 다툼 때문에 Google의 어떤 부분은 열린 웹에 찬성하고, 다른 부분은 반대하며, 때로는 한쪽이 우위를 점한다고 봐야 함

  • 악마의 변호인을 하고 싶지는 않지만, 개인용 컴퓨팅의 역사를 보면 이게 통과되지 않는다면 오히려 놀랄 것 같음
    잠긴 스마트폰이 표준이 되고, Windows가 광고 운반체가 된 흐름을 보면, 이건 IT의 피할 수 없는 진화에서 다음 단계처럼 보임
    언론사가 아직 초기 제안이라 큰 관심이 없을 수도 있지만, 함의를 생각하면 웹에서 Hacker News 바깥에서는 거의 이야기되지 않는다는 점이 인상적임. YouTube에서 이 주제로 영상을 올린 사람은 Rossmann 정도인 것 같음. Twitter에서 “web environment integrity api”를 검색해도 결과가 몇 개 안 되고 답글도 거의 없음. Reddit에서 핵심 문자열을 찾아보면 의미 있는 논쟁이 있는 결과는 WEI와 무관함
    소셜 미디어가 막바지라 그럴 수도 있지만, 예전의 웹이나 일반 컴퓨팅을 위해 싸우고 싶어 하는 사람이 많이 남아 있지 않은 듯함

답변달기