1P by GN⁺ | ★ favorite | 댓글 1개
  • Vivaldi는 Web Environment Integrity가 웹사이트에 브라우저·플랫폼 신뢰 판정 권한을 주면서, 오픈 웹의 접근성과 경쟁을 흔들 수 있다고 봄
  • 이 제안은 제3자 attester가 실행 환경을 검증하는 구조로, 가짜 상호작용 방지를 내세우지만 웹사이트용 DRM처럼 작동할 수 있음
  • 신뢰 판정이 소수 기업에 집중되면 새 브라우저, 소규모 브라우저, 레거시 소프트웨어, Linux 사용자가 웹 접근에서 밀려날 위험이 커짐
  • 브라우저가 구현을 거부해도 웹사이트가 API를 요구하면 사용자를 차단할 수 있고, Google 서비스나 Google Ads가 채택 압력으로 작동할 수 있음
  • 2023년 11월 3일 기준 Google은 Web Integrity API를 진행하지 않기로 했지만, 브라우저와 브라우저 엔진의 다양성은 계속 필요함

Web Environment Integrity가 하려는 일

  • Web Environment Integrity는 웹사이트가 현재 접속한 브라우저와 플랫폼을 신뢰할 수 있는지 API로 확인하게 하는 제안임
  • 신뢰 여부는 권위 있는 제3자인 attester가 판정하는 구조임
  • 목표는 여러 웹사이트에서 “가짜” 상호작용을 막는 데 가까우나, 세부 방식은 불분명함
  • 사용 사례는 겉으로 합리적으로 보일 수 있지만, 실제 효과는 웹사이트용 DRM에 가까워질 수 있음
  • 첫 사용 사례가 광고 상호작용의 진위 확인이라는 점은 Google의 광고 플랫폼 강화와 연결될 수 있음

브라우저 신뢰 판정이 만드는 배제

  • 특정 주체가 어떤 브라우저를 신뢰할지 결정하면, 어떤 브라우저도 자동으로 허용된다는 보장이 없어짐
  • 새 브라우저는 기본적으로 신뢰되지 않는 상태에서 출발하고, attester가 납득할 방식으로 신뢰성을 입증해야 함
  • 명세를 지원하지 않는 레거시 소프트웨어 사용자는 시간이 지나며 웹에서 배제될 수 있음
  • 명세가 벤더 배제 위험을 언급하더라도, 실제 해결책 없이 미온적으로 대응하는 데 그칠 수 있음

플랫폼별 attester와 경쟁 우려

  • 명세의 주요 attester 예시는 Android의 Google Play
    • 이 구조에서는 Google이 자사 플랫폼에서 어떤 브라우저를 신뢰할지 결정하게 됨
    • Vivaldi는 Google이 공정하게 판단하리라고 기대하기 어렵다고 봄
  • Windows에서는 Microsoft가 Windows Store를 통해, Mac에서는 Apple이 비슷한 역할을 맡을 가능성이 언급됨
    • 이 흐름에서는 적어도 Edge와 Safari는 신뢰될 가능성이 높음
    • 다른 브라우저는 Google, Microsoft, Apple의 판단에 의존하게 됨
  • Linux에 대해서는 명확한 답이 없음
    • Linux가 웹 브라우징에서 완전히 배제될지, Canonical이 snaps 패키지 저장소를 통해 결정자가 될지 불분명함
    • Linux 사용자에게는 좋지 않은 상황으로 남아 있음

사람 판별, 자동화, 확장 기능의 불확실성

  • 명세는 실제 사람이 웹사이트와 상호작용하는지 확인하려는 목적을 강하게 암시하지만, 이를 달성하는 방식은 명확하지 않음
  • 남는 질문은 다음과 같음
    • 사용자가 사람처럼 행동하는지 보기 위해 행동 데이터를 사용할지
    • 이 데이터가 attester에게 제공될지
    • 브라우저 입력 자동화에 의존하는 접근성 도구가 브라우저를 신뢰할 수 없게 만들지
    • 확장 기능에 어떤 영향을 줄지
  • 현재 명세는 브라우저 수정과 확장 기능에 예외를 두지만, 확장 기능은 웹사이트 상호작용 자동화를 쉽게 만들 수 있음
  • 예외를 유지하면 공격자가 우회하기 쉽고, 예외를 줄이면 확장 기능에도 제한이 적용될 가능성이 생김

