Platform Tilt

 (mozilla.github.io)
1 คะแนน โดย GN⁺ 2024-01-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Platform Tilt ของ Mozilla ติดตามเงื่อนไขทางเทคนิคบนแพลตฟอร์มซอฟต์แวร์หลัก ๆ ที่ทำให้ Firefox เสียเปรียบเมื่อเทียบกับเบราว์เซอร์หลักของแพลตฟอร์มนั้นเอง และเผยให้เห็นช่องว่างในการแข่งขันด้านความปลอดภัย ความเสถียร ประสิทธิภาพ และฟีเจอร์
  • ประเด็นที่เกี่ยวข้องกับ Apple กระจายกว้างที่สุด ตั้งแต่ การห้ามใช้เอนจินเบราว์เซอร์ของบุคคลที่สาม, ข้อจำกัดของ iOS ด้าน multi-process, JIT และ API การช่วยการเข้าถึง, การตั้งค่าเบราว์เซอร์เริ่มต้น, การเผยแพร่ส่วนขยายและเวอร์ชันเบต้า ไปจนถึงการจัดการเว็บแอปบนหน้าจอหลัก
  • ใน Google Android ประเด็นหลักคือ การไม่มี API สำหรับนำเข้าข้อมูลเบราว์เซอร์, โฟลว์ที่แอป Google เปิด Chrome แทนเบราว์เซอร์เริ่มต้น และกรณีที่ Firefox Android ได้รับหน้าผลการค้นหาคุณภาพต่ำ
  • ใน Microsoft Windows เบราว์เซอร์ของบุคคลที่สามตั้งค่าเบราว์เซอร์เริ่มต้นแบบ โปรแกรมมิง ได้ยาก และโฟลว์อย่าง Search, Copilot และ Widgets ให้ความสำคัญกับ Edge ก่อน
  • โดยรวมแล้ว การเลือกเบราว์เซอร์เริ่มต้น ของผู้ใช้, การย้ายข้อมูลระหว่างเบราว์เซอร์, ฟีเจอร์ของเอนจิน และความสามารถในการเข้าถึงการเผยแพร่ การทดสอบ และส่วนขยาย ล้วนทำงานในแบบที่เอื้อประโยชน์ต่อเบราว์เซอร์ของเจ้าของแพลตฟอร์มในแต่ละแพลตฟอร์ม

สิ่งที่ Platform Tilt ติดตาม

  • Platform Tilt คือแดชบอร์ดที่ติดตามกรณีทางเทคนิคบนแพลตฟอร์มซอฟต์แวร์หลัก ๆ ที่ทำให้ Firefox เสียเปรียบเมื่อเทียบกับเบราว์เซอร์หลักของแพลตฟอร์มนั้น
  • ครอบคลุมด้าน ความปลอดภัย, ความเสถียร, ประสิทธิภาพ และฟีเจอร์ พร้อมเสนอการเปลี่ยนแปลงเพื่อสร้างสภาพแวดล้อมการแข่งขันที่ราบเรียบยิ่งขึ้น
  • การหารือประเด็นแบบเรียลไทม์ดำเนินการที่ platform-tilt issue tracker

ข้อจำกัดของเอนจินเบราว์เซอร์และฟีเจอร์ iOS บนแพลตฟอร์ม Apple

  • App Store forbids third-party browser engines: Rule 2.5.6 ของ Apple App Store Review Guidelines กำหนดให้แอปสำหรับท่องเว็บต้องใช้ WebKit framework และ WebKit JavaScript ที่เหมาะสม
    • นโยบายนี้ทำให้ Firefox ไม่สามารถเผยแพร่บน iOS ด้วย Gecko ได้
    • ยังส่งผลต่อการเผยแพร่ Firefox ผ่าน App Store บนแพลตฟอร์ม Apple อื่น ๆ เช่น macOS ด้วย
    • ควรเปลี่ยนนโยบายของ App Store เพื่ออนุญาตให้เว็บเบราว์เซอร์ใช้เอนจินเบราว์เซอร์ของบุคคลที่สามได้
  • Support for third-party multi-process applications on iOS: เว็บเบราว์เซอร์สมัยใหม่ใช้ สถาปัตยกรรม multi-process ซึ่งรวมถึงโปรเซสแยกตามไซต์และโปรเซสเฉพาะสำหรับฟีเจอร์ที่อ่อนไหว เช่น GPU
    • Safari ใช้โครงสร้าง multi-process บน iOS แต่แอปของบุคคลที่สามที่ไม่ได้ใช้เอนจิน WebKit ของ Safari ไม่ได้รับกลไกเดียวกัน
    • iOS ควรมีกลไกสำหรับสร้างโปรเซสลูกที่ถูกแยกกักและสื่อสารกันได้อย่างมีประสิทธิภาพ
    • ข้อกำหนดประกอบด้วยจำนวนและอายุของโปรเซสลูกตามพฤติกรรมการนำทางของผู้ใช้, การตั้งค่าสิทธิ์แบบจำกัด, messaging และ shared memory, พื้นที่ shared memory แบบ read/write หรือ read-only, entitlement แยกอิสระของโปรเซสแม่และโปรเซสลูก, การโหลดไลบรารีภายในบันเดิล, การเรนเดอร์ IOSurface ผ่าน Metal หรือ OpenGL และการแชร์ข้ามโปรเซส
    • Firefox ใช้ codebase ร่วมกันในหลายระบบปฏิบัติการ ดังนั้นอินเทอร์เฟซและพฤติกรรมการจัดการโปรเซสควรคล้ายกับแพลตฟอร์มอื่น ๆ เช่น macOS และ Android โดยรวม
  • JIT Support on iOS: หากต้องการเผยแพร่เอนจิน JavaScript/WebAssembly ที่มีประสิทธิภาพดี โปรเซสของเบราว์เซอร์ต้องสามารถสร้างพื้นที่หน่วยความจำที่เขียนได้และรันได้
    • แอป iOS ไม่สามารถสร้างสิทธิ์หน่วยความจำลักษณะนี้ด้วย system call mmap(2) ได้
    • เอนจินเรนเดอร์ WebKit ของ Safari มีข้อยกเว้น จึงสามารถสร้างพื้นที่หน่วยความจำที่เขียนได้และรันได้
    • บน macOS มีแนวทางที่เทียบได้กับ Hardened Runtime entitlement ชื่อ com.apple.security.cs.allow-jit และ iOS ก็ควรให้ entitlement ที่เทียบเท่าแก่เบราว์เซอร์ที่ไม่ใช่ WebKit รวมถึงสิทธิ์ใช้ API pthread_jit_write_protect_np และ sys_icache_invalidate
  • Accessibility APIs on iOS: เอกสาร API การช่วยการเข้าถึง ของ iOS ยังไม่สมบูรณ์ และ API จำนวนมากที่เว็บเบราว์เซอร์ต้องใช้เพื่อรองรับมาตรฐานเว็บด้านการช่วยการเข้าถึงยังไม่ได้รับการจัดทำเอกสาร
    • ดูเหมือนว่า WebKit มีบันเดิลระบบแบบ closed source ที่ถูกโหลดใน runtime ซึ่งทำให้การคาดเดาวิธีใช้งานทำได้ยาก
    • ค่าคงที่จำนวนเต็มของ trait บางส่วน เช่น “visited”, “radio button” และค่าคงที่จำนวนเต็มของ notification type บางส่วน เช่น “value changed” ยังไม่ถูกเปิดเผยต่อสาธารณะ
    • API การช่วยการเข้าถึงทั้งหมดที่ WebKit ใช้ควรถูกจัดทำเอกสารและมีความเสถียร และในอุดมคติ WebKit ก็ควรใช้งาน API เหล่านี้ในแบบเดียวกับเอนจินเบราว์เซอร์ของบุคคลที่สาม

