uBlock Origin Lite 제작자, Firefox 스토어 지원 종료

• uBlock Origin Lite는 Firefox Add-ons Store 배포가 중단됐고, 제작자 Raymond Hill은 확장 프로그램을 자체 호스팅으로 옮김
• Mozilla 리뷰 팀은 9월 초 모든 버전을 정책 위반으로 표시하며 사용자 데이터 수집과 “minified, concatenated or otherwise machine-generated code” 포함을 문제 삼음
• Hill은 해당 지적이 JavaScript를 기본적으로 이해하면 말이 되지 않는다고 반박했고, 리뷰 절차를 “nonsensical and hostile”하다고 봄
• Mozilla는 이후 GitHub 이슈에 포함된 이메일에서 실수를 인정하고 사과했지만, uBlock Origin Lite는 여전히 addons.mozilla.org에서 찾을 수 없음
• Firefox 사용자는 GitHub에서 최신 버전을 받아야 하며, 기존 uBlock Origin for Firefox는 계속 제공되고 지원됨

---

Firefox Add-ons Store 배포 중단

• uBlock Origin Lite 제작자 Raymond Hill은 Firefox Add-ons Store 리뷰 팀의 “nonsensical and hostile” 리뷰 절차를 여러 차례 겪은 뒤 스토어 지원을 중단함
• 9월 초 Mozilla는 uBlock Origin Lite의 모든 버전을 정책 위반으로 표시함
  • 리뷰어들은 확장 프로그램이 사용자 데이터를 수집하는 것으로 보인다고 판단함
  • “minified, concatenated or otherwise machine-generated code”가 들어 있다는 점도 문제 삼음
• Hill은 JavaScript를 기본적으로 이해하는 사람이라면 해당 지적이 말이 되지 않는다는 점을 몇 초 만에 알 수 있다고 반박함

자체 호스팅 전환과 사용자 영향

• Hill은 확장 프로그램을 Firefox Add-ons Store에서 내리고 자체 호스팅 버전으로 옮김
• Firefox에서 uBlock Origin Lite를 계속 쓰려는 사용자는 GitHub에서 최신 버전을 내려받아야 함
  • 해당 버전은 자체적으로 자동 업데이트할 수 있음
• 닫힌 GitHub issue의 마지막 메시지에는 Mozilla가 실수를 인정하고 사과한 이메일이 포함됨
• 그럼에도 uBlock Origin Lite는 Mozilla Add-ons Store에서 제거된 상태이며, addons.mozilla.org에서 더 이상 찾을 수 없음

uBlock Origin과 Manifest 버전 맥락

• 기존 uBlock Origin for Firefox는 여전히 제공되고 지원됨
• Lite 버전은 Manifest V3 기반 확장으로, 프로세서와 메모리 같은 리소스 사용 부담이 더 가볍고 효율적임
• Hill은 Chrome이 uBlock Origin을 지원되지 않는 확장으로 표시하기 시작한 뒤 uBlock Origin Lite로 전환할 것을 권장한 바 있음
• Mozilla는 가까운 미래에 Manifest V2 기반 확장 지원을 중단할 계획이 없어서, uBlock Origin은 Firefox 및 MV2 지원 브라우저에서 계속 존재하고 동작함

[GN⁺]

Hacker News 의견들

