iOS เริ่มอนุญาตเอนจินเบราว์เซอร์ทางเลือกในญี่ปุ่น

 (developer.apple.com)
8 คะแนน โดย GN⁺ 2026-01-02 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งแต่ iOS 26.2 เป็นต้นไป แอปสำหรับผู้ใช้ในญี่ปุ่นสามารถใช้ เอนจินเบราว์เซอร์ที่ไม่ใช่ WebKit ได้ โดยอนุญาตทั้งแอปเบราว์เซอร์เต็มรูปแบบและ แอปที่ใช้เอนจินเบราว์เซอร์แบบฝัง
  • Apple จะมอบสิทธิ์เข้าถึงเทคโนโลยีระบบสำหรับการสร้างเอนจินเบราว์เซอร์ประสิทธิภาพสูงให้แก่นักพัฒนาที่ได้รับอนุมัติ เช่น JIT compilation และการรองรับหลายโปรเซส
  • เนื่องจากมีความเสี่ยงด้านความปลอดภัย Apple จะมอบสิทธิ์นี้ให้เฉพาะนักพัฒนาที่ผ่าน ข้อกำหนดด้านความปลอดภัยและความเป็นส่วนตัวที่เข้มงวด และให้คำมั่นว่าจะอัปเดตความปลอดภัยอย่างต่อเนื่องเท่านั้น
  • ทั้งแอปเบราว์เซอร์และแอปท่องเว็บภายในแอปต้องผ่านเกณฑ์รายละเอียด เช่น อัตราการผ่านการทดสอบ, ความปลอดภัยของหน่วยความจำ, การรับมือช่องโหว่, นโยบายบล็อกคุกกี้
  • มาตรการครั้งนี้ถูกมองว่าเป็น การเปลี่ยนนโยบายเพื่อขยายทางเลือกของเอนจินเบราว์เซอร์ในตลาดญี่ปุ่น พร้อมคงความปลอดภัยของผู้ใช้ไว้

ภาพรวมการอนุญาตเอนจินเบราว์เซอร์ทางเลือกใน iOS 26.2

  • ใน iOS 26.2 ขึ้นไป อนุญาตให้ใช้เอนจินเบราว์เซอร์ที่ไม่ใช่ WebKit สำหรับผู้ใช้ในญี่ปุ่น
    • แอปที่ได้รับอนุญาตมี 2 ประเภท:
      1. แอปเบราว์เซอร์โดยเฉพาะ (มอบประสบการณ์ท่องเว็บแบบเต็มรูปแบบ)
      2. แอปท่องเว็บภายในแอปที่ผู้ดูแลเอนจินเบราว์เซอร์เป็นผู้จัดหา (ใช้เอนจินแบบฝัง)
  • Apple มอบสิทธิ์เข้าถึง เทคโนโลยีระบบหลัก เช่น JIT compilation และการรองรับหลายโปรเซส ให้แก่นักพัฒนาที่ได้รับอนุมัติ
  • เนื่องจากเอนจินเบราว์เซอร์อาจเผชิญกับเนื้อหาที่เป็นอันตรายและข้อมูลผู้ใช้ที่ละเอียดอ่อน Apple จึง อนุมัติเฉพาะนักพัฒนาที่ผ่านเกณฑ์ที่กำหนดและปฏิบัติตามข้อกำหนดด้านความปลอดภัยอย่างต่อเนื่องเท่านั้น

Web Browser Engine Entitlement (สำหรับแอปเบราว์เซอร์โดยเฉพาะ)

  • สิทธิ์นี้ช่วยให้สามารถพัฒนา แอปเบราว์เซอร์ที่ใช้เอนจินเบราว์เซอร์ทางเลือก ได้
    • ต้องตรวจสอบข้อกำหนดก่อนสมัครและยื่นคำขอต่อ Apple
    • มีเอกสารอ้างอิงทางเทคนิคให้ ได้แก่ BrowserEngineKit, BrowserEngineCore, คู่มือการตั้งค่าเบราว์เซอร์เริ่มต้น