ช่องว่างด้านประสบการณ์ผู้ใช้ การจัดจำหน่าย และการขยายความสามารถของแพลตฟอร์ม Apple

  • Messages integration on iOS: หน้าโฮมของ iOS Safari แสดงลิงก์ที่ได้รับล่าสุดและรายชื่อติดต่อที่ส่งมาจากแอป Messages แต่เบราว์เซอร์ของบุคคลที่สามไม่มีสิทธิ์เข้าถึง ข้อมูล Messages จึงไม่สามารถให้ฟีเจอร์เดียวกันได้

  • Importing browser data on iOS: บน iOS ข้อมูลการท่องเว็บ เช่น ประวัติการเข้าชม บุ๊กมาร์ก และคุกกี้ เบราว์เซอร์ของบุคคลที่สามไม่สามารถเข้าถึงได้ และไม่มี API สำหรับนำเข้าข้อมูล

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

  • Setting and checking default browser on iOS: iOS ไม่มีฟีเจอร์ให้เบราว์เซอร์ของบุคคลที่สามเรียกพรอมป์ของระบบเพื่อขอให้ตั้งตัวเองเป็น เบราว์เซอร์เริ่มต้น

    • Android มีฟีเจอร์คล้ายกันผ่านการร้องขอ browser role ส่วน macOS มีผ่าน LSSetDefaultHandlerForURLScheme และ LSSetDefaultRoleHandlerForContentType
    • เบราว์เซอร์บน iOS ทำได้เพียง deep link ไปยัง UI การตั้งค่า และผู้ใช้ต้องเข้าใจหน้าการตั้งค่าแล้วเปลี่ยนเอง
    • มีกรณีที่ใน iOS 17.2.1 เมื่อพิมพ์ “Default browser app” หรือ “Default” ในการค้นหา Settings แล้วไม่พบผลลัพธ์สำหรับการเปลี่ยนเบราว์เซอร์เริ่มต้น
    • เบราว์เซอร์ของบุคคลที่สามยังตรวจจับไม่ได้ว่าตอนนี้ตัวเองเป็นเบราว์เซอร์เริ่มต้นหรือไม่ ทำให้ยากต่อการปรับแต่งเบราว์เซอร์ตามเจตนาของผู้ใช้ หรือขอให้เปลี่ยนเบราว์เซอร์เริ่มต้นในจังหวะที่เหมาะสม

  • Origin-Based Associated Domains dependent features for third-party browser engines on iOS: หากเบราว์เซอร์ที่ไม่ใช่ WebKit ต้องการรองรับ password autofill, one-time codes, passkeys, Apple Pay จะต้องสามารถระบุ associated domain ตาม origin ของเนื้อหาเว็บได้

    • เบราว์เซอร์ที่ใช้ WebKit สามารถ override associated domain ของแอปเบราว์เซอร์ให้เป็นโดเมนที่ผู้ใช้กำลังเข้าชมได้
    • ตัวอย่างเช่น ในช่องกรอกรหัสผ่านของ example.com เบราว์เซอร์ควรระบุว่าช่องนั้นอยู่ใน origin ของ example.com เพื่อให้ตัวจัดการรหัสผ่านถูกเรียกในขอบเขตของ example.com
    • การรองรับ Apple Pay อาจต้องมีการเปลี่ยนแปลงเพิ่มเติม เพื่อให้สามารถรับชำระเงินสำหรับผู้รับเงิน Apple Pay ที่ลงทะเบียนไว้ได้เช่นเดียวกับ Safari

  • Browser extension support on iOS: Safari รองรับส่วนขยายที่จัดจำหน่ายผ่าน iOS App Store แต่เบราว์เซอร์ของบุคคลที่สามให้ฟีเจอร์ส่วนขยายของตนเองได้ยากเนื่องจาก App Store Review Guidelines 2.5.2

    • ส่วนขยายเบราว์เซอร์เป็นองค์ประกอบหลักของระบบนิเวศเว็บ และช่วยให้นักพัฒนาเพิ่มฟังก์ชันให้เบราว์เซอร์ เพื่อยกระดับยูทิลิตี้ ความสะดวกในการใช้งาน และการทำงานร่วมกันกับแอประบบ
    • ควรผ่อนปรนข้อกำหนดซอฟต์แวร์ของ App Store เพื่อให้เบราว์เซอร์ของบุคคลที่สามใช้แค็ตตาล็อกส่วนขยายของตนเองได้

  • Beta testing on iOS: บน iOS ไม่สามารถแจกจ่ายแอปเวอร์ชันเบตาผ่าน App Store ได้ ต้องใช้ TestFlight

    • TestFlight มี ขีดจำกัด 10,000 คน ซึ่งน้อยเมื่อเทียบกับขนาดผู้ใช้เบตาของเบราว์เซอร์ขนาดใหญ่
    • เมื่อถึงขีดจำกัด ต้องลบผู้ใช้เก่าออกด้วยตนเอง ทำให้เกิดภาระในการดูแลรักษา
    • ผู้ใช้ต้องผ่านขั้นตอนติดตั้งแอป TestFlight, ขอ access code, รอรับ, แล้วกรอกรหัส
    • Safari เวอร์ชันใหม่ถูกรวมอยู่ในเบตาของระบบปฏิบัติการ iOS จึงไม่อยู่ภายใต้ข้อจำกัดเดียวกัน
    • แนวทางแก้ที่เสนอคืออนุญาตให้แจกจ่ายบิลด์ pre-release ของเบราว์เซอร์ผ่าน App Store หรือยกเลิกขีดจำกัดผู้ใช้ TestFlight และอนุญาตให้เผยแพร่ผ่านลิงก์สาธารณะได้ไม่จำกัด

  • iOS and macOS "Search Web" features open links in Safari instead of the user’s default browser: เมนูบริบท Search Web หรือ Search with <Search Engine> บน iOS และ macOS รวมถึงจุดเข้าค้นหา Services บนแถบเมนูของ macOS จะเรียกค้นหาใน Safari โดยไม่สนใจเบราว์เซอร์เริ่มต้น

  • SFSafariViewController should respect the user’s default browser: SFSafariViewController เป็น API ระดับสูงที่ทำให้แอป iOS สามารถมอบการเรนเดอร์เนื้อหาเว็บให้เบราว์เซอร์ของผู้ใช้ และฝังไว้ภายในแอปได้

    • 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 วัน, และปัญหาที่ผู้ใช้ WebKit Firefox นอก EU ซึ่งย้ายมาอยู่ EU อย่างถาวรยังคงติดอยู่กับเวอร์ชัน “orphaned” ที่ไม่ได้รับการอัปเดต
    • นักพัฒนาเบราว์เซอร์ต้องพัฒนา ดูแลรักษา และแจกจ่ายแอปสองตัวที่แยกจากกันโดยสิ้นเชิง ทำให้เกิดความซับซ้อนในการย้ายข้อมูล ผู้ใช้หลุดออก การได้ผู้ใช้ลดลง และข้อจำกัดต่อการ rollout แบบ A/B ซ้ำ ๆ สำหรับผู้ใช้ iOS ใน EU
    • ทางเลือกที่เสนอคือรวม webview ของทั้งสองเอนจินไว้ในไบนารีและบันเดิลเดียวทั่วโลก และให้ OS แจ้ง eligibility ของ BrowserEngineKit แก่แอปตอนเริ่มทำงาน

  • นักพัฒนาเว็บควรสามารถทดสอบด้วยเอนจินเบราว์เซอร์ทางเลือกบน iOS ได้โดยไม่ขึ้นกับสถานที่: ตอนเปิดตัวครั้งแรก BrowserEngineKit มีข้อจำกัดด้านตำแหน่งที่ตั้ง ซึ่งปิดกั้นการทดสอบเอนจินของตนเองบนอุปกรณ์นอกสหภาพยุโรป (EU)

    • ข้อจำกัดนี้ถูกยกเลิกสำหรับการพัฒนาและทดสอบภายในเครื่องใน 18.2 beta แล้ว แต่ยังคงมีผลกับนักพัฒนาเว็บ
    • นักพัฒนาเว็บนอก EU ก็อาจต้องรองรับผู้ใช้ใน EU ได้เช่นกัน จึงจำเป็นต้องมีกลไกที่ช่วยให้ทดสอบเว็บไซต์บนเอนจินเบราว์เซอร์ทางเลือกได้ง่าย โดยไม่ขึ้นกับตำแหน่งที่ตั้ง

  • เบราว์เซอร์ที่ใช้เอนจินทางเลือกควรสามารถติดตั้งและจัดการเว็บแอปบนหน้าจอโฮมของ iOS ได้: แม้จะมี API ที่ให้เอนจินเบราว์เซอร์ทางเลือกเพิ่มเว็บแอปลงในหน้าจอโฮมของ iOS ได้ แต่แอปดังกล่าวจะเปิดใน Safari

    • ฟีเจอร์เฉพาะเอนจิน สถานะผู้ใช้ และค่ากำหนดก่อนและหลังการติดตั้งแตกต่างกัน ทำให้ประสบการณ์ถูกแยกออกจากกัน
    • Apple คัดค้านการอนุญาตให้เอนจินที่ไม่ใช่ WebKit เรนเดอร์เว็บแอปบนหน้าจอโฮม โดยอ้างเหตุผลด้านความปลอดภัย
    • ข้อกำหนดด้านความปลอดภัยพื้นฐานของเว็บแอปบนหน้าจอโฮมเหมือนกับข้อกำหนดเรื่องแซนด์บ็อกซ์ข้ามไซต์และการแยกส่วนที่บังคับใช้กับการท่องเว็บทั่วไปอยู่แล้ว
    • Android มอบหมายการเรนเดอร์เว็บแอปให้กับเอนจินเบราว์เซอร์ของบุคคลที่สามมาหลายปีแล้ว และ iOS ก็ควรเปิดใช้งานสิ่งนี้เช่นกัน