• 직장에서 중간 규모의 브라우저 확장을 관리하고 있고 Firefox에도 제공했지만, 수동 심사 이후 Mozilla 스토어에 다시 들어가려고 지난 1년간 고생함
  미국에 있는데 유럽, 아마 루마니아 쪽에 있는 심사자가 두 명 정도뿐인 듯하고, 응답 시간이 길며 “개인정보 처리방침이 필요하다”처럼 이미 있는 걸 못 보거나, 빌드 결과물을 보고 “기계 생성·난독화 코드”라고 하거나, 안내를 안 따라 잘못된 디렉터리에서 “소스를 재현할 수 없다”고 하는 식의 단순 실수를 해결하는 데 2주씩 걸려 매우 답답함

  • 비슷한 처지임. 업무로 Chrome/Firefox/Edge 합쳐 설치 수 약 100만인 확장을 배포하는데, 사용량은 가장 적은 Firefox 심사 절차가 완전히 비정상적임
    재현 가능한 빌드를 요구하면서도 올바른 yarn 버전을 설치하지 못하고, README에 굵게 여러 번 적어둔 정확한 설치 명령이나 Node 버전 설치 절차와 자동화 스크립트 같은 기본 설정 단계도 따라오지 못함
    사기업이 비공개 NPM 모듈을 쓰는 “미친 짓”을 하면 더 난감해짐. 미리 설정한 계정 접근권을 제공하거나 심사용 계정 권한을 주겠다고 해도 Mozilla는 “심사 중 외부 계정을 쓰기 어렵다”고 함
    브라우저 심사팀과 상호작용해야 하는 것 자체가 더 이상 Firefox를 추천하지 않는 큰 이유임. 기껏해야 무능하고, Google 검색 계약 수입을 최대한 빨아먹는 중일 뿐 대안적이고 안전한 브라우저를 진지하게 제공하려는 것 같지 않음
  • “소스를 재현할 수 없다”가 가장 큰 문제였고, 그들이 원하는 정확한 방식의 재현 가능한 빌드를 지원하려고 빌드에 꽤 복잡한 요소를 추가해야 했음
    그런데 확장은 Rust에서 wasm 파일을 빌드하는 구조이고, 몇 번 주고받다 보니 그 wasm은 재현 가능할 필요가 없다는 결론이 나옴. 확장의 핵심이자 로직의 99%가 들어 있는데도 말임
    JS가 재현된들 wasm 안에 임의의 잠재적 악성 코드를 숨길 수 있다면 무슨 의미가 있는지 모르겠음
    한동안은 AMO 쪽 “재현 가능한 빌드”를 단순하게 만들려고 미리 빌드한 wasm을 소스 패키지나 npm에 넣는 방안까지 진지하게 고려했는데, 그러면 실제 빌드 방식과는 더 멀어짐
  • 브라우저 확장 심사 절차를 들을 때마다, 사람이 README를 읽고 빌드 과정을 손으로 맞춰야 한다는 점이 충격적임
    어떤 경우에는 심사자가 가상 머신을 재사용하거나 아예 쓰지 않는다고도 들었음
    심사 양식에는 git 링크를 붙여 넣는 입력칸이 있고, 지정된 메모리·디스크의 VM을 세우고 git을 클론한 뒤 docker build -t ./docker/review/Dockerfile을 실행하는 잘 문서화된 자동화 파이프라인이 있을 줄 알았음
    심사자들도 업무 만족도 차원에서 이런 도구를 조직에 강하게 요구했을 법한데 의외임. 화난 앱 소유자들에게 얼마나 시달릴지 상상하기도 어려움
  • 이전 직장의 확장을 다룰 때도 같은 문제를 겪었음. Firefox 심사 과정은 정말 악몽 같았고, 지연과 오해도 위와 같았음
    결국 회사는 사용량이 낮고 심사가 너무 고통스러워 Firefox 확장 업데이트 빈도를 줄였음. 그 회사에서 Firefox를 쓰던 유일한 엔지니어, 어쩌면 유일한 직원이었던 입장에선 안타까웠음
  • 이런 일의 문제는 좋은 심사를 할 자격이 있는 사람일수록 보통 코드를 검토하기보다 뭔가를 만드는 훨씬 더 흥미로운 일을 얻을 수 있다는 것임
    어느 정도 기술이 필요한 일이지만 동시에 꽤 지루하고, 그런 더 흥미로운 일은 보수도 더 좋을 가능성이 큼