คุณสมบัติที่ต้องมี

  • แอปต้องเป็น การแจกจ่ายสำหรับ iOS ในญี่ปุ่นเท่านั้น และจัดเป็น ไบนารีแยกต่างหาก จากแอปอื่นที่ใช้เอนจินที่ระบบจัดเตรียมไว้
  • ต้องมี Default Browser Entitlement
  • ข้อกำหนดด้านความสามารถ:
    • ผ่าน Web Platform Tests อย่างน้อย 90% และ Test262 อย่างน้อย 80%
    • ต้องผ่านเกณฑ์เดียวกันแม้ในสถานะปิดการใช้งาน JIT (เช่น Lockdown Mode)

ข้อกำหนดด้านความปลอดภัย

  • ต้องใช้ กระบวนการพัฒนาที่ปลอดภัย และติดตามช่องโหว่ในซัพพลายเชน
  • ต้องระบุ URL นโยบายการเปิดเผยช่องโหว่ และมีช่องทางรับรายงานจากบุคคลที่สาม
  • มีหน้าที่ต้อง บรรเทาช่องโหว่ภายใน 30 วัน และตอบสนองอย่างรวดเร็ว
  • ต้องมี หน้าเผยแพร่รายการช่องโหว่ที่แก้ไขแล้ว
  • ต้อง เผยแพร่นโยบาย root certificate และเข้าร่วม CA/Browser Forum
  • ต้องรองรับ โปรโตคอล TLS รุ่นล่าสุด

ข้อกำหนดด้านความปลอดภัยของโปรแกรม

  • ใช้ ภาษาแบบ memory-safe หรือฟังก์ชันด้านความปลอดภัย
  • ใช้เทคนิคบรรเทาความเสี่ยงสมัยใหม่ เช่น Pointer Authentication Codes(PAC) และ Memory Integrity Enforcement(MIE)
  • ต้องมี การแยกโปรเซสและการตรวจสอบ IPC และ แก้ช่องโหว่ตามลำดับความสำคัญ
  • ห้ามใช้ไลบรารีที่หยุดได้รับอัปเดตความปลอดภัยแล้ว

ข้อกำหนดด้านความเป็นส่วนตัว

  • บล็อกคุกกี้บุคคลที่สามโดยค่าเริ่มต้น และอนุญาตได้เมื่อผู้ใช้ยินยอมเท่านั้น
  • ต้องมี การแยกพื้นที่จัดเก็บตามแต่ละไซต์ และบล็อกการเข้าถึงข้ามไซต์
  • ห้ามซิงก์สถานะข้ามแอป ยกเว้นเมื่อผู้ใช้อนุญาตอย่างชัดเจน
  • ห้ามแชร์ตัวระบุอุปกรณ์ และต้องมี การติดป้าย App Privacy Report
  • API ที่เข้าถึง PII ต้องให้ผู้ใช้เป็นผู้เปิดใช้งานและยินยอมก่อน

Embedded Browser Engine Entitlement (สำหรับการท่องเว็บภายในแอป)

  • สามารถ ฝังเอนจินเบราว์เซอร์ทางเลือก ภายในแอปเพื่อแสดงเนื้อหาเว็บได้
    • การท่องเว็บภายในแอปจำกัดเฉพาะเพื่อการแสดงเนื้อหาที่เข้าถึงได้จากเว็บเบราว์เซอร์
    • UI ต้อง กินพื้นที่ส่วนใหญ่ของหน้าจอ และต้องมี ปุ่มเปิดด้วยเบราว์เซอร์เริ่มต้น และ การแสดงโดเมน/URL

คุณสมบัติที่ต้องมี

  • ผู้สมัครต้องเป็น browser engine steward
    • เป็นองค์กรที่รับผิดชอบโดยตรงต่อ การดำเนินงานและการตอบสนองด้านความปลอดภัย ของเอนจิน
    • ต้องเป็นเอนจินแยกต่างหากที่มี สถาปัตยกรรมอิสระและรองรับ Web API