การย้ายข้อมูล เบราว์เซอร์เริ่มต้น และประสบการณ์การค้นหาของ Google Android

  • การนำเข้าข้อมูลเบราว์เซอร์บน Android: บน Android ข้อมูลการท่องเว็บ เช่น ประวัติการเข้าชม บุ๊กมาร์ก และคุกกี้ ไม่สามารถเข้าถึงได้โดยเบราว์เซอร์บุคคลที่สาม
    • ข้อมูลถูกเก็บไว้ใน data directory ของแอปเว็บเบราว์เซอร์ และเบราว์เซอร์บุคคลที่สามไม่สามารถเข้าถึงโดยตรงได้
    • ไม่มี API หรือ ContentProvider ที่ทำให้สามารถนำเข้าข้อมูลได้
    • การไม่มีฟังก์ชันนำเข้าข้อมูลสร้างแรงเสียดทานครั้งใหญ่ในการย้ายจาก Chrome ไปยังเบราว์เซอร์อื่น
  • ฟีเจอร์บางอย่างของ Android เปิด Chrome แทนเบราว์เซอร์เริ่มต้นของผู้ใช้: ฟีเจอร์ต่าง ๆ เช่น Google Search และ Discover ใน แอปพลิเคชัน Google ที่ติดตั้งมาล่วงหน้า จะเพิกเฉยต่อการเลือกเบราว์เซอร์เริ่มต้นของผู้ใช้ และเปิดลิงก์เว็บไซต์ภายนอกใน Chrome เสมอ
    • ยังมีจุดเข้าสู่การใช้งานเพิ่มเติมในฟีเจอร์ที่ฝังมาในระบบ เช่น แถบค้นหาบนหน้าจอหลักและตัวเรียกแอป
    • ทุกครั้งที่ลิงก์เปิดใน Chrome ผู้ใช้จะถูกพาออกจากเบราว์เซอร์เริ่มต้น
    • แอปและฟีเจอร์ที่ฝังมาในระบบทั้งหมดที่เปิดลิงก์ภายนอก ควรเปิดในเบราว์เซอร์เริ่มต้นของผู้ใช้
  • หน้าผลการค้นหาคุณภาพต่ำกว่าในเอนจินเบราว์เซอร์บุคคลที่สามบน Android: บน Android ประสบการณ์การค้นหาเว็บผสานรวมอย่างใกล้ชิดกับฟีเจอร์ที่ฝังมาในระบบหลายอย่าง และเคยมีกรณีที่ Firefox ได้รับหน้าผลการค้นหาคุณภาพต่ำกว่า Chrome
    • สำหรับคำค้นหาเดียวกัน Firefox Android ได้รับหน้าเว็บที่มีข้อมูลน้อยกว่าและคุณภาพการออกแบบต่ำกว่า Chrome
    • โดยเคร่งครัดแล้วนี่เป็นประเด็นของเว็บไซต์ Google Search แต่เนื่องจากความสำคัญของการค้นหาและระดับการผสานรวมบน Android จึงนำไปสู่ช่องว่างด้านประสบการณ์ผู้ใช้ที่ทำให้ไม่อยากเลือกเบราว์เซอร์บุคคลที่สาม
    • ไม่มีข้อจำกัดทางเทคนิคที่ทำให้หน้าเว็บดังกล่าวทำงานบน Firefox ไม่ได้
    • สถานะของประเด็นนี้คือ closed