• Mozilla에서 일하지만 Addons와는 거리가 멀어서 그쪽이 어떤 압박을 받는지는 모름
  그래도 내가 운영한다면, 지금 상대는 gorhill임. 그냥 그를 전체 권한을 가진 부가 기능 심사자로 만들고 자기 확장만 심사해도 된다고 하겠음
  그의 역량이나 신뢰성을 검증할 필요가 없음. 어떤 계약자나 직원보다 훨씬 더 많은 과거 데이터가 그를 뒷받침함
  그가 유일무이한 경우도 아님. 예전만큼 자원봉사자 중심은 아니지만 여전히 많은 중요한 기여가 자원봉사자에게서 나오고, 적어도 SpiderMonkey 팀에는 외부 기여자와 유급 기여자 사이의 벽이 없음
  gorhill을 심사팀의 정식 구성원으로 만들지 못할 이유가 없어 보임. 지금 상황을 보면 그가 당장 받아들일 것 같진 않지만, 다른 사람이나 조직에 줄 수 있는 특별 예외를 주는 것보다 더 타당함
  그는 이미 Firefox의 역량과 성공에 크게 기여하고 있으니, 이미 존재하고 가치도 있는 심사에도 기여하게 하면 됨. 자기 심사만 해도 충분하다고 봄
  이제 Slack에서 누구를 귀찮게 해야 할지 찾아봐야겠음

  • 여기엔 동의하지 않음. 자기 코드를 자기 심사하게 허용하면 안 됨. 그건 심사의 목적을 무너뜨림
    슈퍼스타라 해도 다른 사람이 코드를 보게 해서 보안 관행이 느슨해지지 않도록 해야 함
    이런 특권을 허용하면 경계선에 있는 다른 슈퍼스타들도 같은 권한을 원할 것임
    과학 출판에서도 편집장이라 해도 자기 논문은 다른 사람이 심사하고, 의사결정 과정은 본인이 보지 못하는 곳에서 진행됨. 그게 과학에 좋음
  • 이건 현재처럼 전적으로 기술적이어야 하는 심사 절차와 달리, 평판에 더 큰 비중을 두자는 제안처럼 들림
    좋은 아이디어일 수도 있지만, Mozilla가 평판을 일관되게 평가하지 않는다는 새로운 불만을 받을 수 있음
    https://wiki.mozilla.org/Add-ons/Reviewers/Guide/Reviewing
  • 큰 부탁일 수 있지만, 왜 FF에 자기 루트 인증서를 추가하고 직접 부가 기능에 서명할 수 없게 했는지 알아봐 줄 수 있을까
    대신 ESR/Developer/Nightly 버전을 쓰고 xpinstall.signatures.required를 false로 설정해야 해서 보안이 크게 낮아짐
  • 그가 조금 가라앉을 것 같음. 수천 시간을 쏟은 걸 무지한 사람이 내려버리면 답답할 테니 그의 행동을 전혀 탓하지 않음
    일주일 안에는 돌아올 것 같고, Firefox에서 일반 uBlock Origin보다 배터리를 아낄 수 있어서 중요함

