1P by GN⁺ | ★ favorite | 댓글 1개
  • Google Chrome 팀의 최근 결정·제안이 웹 개방성과 브라우저 선택권을 해친다는 문제의식에서, Chromium/Google Chrome 대신 Firefox나 Epiphany 사용을 권하는 목록임
  • Manifest v3는 콘텐츠 차단 확장 기능을 약화시키는 사례로 지목되며, Firefox와 Chrome의 광고 차단 확장 기능 논쟁을 다룬 The Verge 링크가 붙어 있음
  • JPEG XL은 휴대폰 저장공간을 절약할 수 있는 사진 포맷인데도 Chrome에서 배제된 사례로 묶임
  • Web Environment Integrity는 전체 웹사이트용 DRM으로 불리며, 웹과 오픈소스 브라우저·운영체제에 해를 끼칠 수 있는 제안으로 다뤄짐
  • 주변 사람에게 Chrome/Chromium 사용 중단 이유를 설명할 때 쓸 수 있는 공유용 자료이며, 대안으로 FirefoxEpiphany가 명시됨

Chrome/Chromium 사용 중단을 권하는 이유

  • Google Chrome 팀의 최근 움직임 중 세 가지가 적대적 사례로 묶임
    • Manifest v3: 콘텐츠 차단 확장 기능 방해
    • JPEG XL: 사진 포맷 배제
    • Web Environment Integrity: 전체 웹사이트용 DRM에 가까운 제안

Manifest v3와 콘텐츠 차단 확장 기능

JPEG XL 배제

Web Environment Integrity

  • Web Environment Integrity는 전체 웹사이트를 위한 DRM으로 불림
  • 이 제안은 웹, 오픈소스 브라우저, 오픈소스 운영체제에 해를 끼칠 수 있는 항목으로 제시됨
  • 연결된 Ars Technica 링크 제목은 Google의 Web Integrity API가 웹을 위한 DRM처럼 들린다는 내용임
  • 링크: Google’s Web Integrity API sounds like DRM for the web

권장 브라우저

  • 이 목록은 주변 사람에게 Chromium 또는 Google Chrome 사용을 멈춰야 하는 이유를 설명하기 위한 자료임
  • 주 웹 브라우저 대안으로 Firefox 또는 Epiphany가 제안됨

댓글과 토론