โฟลว์ที่ให้ความสำคัญกับ Edge บน Microsoft Windows

  • การตั้งค่าเบราว์เซอร์เริ่มต้นบน Windows: Windows ไม่มีความสามารถให้เบราว์เซอร์บุคคลที่สาม ร้องขอด้วยวิธีเชิงโปรแกรม ให้ตั้งค่าตัวเองเป็นเบราว์เซอร์เริ่มต้น
    • แม้หลังติดตั้งเบราว์เซอร์แล้ว ผู้ใช้ยังต้องไปที่การตั้งค่าของระบบปฏิบัติการและเลือกเอง ซึ่งสร้างแรงเสียดทานและแรงเฉื่อยที่ทำให้ยังคงใช้ Edge ต่อไป
    • Android และ macOS มีรูปแบบที่ให้ผู้ใช้อนุมัติหรือปฏิเสธได้ง่ายผ่านพรอมป์ของระบบหรือ API ที่เกี่ยวข้อง
    • ใน Windows 10 ผู้ใช้ต้องคลิกหลายครั้งใน UI การตั้งค่าและยืนยันซ้ำ ส่วน Windows 11 มีปุ่ม Set default แต่ยังไม่เพียงพอ
  • เบราว์เซอร์เริ่มต้นถูกตั้งเป็น Edge โดยโฟลว์หลายอย่างของ Windows: Windows 10 และ 11 แสดงข้อความอย่างต่อเนื่องว่า Microsoft Edge เป็นเบราว์เซอร์ “recommended” ของ Windows และมี UI สำหรับเปลี่ยนเบราว์เซอร์เริ่มต้นเป็น Edge
    • ถ้อยคำบางส่วนถามให้ใช้ “recommended browser settings” ซึ่งไม่ได้แสดงอย่างชัดเจนว่ามีการเปลี่ยนเบราว์เซอร์เริ่มต้น
    • ตัวอย่างต่าง ๆ ถูกเพิ่มและลบออกจากพื้นผิว UI ที่แสดงโดยอัตโนมัติ เช่น Windows Update และเปลี่ยนแปลงอยู่เรื่อย ๆ
    • คอมโพเนนต์ของ Windows สามารถเปลี่ยนเบราว์เซอร์เริ่มต้นของผู้ใช้ได้โดยตรง แต่เบราว์เซอร์บุคคลที่สามต้องใช้ deep link ของโปรโตคอล ms-settings:
    • Windows เองก็ควรใช้ความสามารถและ API แบบเดียวกับที่มีให้เบราว์เซอร์บุคคลที่สาม
  • ฟีเจอร์บางอย่างของ Windows เปิด Edge แทนเบราว์เซอร์เริ่มต้นของผู้ใช้: ฟีเจอร์หลักอย่างน้อยสามอย่างของ Windows เปิด URL ใน Microsoft Edge แทนที่จะเปิดในเบราว์เซอร์เริ่มต้นปัจจุบัน
    • Windows Search หรือ Start Menu Search ปรากฏผ่านช่องค้นหา/ปุ่มค้นหาบนแถบงาน การพิมพ์ในเมนูเริ่ม และคีย์ลัด WIN+S โดยทั้งผลการค้นหาและลิงก์บทความจะเปิดใน Edge
    • Windows Copilot แสดงเป็นหน้าต่างที่ dock อยู่ด้านขวาของหน้าจอใน Windows 11 และเปิดลิงก์ในคำตอบหรือพื้นที่เรนเดอร์ใน Edge
    • Widgets ใน Windows 10 เรียกว่า “news and interests” แสดงข้อมูล เช่น ข่าว สภาพอากาศ หุ้น และคะแนนกีฬา และเปิดลิงก์หน้าเว็บใน Edge

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

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

 
GN⁺ 2024-01-21
ความคิดเห็นจาก Hacker News

  • ทั้ง Android และ Microsoft ดูเหมือนจะมีแอปที่เปิดลิงก์ด้วยวิธีของตัวเองแทนที่จะใช้เบราว์เซอร์ที่ผู้ใช้เลือกไว้ แต่ปัญหาที่ใหญ่กว่าคือเมื่อกดลิงก์ภายในแอปแล้วมันเปิด เว็บวิวในตัว ขึ้นมาเหมือนเป็นเบราว์เซอร์
    แอปสามารถเฝ้าติดตามกิจกรรมบนเว็บที่ทำอยู่ในนั้นได้ อยากให้ Android Play Store และ iOS App Store บังคับให้เว็บไซต์ของบุคคลที่สามทั้งหมดต้องเปิดด้วยเบราว์เซอร์ของผู้ใช้
    น่าจะทำได้โดยจัดประเภทแอปเป็น “เว็บเบราว์เซอร์” และ “ไม่ใช่เว็บเบราว์เซอร์” แล้วให้แอปที่ “ไม่ใช่เว็บเบราว์เซอร์” ลงทะเบียนโดเมนที่เข้าถึงได้เพียงสั้น ๆ ราว 5~10 โดเมน และให้ระบบปฏิบัติการบล็อกที่เหลือ
    แอปอย่าง Facebook, FB Messenger, Google Maps ซึ่งไม่ได้มีจุดประสงค์หลักเพื่อท่องเว็บ ก็น่าจะถือเป็น “ไม่ใช่เว็บเบราว์เซอร์” ได้อย่างชัดเจน
    แบบนี้จะช่วยป้องกันปัญหาการสอดส่องผ่านเว็บวิวในตัว และยังใช้ รหัสผ่าน·ที่อยู่·บุ๊กมาร์ก·ประวัติการเข้าชม ที่ซิงก์ไว้กับโปรไฟล์เบราว์เซอร์ได้เหมือนเดิม ถ้าผมกำหนดโลกได้ตามใจ ก็อยากบังคับให้แอปที่เปิดลิงก์มีเมนูตามบริบท “เปิดในหน้าต่างเบราว์เซอร์แบบส่วนตัว” ด้วย

    • ส่วนตัวผมก็คิดเหมือนกัน แต่ไม่นานมานี้ได้รู้ว่าผู้ใช้ส่วนใหญ่กลับไม่ได้คิดแบบนั้น ตอนเปิดตัวแอป autotempest เราตั้งให้ลิงก์ของบุคคลที่สามที่พาไปยังหน้ารายละเอียดรถจากหลายเว็บไซต์ เปิดด้วยเบราว์เซอร์เริ่มต้นของผู้ใช้ทั้งหมด แต่ผู้ใช้ไม่ชอบและต้องการอย่างมากให้เปิดภายในแอป
      สุดท้ายเลยเปลี่ยนค่าเริ่มต้นเป็นเปิดภายในแอป แต่ยังคงมีตัวเลือกให้ใช้เบราว์เซอร์เริ่มต้นอยู่
    • การแก้ปัญหา เบราว์เซอร์ภายในแอป เป็นหนึ่งในงานสำคัญลำดับต้น ๆ ของ 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 ของทุกคำขอ ก็จะเข้มงวดเกินไปจนทำให้นักพัฒนาหลายคนอาจโหลดแม้แต่เว็บไซต์ของตัวเองได้ไม่ถูกต้อง

  • Mozilla จะออกมาตั้งคำถามว่า “App Store ห้ามเอนจินเบราว์เซอร์ของบุคคลที่สาม” ก็สมเหตุสมผลอยู่ แต่ไม่แน่ใจว่าอยากดึงปมนี้ออกมาจริงไหม
    เพราะมี การผูกขาด Safari บนอุปกรณ์ iOS นักพัฒนาจำนวนมากจึงใส่ใจเรื่องรองรับเบราว์เซอร์ที่ไม่ใช่ Chrome ตอนนี้ก็จำเป็นต้องทำแบบนั้น
    ถ้าผู้ใช้เริ่มได้รับข้อความว่า “ฟีเจอร์ที่พังนั้นไม่พังบน Chrome” นั่นคือเส้นทางสู่การผูกขาด และหลังจากนั้นเวลา Google สร้างมาตรฐานเว็บใหม่ก็แทบไม่ต้องอาศัยฉันทามติมากนัก
    สภาพตอนนี้ก็แย่อยู่แล้ว แต่ก็อาจแย่ลงได้ หวังว่าการคาดการณ์นี้จะผิด

    • การท้าทายการผูกขาด Safari ที่ Apple บังคับไว้บน iOS ย่อมสอดคล้องกับผลประโยชน์ของ Mozilla อยู่แล้ว แค่ Chrome ถูกกดไว้บน iOS ไม่ได้แปลว่าการที่ Firefox ถูกกดไว้ด้วยจะเป็นผลดีกับ Firefox
      ถ้าข้อจำกัดของ Apple ที่ทำให้ Firefox ไม่สามารถใช้ Gecko และ WebExtensions บน Gecko โดยเฉพาะตัวบล็อกโฆษณา หายไป ส่วนแบ่งของ Firefox บน iOS ก็มีแต่จะเพิ่มขึ้น
      และผู้ใช้ Firefox บน iOS ที่เพิ่มขึ้นนั้นก็จะซิงก์กับ Firefox บนเดสก์ท็อปและ Firefox บน iOS ที่บล็อกโฆษณาได้ ซึ่งอาจชักจูงให้ใช้ Firefox บนเดสก์ท็อปด้วย
    • มาพูดแบบเดียวกันเลย ไม่ว่าจะมองว่าดีหรือไม่ดี การที่บน iOS ไม่สามารถแทนที่ Safari ด้วย Chrome ได้ คือกลไกเดียวที่ขวางไม่ให้ Chrome ครอบงำทั้งหมด
    • ถ้า iOS เปิดให้แข่งขันเสรี คิดว่าคนจำนวนมากจะติดตั้ง Chrome โดยเฉพาะผู้ใช้พีซีที่มีอุปกรณ์ Apple แค่ iPhone เท่านั้น
    • เหตุผลที่ฉันทำให้เว็บไซต์ของตัวเองใช้งานได้บน Firefox ไม่ใช่เพราะต้องทำให้ใช้งานได้บน Safari ด้วย
      Firefox มักจะใช้งานได้อยู่แล้ว และถึงจะไม่ ก็ไม่ได้อยากคอยกังวลเพิ่มกับอีกหนึ่งเทคโนโลยีสแต็กเพราะ Safari ซึ่งเป็นแพลตฟอร์มที่ถูกปล่อยทิ้งและต้องมีงานเพิ่มเสมอ
    • ถ้า Mozilla ไม่ยกปัญหาของ Apple ขึ้นมา ความไม่พอใจต่อบริษัทอื่นก็อาจถูกเมินโดยใชั Safari เป็นข้ออ้างได้ เพราะ Mozilla พูดถูกเรื่องพฤติกรรมของ Apple อยู่แล้ว ถ้าวิจารณ์ Google/Microsoft แต่ไม่แตะ Apple ก็จะดูหน้าซื่อใจคด
      เริ่มเหนื่อยกับตรรกะที่ใช้ปกป้องสภาพปัจจุบันแล้ว การคงสภาพเดิมไม่ได้พาไปในทางที่ดี และถ้าไม่มีมาตรการแรง ๆ มันก็จะไม่เปลี่ยน ดูเหมือนฝั่งที่ปกป้องการคงสภาพเดิมของ Apple เองก็ไม่มีแผนว่าจะทำให้ดีขึ้นต่อไปอย่างไร
      Safari เพียงอย่างเดียวไม่พอจะหยุดการครอบงำของ Chrome และหลังจากกฎ App Store ของ EU มีผลบังคับใช้ ก็มีโอกาสไม่น้อยที่จะมีการบังคับให้เปิดเอนจินเบราว์เซอร์ ดังนั้นในระยะยาวตัวการคงสภาพเดิมเองก็ไม่ได้รับประกัน
      ตอนนี้เป็นช่วงที่รัฐบาลสหรัฐซึ่งแสดงเจตจำนง บังคับใช้กฎหมายต่อต้านการผูกขาด กับบริษัทเทคโนโลยีอย่างแข็งขันในเชิงประวัติศาสตร์ กำลังจะหมดวาระ หลายคนยังไม่เข้าใจมากพอว่ารัฐบาล Biden เป็นมิตรกับแนวทางต่อต้านการผูกขาดมากแค่ไหน
      รัฐบาลนี้อาจอยู่ต่ออีก 4 ปีหรือไม่ก็ได้ แต่เมื่อคำนึงถึงความไม่แน่นอนนั้น นี่ถือเป็นหนึ่งในโอกาสดีที่สุดนับตั้งแต่คดีต่อต้านการผูกขาด Windows ยุคแรก ๆ ที่จะเรียกร้องให้มีการแทรกแซง Google/Apple/Microsoft อย่างจริงจัง
      การมีรัฐบาลที่เปิดรับแนวคิดต่อต้านการผูกขาด การเปลี่ยนแปลงของความรู้สึกผู้บริโภคต่อ Big Tech แรงกดดันของ Apple รอบ iOS และความเคลื่อนไหวของ Google ในเดือนมิถุนายนที่จะทำให้ตัวบล็อกโฆษณาอ่อนแอลง กำลังมาบรรจบกัน ทำให้ตอนนี้เป็นเวลาที่ดีในการผลักดันให้เปลี่ยนแปลงสภาพปัจจุบันอย่างจริงจัง
      ไม่ใช่ว่าไม่มีความเสี่ยง แต่รอไปก็ไม่ได้ทำให้สถานการณ์ดีขึ้น ยิ่งรอ Firefox ก็ยิ่งมีความสำคัญน้อยลง โอกาสที่รัฐบาลจะเปลี่ยนก็ยิ่งมากขึ้น และ Mozilla ก็ยิ่งใช้กระแสสังคมได้ยากขึ้น
      จะไม่มีช่วงเวลาที่ Mozilla ชนะข้อโต้แย้งนี้ได้ง่าย ๆ แบบ 100% และถ้าไม่ทำตอนนี้ สุดท้ายก็จะถูกเบียดออกจากตลาดอย่างสมบูรณ์
      สนับสนุนให้เดินหน้าเต็มกำลังกับทุกฝ่ายรวมถึง Apple หากกังวลว่าหลังเปิด iOS แล้ว Chrome จะครอบงำ ปัญหานั้นก็ควรจัดการด้วยการกำกับดูแล Google และตอนนี้คือเวลาที่ดีที่สุดที่จะเสนอข้อเรียกร้องนั้น

  • ในฐานะผู้ใช้ Android เหตุผลหลักที่ไม่ใช้ Firefox ไม่ใช่พฤติกรรมต่อต้านการแข่งขัน แต่เป็นเพราะ มันรู้สึกช้า
    บน Firefox มักมีอาการเลย์เอาต์สั่นตอนโหลดโฮมเพจ แอนิเมชันคีย์บอร์ดกระตุกเป็นบางครั้ง และใช้ตัวเลือกเมนู “ปล่อยเพื่อเลือก” ไม่ได้

    • ใช้มาหลายปีแล้ว แต่ไม่เคยรู้สึกถึงความต่างแบบนั้น
    • “ปล่อยเพื่อเลือก” คืออะไร?
    • บน Firefox แม้แต่ คีย์ลัดสำหรับการนำทางด้วยคีย์บอร์ด พื้นฐานของคีย์บอร์ดภายนอกก็ใช้ไม่ได้เลย

  • https://github.com/mozilla/platform-tilt/issues/3
    การรองรับ JIT บน iOS เป็นปัจจัยที่ถูกพูดถึงน้อยเกินไปมากในประเด็นว่า “EU จะบังคับให้ iOS รองรับเอนจินเรนเดอร์ของบุคคลที่สาม”
    Apple จะยอมให้แอปรองรับ JIT หรือไม่? จะสร้างสิทธิ์ใหม่ที่นักพัฒนาเบราว์เซอร์ต้องขอหรือเปล่า? น่าสนใจ แต่ดูไม่น่าเป็นไปได้

    • Apple ใช้วิธีจำกัดบางสิทธิ์ไว้เฉพาะเว็บเบราว์เซอร์บน macOS อยู่แล้ว ตัวอย่างคือสิทธิ์ Passkey
      com.apple.developer.web-browser.public-key-credential
      https://developer.apple.com/documentation/bundleresources/en...
    • LuaJit ระบุว่ารองรับ iOS: https://luajit.org/status.html#ios
      มีใครรู้ไหมว่าอันนี้ยังถูกต้องอยู่หรือเปล่า? เมื่อก่อนอาจจะจริง แต่ตอนนี้ไม่รองรับแล้วหรือไม่?

  • บทความที่เกี่ยวข้อง: https://blog.mozilla.org/netpolicy/2024/01/19/platform-tilt/
    มาจาก https://news.ycombinator.com/item?id=39059255 แต่ที่นั่นไม่มีคอมเมนต์

  • บน macOS ถ้าคลิกขวาที่ข้อความที่เลือกไว้แล้วเลือกค้นหาบนเว็บ ต่อให้ตั้งเบราว์เซอร์เริ่มต้นเป็นตัวอื่นก็จะเปิด Safari เสมอ อาจเป็นแค่ใน Mail.app ก็ได้ แต่ดูเหมือนประเด็นนี้จะตกหล่นไป

  • ข้อบ่นที่ใหญ่ที่สุดเกี่ยวกับ Firefox บน Android คือบางครั้งพิมพ์โดเมนในแถบที่อยู่แล้วกด Enter แต่ ไม่มีอะไรเกิดขึ้นเลย
    อาการนี้เกิดขึ้นแบบไม่สม่ำเสมอ และกระทบเฉพาะบางเว็บไซต์ เช่น https://forum.syncthing.net
    ปิดแท็บหรือเปลี่ยนไปใช้แท็บอื่นก็ไม่หาย ต้องบังคับปิดแอปถึงจะกลับมาปกติ

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

  • ส่วนใหญ่เข้าใจได้ แต่หัวข้อ การผสานกับ Messages บน iOS ให้ความรู้สึกไม่ค่อยดี
    ถ้าเป็นแค่ API สำหรับ “ลิงก์ที่ส่งล่าสุด” ที่ผู้ใช้ต้องเลือกเองก็คงไม่มีปัญหา แต่การเข้าถึงข้อมูลข้อความทั้งหมดนั้น ต่อให้ Mozilla เป็นผู้พัฒนาก็ไม่อยากให้แอปบุคคลที่สามได้สิทธิ์นี้เด็ดขาด
    ในกรณีของส่วนขยายบน iOS นั้น Orion สามารถติดตั้งส่วนขยายได้จากทั้งแกลเลอรีส่วนขยายของ Chrome และ Firefox ดังนั้นดูเหมือนว่านี่อาจไม่ใช่ปัญหาจริง หรือไม่ก็ผ่าน App Review มาแล้วและคงอยู่แบบนี้มาหลายปี

    • การรองรับส่วนขยาย Firefox ของ Orion เป็นสัญญาณอันตรายอย่างมาก ใน issue สองรายการนี้ของตัวติดตาม Firefox-iOS ที่เกี่ยวกับส่วนขยายและการบล็อกเนื้อหา Orion ก็ถูกพูดถึงมานานแล้ว แต่ไม่มีคำตอบจาก Mozilla
      [0]: https://github.com/mozilla-mobile/firefox-ios/issues/7374
      [1]: https://github.com/mozilla-mobile/firefox-ios/issues/9155

  • การคัดลอก·วางใน Google Colab ทำงานได้ถูกต้องบน Chrome แต่ไม่เป็นเช่นนั้นบน Firefox

  • เขาบอกว่า “ข้อมูลการท่องเว็บอย่างประวัติการเข้าชม เว็บไซต์ที่คั่นหน้าไว้ และคุกกี้ ไม่สามารถให้เบราว์เซอร์บุคคลที่สามบน Android เข้าถึงได้” แต่ในมุมผู้ใช้ ทำไมถึงอยากให้แอปพลิเคชันบุคคลที่สามเข้าถึงประวัติการเข้าชม คั่นหน้า และคุกกี้ในเบราว์เซอร์ของฉันกัน?
    นั่นเป็น การรั่วไหลของความเป็นส่วนตัว อย่างชัดเจน Firefox ควรเอาไปได้เฉพาะข้อมูลที่ Firefox สร้างขึ้นตอนที่ฉันใช้ Firefox เท่านั้น ไม่ใช่ข้อมูลจากบริบทอื่น

    • จะถือว่าเป็นการรั่วไหลก็ต่อเมื่อเข้าถึงโดยไม่ได้รับอนุญาตเท่านั้น ตราบใดที่ผู้ใช้ยังตอบได้ว่า “ไม่ได้เด็ดขาด” การที่แอปสามารถร้องขอสิทธิ์เข้าถึงข้อมูลนั้นได้ก็ไม่ใช่ปัญหา
    • ในฐานะผู้ใช้ที่อยากย้ายไปเบราว์เซอร์ใหม่ได้ง่าย ๆ ก็อยากให้เบราว์เซอร์ใหม่เข้าถึง ข้อมูลอย่างคั่นหน้า จากเบราว์เซอร์เดิมเพื่อทำให้ขั้นตอนง่ายขึ้น
    • หลัก ๆ ก็เพื่อใช้กับการนำเข้า/ส่งออกข้อมูลระหว่างเบราว์เซอร์อื่น ๆ เป็นงานที่พบบ่อยมากในขั้นตอน onboarding
    • ประวัติการเข้าชมกับคุกกี้นั้นคัดค้านได้แน่นอน แต่ การส่งออกคั่นหน้าแล้วนำเข้ากลับมา เป็นสิ่งจำเป็น
      แต่ Firefox บน Android กลับไม่รองรับแม้กระทั่งสิ่งนั้น :facepalm:
      https://github.com/mozilla-mobile/fenix/issues/417
    • อันนี้ดูเป็นการตีความแบบไม่ค่อยตรงไปตรงมานัก รายชื่อติดต่อหรือข้อมูลอ่อนไหวอื่น ๆ ก็สามารถนำเข้าได้อยู่แล้วโดยไม่เกิด “การรั่วไหลของความเป็นส่วนตัว”
      ใน issue นั้นก็ไม่ได้เรียกร้องฟีเจอร์นำเข้าที่ไม่มีการตรวจสอบ แต่กำลังบอกว่า Android สามารถเป็นตัวกลางจัดการการเข้าถึงข้อมูลอ่อนไหวอื่น ๆ โดยอาศัยความยินยอมจากผู้ใช้ได้