구현 거부가 어려운 이유

  • 브라우저가 Web Environment Integrity를 구현하지 않으면 신뢰되지 않는 브라우저가 될 수 있음
  • 웹사이트가 이 API를 요구하면 해당 브라우저 사용자를 거부할 수 있음
  • Google은 웹사이트 채택을 밀어붙일 수단을 갖고 있음
    • Google 자체 서비스가 이 기능에 의존하게 만들 수 있음
    • Google 웹사이트를 사용할 수 없게 되는 것은 대부분의 브라우저에 치명적일 수 있음
    • Google Ads를 쓰는 사이트에 API 사용을 요구할 수도 있음
  • 첫 목표가 가짜 광고 클릭 방지라면, Google Ads와의 결합만으로도 API 채택이 빠르게 퍼질 수 있음

법적 제동 가능성과 한계

  • Vivaldi는 EU 법이 소수 기업에게 어떤 브라우저를 허용할지 결정하는 큰 권한을 허용하지 않을 가능성이 크다고 봄
  • attester는 가능한 한 공정해야 한다는 압박을 강하게 받을 수 있음
  • 다만 입법과 사법 절차는 느리기 때문에, 정부와 법원이 검토하는 동안 이미 피해가 생길 수 있음
  • 제안이 진행되면 오픈 웹에 어려운 시간이 올 수 있고, 소규모 벤더가 특히 큰 영향을 받을 수 있음

Google의 이전 제안들과 시장 지배력

  • Google의 브라우저 시장 지배력은 웹에 존재론적 위협이 될 잠재력을 갖고 있다고 평가됨
  • Vivaldi는 Google이 이전에도 웹에 좋지 않은 제안을 내놓았다고 보며, 예시로 FLOC, TOPIC, Client Hints를 듦
  • Web Environment Integrity는 이 흐름의 연장선에 있으며, Microsoft와 Apple이 Google과 협력해 브라우저와 운영체제 경쟁을 제한하게 만들 수 있다는 점에서 더 큰 위협으로 다뤄짐
  • 장기적으로는 Google이 더 평평한 경쟁 환경에 놓이도록 해야 하며, 법제화와 Google 시장 점유율 축소가 모두 필요함

2023년 11월 3일 업데이트

  • Google은 Web Integrity API를 진행하지 않기로 함
  • Vivaldi는 이를 오픈 웹의 중립성에 매우 긍정적인 일로 봄
  • 다만 Google이 웹 전체의 이익보다 자사 이해관계에 크게 움직인다고 보며, 무엇으로 이를 대체할지는 지켜봐야 한다고 봄
  • FLOC 이후 Topics가 나온 것처럼, 덜 거슬려 보이지만 사용자에게 유해한 명세가 나올 수 있다는 의심도 남아 있음
  • 이 결정이 Google의 광고 과금 모델을 클릭당 과금에서 노출당 과금으로 옮기겠다는 최근 발표와 맞물린 점도 의심스럽다고 봄
  • 단일 주체가 웹의 미래를 좌우하지 못하게 하려면 브라우저와 브라우저 엔진의 다양성이 중요함

댓글과 토론

