▲

iOS가 일본에서 대체 브라우저 엔진을 허용 시작

 (developer.apple.com)
7P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • iOS 26.2 이상에서 일본 사용자용 앱은 WebKit 이외의 브라우저 엔진을 사용할 수 있으며, 전체 브라우저 앱과 임베디드 브라우저 엔진을 사용하는 앱 두 종류가 허용됨
  • Apple은 승인된 개발자에게 JIT 컴파일, 멀티프로세스 지원 등 고성능 브라우저 엔진 구현을 위한 시스템 기술 접근 권한을 제공함
  • 보안 위험을 이유로, Apple은 엄격한 보안·프라이버시 요건을 충족하고 지속적인 보안 업데이트를 약속한 개발자에게만 권한을 부여함
  • 브라우저 앱과 인앱 브라우징 앱 모두 테스트 통과율, 메모리 안전성, 취약점 대응, 쿠키 차단 정책 등 세부 기준을 충족해야 함
  • 이번 조치는 일본 시장에서 브라우저 엔진 선택의 폭을 확대하면서도 사용자 보안을 유지하려는 정책 변화로 평가됨

iOS 26.2에서의 대체 브라우저 엔진 허용 개요

  • iOS 26.2 이상 버전에서 일본 내 사용자용으로 WebKit 외의 브라우저 엔진 사용이 허용됨
    • 허용 대상은 두 가지 유형의 앱:
      1. 전용 브라우저 앱(전체 웹 브라우징 경험 제공)
      2. 브라우저 엔진 관리자가 제공하는 인앱 브라우징 앱(임베디드 엔진 사용)
  • Apple은 승인된 개발자에게 JIT 컴파일, 멀티프로세스 지원 등 핵심 시스템 기술 접근 권한을 부여함
  • 브라우저 엔진은 악성 콘텐츠와 민감한 사용자 데이터에 노출되므로, Apple은 특정 기준을 충족하고 지속적 보안 요건을 이행하는 개발자만 승인함

Web Browser Engine Entitlement (전용 브라우저 앱용)

  • 이 권한을 통해 대체 브라우저 엔진을 사용하는 브라우저 앱을 개발 가능
    • 신청 전 요건 검토 후 Apple에 요청 제출 필요
    • 기술 참고 자료로 BrowserEngineKit, BrowserEngineCore, 기본 브라우저 설정 가이드 제공

자격 요건

  • 앱은 일본 내 iOS 전용 배포여야 하며, 시스템 제공 엔진을 사용하는 다른 앱과 별도 바이너리로 구성
  • Default Browser Entitlement를 보유해야 함
  • 기능 요건:
    • Web Platform Tests 90% 이상, Test262 80% 이상 통과
    • JIT 비활성화 상태(예: Lockdown Mode)에서도 동일 기준 충족

보안 요건

  • 보안 개발 프로세스 채택 및 공급망 취약점 모니터링
  • 취약점 공개 정책 URL 제공 및 제3자 보고 채널 확보
  • 30일 내 취약점 완화 조치 등 신속 대응 의무
  • 해결된 취약점 공개 페이지 운영
  • 루트 인증서 정책 공개 및 CA/Browser Forum 참여
  • TLS 최신 프로토콜 지원 필수

프로그램 보안 요건

  • 메모리 안전 언어 또는 안전 기능 사용
  • Pointer Authentication Codes(PAC) , Memory Integrity Enforcement(MIE) 등 최신 완화 기술 적용
  • 프로세스 분리 및 IPC 검증, 취약점 우선 해결
  • 보안 업데이트 중단된 라이브러리 사용 금지

프라이버시 요건

  • 서드파티 쿠키 기본 차단, 사용자 동의 시만 허용
  • 사이트별 스토리지 분리 및 교차 사이트 접근 차단
  • 앱 간 상태 동기화 금지, 명시적 사용자 허가 시만 허용
  • 기기 식별자 공유 금지, App Privacy Report 라벨링 필수
  • PII 접근 API는 사용자 활성화 및 동의 필요

Embedded Browser Engine Entitlement (인앱 브라우징용)

  • 앱 내에서 대체 브라우저 엔진을 임베드해 웹 콘텐츠 표시 가능
    • 인앱 브라우징은 웹 브라우저에서 접근 가능한 콘텐츠 표시 목적에 한정
    • UI는 화면 대부분을 차지, 기본 브라우저로 열기 버튼, 도메인/URL 표시 필요

자격 요건

  • 신청자는 브라우저 엔진 관리 주체(browser engine steward) 여야 함
    • 엔진의 운영·보안 대응 책임을 직접 지는 조직
    • 독립적 아키텍처와 Web API 지원을 가진 별도 엔진이어야 함

앱 요건

  • 일본 내 iOS 전용 배포, 기본 브라우저 권한 보유 금지
  • Web Platform Tests 90% , Test262 80% 이상 통과
  • JIT 비활성화 상태에서도 동일 기준 충족