• 타임라인을 제대로 이해했다면 gorhill이 과하게 반응한 듯함. 지난 5년 넘게 Mozilla가 한 거의 모든 일에 보통 혹독하게 비판적인 입장에서도 그렇게 봄
  Mozilla가 모든 부가 기능 개정판을 수동으로 안전하게 제때 심사하는 건 현실적으로 어렵고, 결국 자동화와 긴 지연 사이에서 골라야 했을 것임. 자동화에는 거짓 양성이 필연적으로 생김
  대안은 무엇일까. 출시 전 심사를 아예 없애는 것일까. 사용자로서는 그러지 않길 바람. 실제로 화려한 공급망 공격이 야생에서 실행된다는 확인까지 있는 상황임
  심사 정책은 gorhill 자신도 보호함. 스파이웨어를 넣으라고 협박해도 출시 전에 잡힐 가능성이 있으면, 그를 물리적으로 협박할 표적으로 삼을 매력이 조금 줄어듦

  • Firefox의 가장 인기 있는 확장 게시자 중 한 명에게는 더 높은 단계의 심사 서비스를 기대하는 게 합리적임
    Gorhill과 다른 상위 확장 개발자들은 Firefox에 실제 가치를 제공하고, 수년간 좋은 행동을 보여줬음
    마음대로 게시해도 된다는 뜻은 아니지만, 심사자가 유명 플러그인을 거절하려 한다면 두 번째 사람이 봐야 함. 이번 실수도 당연히 잡혔을 것임
    “Firefox가 개발자 관계에 투자를 덜 한다”는 또 다른 사례처럼 느껴짐. 그들에게 크게 의존한다는 점을 생각하면 놀라움
    uBlock Origin Lite가 840만 사용자를 가진다면, gorhill에게 Mozilla 전담 담당자가 없다는 건 이해하기 어려움. 확장에 문제가 있으면 전화로 알려야 할 수준임
  • 부가 기능이 표시된 것 자체는 놀랍지 않음. GitHub 이슈에 링크된 파일명들이 모두 알려진 추적기와 직접 관련 있어 보이게 되어 있었고, 물론 uBOL은 그걸 차단하는 것임
    Mozilla가 쓰는 자동 스캔 도구가 “이건 Google Tag Manager다”라고 잡고, 수상한 스크립트를 포함한 부가 기능에 보통 보내는 경고를 냈을 가능성이 큼
    다만 이메일에는 “Mozilla Add-ons 팀이 수동으로 검토했다”고 분명히 적혀 있음
    그게 거짓말이거나, 수동 심사자가 자신이 돌린 자동 도구에 거짓 양성이 있을 수 있다는 걸 이해하지 못한 것임
    Mozilla 같은 플랫폼에서 자동 악용 탐지를 하는 건 문제 없지만, 커뮤니케이션에서 거짓말을 하지는 말아야 함. 아니면 부가 기능 차단을 다룰 때 뭘 하는지 아는 사람을 고용해야 함
  • 적어도 덜 엉망인 심사 시스템은 가능해야 하지 않을까
    자체 호스팅 확장이어도 제출 시 심사를 통과하지 못해 임의의 시간을 기다려야 하고, 필터링 규칙이 확장에 패키징되는 상황에서는 시간이 중요함. 승인 알림을 받으면 다시 확장 파일을 수동 다운로드하고 이름을 바꾼 뒤 GitHub에 올리고, update_url을 새 버전으로 수동 패치해야 한다고 함
    2024.9.12.1004를 제출한 뒤 자체 호스팅 승인을 받기까지 5일이 걸렸고, 작성 시점에는 2024.9.22.986도 아직 승인되지 않았음
    취미로 하기엔 전혀 즐거울 것 같지 않음
    https://github.com/uBlockOrigin/uBOL-home/issues/197
  • 심사 절차의 절충점에 대한 말에는 동의하지만, Raymond Hill이 과하게 반응했다는 데는 강하게 동의하지 않음
    그는 uBlock을 취미로 하는 개인 개발자이고 기부도 받지 않으니 우리에게 빚진 게 없음
    심사 절차가 자신의 시간과 에너지를 쏟을 만큼 매끄러운지 판단할 권리가 있고, 이번엔 아니라고 결정했을 뿐임
    확장을 오픈소스로 만들었으니 누구든 대신 uBlock Origin Lite를 게시할 수 있음
  • 작성자가 과하게 반응한 것 같지는 않고, 첫 문단이 타임라인과 맞지 않는 듯함. 기사에서 제대로 전달하지 못했을 수도 있으니 GitHub 이슈를 보는 편이 나음
    https://github.com/uBlockOrigin/uBOL-home/issues/197
    이건 자동 심사가 아니라 부실한 수동 심사였음
    작성자는 AMO 심사 절차에 어떤 일이 들어가는지도 추가로 설명하면서, 그 스트레스를 감당하고 싶지 않다고 함. 또 다소 해로운 버전의 플러그인이 남아 있다는 점도 말함
    스트레스를 감당하기 싫다는 건 완전히 이해할 수 있는 반응임

