플랫폼 기울기

 (mozilla.github.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Mozilla의 Platform Tilt는 주요 소프트웨어 플랫폼에서 Firefox가 자사 1차 브라우저보다 불리해지는 기술적 조건을 추적하고, 보안·안정성·성능·기능 측면의 경쟁 격차를 드러냄
  • Apple 관련 이슈는 제3자 브라우저 엔진 금지, iOS 다중 프로세스·JIT·접근성 API 제약, 기본 브라우저 설정, 확장·베타 배포, 홈 화면 웹앱 처리까지 가장 넓게 퍼져 있음
  • Google Android에서는 브라우저 데이터 가져오기 API 부재, Google 앱이 기본 브라우저 대신 Chrome을 여는 흐름, Firefox Android에 낮은 품질의 검색 결과 페이지가 제공된 사례가 핵심임
  • Microsoft Windows에서는 제3자 브라우저가 기본 브라우저를 프로그래밍 방식으로 설정하기 어렵고, Search·Copilot·Widgets 같은 흐름이 Edge를 우선함
  • 공통적으로 사용자의 기본 브라우저 선택, 브라우저 간 데이터 이동, 엔진 기능, 배포·테스트·확장 접근성이 플랫폼별 자사 브라우저에 유리하게 작동함

Platform Tilt가 추적하는 것

  • Platform Tilt는 주요 소프트웨어 플랫폼에서 Firefox가 1차 브라우저보다 불리해지는 기술적 사례를 추적하는 대시보드임
  • 대상은 보안, 안정성, 성능, 기능이며, 더 평평한 경쟁 환경을 만들기 위한 변경 사항을 제안함
  • 실시간 이슈 논의는 platform-tilt issue tracker에서 진행됨

Apple 플랫폼의 브라우저 엔진·iOS 기능 제약

  • App Store forbids third-party browser engines: Apple App Store Review Guidelines의 Rule 2.5.6은 웹 탐색 앱이 적절한 WebKit 프레임워크와 WebKit JavaScript를 사용해야 한다고 요구함
    • 이 정책 때문에 Firefox는 iOS에서 Gecko로 배포될 수 없음
    • macOS 같은 다른 Apple 플랫폼에서도 App Store를 통한 Firefox 배포에 영향을 줌
    • 웹 브라우저에 제3자 브라우저 엔진을 허용하도록 App Store 정책을 바꿔야 함
  • Support for third-party multi-process applications on iOS: 현대 웹 브라우저는 사이트별 프로세스와 GPU 같은 민감 기능의 전용 프로세스를 포함하는 다중 프로세스 아키텍처를 사용함
    • Safari는 iOS에서 다중 프로세스 구조를 쓰지만, Safari의 WebKit 엔진을 쓰지 않는 제3자 앱에는 같은 메커니즘이 제공되지 않음
    • iOS는 격리된 자식 프로세스를 만들고 효율적으로 통신하는 메커니즘을 제공해야 함
    • 요구 사항에는 사용자 탐색 동작에 따른 자식 프로세스 수와 수명, 제한된 권한 설정, 메시징과 공유 메모리, read/write 또는 read-only 공유 메모리 영역, 부모·자식 프로세스의 독립적 entitlement, 번들 내 라이브러리 로딩, Metal 또는 OpenGL을 통한 IOSurface 렌더링과 프로세스 간 공유가 포함됨
    • Firefox는 여러 운영체제에서 공유 코드베이스를 쓰므로, 프로세스 관리 인터페이스와 동작이 macOS·Android 같은 다른 플랫폼과 대체로 비슷해야 함
  • JIT Support on iOS: 성능 좋은 JavaScript/WebAssembly 엔진을 배포하려면 브라우저 프로세스가 쓰기 가능하면서 실행 가능한 메모리 영역을 만들 수 있어야 함
    • iOS 앱은 mmap(2) 시스템 호출로 이런 메모리 권한을 만들 수 없음
    • Safari의 WebKit 렌더링 엔진에는 예외가 있어 쓰기 가능·실행 가능 메모리 영역을 만들 수 있음
    • macOS에는 Hardened Runtime entitlement인 com.apple.security.cs.allow-jit에 해당하는 방식이 있으며, iOS도 비-WebKit 브라우저에 동등한 entitlement와 pthread_jit_write_protect_np, sys_icache_invalidate API 사용 권한을 제공해야 함
  • Accessibility APIs on iOS: iOS 접근성 API 문서는 불완전하며, 웹 브라우저가 접근성 웹 표준을 지원하는 데 필요한 API 다수가 문서화되어 있지 않음
    • WebKit에는 런타임에 로드되는 폐쇄 소스 시스템 번들이 있는 것으로 보이며, 이 때문에 사용 방식 추정도 어려움
    • “visited”, “radio button” 같은 trait 정수 상수와 “value changed” 같은 notification type 정수 상수 일부가 공개되어 있지 않음
    • WebKit이 사용하는 모든 접근성 API는 문서화되고 안정적이어야 하며, WebKit도 제3자 브라우저 엔진과 같은 방식으로 이를 사용하는 것이 이상적임

Apple 플랫폼의 사용자 경험·배포·확장 격차

  • Messages integration on iOS: iOS Safari 홈 페이지는 Messages 앱에서 최근 받은 링크와 보낸 연락처를 보여주지만, 제3자 브라우저는 Messages 데이터 접근 권한이 없어 같은 기능을 제공할 수 없음
  • Importing browser data on iOS: iOS에서 방문 기록, 북마크, 쿠키 같은 브라우징 정보는 제3자 브라우저가 접근할 수 없고 가져오기 API도 없음
    • 이 데이터는 민감하지만, 주요 데스크톱 플랫폼에서는 유사한 가져오기 기능이 가능함
    • iOS는 건강·피트니스 데이터처럼 사용자 동의로 민감 데이터 접근을 중재할 수 있음
    • 데이터 가져오기가 불가능하면 Safari에서 다른 브라우저로 전환할 때 마찰이 생김
  • Setting and checking default browser on iOS: iOS는 제3자 브라우저가 자신을 기본 브라우저로 설정해 달라고 시스템 프롬프트를 띄우는 기능을 제공하지 않음
    • Android는 browser role 요청을 통해, macOS는 LSSetDefaultHandlerForURLScheme와 LSSetDefaultRoleHandlerForContentType을 통해 유사 기능을 제공함
    • iOS 브라우저는 설정 UI로 deep link만 할 수 있고, 사용자가 설정 화면을 이해해 직접 변경해야 함
    • iOS 17.2.1에서 Settings 검색에 “Default browser app” 또는 “Default”를 입력해도 기본 브라우저 변경 결과가 나타나지 않는 사례가 있음
    • 제3자 브라우저는 현재 자신이 기본 브라우저인지 감지할 수도 없어, 사용자 의도를 바탕으로 브라우저를 최적화하거나 적절한 시점에 기본 브라우저 변경을 요청하기 어려움
  • Origin-Based Associated Domains dependent features for third-party browser engines on iOS: 비-WebKit 브라우저가 password autofill, one-time codes, passkeys, Apple Pay를 지원하려면 웹 콘텐츠 origin 기반의 associated domain을 지정할 수 있어야 함
    • WebKit 기반 브라우저는 브라우저 앱의 associated domain을 사용자가 탐색 중인 도메인으로 override할 수 있음
    • 예를 들어 example.com의 비밀번호 입력 필드에서 브라우저는 해당 필드가 example.com origin에 속한다고 표시해 비밀번호 관리자가 example.com 범위로 호출되게 해야 함
    • Apple Pay 지원에는 Safari처럼 등록된 Apple Pay 수취인에 대해 결제를 받을 수 있도록 추가 변경이 필요할 수 있음
  • Browser extension support on iOS: Safari는 iOS App Store로 배포되는 확장을 지원하지만, 제3자 브라우저는 App Store Review Guidelines 2.5.2 때문에 자체 확장 기능을 제공하기 어려움
    • 브라우저 확장은 웹 생태계의 핵심 요소이며, 개발자가 브라우저에 기능을 추가해 유틸리티·사용성·시스템 앱과의 상호운용성을 높일 수 있게 함
    • 제3자 브라우저가 자체 확장 카탈로그를 쓸 수 있도록 App Store 소프트웨어 요구 사항을 완화해야 함
  • Beta testing on iOS: iOS에서는 App Store에 베타 버전 앱을 배포할 수 없고 TestFlight를 사용해야 함
    • TestFlight는 10,000명 제한이 있어 대규모 브라우저의 베타 사용자 규모에 비해 작음
    • 제한에 도달하면 오래된 사용자를 수동으로 제거해야 해 유지보수 부담이 생김
    • 사용자는 TestFlight 앱 설치, access code 신청, 수신 대기, 코드 입력 절차를 거쳐야 함
    • Safari 새 버전은 iOS 운영체제 베타에 포함되어 같은 제한을 받지 않음
    • 해결책으로 브라우저의 App Store 사전 릴리스 빌드 배포 허용 또는 TestFlight 사용자 제한 제거와 공개 링크 무제한 배포가 제안됨
  • iOS and macOS "Search Web" features open links in Safari instead of the user’s default browser: iOS와 macOS의 Search Web 또는 Search with <Search Engine> 컨텍스트 메뉴, macOS 메뉴바의 Services 검색 진입점은 기본 브라우저와 무관하게 Safari에서 검색을 실행함
  • SFSafariViewController should respect the user’s default browser: SFSafariViewController는 iOS 앱이 웹 콘텐츠 렌더링을 사용자 브라우저에 맡기면서 앱 안에 임베드할 수 있게 하는 고수준 API임
    • 이 API는 사용자의 기본 브라우저와 무관하게 항상 Safari 버전을 사용함
    • 웹 콘텐츠 표시 경험이 일관되지 않고, 대체 브라우저에서 트래픽이 빠져나감
  • Browsers with alternative engines should be able to ship a single binary & bundle on iOS: Apple의 현재 제안은 자체 브라우저 엔진을 쓰려는 브라우저 벤더가 기존 앱을 업데이트하는 대신 EU에서 별도 앱을 배포하도록 요구함
    • 기존 EU 사용자는 새 앱으로 옮겨야 하며, 이는 실행 가능성이 낮고 경쟁 장벽을 만듦
    • Firefox의 우려 사례에는 WebKit Firefox에서 Gecko Firefox로의 발견·마이그레이션 어려움, Gecko Firefox EU 사용자가 EU 밖에서 30일 넘게 체류할 때 접근을 잃는 문제, EU로 영구 이전한 비EU WebKit Firefox 사용자가 업데이트되지 않는 “orphaned” 버전에 남는 문제가 포함됨
    • 브라우저 개발자는 완전히 별개인 두 앱을 개발·유지·배포해야 하며, 데이터 마이그레이션 복잡성, 사용자 이탈, 획득 감소, EU iOS 사용자를 위한 반복적 A/B 롤아웃 제한이 생김
    • 대안으로 전 세계 단일 바이너리와 번들에 두 엔진의 webview를 포함하고, OS가 시작 시 BrowserEngineKit eligibility를 앱에 알려주는 방식이 제안됨
  • Web developers should be able to test with alternative browser engines on iOS regardless of location: BrowserEngineKit은 처음 발표 때 EU 밖 기기에서 자체 엔진 테스트를 막는 위치 제한이 있었음
    • 이 제한은 18.2 beta에서 로컬 개발과 테스트에는 해제됐지만, 웹 개발자에게는 여전히 남아 있음
    • EU 밖 웹 개발자도 EU 사용자를 지원할 수 있으므로, 위치와 무관하게 대체 브라우저 엔진에서 사이트를 쉽게 테스트할 메커니즘이 필요함
  • Browsers with alternative engines should be able to install and manage home screen web apps on iOS: 대체 브라우저 엔진이 iOS 홈 화면에 웹앱을 추가할 수 있는 API는 있지만, 해당 앱은 Safari에서 열림
    • 설치 전후에 엔진별 기능, 사용자 상태, 선호가 달라져 경험이 분리됨
    • Apple은 보안을 이유로 비-WebKit 엔진의 홈 화면 웹앱 렌더링 허용에 반대했음
    • 홈 화면 웹앱의 기본 보안 요구 사항은 일반 웹 탐색에서 이미 적용되는 사이트 간 샌드박스와 격리 요구 사항과 같음
    • Android는 수년간 웹앱 렌더링을 제3자 브라우저 엔진에 위임해 왔으며, iOS에서도 이를 활성화해야 함

Google Android의 데이터 이동·기본 브라우저·검색 경험

  • Importing browser data on Android: Android에서 방문 기록, 북마크, 쿠키 같은 브라우징 정보는 제3자 브라우저가 접근할 수 없음
    • 데이터는 웹 브라우저 앱의 data directory에 보관되며, 제3자 브라우저가 직접 접근할 수 없음
    • 가져오기를 가능하게 하는 API나 ContentProvider도 없음
    • 데이터 가져오기 부재는 Chrome에서 다른 브라우저로 전환하는 데 큰 마찰을 만듦
  • Some Android features launch Chrome instead of the user’s default browser: 사전 설치된 Google application의 Google Search, Discover 같은 기능은 사용자의 기본 브라우저 선택을 무시하고 외부 웹사이트 링크를 항상 Chrome에서 엶
    • 홈 화면 검색창과 앱 런처 같은 내장 기능에서도 추가 진입점이 있음
    • 링크가 Chrome에서 열릴 때마다 사용자는 기본 브라우저에서 이탈함
    • 외부 링크를 여는 모든 내장 앱과 기능은 사용자의 기본 브라우저에서 열어야 함
  • Lower quality search result pages in third-party browser engines on Android: Android에서 웹 검색 경험은 여러 내장 기능과 밀접하게 통합되어 있으며, Firefox에는 Chrome보다 낮은 품질의 검색 결과 페이지가 제공된 사례가 있음
    • 동일한 검색어에서 Firefox Android는 Chrome보다 정보가 적고 디자인 품질이 낮은 페이지를 받았음
    • 이는 엄밀히는 Google Search 웹사이트 이슈지만, Android에서 검색의 중요성과 통합 수준 때문에 제3자 브라우저 선택을 꺼리게 하는 사용자 경험 격차로 이어짐
    • Firefox에서 해당 페이지가 동작하지 못하게 하는 기술적 제한은 없음
    • 이 이슈의 상태는 closed임

Microsoft Windows의 Edge 우선 흐름

  • Setting default browser on Windows: Windows는 제3자 브라우저가 자신을 기본 브라우저로 설정해 달라고 프로그래밍 방식으로 요청하는 기능을 제공하지 않음
    • 브라우저 설치 후에도 사용자는 운영체제 설정으로 이동해 직접 선택해야 하며, 이는 Edge 사용을 지속하게 하는 마찰과 관성을 만듦
    • Android와 macOS는 시스템 프롬프트나 관련 API를 통해 사용자가 쉽게 승인·거절할 수 있는 패턴을 제공함
    • Windows 10에서는 설정 UI에서 여러 번 클릭하고 이중 확인해야 하며, Windows 11에는 Set default 버튼이 있지만 충분하지 않음
  • Default browser is set to Edge by several Windows flows: Windows 10과 11은 Microsoft Edge가 Windows의 “recommended” 브라우저라는 메시지를 지속적으로 표시하고, 기본 브라우저를 Edge로 바꾸는 UI를 제공함
    • 일부 문구는 “recommended browser settings”를 적용하라고 묻는데, 기본 브라우저 변경을 명확히 드러내지 않음
    • 예시는 Windows 업데이트 등 자동으로 표시되는 UI 표면에서 추가·제거되며 계속 변함
    • Windows 구성 요소는 사용자의 기본 브라우저를 직접 바꿀 수 있지만, 제3자 브라우저는 ms-settings: 프로토콜 deep link를 사용해야 함
    • Windows도 제3자 브라우저에 제공되는 것과 같은 기능과 API를 사용해야 함
  • Some Windows features launch Edge instead of the user’s default browser: Windows의 최소 세 가지 주요 기능은 URL을 현재 기본 브라우저가 아니라 Microsoft Edge에서 엶
    • Windows Search 또는 Start Menu Search는 작업 표시줄 검색 상자·검색 버튼, 시작 메뉴 입력, WIN+S 단축키로 나타나며, 검색 결과와 기사 링크가 모두 Edge에서 열림
    • Windows Copilot은 Windows 11에서 화면 오른쪽에 도킹된 창으로 표시되며, 응답이나 렌더링 영역의 링크를 Edge에서 엶
    • Widgets는 Windows 10에서 “news and interests”로 불리며, 뉴스·날씨·주식·스포츠 점수 같은 정보를 보여주고 웹 페이지 링크를 Edge에서 엶

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Android와 Microsoft 모두 사용자가 선택한 브라우저가 아니라 자체 방식으로 여는 앱이 있다고 하는데, 더 큰 문제는 앱 안에서 링크를 누를 때 내장 웹뷰를 브라우저처럼 띄우는 것임
    그 안에서 하는 웹 활동을 앱이 감시할 수 있음. Android Play Store와 iOS App Store가 모든 제3자 웹사이트를 사용자의 브라우저로 열도록 강제했으면 함
    앱을 “웹 브라우저”와 “웹 브라우저 아님”으로 분류하고, “웹 브라우저 아님” 앱은 접근 가능한 도메인을 짧게 5~10개 정도만 등록하게 하며 나머지는 운영체제가 차단하는 식이 가능함
    Facebook, FB Messenger, Google Maps처럼 주 용도가 웹 탐색이 아닌 앱은 명확히 “웹 브라우저 아님”으로 볼 수 있음
    이렇게 하면 내장 웹뷰의 감시 문제를 막고, 브라우저 프로필에 동기화된 비밀번호·주소·북마크·방문 기록을 그대로 쓸 수 있음. 세상을 마음대로 정할 수 있다면 링크를 여는 앱에는 “비공개 브라우저 창에서 열기” 문맥 메뉴도 요구하고 싶음

    • 개인적으로는 같은 생각이지만, 최근 대부분의 사용자는 그렇지 않다는 걸 알게 됨. autotempest 앱을 출시하면서 여러 사이트의 차량 상세 페이지로 직접 연결되는 제3자 링크를 모두 사용자 기본 브라우저로 열게 했는데, 사용자들이 싫어했고 앱 안에서 열리기를 강하게 원했음
      그래서 앱 내부 열기를 기본값으로 바꾸되, 기본 브라우저를 쓰는 옵션은 남겨둠
    • 앱 내부 브라우저 문제를 해결하는 건 Open Web Advocacy의 최우선 과제 중 하나임. 다만 Digital Markets Act 범위 안에서 가능한 일이 무엇인지 때문에 복잡해짐
      정말 중요한 사안이라는 데 동의하며, 돕고 싶다면 Open Web Advocacy에 연락해 달라
    • Google은 오히려 Android 개발자를 정반대 방향으로 밀어붙이려고 Custom Tabs 기능을 만들었음
      앱이 관련 없는 페이지, 예를 들어 사용자가 제공한 링크를 열기만 해도 기본 브라우저 대신 “custom tab”으로 열도록 권장하며, 명시적 목적은 사용자가 앱을 떠나지 않게 해서 참여도를 지키는 것임
      당연히 사용자가 시스템 전체에서 끌 수 있는 설정은 없고, 앱마다 설정을 찾아야 하며 그나마 설정이 있기를 바라야 함
      https://android-developers.googleblog.com/2023/02/bringing-b...
    • 이미 어느 정도는 가능해서 “브라우저에서 열기”를 누를 수 있음. 다만 이게 Google의 이익에 맞는지는 모르겠음
      Android가 카메라 같은 런타임 권한을 추가한 지 주요 버전으로 9세대가 지났지만, 인터넷 접근은 아직도 권한을 요구하지 않음
    • 2~4번의 “웹뷰 문맥을 샌드박스화해서 실제 웹 탐색 활동이나 다른 앱의 웹뷰와 겹치지 않게 하는 것”은 1번의 “앱이 자체 웹뷰를 제어할 수 있어서 위험하다”와 충돌하는 것 아닌가 싶음
      “접근 가능한 도메인”이 실제로 뭘 뜻하는지도 애매함. 명시적으로 이동한 URL의 도메인만 검사하면 너무 느슨해서 우회가 쉽고, 모든 요청 URL을 검사하면 너무 엄격해서 많은 개발자가 자기 사이트도 제대로 못 불러올 수 있음

  • “App Store가 제3자 브라우저 엔진을 금지한다”는 점에 Mozilla가 문제 제기하는 건 정당하지만, 그 실타래를 당기고 싶은지는 모르겠음
    iOS 기기에서 Safari 독점이 있기 때문에 상당수 개발자가 비Chrome 지원을 신경 씀. 지금은 어쩔 수 없이 해야 함
    사용자에게 “깨진 기능은 Chrome에서는 안 깨져요”라는 메시지가 가기 시작하면 독점으로 가는 길이고, 그 뒤에는 Google이 새 웹 표준을 만들 때 합의가 별로 필요 없어짐
    현재 상태도 엉망이지만 더 나빠질 수도 있음. 이 예상이 틀렸으면 좋겠음

    • iOS에서 Apple이 강제한 Safari 독점에 도전하는 건 당연히 Mozilla의 이익에 맞음. Chrome도 iOS에서 억눌린다는 이유만으로 Firefox가 억눌리는 게 Firefox에 득이 되지는 않음
      Firefox가 Gecko와 Gecko 기반 WebExtensions, 특히 광고 차단기를 구현하지 못하게 하는 Apple 제한이 사라지면 iOS에서 Firefox 점유율은 오를 수밖에 없음
      그렇게 생긴 iOS Firefox 사용자들은 데스크톱 Firefox와 광고 차단이 되는 iOS Firefox를 동기화할 수 있게 되므로 데스크톱에서도 Firefox를 쓰도록 유도될 수 있음
    • 같은 말을 하러 왔음. iOS에서 Safari를 Chrome으로 대체할 수 없다는 점이 좋든 나쁘든 Chrome 완전 지배를 막는 유일한 장치임
    • iOS에서 자유 경쟁이 되면 많은 사람이 Chrome을 설치할 것이라고 봄. 특히 Apple 기기는 iPhone뿐인 PC 사용자 대부분이 그럴 듯함
    • 내 웹사이트를 Firefox에서 동작하게 만드는 이유는 Safari에서도 동작시켜야 해서가 아님
      Firefox는 보통 그냥 동작하고, 설령 아니더라도 항상 추가 작업이 필요한 방치된 플랫폼인 Safari 때문에 또 다른 기술 스택까지 더 신경 쓰고 싶어지지는 않음
    • Mozilla가 Apple을 문제 삼지 않으면, 다른 회사에 대한 불만도 Safari를 핑계로 무시될 수 있음. Apple의 행태에 대해 Mozilla가 맞는 말을 하고 있기 때문에, Google/Microsoft를 비판하면서 Apple을 빼면 위선적으로 보임
      현재 상태를 방어하는 논리에 지쳤음. 현상 유지는 좋은 방향으로 가고 있지 않고, 과감한 조치 없이는 바뀌지 않을 것임. Apple의 현상 유지를 옹호하는 쪽에서도 앞으로 어떻게 나아질지에 대한 계획은 없어 보임
      Safari만으로는 Chrome 지배를 막기에 충분하지 않고, EU의 앱스토어 규칙이 시행된 뒤에는 브라우저 엔진 개방이 강제될 가능성도 작지 않아 장기적으로 현상 유지 자체도 보장되지 않음
      지금은 기술 기업을 상대로 역사적으로 강한 반독점 집행 의지를 보인 미국 행정부가 끝나가는 시점임. Biden 행정부가 얼마나 반독점에 우호적인지 충분히 이해하지 못한 사람이 많음
      이 행정부가 4년 더 갈 수도 있고 아닐 수도 있지만, 그 불확실성을 고려하면 초기 Windows 반독점 사건 이후 Google/Apple/Microsoft에 실제 개입을 요구할 최고의 기회 중 하나임
      반독점에 열린 행정부, 빅테크에 대한 소비자 정서 변화, iOS를 둘러싼 Apple의 압박, 6월에 광고 차단기를 약화시키려는 Google 움직임이 겹친 지금은 현상 변경을 강하게 밀어붙이기 좋은 때임
      위험이 없지는 않지만, 더 기다린다고 상황이 좋아지지 않음. 기다릴수록 Firefox의 관련성은 줄고, 행정부가 바뀔 가능성은 커지며, Mozilla가 여론을 활용하기 어려워짐
      Mozilla가 이 주장을 100% 쉽게 이길 수 있는 순간은 오지 않으며, 지금 하지 않으면 결국 시장에서 완전히 밀려날 것임
      Apple을 포함해 모두에게 전력을 다해 문제 제기하는 것을 지지함. iOS 개방 뒤 Chrome 지배가 걱정된다면 그 문제는 Google을 규제해서 다뤄야 하고, 지금이 그 주장을 하기에 가장 좋은 때임

  • Android 사용자로서 Firefox를 안 쓰는 주된 이유는 반경쟁 행위가 아니라 느리게 느껴지기 때문임
    Firefox에서는 홈 페이지를 불러올 때 레이아웃이 흔들리는 일이 잦고, 키보드 애니메이션이 가끔 튀며, “놓아서 선택” 메뉴 옵션을 쓸 수 없음

    • 몇 년째 쓰고 있는데 그런 차이를 느낀 적은 없음
    • “놓아서 선택”이 뭔가?
    • Firefox에서는 외부 키보드의 기본 키보드 탐색 단축키도 전혀 동작하지 않음

  • https://github.com/mozilla/platform-tilt/issues/3
    iOS의 JIT 지원은 “EU가 iOS에서 제3자 렌더링 엔진을 강제할 것”이라는 논의에서 너무 덜 다뤄진 요소임
    Apple이 앱에 JIT 지원을 허용할까? 브라우저 개발자가 신청해야 하는 새 권한을 만들까? 흥미롭긴 한데, 그럴 것 같지는 않음

  • 관련 글: https://blog.mozilla.org/netpolicy/2024/01/19/platform-tilt/
    https://news.ycombinator.com/item?id=39059255에서 왔지만, 거기에는 댓글이 없음

  • macOS에서 선택 영역을 우클릭해 웹 검색을 선택하면, 기본 브라우저를 다른 것으로 지정해도 항상 Safari가 열림. 아마 Mail.app에서만 그럴 수도 있는데, 이 항목은 빠뜨린 것 같음

  • Android용 Firefox에서 가장 큰 불만은 가끔 주소창에 도메인을 입력하고 Enter를 눌러도 아무 일도 일어나지 않는 것임
    이 동작은 불규칙하고 https://forum.syncthing.net 같은 몇몇 웹사이트에만 영향을 줌
    탭을 닫거나 다른 탭을 써도 해결되지 않고, 앱을 강제 종료해야 고쳐짐

    • 데스크톱에서도 같은 문제가 있음. 주소창에 사실상 아무 변화도 없는 수정을 넣고 블로그 글에서 자랑했던 것 같은데, 그 과정에서 비동기 경쟁 상태를 만들었고 몇 년째 깨진 채로 둔 듯함
      불만은 있어도 Google 브라우저보다는 여전히 나음
    • 나도 겪음. 아주 짜증남. 가끔 무작위로 충돌도 나는데, 그건 최근 한 달쯤 전부터 시작됨

  • 대부분은 이해되지만, iOS의 Messages 통합 항목은 느낌이 좋지 않음
    사용자가 선택해야 하는 “최근 보낸 링크” API 정도라면 문제가 없겠지만, 메시지 데이터 전체 접근은 Mozilla가 개발자라 해도 제3자 앱에 절대 허용하고 싶지 않음
    iOS 확장 기능의 경우 Orion은 Chrome과 Firefox 확장 갤러리 양쪽에서 확장을 설치할 수 있으므로, 이게 실제 문제가 아니거나 App Review를 통과한 뒤 몇 년째 유지되고 있다는 뜻으로 보임

  • Google Colab에서 복사·붙여넣기는 Chrome에서는 제대로 동작하지만 Firefox에서는 그렇지 않음

  • “방문 기록, 북마크한 사이트, 쿠키 같은 탐색 정보가 Android의 제3자 브라우저에서 접근 불가능하다”는데, 사용자 입장에서 왜 제3자 애플리케이션이 내 브라우저의 방문 기록, 북마크, 쿠키에 접근하길 원하겠나?
    그건 명백한 프라이버시 유출임. Firefox는 내가 Firefox를 쓰는 동안 Firefox가 만든 데이터만 가져가면 되고, 다른 맥락의 데이터는 안 됨

    • 허락 없이 접근할 때만 유출임. 사용자가 “절대 안 돼”라고 답할 수 있는 상태에서 앱이 그 데이터 접근을 요청할 수 있는 것 자체는 문제가 없음
    • 새 브라우저로 쉽게 옮기고 싶은 사용자로서는, 새 브라우저가 이전 브라우저의 북마크 등 데이터에 접근해서 과정을 쉽게 해주길 바람
    • 주로 다른 브라우저와 가져오기/내보내기를 하기 위한 것임. 온보딩에서 매우 흔한 작업임
    • 방문 기록과 쿠키는 확실히 반대할 만하지만, 북마크 내보내기와 다시 가져오기는 필수임
      그런데 Android용 Firefox는 그것도 지원하지 않음 :facepalm:
      https://github.com/mozilla-mobile/fenix/issues/417
    • 이건 좀 불성실한 해석 같음. 연락처나 다른 민감한 데이터도 이미 “프라이버시 유출” 없이 가져올 수 있음
      해당 이슈에서도 검증되지 않은 가져오기 기능을 요구하는 게 아니라, Android가 사용자 동의로 다른 민감 데이터 접근을 중재할 수 있다고 말함
답변달기