ข้อกำหนดของแอป

  • แจกจ่ายสำหรับ iOS ในญี่ปุ่นเท่านั้น และ ห้ามมีสิทธิ์เบราว์เซอร์เริ่มต้น
  • ผ่าน Web Platform Tests 90% และ Test262 80% ขึ้นไป
  • ต้องผ่านเกณฑ์เดียวกันแม้ในสถานะปิดการใช้งาน JIT

ข้อกำหนดด้านความปลอดภัยและโปรแกรม

  • ใช้ กระบวนการพัฒนาที่ปลอดภัย, นโยบายการเปิดเผยช่องโหว่, การตอบสนองภายใน 30 วัน, การรองรับ TLS เช่นเดียวกับแอปเบราว์เซอร์โดยเฉพาะ
  • มีหน้าที่ใช้ ภาษาแบบ memory-safe, เทคนิคบรรเทาความเสี่ยงด้านความปลอดภัยสมัยใหม่, และ แก้ช่องโหว่ตามลำดับความสำคัญ
  • ห้ามใช้ไลบรารีที่หยุดได้รับอัปเดตความปลอดภัยแล้ว

ข้อกำหนดด้านความเป็นส่วนตัว

  • บล็อกคุกกี้บุคคลที่สาม, แยกพื้นที่จัดเก็บตามไซต์, และ ห้ามแชร์ตัวระบุอุปกรณ์
  • ต้องมี การติดป้าย App Privacy Report และ ขอความยินยอมจากผู้ใช้เมื่อเข้าถึง PII

ข้อกำหนดเพิ่มเติม

  • ตอนส่งแอปต้อง ระบุชื่อและเวอร์ชันของเอนจินแบบฝัง
  • หลังจากมีการเผยแพร่เอนจินเวอร์ชันใหม่ ต้อง ส่งอัปเดตแอปภายใน 15 วัน

เอกสารอ้างอิงสำหรับนักพัฒนาและแนวทางความปลอดภัย

  • Secure SDLC: แนะนำการพัฒนาที่เน้นความปลอดภัย เช่น threat modeling, การตรวจโค้ด, fuzzing test
  • Memory Safety: ใช้ความปลอดภัยของหน่วยความจำโดยค่าเริ่มต้นของ Swift รวมถึง std::span และออปชัน -fbounds-safety ของ C/C++
  • Vulnerability Management: ต้องจัดการช่องโหว่ที่เปิดเผยโดยอิงตาม CVE-ID และเผยแพร่แพตช์อย่างรวดเร็ว
  • Network Security: แนะนำให้ใช้ Network framework และ SecTrust API ของ iOS SDK
    • ต้องรองรับ TLS 1.2, 1.3 และหากใช้โปรโตคอลรุ่นเก่าต้องมีคำเตือนผู้ใช้

เอกสารและข้อตกลงที่เกี่ยวข้อง

  • Embedded Browser Engine Entitlement Addendum for Apps in Japan
  • Web Browser Engine Entitlement Addendum for Apps in Japan

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
wedding 2026-01-05

ไม่ได้ประชดนะ แต่ซาฟารีเองก็คงปฏิบัติตามข้อกำหนดมากมายพวกนั้นได้ดีอยู่แล้ว...ใช่ไหม?
 
kimjoin2 2026-01-03

ว้าว น่าทึ่งเหมือนกันที่เริ่มจากญี่ปุ่น ผมนึกว่าเรื่องแบบนี้ยุโรปหรืออเมริกาน่าจะมาก่อน
 