• 일반 사용자에게 배포하려면 문지기에게 확장을 제출해야 한다는 게 매우 짜증남
  gorhill이 GitHub에서 말했듯 자체 호스팅 버전 승인에도 며칠이 걸렸는데, 이건 받아들일 수 없음
  소프트웨어를 배포하려면 Microsoft 승인을 받아야 한다고 상상해 보라. Android도 이렇게 닫혀 있진 않음
  서명 강제와 XUL 제거는 Mozilla가 한 최악의 일임. Google도 똑같고 더 나쁘지만, 그건 Google에게나 예상되는 일이지 Mozilla에게 기대한 일은 아님

  • XUL은 사라져야 했음. 다른 문제들은 사실 직접 관련이 크지 않았고, “어차피 대부분의 확장을 깨뜨릴 거면 이때 우리가 원하는 다른 것도 밀어붙이자”에 가까웠음. 오히려 XUL이 희생양임
    XUL 제거 후 한동안 VimFx를 유지했기 때문에 알고 있음. 바뀌는 내부 API를 따라가는 건 어려웠지만, 제품을 개발해야 하니 그들을 탓할 수는 없었음
    VimFx 유지보수를 포기하게 만든 진짜 이유는 서명 강제였음. “내 코드”조차 합리적인 사용자 경험으로 실행할 수 없게 계속 나사를 조였음
    원했던 방향은 WebExtensions를 호환성과 폐기 보장을 가진 권장 방식으로 제공하고, 다른 API의 호환성은 신경 쓰지 않으며, 내부 API를 쓰는 외부 “전체 접근” 확장은 계속 허용하는 것이었음
    스토어에서 “이 확장은 지원되지 않는 API를 사용하므로 언제든 깨질 수 있고 모든 개인정보를 훔칠 수 있다”고 경고하고 설치 버튼을 새빨갛게 만들어도 허용은 해야 했음
    개발자가 관리하는 서명 키와 업데이트 URL을 쓰는 자체 배포 확장도 계속 지원했어야 함
    이런 API에는 호환성 보장이 없으니 추가 작업도 많지 않았을 것임. 무서운 경고를 추가하는 약간의 UI 작업과 스토어 외 업데이트 코드 유지 정도였음
  • “Microsoft 승인이 있어야 소프트웨어를 배포할 수 있다”는 게 MacOS/iOS에서 소프트웨어 배포하려면 허가가 필요한 것과 같은 뜻인가
    점점 더 많은 플랫폼이 이 방향으로 가고 있고, Windows도 앞으로 그렇게 되더라도 놀라지 않을 것임
  • Firefox에서는 확장 스토어를 거치지 않고도 쉽게 확장을 설치할 수 있음. XUL은 없어져야 했음
  • 데스크톱 Firefox에서는 어디서든 확장을 내려받아 설치할 수 있음. 그들이 문지기 역할을 하는 건 자기 저장소뿐이고, 대부분은 그렇게 하길 원할 것임
    모바일은 Mozilla 저장소 밖에서 확장을 설치하려면 Nightly 빌드가 필요한 듯하고, 이는 그들의 사고가 나머지 모바일 생태계에 오염되고 있음을 시사함

• 부가 기능을 스토어에서 내리는 식의 극단적 조치를 하기 전에, Mozilla가 심사에 질문이나 우려가 있으면 먼저 연락해야 함

  • 앱, 확장, 비슷한 사용자 생성물을 지키는 모든 회사가 너무 빨리 과잉 반응하는 것 같음
    유명 인물이거나 팔로워가 많거나 앱·확장이 아주 인기 있지 않으면, 제때 해결되기를 기대하기 어렵다

• Gorhill의 완전한 uBlock Origin이 Firefox에 남은 거의 유일한 판매 포인트일 수 있음
  Mozilla 최고 경영진이 최근 가져간 터무니없는 액수의 돈이면, 대신 일류 인력으로 팀 하나를 꾸려 Mr. Gorhill이 필요로 하는 모든 일을 전담하게 할 수 있었음

  • 그들은 Mr. Gorhill이 차단하는 광고 회사들을 위해 일하느라 너무 바쁨
    가장 최근에는 어떤 사용자도 요청하지 않은 privacy preserving attribution 기능을 추가했음

• 이 확장이 왜 AMO에 존재하는지 모르겠음. 기사에 따르면 “Lite/Manifest v3 버전”이라는데, Firefox용으로 광고를 제대로 막는 버전 대신 구형 브라우저용 열등판을 왜 설치하겠음

  • Google이 부가 기능 매니페스트를 제한한 몇 안 되는 좋은 이유는 성능과 보안임
    선언형 도메인 목록은 캐시하기 쉽고 불필요한 확장 활성화를 줄임. 권한이 적으면 향후 악성코드에 감염된 버전이 스토어에 올라왔을 때 영향도 훨씬 작아짐
    uBlock의 규칙 엔진은 매우 강력해서 사용자 지정 규칙 세트가 어떤 웹사이트에도 코드를 주입할 수 있을 정도임. 이건 사용자 지정 규칙뿐 아니라, 계정이나 호스팅이 해킹되거나 나중에 매각될 수 있는 내장 규칙에도 적용됨
    물론 내가 Lite 버전을 쓰겠다는 뜻도 아니고 Google의 선택에 동의한다는 뜻도 아님. 그들은 대체 API를 제공하지 않고 광고 차단 API를 죽였으니까
    어차피 코드가 나와 있고 Google Chrome을 계속 쓰는 사람들도 있으니, Firefox에서도 이 버전을 제공할 수는 있음
  • 전력 사용량이 더 낮고, Android용 Firefox에서는 그게 중요함
  • UBO와 달리 훨씬 적은 권한으로 실행할 수 있음
  • 더 빠르고 보안상 함의도 적음. UBO가 더 강력하다는 건 인정하지만 보안상 발자국이 조금 덜 안전한 선택이고, 다른 사람들은 V3 쪽의 더 높은 보안을 택할 수 있음
  • 내 컴퓨터임. 내가 돈 내고 샀고 내가 관리함. 원하는 대로 할 것임
    더 좋은 질문은, Firefox가 내가 원하는 걸 거부한다면 왜 Firefox를 쓰느냐는 것임