Hacker News 의견들
  • “Safari가 새 IE”라는 프레임을 기억해야 함. Safari가 어떤 API를 지원하지 않는다고 IE가 되는 건 아니고, IE도 처음부터 열등한 브라우저였던 건 아님
    모두가 싫어한 IE가 된 이유는 표준에서 벗어나 막대한 점유율로 자기식 웹을 강요했기 때문임. IE는 데스크톱 앱 사업 경쟁을 막으려 정체시킨 듯하고, Google은 데이터 수집과 광고 사업을 위해 비슷한 길을 가는 중이라 봄. Chrome이 새 IE

    • Safari가 비판받은 건 기능 도입이 느려서만이 아니라, 기능을 다른 브라우저와 호환되지 않는 방식으로 구현하는 일이 있었기 때문임
      예를 들면 사생활 보호 모드에서 localStorage 처리 같은 것들이고, 개발자는 IE 때처럼 Safari 감지와 별도 분기나 폴리필을 넣어야 했음. Apple도 네이티브 앱 채택을 밀기 위해 여러 웹 기능을 제한하거나 변형했다는 점에서 표준 이탈 책임이 있음. 다만 요즘은 다른 브라우저와 더 맞춰졌고, 대부분이 Chromium 복제품이라는 점도 아쉬움
    • IE는 발전하지 않아서 확실히 미움받았음. “자기만의 비전”이라는 게 Mozilla와 Opera가 앞으로 나아갈 때 최대한 아무것도 안 하는 것 말고 뭐였는지 궁금함
      웹 개발자 관점에서는 그랬지만, 최종 사용자 관점에서 IE가 같은 방식으로 미움받았던 것 같지는 않음. Chrome은 여전히 혁신하지만 이제는 너무 많은 걸 하려 해서 사용자가 싫어하고, “새 IE” 타이틀은 아직 Safari 쪽에 더 가까움
    • 2017~2018년쯤 프론트엔드를 할 때 Safari가 웹 표준 준수와 렌더링 면에서 가장 많은 문제를 일으켰음
      지원하지 않는 표준은 차라리 알 수 있어서 덜 문제였고, 데스크톱·iPad·iPhone에서 웹 앱을 맞추는 과정에서 Safari 버그와 렌더링 특이성을 쫓는 시간이 IE11보다 더 많았음
    • “IE”에는 두 종류가 있다고 봄. 하나는 표준을 따르지 않고 자기 마음대로 한 IE이고, 다른 하나는 새 표준 도입이 느린 IE임
      Chrome은 전자, Safari는 후자에 가깝고, Safari는 IE만큼 표준 도입이 느리지는 않아서 비교가 썩 좋지는 않음
    • IE는 처음부터 별로였음. Netscape가 동적 HTML을 제안하고 데스크톱 경험을 장악하려 하자 Microsoft가 더 나은 브라우저를 만들고 운영체제에 묶어 무료 배포하면서 본격적으로 밀어붙였음
      IE의 목적은 Netscape를 죽이는 것이었고 성공했지만, Netscape는 브라우저를 오픈소스로 공개했고 그것이 오늘날 Mozilla Firefox가 됨. 이후 Microsoft는 IE를 방치했고, 결국 악성코드 브라우저 같은 Edge와 광고 악성코드 브라우저 같은 Chrome의 경쟁 구도로 이어졌지만 Firefox, Safari, Brave, Opera가 남아 있어 다행임
  • 이 스레드에 동의하면서도 여전히 Chrome을 쓰는 이유가 뭔지 궁금함. 결국 Chrome 사용자끼리 설교하는 셈임
    우리 같은 기술자들이 게으른 핑계로 Google의 지배력을 유지해 주지 않았다면 이렇게 압도적이지 않았을 것임. 2023년이면 Safari와 Firefox는 꽤 오래전부터 충분히 좋아졌음. Dante의 Divina Commedia에서 입장을 취하지 못하는 게으른 자들은 지옥 바깥에 머무는데, 지금 쓰였다면 uBlock 켠 Chrome을 쓰는 많은 기술 노동자가 들어갔을 것임

    • 내 경우는 생태계 때문임. 데스크톱 브라우저가 Android 브라우저와 동기화되는 게 좋고, 브라우저에 Chromecast 지원이 내장된 것도 마음에 듦
      Firefox 모바일 동기화와 Chromecast 확장 시도는 예전에 써봤을 때 별로였지만 오래전이라 다시 볼 수도 있음. 다만 회사 노트북에서는 이 편의들이 별 의미가 없고, 회사 IT가 Firefox를 승인했으며 동료들도 많이 쓰니 오늘 전환해 보려 함
    • 가장 큰 장벽은 편리한 프로필 전환 부재였음. 집·회사·기타 용도로 방문 기록과 북마크가 분리된 프로필을 쓰는 게 작업 흐름에서 중요하고, 컨테이너 탭은 좋은 대체재가 아님
      Firefox는 내부적으로 이를 완전히 지원하면서도 편하게 쓰는 UI 구현은 밀어내는 것 같아 더 답답함. 지금은 Profile Switcher 확장 https://addons.mozilla.org/en-CA/firefox/addon/profile-switc...로 매년 하는 전환 시도를 해보는 중인데, 외부 소프트웨어가 필요하고 언젠가 깨질 것 같음. 외부 링크를 기본 프로필 말고 최근 활성 프로필로 열 수 없는 점도 Chrome보다 불편함
    • “Safari와 Firefox가 오래전부터 좋다”는 말은 내 경험과 다름. 가끔 Firefox로 옮겨 보지만, Mac 사용자가 아니라 Safari는 iOS에서 제약을 감수하는 정도임
      느린 렌더링은 분명 문제고, 사이트 탓인지 브라우저 탓인지 모를 렌더링 버그도 흔해서 다중 페이지 양식 작성 중 작업을 잃은 적도 있음. Firefox는 미적으로도 둔하고 못생겼다고 느낌. Chrome도 Google 로그인 직접 통합, #:~:text= 페이지 내 텍스트 강조, 제거 불가능한 주소창 버튼 같은 나쁜 점이 많지만, 그래도 가장 빠르고 능력 있는 브라우저임
    • 기술자들은 스스로의 최악의 적임. “Chrome, GMail, Google Drive로 옮기자, 정말 강력하다!”라고 해놓고 다음 장면에서 “왜 Google이 이렇게 강하고 나쁜 짓을 하지?”라고 묻는 식임
    • Manifest v3는 지연됐고 나름 정당한 면이 있었으며, v3에 대해 제대로 아는 사람이 많지 않다고 봄
      JPEG XL도 최근 Safari 지원 전까지는 그렇게 큰 사안처럼 보이지 않았고, Chrome이 “원하는 사람이 없어 보인다”고 했다가 사람들이 “원한다”고 하니 다시 개발되는 흐름이라 괜찮아 보임. WEI는 아직 제대로 제안된 단계도 아니지만 셋 중 가장 나쁨. 그래도 Chrome은 필요한 일을 모두 해주고 보안 가치가 높으며, Mozilla는 CEO가 물러나기 전까지 사용자로 받아들이기 어렵다고 봄. 게으름이 아니라 현재 최고의 브라우저라 판단해 의식적으로 Chrome을 쓰는 것임
  • 목록에 빠진 게 있음: Google이 Chrome의 강제 로그인을 시도했다가 선택 해제를 허용한 사건임
    https://www.pcmag.com/news/google-will-let-you-opt-out-of-ch...
    Chrome 69에서는 Gmail 같은 Google 서비스에 브라우저로 로그인하면 Chrome에도 자동 로그인되도록 바뀌었고, 개인정보 논란 끝에 이를 되돌리는 옵션을 제공했음

  • 콘텐츠 차단 확장을 약화시키는 Manifest v3 방해: https://archive.is/i2vGD
    JPEG XL 방해 시도: https://archive.is/2ihEV
    전체 웹사이트용 DRM에 가까운 Web Environment Integrity는 웹, 오픈소스 브라우저, 운영체제에 해로움: https://archive.is/S912x

    • 목록이 너무 짧음. 7년 전의 AMP부터 시작해야 한다고 봄
    • Web Environment Integrity 제안을 이끄는 개발자가 이 구현이 얼마나 위험한지에 대해 너무 현실감이 없어 보여 충격적이었음
    • Chromium에만 구현되고 사실상 강요되는 WebUSB도 언급해야 함: https://caniuse.com/webusb
  • 큰 목록을 기대했는데 항목이 3개뿐이고, 그중 JPEG XL은 Safari가 지원하기 전까지는 최근에야 실현성이 있어 보인 사안이라 애매함
    Chrome이 힘으로 밀어붙인 WebUSB, WebSerial 같은 기능을 넣었으면 훨씬 더 설득력 있었을 텐데, 지금 형태의 목록과 글은 요점을 강하게 전달하지 못함

    • JPEG XL은 원래부터 실현 가능했음. Chrome이 아무도 모르는 선택적 실험을 해놓고, 이를 개발 중단의 근거로 삼았음
      포맷 자체로는 모두에게 이득이고, 이미지를 다루는 대부분의 회사가 JXL을 지지했음. Google은 JXL 대신 자기 포맷을 밀려 했다고 보이므로, 이 사안이 애매하다고 보지는 않음
    • WebUSB는 꽤 유용함. 쉽게 접근 가능한 방식으로 온갖 장치를 제어하는 데 쓰는 사람들을 알고 있음
      Google도 업데이트 웹페이지에서 ADB 연결을 만들어 Android 기기를 업데이트하는 데 사용함. 기능을 빼앗는 게 아니라 추가하는 것이므로 적대적이라고 분류하기는 어려워 보임
    • Safari와 Firefox 구현이 안정화되면 Chrome에도 JXL이 들어갈 수 있다고 봄
  • Chromium v70에서 chrome://net-internals/#sockets를 제거했을 때 신뢰를 잃었음
    이 기능은 개발자 도구 밖에서 일어난 트래픽, 예를 들면 계정 동기화나 추적 요청 같은 것을 실시간 디버그할 수 있게 해줬음

  • Firefox 말고는 대안이 거의 0에 가깝고, Firefox의 사용자 경험이 마음에 들지 않으면 막히는 게 문제임
    Edge, Arc 같은 “새” 브라우저들은 전부 Chromium 껍데기일 뿐임. 새 브라우저를 만드는 진짜 경쟁자가 있는지 궁금함

    • 많은 사람이 Firefox로 못 옮기는 이유가 사용자 경험 때문이라고 보지는 않음. 순수하게 마케팅 문제에 가깝다고 생각함
    • 솔직히 Firefox도 Chrome에 대한 약한 헤지에 불과함. JPEG XL 같은 사안에서는 Chrome과 보조를 맞췄고, 뜻밖에도 Safari가 JPEG XL의 옹호자가 됐음
      Apple이 다시 다른 플랫폼용 Safari를 내주면 좋겠음
    • 오래 Firefox를 써왔지만, 브라우저 전반처럼 UI/UX가 너무 오래 정체돼 있었음
      지금은 Arc가 전통적인 브라우저 UI 패러다임에서 거슬리던 것들을 다시 생각해 주는 점이 좋아서 쓰고 있음. 다만 유행하는 스타트업이라 폭발적으로 망하거나, 기능을 갑자기 크게 바꾸거나, 투자자에게 맞추려고 불쾌한 일을 할 수도 있다는 것도 알고 있음. Firefox 쪽에서는 Containers 같은 확장이 빈틈을 메우지만, UX는 사후에 덧붙인 느낌임
    • Chromium이 오픈소스이고 여러 주체가 사용자에게 해로운 기능을 제거하거나 수정해 빌드할 수 있는 한, 대안이 “껍데기”인 것 자체는 문제로 보지 않음
      Google이 Chromium 수정을 어렵게 만들면 브라우저 유지보수자들은 빠르게 다른 엔진으로 옮겨갈 것임
    • Brave를 1년쯤 쓰고 있는데 Firefox나 Chrome이 그립지 않음
  • 목록에 이것들도 추가하고 싶음: URL에서 http://를 제거한 일, Android에서 선형 탭 보기를 엄지로 첫 탭에 접근하기 어려운 2차원 그리드로 바꾼 일, Android에서 확장 기능과 광고 차단이 없는 점, Chromebook에서 Bluetooth 마우스 스크롤 휠이 수년째 불안정한 점
    URL 문제는 몇 년 뒤 데스크톱에서 주소창 우클릭 후 “Always show full URLs”를 켤 수 있게 되며 일부 해결됨. Chromebook 스크롤 문제는 crosh 콘솔에서 gesture_prop로 임시 해결만 가능했는데, 의도인지 게으름인지는 모르겠음

  • 웹마스터들이 반격해서 사용자 에이전트가 Chrome이면 성가신 팝업을 띄워야 함
    예를 들어 Firefox로 옮기라고 유도할 수 있고, EFF.org가 그런 팝업의 참고 구현을 제공할 수도 있음

    • 진지하게 묻자면 2023년에 웹마스터라는 개념이 아직 존재하나? 사이트는 개발·테스트·승인·운영 배포 단계를 거쳐 만들어지고, 실제 프로덕션 서버에는 배포 에이전트 말고 아무도 접근하지 못하는 경우도 많음
    • “안전하지 않은 브라우저를 사용 중입니다. Mozilla Firefox 같은 안전한 브라우저로 업그레이드하세요.” 정도면 될 듯함
    • 사이트를 완벽히 렌더링할 수 있는 브라우저를 쓴다는 이유로 사용자를 벌주는 건 매우 적대적임. 사용자는 쓰는 기기에 설치된 브라우저를 선택할 권한이 없을 수도 있음
    • 팝오버와 팝업을 더 늘리자고? 차라리 사이트를 느리게 만드는 건 어떨까
    • Chrome이 점유율을 얻은 방식 중 하나가 바로 이거였음. 예전에 큰 Flash/HTML5 게임 플랫폼 중 하나에서 일할 때, 다른 브라우저가 감지되면 Chrome으로 전환하라는 배너를 넣는 대가로 Google에게 큰돈을 받았음
  • Firefox는 한때 성능이 떨어졌지만, 내부 개선 덕분에 그 시절은 끝났음. 오래된 Firefox와 지금 Firefox의 메모리·CPU 사용량은 큰 차이가 있는데, 아직도 Firefox가 변하지 않았다고 생각하는 사람이 많아 아쉬움
    개인적으로 빠르게 측정해 보니 열린 활성 탭 하나당 평균 10MiB 정도를 썼음. Linux Mint 20.3에서 Firefox 115, 확장 13개, 탭 90개를 열고 테스트했으며 uBlock Origin, Multi-Account Containers, Tree Style Tab 등을 사용했음. 90개 탭에는 게임 상점, 쇼핑, YouTube 10개, Google Drive/Docs 14개, 문서 페이지와 HN 스레드들이 포함됐음. 처음 시작해 HN 첫 페이지만 로드하면 372MiB, HN 탭 2개는 386MiB, 세 번째 HN 탭은 394MiB였고, 90개 탭을 모두 강제로 로드하면 954MiB였음. 로딩 중 스크린샷: https://pasteboard.co/Bxf2TI9P8YT2.png, 로딩 후 스크린샷: https://pasteboard.co/m3tVzYNMtDmD.png. Chrome 사용량을 집단적으로 줄여야 하는 시점임

    • HN 첫 페이지와 이 글만 열었는데 386MiB라니, 고급 데스크톱 컴퓨터도 RAM이 128MiB 이하였던 시절을 아직 기억하는 입장에서는 많아 보임
      이렇게 가벼운 사이트 탭 몇 개만으로 그 세 배를 쓰는 건 큰 메모리 사용량처럼 느껴짐. Firefox의 조상격 브라우저를 8MiB RAM 컴퓨터에서 쓴 적이 있어서, 브라우저 시작에 수백 MiB가 필요하다는 것 자체가 여전히 이상하게 느껴짐
    • 추가로 해볼 만한 테스트는 BrowserBench임: https://browserbench.org/Speedometer2.1/
      컴퓨터 사양에 따라 크게 달라짐. 매일 쓰는 오래된 Linux PC도 아직 충분히 빠르지만, 더 최신 미니 PC들은 어떤 브라우저를 쓰든 이 낡은 장비를 훨씬 앞섬