Hacker News 의견들
  • Google이 이런 말을 하는 건 특히 어이없음. Android의 SafetyNet은 명목상 보안을 위한 것이지만 실제로는 보안을 크게 낮추는 결과를 냄
    최신이고 안전한 서드파티 ROM은 막으면서, 제조사가 제공하는 끔찍하게 취약한 ROM은 통과시킴. 막으면 사용자 반발이 클 테니 그대로 두는 것임
    결국 평균 사용자에게 의미 있는 보안 향상을 주기보다는 벤더 종속으로 작동하고, 고급 사용자가 새 하드웨어를 사지 않고 보안을 개선하는 길을 막음. 이런 attestation이 사용자에게 정당한 이익을 준다는 주장에는 더 강하게 반박해야 함

    • 사용자에게 적대적인 잠긴 전화기 얘기라면, 이 제안을 올린 Google 직원 Ben Wiser의 블로그 최신 글이 자기 iPhone에서 원하는 소프트웨어를 자유롭게 못 돌려 억울하다는 불평이라는 점이 엄청난 아이러니임
      https://benwiser.com/blog/I-just-spent-%C2%A3700-to-have-my-...
      https://github.com/RupertBenWiser/Web-Environment-Integrity
    • 거의 어떤 소프트웨어나 웹사이트도 편의성이나 보안 향상 같은 사용자 이익이 있다고 포장할 수 있음. 더 중요한 질문은 만든 사람에게 어떤 이익이 있는지, 그리고 그것이 실제로 무엇을 하는지임
      과도한 데이터를 흘리지 않는 웹 클라이언트를 쓸 수 있지만, Google은 우리가 그런 클라이언트를 쓰지 않길 바랄 것임. 승인되지 않은 웹 클라이언트를 전부 “봇”으로, 사용자의 환경 정보를 과하게 공개하지 않는 웹 이용을 전부 “사기”로 포장할 수도 있음
      모든 웹 이용을 상업적 행위로 보고 모든 웹사이트를 광고 그릇으로 취급하는 전부 아니면 전무식 사고는 전형적인 인지 왜곡에 가까움
    • 맞음. 우회 자체는 사소하지만 기기를 루팅해야 하므로, 커스텀 ROM에서도 오히려 보안 저하가 생길 수 있음
    • GrapheneOS에는 그 설명이 맞지 않음
      https://grapheneos.org/articles/attestation-compatibility-gu...
      SafetyNet 자체도 이미 폐기 예정임
      https://developer.android.com/training/safetynet/deprecation...
  • 논란이 되는 브라우저 기능은 언제나 비슷함. 구현하지 않으면, 그 기능을 요구하는 웹사이트에서 사용자 경험이 나빠질 수 있음
    하지만 소프트웨어 제작자라면 고객에게 무엇이 최선인지 스스로 판단해야 함. 이걸 따르지 않을 유일한 희망이 EU가 Google을 혼내는 것뿐이라면, 스스로 강한 입장을 취할 의지가 없는 것처럼 보여 걱정됨

    • 대형 웹 서비스 중 사용자에게 최선인지에 따라 움직이는 곳은 거의 없음. 이게 힘을 얻으면 Google은 “신뢰되지 않은” 페이지에서 발생한 노출에 대해 AdSense 지급을 거부할 수 있고, 광고 수익에 의존하는 대형 사업자들은 사용자 따위 신경 쓰지 않고 곧바로 WEI를 구현할 것임
    • 이건 범주 오류에 가까움. 대부분의 브라우저 기능이나 API는 사용자가 충분히 보급되기 전까지 점진적 개선으로 다뤄지고, 나중에 기능 존재를 가정하더라도 대개는 경험 저하에 그치지 사이트가 완전히 깨지지는 않음
      하지만 웹 attestation은 다름. 웹사이트가 요구하고 브라우저가 구현하지 않으면, 적지 않은 경우 사용자는 그 사이트에서 완전히 차단될 수 있음
      더구나 Vivaldi가 WEI를 구현하더라도 attestation 기관인 Google, Microsoft, Apple 또는 웹사이트 자체가 Vivaldi를 유효한 환경으로 인정하지 않을 가능성도 큼. 광고 차단 확장, 사용자 자동화, 스크립팅처럼 사용자에게 너무 많은 자유를 주는 브라우저를 “허용 가능한 환경”으로 볼지 의문임
    • WEI가 다른 점은 다른 웹 기능을 어떻게 구현할지에 대한 선택권까지 사실상 통제한다는 것임. 예를 들어 요소 차단을 허용할지, 개발자 콘솔을 보여줄지까지 영향을 줄 수 있음
      Encrypted Media Extensions를 제외하면, 그것도 WEI보다 훨씬 제한적이지만, 이런 식으로 작동하는 웹 표준은 잘 모르겠음
    • Google은 가장 인기 있는 검색 엔진과 광고망도 통제하므로, 따르지 않는 웹사이트에 광고나 트래픽을 주지 않는 방식으로 웹 개발자에게 상당한 압박을 가할 수 있음
      이미 모든 광고를 차단하므로 광고 수익 극대화를 기준으로 결정을 내리는 개발자에게 전적으로 공감하지는 않지만, 여기서 개발자에게 “네 선택이니 그냥 거부하라”고 부담을 떠넘기는 건 공정하지 않음
    • Google은 이런 시도를 하다가 이전에도 밀린 적이 있음. 떠오르는 것만 두 가지임
      1. FLoC: https://www.theverge.com/2022/1/25/22900567/google-floc-aban...
      2. Dart: Google은 JavaScript를 대체하려 했지만 Mozilla와 Microsoft가 참여하지 않았다는 이유로 거부했고, 결국 프로젝트가 죽었음
        Google은 많은 것을 시도함. Mozilla, Microsoft, Apple은 아직 충분히 강해서, 특히 미국 밖에서는 나쁜 아이디어라고 보는 것에 맞설 수 있음
  • 지금까지 관련 스레드는 이 정도인 듯함. 빠뜨린 게 있을까?
    Google is already pushing WEI into Chromium - https://news.ycombinator.com/item?id=36876301 - July 2023 (705 comments)
    Google engineers want to make ad-blocking (near) impossible - https://news.ycombinator.com/item?id=36875226 - July 2023 (439 comments)
    Google vs. the Open Web - https://news.ycombinator.com/item?id=36875164 - July 2023 (161 comments)
    Apple already shipped attestation on the web, and we barely noticed - https://news.ycombinator.com/item?id=36862494 - July 2023 (413 comments)
    Google’s nightmare “Web Integrity API” wants a DRM gatekeeper for the web - https://news.ycombinator.com/item?id=36854114 - July 2023 (447 comments)
    Web Environment Integrity API Proposal - https://news.ycombinator.com/item?id=36817305 - July 2023 (437 comments)
    Web Environment Integrity Explainer - https://news.ycombinator.com/item?id=36785516 - July 2023 (44 comments)
    Google Chrome Proposal – Web Environment Integrity - https://news.ycombinator.com/item?id=36778999 - July 2023 (93 comments)
    Web Environment Integrity – Google locking down on browsers - https://news.ycombinator.com/item?id=35864471 - May 2023 (1 comment)

    • 관련 글이 하나 있었는데 플래그 처리됐음
      “I don't know why this enrages folks so much.” Googler re Chrome anti-feature https://news.ycombinator.com/item?id=36868888
      충분한 카르마를 가진 사용자들이 플래그한 것 같지만, 한동안 “[flagged]”라고 표시되지는 않으면서 앞쪽 페이지에 나타나지 않고 추천도 더 받지 않아 헷갈렸음. “[flagged]” 표시에는 지연이 있는 건가 싶음
  • 진지하게 항의하려면 이렇게 할 수 있음. 각자 웹사이트에 사용자 에이전트가 이 API를 구현했는지 확인하는 코드를 넣고, 통과하면 그 브라우저는 환영받지 못한다고 이유와 함께 알려주는 것임
    #BoycottGoogle #BoycottChrome #BoycottBullshit

    • 공감하고 다 같이 그렇게 하면 좋겠지만, 내가 같이 일하는 돈을 쥔 사람들이 동의할 모습은 상상이 안 됨
    • 그걸 상사에게 말해야 함. 그리고 Google이 원한다면 이걸 숨기는 방법도 만들 수 있을 것 같음
  • 늘 그렇듯 Google의 WEI에 대한 장문의 글이지만, Apple이 이미 조용히 이 배를 띄웠고 그래서 관심이나 반발을 거의 받지 않았다는 점은 언급하지 않음
    https://httptoolkit.com/blog/apple-private-access-tokens-att...
    https://toot.cafe/@pimterry/110775130465014555
    기술 뉴스와 블로그의 안타까운 상태임. 더 큰 그림은 보지 않고 같은 드라마만 되풀이함

    • 전 세계 인터넷 사용자 다수처럼 Apple 제품을 갖고 있지 않아서 알아차리지 못했고, 영향을 받은 적도 없으며 아마 앞으로도 그럴 가능성이 큼
      반면 Google Analytics나 Google 광고를 쓰는 웹사이트와는 계속 상호작용함. 그 사이트들이 내가 선택한 브라우저를 거부하기 시작하면 인터넷의 상당 부분에서 실제로 막히게 됨
      나머지 인터넷 사용자 60% 도 사실상 이 기술을 받아들이도록 강요받을 수 있음. 영향받는 사용자가 한두 자릿수 규모로 더 많으니 경보를 울릴 충분한 이유가 됨
    • 글에서도 그 점을 말함. Safari가 지배적인 웹 브라우저가 아니기 때문에 같은 문제가 되지 않음. Apple이 이걸로 행사할 수 있는 힘은 매우 제한적임
    • “저쪽에 더 큰 나쁜 놈이 있다”는 식의 방어는 이길 수 있는 전략이 아님
    • 개인적으로 Private Access Tokens는 WEI만큼 나쁘지는 않다고 봄. PAT는 CAPTCHA를 우회하는 정도지만, WEI는 사람들을 사이트에서 완전히 막을 가능성이 큼
    • 분명 더 많은 관심을 받았어야 함
  • 첫 사용 사례가 광고 상호작용이 진짜인지 확인하는 것이라는 점은 시작에 불과함. Attestation은 결국 광고주가 사용자가 실제로 자리에 있고 화면을 보고 있는지 요구하게 만들 수 있음
    Black Mirror의 “Fifteen Million Merits” 에피소드처럼 될 수 있음

    • Sony는 이미 Black Mirror의 그 정확한 시나리오에 대한 특허를 갖고 있음
      https://www.creativebloq.com/sony-tv-patent
      TV 시청자가 광고를 건너뛰려면 브랜드 이름을 외쳐야 하는 내용임. “McDonald's!”라고 외쳐야 Big Mac이 사라지는 식
      기업들은 막지 않으면 가장 미친 짓과 끔찍한 짓을 할 것이고, 실제로 일어날 것임
    • Android에서는 일부 동영상 광고가 알림창을 내려도 일시정지됨
    • 모든 미디어 사이트가 반드시 써야 하는 호스트 브라우저 안에서 WASM으로 구현된 전체 브라우저 엔진을 또 하나 얹는 날이 기다려짐
  • 이제 두 가지가 필요함. 첫째, Google을 검색과 광고로 분리하는 반독점 분할. 둘째, 광고세
    검색 엔진이 광고를 너무 많이 보여주는 것이 경제적으로 손해가 되게 만들어야 함

    • 첫 번째에는 동의하지만 두 번째는 목표를 빗나간 것 같음. 이건 검색과는 별 관련이 없음
      Google이 최대 광고 판매자이면서 동시에 가장 인기 있는 브라우저인 Chrome/Chromium 제작자라는 시장 지위를 이용해, 사용자가 어느 웹사이트에서든 Google 광고를 보지 않을 수 없게 만들려는 것임
    • 검색과 광고를 분리하는 아이디어는 판도를 바꿀 수 있다고 보지만, 검색은 광고 없이 어떻게 수익을 내고, 순위 알고리즘을 훼손하지 않을 수 있을까?
    • 검색 엔진이 광고를 보여주는 것이 경제적으로 손해가 되지는 않을 것임. 첫 화면의 광고 자리는 언제나 가치 있게 팔 수 있음
      대신 전술적으로 손해가 되어야 함. 광고가 정확도를 해치고 사용자를 떠나게 만들기 때문임. 하지만 훨씬 더 정확한 경쟁자가 없으면 오래 버틸 수 있음
      Google 검색에는 희망적인 신호도 있음. 일부는 정확도가 떨어졌다고 보고하고, Google은 스팸을 피하려고 특유의 동작을 계속 바꾸는데, 그 과정에서 사람들이 SEO와 Google 검색 요령에 들인 노력을 가치 없게 만들고 있음. 다만 이 둘은 같은 현상일 수도 있음
  • “이 웹사이트는 사용자의 기기와 호환되지 않습니다”라는 문구가 YouTube에 뜨는 모습이 보임
    Google 통제 아래 있고, 공식 브라우저에서 광고를 보길 원하니 이상하지 않음. 은행 앱에도 초기에 들어갈 수 있음
    장기적으로는 시들어 죽거나, 반독점 조치로 이어질 것임. 다른 길은 잘 보이지 않음

    • 모든 스트리밍 서비스가 해적판 방지를 명목으로 빠르게 구현할 가능성이 큼. 효과는 없고, 더 자유를 존중하는 브라우저나 운영체제로 보고 싶은 사람들만 해치게 될 것임
    • Android와 iOS처럼 부팅부터 이어지는 완전한 신뢰 사슬이 없으면, 그리고 독점 데스크톱 환경이 제공할 수 있는 경우가 아니라면, “나는 합법적인 브라우저”라는 교환을 위조할 수 있어야 함
      신경 쓰는 1%는 그렇게 할 것임. 하지만 예전에는 열린 웹이었던 곳에서 이제 지하의 “크랙” 같은 방식으로 내려가야 한다는 점이 끔찍함. 탐지되면 차단될 위험도 있음
    • 은행이 목표는 아님. 은행이 장애인, 장애가 있는 법인 계정 관리자, 고령자를 방해하는 조치를 하면 크게 얻어맞을 것임. 조심스럽게 움직일 수밖에 없음
  • WEI가 문에 달린 엿보기 구멍보다 정확히 뭐가 더 나쁜지 모르겠음. 봇은 이미 큰 문제이고 더 나빠지고 있음. 대안은 무엇인가?
    현실에서도 웹에서도 상대가 누구인지 알아야 함. 아마 혼자일지 모르지만, WEI는 좋은 것이라고 봄
    사이트를 운영해 본 사람이라면 봇 때문에 얼마나 골치 아픈지 알 것임. 봇을 신경 쓰지 않는 사이트는 WEI를 쓰지 않으면 됨. 물론 실제로는 쓸 것임. 봇이 골칫거리이기 때문임
    AI가 발전하면서 이는 어차피 피할 수 없었음. 아니라고 생각하는 건 망상에 가까움

    • SSL은 실제로는 서버 인증서에만 쓰임. 인증기관 때문에 별로였고 불만도 많았지만 Let’s Encrypt가 나오면서 상황이 나아졌음. 그리고 정체성은 도메인 제어에만 묶여 있으며, 코드 서명 인증서처럼 훨씬 침습적이고 사실상 장사판인 것과는 다름
      WEI는 “승인된 기기” 방식의 진짜 DRM이 될 잠재력이 있음. 매우 침습적이며, 대기업 마음대로 스크린 리더, 광고 차단, 추적 방지, 지문 추적 방지, 저작권 콘텐츠 다운로드, 앞으로 떠올릴 모든 사용 방식을 배제하는 데 쓰일 수 있음
      말 그대로 웹을 App Store로, 좋게 봐도 여러 개의 앱 스토어로 만드는 관문임. 봇이 문제라면 구체적으로 말해야 함. 좋은 봇도 많고, 아이러니하게도 봇 트래픽의 대부분은 이런 것을 추진하는 대기업들에서 나옴. 악성 봇에는 IP 차단 목록이 있고, 회색지대의 조작 봇은 문제지만 왜 모든 사용자에게 의무 수갑을 채워야 하는지는 별개임
    • WEI의 본질은 사용자가 자기 기기를 완전히 통제하지 못하게 하는 것임. 사람에게 기기 통제권을 주면 봇은 생김. 봇 제거가 범용 컴퓨팅보다 더 중요하다고 믿는지의 문제임
      봇은 그저 소유자가 원하는 일을 하는 컴퓨터일 뿐임. WEI를 좋아하는 입장은 타인이 컴퓨터를 마음에 들지 않는 방식으로 쓰는 것이 불편해서, 그 컴퓨터의 통제권을 빼앗고 싶어 하는 셈임
      강한 AI가 문턱에 온 지금, 범용 컴퓨팅을 빼앗으려는 움직임이 보임. 최악의 결과들은 모두 사람들이 자기 컴퓨터를 통제할 능력을 잃는 데서 나옴
    • SSL은 어떤 제3자가 내 소프트웨어와 하드웨어를 승인해야만 동작하도록 요구하지 않음
    • TLS는 웹사이트가 사용자가 원하는 기술 스택, 즉 하드웨어·운영체제·브라우저 사용을 제한하게 만들지 않음. WEI는 그렇게 함
    • 이 기능이 없는 브라우저를 쓰는 사람은 웹을 쓰기 위해 극단적인 절차를 거쳐야 하는 2등 시민이 되거나, 아예 웹 대부분에서 차단될 수 있음
      개인적으로 만든 웹 스크래퍼 스크립트를 여러 개 씀. 예를 들어 모든 급여명세서를 디지털 사본으로 갖고 있음. 이런 것들이 거의 다 쓸모없어질 것임
      이전 직장의 퇴직연금 사이트는 월별 명세서를 수동으로만 내려받게 했고, Mechanize 라이브러리를 감지해 로봇 금지 경고를 띄웠음. 매달 수동으로 하는 사람은 없을 텐데, 로봇도 허용하지 않았던 것임
      그래도 그때는 차단하려면 어딘가에 특수 소프트웨어를 설치해야 했지만, 이건 그런 짓을 훨씬 쉽게 만들어 줌. Selenium 같은 도구도 걱정됨. 이건 SSL이 아님
  • 이 제안에 대한 도덕적 분노는 많고, 당연함. 오히려 더 강해져야 함. 다만 그와 별개로, 이 제안은 어쨌든 잘 작동하지 않을 것 같음
    반대 없이 구현되면 닫힌 루프의 단단한 DRM 웹이 되고, 입법자들의 관심을 끌 것임. 그러길 바람
    반대하는 브라우저가 남아 있으면 웹사이트 입장에서는 별 쓸모가 없음. 어차피 사기 탐지를 위한 백업 메커니즘을 유지해야 하기 때문임. 유지할 거라면 훨씬 더 많은 개인 데이터를 모을 수 있는 기존 방식을 단일 해법으로 쓰는 편이 낫다고 볼 것임

    • 이건 애초에 개별 웹사이트를 위한 게 아니었음. 순전히 Google의 광고 사업을 보호하기 위한 조치임