• 이건 꽤 가혹해 보임. Mozilla가 실수했고, 사과했고, 실수를 고쳤고 어쩌면 절차도 개선했는데, 작성자는 그래도 확장을 내려버리고 Mozilla를 비판함
  내 생각엔 작성자가 이를 너무 개인적으로 받아들였거나, 심사 절차 개선을 원해서 강한 메시지를 던진 것임. 그 과정에서 프로젝트 가시성은 좀 손해를 봤음

  • 애초에 uBlock Origin이 왜 생겼는지 떠올려야 함. Raymond Hill은 uBlock 주변의 온갖 관리 잡무에 질렸고, 취미였던 일이 일처럼 느껴지기 시작했음
    https://github.com/gorhill/uBlock/issues/38#issuecomment-918...
    그래서 Mozilla 심사 절차에도 질려 그만두겠다고 하는 건 예측 가능한 일임
    그때 프로젝트를 양심 없는 임의의 사람에게 넘겼고, 그 사람은 곧바로 수익화하려 했으며, Raymond는 그 결과를 싫어해 자기 이전 프로젝트를 비판해야 했고 결국 중간에 많은 추가 작업만 거친 채 거의 출발점으로 돌아왔음
  • 작성자는 자원봉사자이고 이 소프트웨어는 애정으로 만든 결과물이니 당연히 개인적임
    이런 프로젝트는 작성자가 공동체에 가치 있는 선물을 주고 있고, 공동체가 그것을 받아들이고 감사한다고 느낄 때 잘 굴러감
    자기 창작물을 무감정한 “심사” 절차에 제출해야 하고, 아무도 제대로 보지 않았다는 게 분명한 방식으로 거절당하면 단순한 의욕 저하가 아니라 모욕임
    나라도 떠났을 것임
  • Mozilla가 템플릿 이메일을 보냈을 뿐인데, 그 이상 뭔가 한 것처럼 말하고 있음
    작성자에게 사전 양방향 커뮤니케이션 없이 부가 기능이 다시 제거되지 않으리라는 보장조차 하지 않았음
    Mozilla에는 보도자료 페이지가 있으니 무엇이 잘못됐고 앞으로 어떻게 바꿀지 공개적으로 명확히 낼 수 있었음. 이 확장이 훌륭하다고 인정하고 사용자에게 제공되도록 자금을 기여할 수도 있었음
    하지만 대신 심사자가 크게 망친 뒤 체면을 살리기 위해 가능한 최소한만 했음. 첫 심사에서 든 근거들은 명백히 틀렸고, 초급 JS 개발자도 알 수 있는 수준임
    심지어 AI 심사자가 더 잘했을 것임. ChatGPT 4o mini는 이 파일이 난독화 코드로 보이지 않고, 공백·줄바꿈·주석이 제거된 압축 형태가 아니며, 주석·들여쓰기·구조화된 함수가 있어 난독화 코드의 특징이 아니라고 판단했음
  • “작성자가 너무 개인적으로 받아들였다”라니, 성가신 무급 개발자들이 자기 개인 프로젝트에 감정을 섞다니 참 문제임
    Firefox “스토어”를 운영하는 사람들처럼 차갑고 무감정할 수는 없는 걸까
  • gorhill이 “부유한 대형 조직에 무한한 두 번째 기회 주기” 게임을 하고 싶어 하지 않는다고 탓할 수 없음
    그의 입장이라면 다르게 행동했을 것 같아도, 어느 순간은 충분함
    그리고 Mozilla는 사과하지 않았음. 사과 경찰 노릇을 하려는 건 아니지만, 그건 “apologize”라는 단어가 들어간 형식적인 고객지원식 문장일 뿐임
    그 정도면 됐고 누구도 더 기대하지는 않지만, 그게 무엇인지 그대로 인정할 수는 있음