보안 및 프로그램 요건

  • 보안 개발 프로세스, 취약점 공개 정책, 30일 내 대응, TLS 지원 등 전용 브라우저 앱과 동일
  • 메모리 안전 언어 사용, 최신 보안 완화 기술 적용, 취약점 우선 해결 의무
  • 보안 업데이트 중단된 라이브러리 사용 금지

프라이버시 요건

  • 서드파티 쿠키 차단, 사이트별 스토리지 분리, 기기 식별자 공유 금지
  • App Privacy Report 라벨링 및 PII 접근 시 사용자 동의 필요

추가 요건

  • 앱 제출 시 임베디드 엔진 이름과 버전 명시
  • 엔진 새 버전 공개 후 15일 이내 앱 업데이트 제출

개발자 참고 자료 및 보안 가이드

  • Secure SDLC: 위협 모델링, 코드 감사, 퍼징 테스트 등 보안 중심 개발 권장
  • Memory Safety: Swift의 기본 메모리 안전성, C/C++의 std::span, -fbounds-safety 옵션 등 활용
  • Vulnerability Management: CVE-ID 기반 공개 취약점 관리, 신속한 패치 배포 필요
  • Network Security: iOS SDK의 Network framework, SecTrust API 사용 권장
    • TLS 1.2, 1.3 지원 필수, 구버전 프로토콜 사용 시 사용자 경고 필요

관련 문서 및 계약서

  • Embedded Browser Engine Entitlement Addendum for Apps in Japan
  • Web Browser Engine Entitlement Addendum for Apps in Japan
▲
kimjoin2 4시간전  [-]