GN⁺ 2026-01-02
ความคิดเห็นจาก Hacker News

  • ฉันไม่คิดว่า Apple จะขวางเบราว์เซอร์คู่แข่ง แต่ก็รู้ว่า มันจะเกิดขึ้นแน่
    รู้สึกว่า iPhone คือปราการด่านสุดท้ายที่คอยกันการผูกขาดของ Chrome/Chromium โดยพฤตินัย
    Google คงไม่ปล่อยปละแบบ Microsoft แต่สุดท้ายก็คงมีอิทธิพลได้มากขนาดนั้น
    ไม่อยากเห็นโลกที่เว็บไซต์ส่วนใหญ่ใช้งานได้ดีแค่บน Chrome จริงๆ
    สุดท้ายความดื้อของ Apple ก็กลายเป็นตัวที่คอยขัดกระแสนี้ไว้ แม้จะไม่ได้ตั้งใจก็ตาม

    • อยากให้หน่วยงานกำกับดูแลจำกัด การควบคุมแบบเผด็จการ ของ Apple ให้หมดจด
      ฉันคิดว่าความกังวลเรื่อง Chrome ครองเว็บนั้นเกินจริงไปหน่อย การมี API ใหม่เพิ่มขึ้นไม่ได้แปลว่าทุกเว็บจะรีบใช้มันทั้งหมด
      Firefox ยังเคยกอบกู้เว็บได้ในยุคที่ IE มีส่วนแบ่ง 95% แล้วทำไมตอนนี้เราต้องพึ่ง Apple บริษัทเดียวด้วยก็ไม่รู้
      มันดูเหมือน ภาวะหมดหวังที่ถูกฝังจนเคยชิน มากกว่า
    • ตราบใดที่ Safari ยังเป็นแอปเริ่มต้น ฉันไม่คิดว่า Chrome จะเป็นภัยคุกคามใหญ่บน iOS
      แถมเว็บบนมือถือเองก็กำลัง หดตัวไปสู่โลกที่ยึดแอปเป็นศูนย์กลาง มากขึ้นเรื่อยๆ
      ยังมีแนวโน้มที่ AI search จะมาแทน web search อีก เลยยิ่งรู้สึกว่าอิทธิพลของเว็บจะลดลงไปอีก
    • เรือได้ออกจากท่าไปแล้ว Apple ก็เป็นส่วนหนึ่งของปัญหา
      อย่างเช่น FaceTime ไม่รองรับ Firefox ฉันเลยใช้ Edge แต่สุดท้ายก็ต้องย้ายไป Google Meet
    • ตอนก่อนหน้านี้ที่ IE ครองตลาดด้วยการเพิ่มฟีเจอร์ใหม่ คนกลับชอบมันด้วยซ้ำ
      ปัญหาเริ่มขึ้นตอนที่พวกเขา หยุดสร้างนวัตกรรม
      เทคโนโลยีอย่าง ActiveX, Flash, Silverlight สร้างปัญหาความปลอดภัยและทำเว็บพัง สุดท้าย IE ก็กลายเป็นนรกทั้งสำหรับนักพัฒนาและผู้ใช้
      ฉันคิดว่า Mobile Safari ทุกวันนี้กำลังรับบทนั้นต่อ
      บนพีซีและ Android ฉันใช้ Firefox แต่บนมือถือฉันมองว่า เบราว์เซอร์ที่ใช้ Chromium เป็นตัวเลือกที่ดีกว่า
    • Safari แย่มากจนอยากได้ ประสบการณ์ Chrome แบบจริงๆ บน iOS

  • ข้อกำหนด “การใช้ภาษาแบบ memory-safe” ในกฎใหม่ของญี่ปุ่นน่าสนใจดี
    แต่ Apple เองผ่านเงื่อนไขนี้หรือเปล่า? WebKit เขียนด้วย C++
    แล้วคำว่า “ฟีเจอร์ที่ช่วยเพิ่ม memory safety” จริงๆ หมายถึงอะไร ก็ยังคลุมเครืออยู่

    • ดูเอกสาร Safer C++ Guidelines ของ WebKit ได้
    • ก็สงสัยเหมือนกันว่าสักวัน Apple จะเปลี่ยน WebKit เป็น เอนจินที่ใช้ Swift หรือค่อยๆ ย้ายไปทางนั้นหรือเปล่า

  • น่าแปลกใจที่ Apple ยังไม่ยอมเปิดทั่วโลก
    การรักษาระบบที่เปิดในประเทศหนึ่งแต่ปิดอีกประเทศหนึ่ง สุดท้ายย่อมนำไปสู่ ความสับสนและต้นทุน

    • แต่ตราบใดที่ รายได้ยังไม่สะเทือน Apple ก็คงเดินแนวทางนี้ต่อไป
      สำหรับบริษัทข้ามชาติ การรับมือข้อกำหนดซับซ้อนแบบนี้เป็นเรื่องปกติอยู่แล้ว
    • ในเชิงเทคนิคมันทำได้ แต่ ต้นทุนทางจิตใจและต้นทุนการปฏิบัติการ ในการจัดการกฎรายภูมิภาค รวมถึงการสอนพนักงานและลูกค้า น่าจะสูงมาก
      การควบคุมเอนจินเบราว์เซอร์ดูเหมือนเป็นเรื่องของ การคงอำนาจควบคุม มากกว่ารายได้
    • หวังว่าจะได้ใช้ Firefox และ uBlock Origin แบบสมบูรณ์จริงๆ เร็วๆ นี้
    • คำว่า “FeatureToggles.swift” ฟังดูเหมือนมุก แต่ก็เหมือนคำเสียดสีนโยบายของ Apple ดี
    • Apple เกลียดการถูกสั่งอย่างมาก
      การเจรจากับญี่ปุ่นอาจดีกว่ากับ EU แต่ก็ยังไม่พอใจอยู่ดี
      เพราะงั้นคงไม่ยอมอ่อนข้อทั่วโลกง่ายๆ

  • ดูเหมือน Apple จะเอา กฎอนุญาตเอนจินเบราว์เซอร์ของบุคคลที่สาม ที่ทำไว้ใน EU มาใช้กับญี่ปุ่นตรงๆ
    แต่เงื่อนไขมันเข้มงวดเกินไป จนใน EU เองก็ยัง ไม่เคยมีเบราว์เซอร์เอนจินทางเลือกออกสู่ตลาดจริง
    แอปต้องทำเป็นไบนารีแยกทั้งหมด ทำให้เบราว์เซอร์ใหญ่ๆ อย่าง Chrome เปลี่ยนได้ยาก

    • แถมใน EU ยังมีข้อจำกัดเพิ่มว่า นักพัฒนาต้องอยู่ใน EU อีกด้วย

  • เคยหวังว่ากฎหมายของญี่ปุ่นและ EU จะผลักให้เกิดการเปลี่ยนแปลงระดับโลก แต่บริษัทใหญ่ๆ มี ศักยภาพพอจะรับความไร้ประสิทธิภาพรายประเทศ ได้

    • ฝั่งฮาร์ดแวร์มีการทำให้เป็นมาตรฐานเดียวกันแบบ USB-C แล้ว แต่ซอฟต์แวร์ยังแยกกันอยู่
      เช่น iPhone จำกัดการเข้าถึง alternative app store ตามตำแหน่งที่อยู่
      ดู บทความที่เกี่ยวข้อง ได้
    • ถ้ากฎหมายบังคับให้ Apple ต้องเอาฟีเจอร์อย่าง ป๊อปอัปความโปร่งใสการติดตาม ออกล่ะ?
      Apple โดนปรับจากป๊อปอัปนั้นมาแล้วในสองประเทศ
    • หลายนโยบายของ Apple มีลักษณะต่อต้านการแข่งขันก็จริง แต่ฉันคิดว่า ข้อจำกัดเรื่องเอนจินเบราว์เซอร์ มีเป้าหมายเรื่องความปลอดภัย แบตเตอรี่ และการทำมาตรฐานให้สอดคล้องกันมากกว่า

  • ดูจากข้อกำหนดเรื่อง “ผู้จัดการเอนจินเบราว์เซอร์” แล้ว เหมือนจริงๆ จะมีแค่ Google กับ Mozilla ที่มีคุณสมบัติ
    แม้แต่ Microsoft ก็ถูกตัดออกเพราะใช้ Blink
    เอนจินขนาดเล็กก็คงทำตามข้อกำหนดฟังก์ชันพื้นฐานไม่ไหว จึงดูเหมือน แทบเป็นไปไม่ได้ที่จะเข้ามาแข่ง

  • ตอนนี้จะได้ใช้ Firefox จริงๆ + uBlock Origin บน iOS แล้วหรือยังนะ

    • Apple คงทำแค่ ปฏิบัติตามตัวอักษรของกฎหมาย แต่จะยังขัดขืนทุกทางเหมือนเดิม
      ไม่ว่าจะเป็นข้อกำหนดซับซ้อน API ที่ถูกจำกัด หรือปล่อยบั๊กค้างไว้ จนนักพัฒนาต้องลำบาก
      ไม่น่ามีบริษัทไหนยอมทุ่ม ทรัพยากรด้านกฎหมายและการพัฒนา มากพอเพื่อพอร์ตเอนจินเต็มรูปแบบมาเพื่อแค่ตลาดญี่ปุ่น
    • Mozilla เองก็น่าจะไม่เข้าร่วม เพราะ ภาระในการดูแลแอปรายภูมิภาค
      บทความที่เกี่ยวข้อง
    • ระหว่างนี้ใช้ uBlock Origin Lite สำหรับ Safari ไปก่อนได้
      ใช้ได้ค่อนข้างดี
    • ใน EU ก็ใช้กฎเดียวกัน แต่ ยังไม่มีเบราว์เซอร์เอนจินทางเลือกเกิดขึ้น
      ตอนนี้ใช้ uBlock Origin Lite สำหรับ Safari หรือบล็อกโฆษณาตัวอื่นแทนได้
    • เพื่ออ้างอิงไว้ iOS Safari รองรับ uBlock Origin Lite อยู่แล้ว
      Firefox เองก็มีฟีเจอร์บล็อกตัวติดตามของตัวเอง

  • ฉันเห็นคนจำนวนมากกลัวว่าถ้า Apple เปิดระบบนิเวศ ภาพลักษณ์แบบ เป็นมิตรกับผู้บริโภค จะหายไป
    แต่ตรรกะที่ว่า “ถ้า Apple ไม่ควบคุม ทุกอย่างจะวุ่นวาย” เป็นเพียง การเลือกสุดโต่งสองด้าน เท่านั้น
    เราต้องการ จุดกึ่งกลาง ระหว่างการควบคุมทั้งหมดโดย Apple กับการปล่อยผู้ใช้ตามยถากรรม
    ถ้าตลาดทำงานเชิงแข่งขันไม่ได้จริง กฎระเบียบก็ควรปกป้องผู้ใช้และนักพัฒนา
    การที่ Apple ล็อกฮาร์ดแวร์ไว้เป็น บรรทัดฐานที่อันตราย และน่ากังวลว่าบริษัทอื่นจะเอาอย่าง

    • Apple ควบคุมความเร็วและทิศทางของนวัตกรรม บน iOS โดยตรง
      ฟีเจอร์ใหม่หรือแอปใหม่จะไม่มีทางเกิดขึ้นได้เลยถ้า Apple ไม่อนุญาต
      บริการอย่าง Dropbox หรือ GDrive ก็ยังต้องเสียฟังก์ชันไปเพื่อให้เข้ากับ แบ็กเอนด์ที่เต็มไปด้วยบั๊ก ของ Apple
      โครงสร้างแบบนี้ไม่ปกติเลย
    • สุดท้ายทางเลือกมีแค่ Android จริงๆ งั้นหรือ?

  • ข้อกำหนดของ Apple เรื่อง ต้องใช้ไบนารีแยก แทบจะเข้าข่ายผิดกฎหมายอยู่แล้ว
    การห้ามแชร์สถานะล็อกอินและการบังคับบล็อกคุกกี้ไม่ใช่หน้าที่ของ OS
    แถม Apple เองยังไม่ทำตาม กฎแพตช์ความปลอดภัยภายใน 30 วัน ด้วยซ้ำ

  • น่าทึ่งที่ Apple ทุ่มเท อย่างสุดขั้ว เพื่อทำข้อยกเว้นเฉพาะบางประเทศเท่านั้น