• 정당한 대응임. uBO는 킬러 확장인데, Mozilla는 Google식의 끔찍한 기계 주도 확장 심사 절차를 고집하려면 적어도 현존하는 가장 중요한 확장 중 하나에는 예외를 둬야 한다는 생각을 못 한 듯함
  Mozilla가 “실수를 깨달았다”고 해도, gorhill이 이 일 전체에 완전히 분노해서 협조를 거부하는 건 이해됨
  그들의 실수는 그가 많은 확장·오픈소스 개발자들처럼 적은 감사와 늘어나는 요구를 대가로 잡무를 견딜 거라고 가정한 데 있음
  결과는 전혀 이상적이지 않지만, 안타깝게도 책임은 전적으로 Mozilla에 있음

  • 이건 uBOL에 관한 일임. 메인 확장에서 큰 지연은 별로 못 봤음
    메인 확장은 Chrome/Edge보다 Firefox에서 항상 더 최신임
  • uBO가 킬러 확장이라는 말을 보니, Google의 최종 목표가 Mozilla를 급여 명단에 유지하고 제품 혁신 동기를 낮춘 뒤 Firefox 사용자가 서서히 빠져나가 아무도 쓰지 않게 만들고 Chrome의 위치를 굳히는 것인지 궁금해짐
    그렇게 광고 차단기를 처리하는 셈임. 이미 Chromium에 광범위한 통제력을 갖고 있으니, 남는 실질적 대안은 공격하기 훨씬 어려운 Safari뿐임
    Google이 Firefox의 광고 차단 확장을 막을 수는 없지만, Firefox를 사실상 방치 소프트웨어처럼 운영하도록 Mozilla를 부추겨 죽게 만들 수는 있음
    Mozilla Foundation이 자기 위치를 이렇게 심하게 망친 건 부끄럽고, 이 행동들을 단순한 무능으로만 돌리기 어려움
  • uBlock Origin은 오늘날 Firefox가 의미 있는 브라우저 시장 점유율을 조금이라도 갖는 주된 이유일 가능성이 큼
    Firefox가 이를 지원하지 않았다면 다른 브라우저를 쓰고 있었을 것임. Mozilla가 제대로 하는 일이 계속 줄어드는 상황이라면 gorhill에게 극진해야 함

• Raymond Hill이 uBlock Origin, 즉 Manifest v2 버전에는 같은 조치를 하지 않길 정말 바람
  다른 사람에게 자체 호스팅 확장 설치를 권하기는 그리 편하지 않음
  Mozilla와 Raymond Hill이 이 문제를 함께 해결할 수 없거나 해결하지 않는다는 게 아쉬움. 이런 확장에서 그런 심사를 받으면 안 됐다는 건 이해하고, 그가 더 이상 신경 쓰기 싫다는 것도 이해하지만, 이 상황이 uBlock Origin 프로젝트의 장기 안정성에 어떤 영향을 줄지 걱정됨
  전체 상황이 확실히 건강하지 않아 보임
  https://github.com/uBlockOrigin/uBOL-home/issues/197#issueco...

  • UBO는 모든 브라우저를 합치면 Firefox 전체 사용자보다 사용자가 더 많아도 놀랍지 않고, 적어도 한 자릿수 배수 범위 안에는 있을 것 같음
    사소한 플랫폼 하나가 고집을 부린다고 프로젝트가 위험하다는 식으로 암시하는 건 터무니없음
  • 링크의 최신 업데이트에 따르면 Mozilla 심사팀이 오류를 인정하고 바로잡았음. 계속 존재할 수 있기를 바람
  • uBlock Origin 1.60은 아직 Mozilla 심사에 묶여 있음
    나온 지 약 일주일이 됐는데도 Firefox 부가 기능 사이트에서 받을 수 있는 최신 버전은 1.59임