Wow 일본에서 시작된것도 신기하네요. 이런건 유럽이나 미국이 먼저가 될 줄 알았는대

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • 나는 Apple이 경쟁 브라우저를 막을 거라 생각하지 않지만, 그 일이 일어날 것은 알고 있음
    iPhone이 사실상 Chrome/Chromium 독점을 막는 마지막 보루라고 생각함
    Google이 Microsoft처럼 방치하진 않겠지만, 그만큼의 영향력을 가지게 될 것임
    대부분의 사이트가 Chrome에서만 제대로 작동하는 상황은 정말 원치 않음
    결국 Apple의 고집이, 의도치 않게라도, 이 흐름을 막고 있는 셈임

    • 규제 기관이 Apple의 독재적 통제를 전면적으로 제한하길 바람
      Chrome이 웹을 지배한다는 걱정은 과장이라 생각함. 새로운 API가 추가된다고 해서 모든 웹사이트가 그걸 쓰는 건 아님
      Firefox가 95% 점유율의 IE 시대에도 웹을 구했는데, 왜 지금은 Apple 하나에 의존해야 하는지 모르겠음
      이건 일종의 학습된 무기력 같음
    • Safari가 기본 앱으로 설정되어 있는 한, iOS에서 Chrome이 큰 위협이 될 거라 보지 않음
      게다가 모바일 웹 자체가 점점 앱 중심으로 축소되고 있음
      AI 검색이 웹 검색을 대체하려는 흐름도 있어서, 웹의 영향력은 더 줄어들 것 같음
    • 이미 그 배는 떠났음. Apple도 문제의 일부임
      예를 들어, FaceTime이 Firefox를 지원하지 않아 Edge를 썼는데, 결국 Google Meet으로 옮겨야 했음
    • 예전 IE가 새로운 기능을 추가하며 시장을 장악했을 때, 사람들은 오히려 좋아했음
      문제는 그들이 혁신을 멈췄을 때 시작됐음
      ActiveX, Flash, Silverlight 같은 기술들이 보안 문제를 일으키며 웹을 망쳤고, 결국 IE는 개발자와 사용자 모두에게 지옥이 됨
      지금의 Mobile Safari가 그 역할을 이어받았다고 생각함
      나는 PC와 Android에서는 Firefox를 쓰지만, 모바일에서는 Chromium 기반 브라우저가 더 나은 선택이라 봄
    • Safari가 너무 별로라서, iOS에서 진짜 Chrome 경험을 하고 싶음

  • 일본의 새로운 규정 중 “메모리 안전 언어 사용” 요구사항이 흥미로웠음
    그런데 Apple 자신은 이걸 충족할까? WebKit은 C++로 작성되어 있음
    “메모리 안전성을 개선하는 기능”이 구체적으로 뭘 의미하는지도 모호함

    • WebKit의 Safer C++ Guidelines 문서를 참고할 수 있음
    • 언젠가 Apple이 WebKit을 Swift 기반 엔진으로 교체하거나 점진적으로 전환할지도 궁금함

  • Apple이 아직 전 세계적으로 개방하지 않은 게 놀라움
    한 나라에서는 열고, 다른 나라에서는 막는 시스템을 유지하는 건 결국 혼란과 비용으로 이어질 것임

    • 하지만 Apple은 수익이 유지되는 한 계속 이런 방식을 고수할 것임
      다국적 기업에게 이런 복잡한 규제 대응은 일상적인 일임
    • 기술적으론 가능하지만, 지역별 규칙을 관리하고 직원과 고객을 교육하는 데 드는 정신적·운영적 비용이 클 것임
      브라우저 엔진 통제는 수익보다 통제력 유지의 문제로 보임
    • 하루빨리 Firefox와 uBlock Origin을 제대로 쓸 수 있길 바람
    • “FeatureToggles.swift”라니, 농담 같지만 Apple의 정책을 풍자하는 말 같음
    • Apple은 지시받는 걸 극도로 싫어함
      일본과의 협상은 EU보다 나았지만, 여전히 불만이 많음
      그래서 전 세계적으로 쉽게 굴복하지 않을 것임

  • Apple이 EU에서 만든 제3자 브라우저 엔진 허용 규칙을 일본에도 그대로 적용하는 듯함
    하지만 조건이 너무 까다로워서, 실제로 EU에서도 대체 엔진 브라우저가 출시된 적이 없음
    앱을 완전히 별도의 바이너리로 만들어야 해서, Chrome 같은 대형 브라우저는 전환이 어려움

    • 게다가 EU에서는 개발사가 EU 내에 있어야 함이라는 추가 제약도 있음

  • 일본과 EU의 법이 전 세계적 변화를 유도하길 바랐지만, 대기업들은 국가별 비효율을 감수할 여력이 있음

    • 하드웨어 측면에서는 USB-C처럼 통일이 이루어졌지만, 소프트웨어는 여전히 분리됨
      예를 들어, iPhone은 위치 기반으로 대체 앱스토어 접근을 제한함
      관련 기사 참고
    • 만약 법이 Apple의 트래킹 투명성 팝업 같은 기능을 제거하라고 한다면?
      이미 두 나라에서 Apple이 그 팝업으로 벌금을 맞았음
    • Apple의 많은 정책이 반경쟁적이지만, 브라우저 엔진 제한은 보안·배터리·표준화 목적이 더 크다고 생각함

  • “브라우저 엔진 관리자” 요건을 보면, 사실상 Google과 Mozilla만 자격이 있는 듯함
    Microsoft조차 Blink 기반이라 제외됨
    소규모 엔진들은 기본 기능 요건을 충족하기 어려워, 실질적으로 진입 불가능해 보임

  • 이젠 iOS에서 진짜 Firefox + uBlock Origin을 쓸 수 있을까 궁금함

    • Apple은 법의 문자적 준수만 할 뿐, 여전히 모든 수단으로 저항할 것임
      복잡한 요구사항, 제한된 API, 버그 방치 등으로 개발자들이 고생할 것임
      일본 시장만을 위해 완전한 엔진을 이식할 만큼의 법무·개발 리소스를 투자할 회사는 없을 듯함
    • Mozilla도 지역별 앱 유지 부담 때문에 참여하지 않을 가능성이 높음
      관련 기사
    • 그동안은 Safari용 uBlock Origin Lite를 쓰면 됨
      꽤 괜찮음
    • EU에서도 같은 규칙이 적용됐지만, 대체 엔진 브라우저는 등장하지 않았음
      지금은 Safari용 uBlock Origin Lite나 다른 광고 차단기를 쓸 수 있음
    • 참고로 iOS Safari는 이미 uBlock Origin Lite를 지원함
      Firefox도 자체 추적 차단 기능이 있음

  • Apple이 생태계를 열면 소비자 친화적 이미지가 사라질까 두려워하는 사람들을 자주 봄
    하지만 “Apple이 통제하지 않으면 혼란이 온다”는 논리는 양극단의 선택지일 뿐임
    우리는 Apple의 완전 통제와, 사용자 방임 사이의 중간 지점이 필요함
    시장이 경쟁적으로 작동하지 않는다면, 규제가 사용자와 개발자를 보호해야 함
    Apple이 하드웨어를 잠그는 건 위험한 선례이며, 다른 기업들이 이를 따라할까 우려됨

    • Apple은 iOS의 혁신 속도와 방향을 직접 통제함
      새로운 기능이나 앱은 Apple이 허락하지 않으면 존재할 수 없음
      Dropbox, GDrive 같은 서비스도 Apple의 버그 많은 백엔드에 맞추느라 기능을 잃었음
      이런 구조는 비정상적임
    • 대안은 결국 Android밖에 없는 걸까?

  • Apple의 별도 바이너리 요구는 사실상 법 위반 수준임
    로그인 상태 공유 금지, 쿠키 차단 강제 등은 OS가 할 일이 아님
    심지어 Apple 자신은 30일 내 보안 패치 규정을 지키지 않음

  • Apple이 특정 국가에서만 예외를 두기 위해 극단적인 노력을 기울이는 게 놀라움

답변달기