Google Chrome ให้บริการ API ที่เข้าถึงได้เฉพาะบน *.google.com

 (twitter.com/lcasdev)
2 คะแนน โดย GN⁺ 2024-07-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Google Chrome ให้บริการ API ที่อนุญาตให้เฉพาะ ไซต์ *.google.com เข้าถึงข้อมูลการใช้งาน CPU ของระบบ/แท็บ, การใช้งาน GPU, การใช้งานหน่วยความจำ, ข้อมูลโปรเซสเซอร์โดยละเอียด และการเข้าถึงแบ็กแชนเนลสำหรับล็อก
  • API เดียวกันนี้ไม่ถูกเปิดเผยให้ไซต์อื่นใช้งาน จึงเกิดข้อถกเถียงว่าเวนเดอร์เบราว์เซอร์ควรมอบ สิทธิพิเศษ ให้เว็บไซต์ของตนเองได้หรือไม่
  • DMA บัญญัติแนวคิดที่ว่าเวนเดอร์เบราว์เซอร์ซึ่งเป็น gatekeeper ของอินเทอร์เน็ตต้องให้ฟังก์ชันเดียวกันแก่ทุกฝ่ายไว้ในกฎหมาย และขึ้นอยู่กับการตีความ การเปิดเผยข้อมูลเพิ่มเติมเฉพาะให้พร็อพเพอร์ตีของ Google อาจเข้าข่าย ละเมิด DMA ได้
  • Zoom อาจตกอยู่ในสถานะเสียเปรียบในการแข่งขัน เพราะไม่ได้รับ ฟังก์ชันดีบัก CPU แบบเดียวกับ Google Meet
  • ฟังก์ชันนี้ถูกติดตั้งในรูปแบบ ส่วนขยาย Chrome ในตัว ที่ไม่สามารถปิดใช้งานได้และไม่ปรากฏในแผงส่วนขยาย โดยใน Microsoft Edge และ Brave ก็มีฟังก์ชันเดียวกันให้เฉพาะโดเมน *.google.com เช่นกัน

ข้อมูลที่ API สำหรับ *.google.com โดยเฉพาะเปิดเผย

  • Chrome ให้ข้อมูลที่ใกล้เคียงกับสถานะระบบและการดีบักเฉพาะกับไซต์ *.google.com
    • การใช้งาน CPU ของระบบและแท็บ
    • การใช้งาน GPU
    • การใช้งานหน่วยความจำ
    • ข้อมูลโปรเซสเซอร์โดยละเอียด
    • แบ็กแชนเนลสำหรับล็อก
  • API เดียวกันนี้ไม่ถูกเปิดเผยให้ไซต์อื่น และใช้งานได้เฉพาะบนโดเมน *.google.com

วิธีติดตั้งใช้งานและพฤติกรรมของเบราว์เซอร์ที่ต่อยอดจาก Chromium

  • ฟังก์ชันนี้ถูกติดตั้งในรูปแบบ ส่วนขยาย Chrome ในตัว ที่ไม่สามารถปิดใช้งานได้และไม่แสดงในแผงส่วนขยาย
  • ซอร์สโค้ดอยู่ในพาธ hangout_services ของ Chromium
  • ก่อนหน้านี้ยังไม่ชัดเจนว่าส่วนขยายเดียวกันนี้ถูกรวมอยู่ในเบราว์เซอร์อื่นที่ต่อยอดจาก Chromium ด้วยหรือไม่ แต่ในการอัปเดตภายหลังมีการยืนยันพฤติกรรมดังต่อไปนี้
    • ใน Microsoft Edge ฟังก์ชันนี้ก็ให้ใช้งาน เฉพาะโดเมน *.google.com เช่นกัน
    • Brave ก็มีส่วนขยายที่ติดตั้งมาล่วงหน้า ซึ่งอนุญาตให้ Google ดึงข้อมูลนี้ได้เฉพาะจาก *.google.com และมีพฤติกรรมเหมือน Chrome และ Edge

ประเด็นด้านการแข่งขันและกฎระเบียบ

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

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

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

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

  • ดูจากชื่อ hangout_services แล้วเหมือนเป็นแฮ็กหนี้ทางเทคนิคเก่า ๆ ที่ทำขึ้นเพื่อให้การพัฒนา Google Hangouts ง่ายขึ้น
    น่าจะมีไว้เพื่อส่งข้อมูล telemetry ให้ทีม Hangouts โดยตรง Hangouts เป็นแอปแรก ๆ ที่ทำวิดีโอคอลบนเบราว์เซอร์ และสิ่งนี้ภายหลังก็กลายเป็น WebRTC โมดูลนี้เปิดเผยข้อมูลการใช้งาน CPU/GPU/RAM และข้อมูลฮาร์ดแวร์ที่ปกติแอปไม่ควรเห็นได้ Google น่าจะเห็นเธรด Twitter นี้แล้วลบทิ้งไปเฉย ๆ Hangouts ก็เป็นผลิตภัณฑ์ที่ตายไปแล้ว และแม้โค้ดฝั่งเซิร์ฟเวอร์จะยังใช้อยู่ ตอนนี้ขอบเขตการใช้งาน WebRTC ก็กว้างกว่ามาก ดังนั้นทีม Chrome น่าจะมอนิเตอร์ประสิทธิภาพเองในแบบหลายไซต์อยู่แล้ว

    • ไม่ใช่ อันนี้ตอนนี้ Google Meet ใช้อยู่ ถ้าเปิดแผง "Troubleshooting" ของ meet.google.com ใน Chrome จะเห็นการใช้งาน CPU ทั้งระบบแบบเรียลไทม์ :)
    • ถ้าไม่นับเรื่องละเมิดความเป็นส่วนตัว ผมว่ามันเป็นประเด็น ผูกขาดทางการค้า ชัด ๆ ไม่ใช่เหรอ Google กำลังใช้การครองตลาดเบราว์เซอร์ในทางที่ผิด เพื่อให้ผลิตภัณฑ์ของตัวเองได้เปรียบในตลาดวิดีโอคอนเฟอเรนซ์
    • อาจจะใช้ติดตามการใช้งาน CPU/GPU ฯลฯ เพื่อปรับละเอียดว่าจะใช้สตรีมวิดีโอคุณภาพระดับไหนหรือเปล่า
      ถึงจะไม่ใช่มาตรฐาน แต่ถ้าเป็นแอปเนทีฟก็น่าจะทำเรื่องแบบนี้ได้อยู่แล้ว

  • ผมน่าจะอธิบายเรื่องส่วนนี้ได้บ้าง อ้างอิงก่อนว่าผมเป็นอดีตพนักงาน Google
    เคยทำงานกับ GVC ซึ่งเป็นแพลตฟอร์มวิดีโอคอนเฟอเรนซ์ภายในของ Google อยู่ช่วงหนึ่ง ตอนปี 2010–2011 อุปกรณ์วิดีโอคอนเฟอเรนซ์จำนวนมากของบริษัทเป็นอุปกรณ์ proprietary อย่าง Cisco Tandberg ซึ่งราคาแพง ทำให้การกระจายไปยังห้องประชุมหลายพันห้องมีต้นทุนสูง ช่วงเวลาใกล้ ๆ กัน ทีมอื่นกำลังพัฒนา Hangouts อยู่ ผมจำไม่ค่อยได้ว่าตอนนั้นชื่อ Google Meet หรือเปลี่ยนเป็นชื่อนั้นทีหลัง ชื่อ Hangouts น่าจะถูกใช้ตอนที่รวมเข้ากับผลิตภัณฑ์เมื่อ Google+ ออกมา การตั้งค่า GVC มีหลายแบบ แต่ที่พบบ่อยที่สุดคือชุดจอ/คอมพิวเตอร์แบบ All-in-One (AIO) และมันเป็นพีซี Intel เต็มรูปแบบ ดังนั้นแพลตฟอร์ม GVC จึงเป็น Linux distro แบบคัสตอม ออกแบบมาให้สื่อสารกับบริการของ Google และกระจายซอฟต์แวร์อัปเดตได้ ยังเก็บ distro เก่าไว้เผื่อบูตล้มเหลว และมีปัญหาอื่น ๆ เช่นการตั้งชื่ออุปกรณ์ ต้องรองรับฮาร์ดแวร์หลากหลายอย่าง เช่น แผงสัมผัส กล้อง PTZ ขนาดใหญ่ และไมโครโฟนหลายตัว ท้ายที่สุด Hangouts ก็กลายเป็นสแต็กพื้นฐานของ GVC และแทนที่ Tandberg ได้เกือบทั้งหมด ช่วยประหยัดเงินจำนวนมาก ระบบนี้ใช้อยู่แน่นอนจนถึงปี 2017 หลังจากนั้นไม่รู้ การมอนิเตอร์ก็เป็นส่วนหนึ่งของเรื่องนั้น ดังนั้นถ้าเห็น API เฉพาะ *.google.com ก็ต้องดูให้ละเอียด จากแค่ Tweet บอกไม่ได้ว่า Google สามารถตรวจสอบ Chrome ทุกอินสแตนซ์ทั่วโลกได้หรือว่าใช้ได้เฉพาะบน google.com เท่านั้น แต่ดูจากชื่อ hangouts_services และข้อจำกัดโดเมนแล้ว มีความเป็นไปได้สูงว่าเป็นการรองรับการมอนิเตอร์ Chrome แบบฝังตัวสำหรับ GVC ผมอาจผิดก็ได้

    • ผมว่าไม่น่าใช่เรื่องนั้น เมื่อกี้ลอง โทรผ่าน Meet ใน Firefox ดู พอกดปุ่มแก้ปัญหา กราฟ CPU จะถูกปิดใช้งาน และมีข้อความว่า "ถ้าต้องการดูการใช้งาน CPU ให้ลองใช้ Chrome"
      ใน Chrome จะดูการใช้งาน CPU ได้ แม้ไม่รู้ว่าเป็น CPU ที่ Meet ใช้หรือทั้งระบบ แต่ไม่ว่าจะอย่างไหนก็ไม่น่าเป็นสิ่งที่ API ทั่วไปทำได้ ลองตรวจสอบด้วยงานเบื้องหลัง yes หลายตัวแล้ว ชัดเจนว่าเป็นทั้งระบบ เสริมอีกนิด เรื่องชื่อสับสนเกิดขึ้นตลอด แต่ GVC เป็นชื่อที่ชัดเจนและดีมากจริง ๆ
    • เป็นเรื่องที่น่าสนใจ แต่ดูไม่น่าจะเกี่ยวข้องกับกรณีนี้แม้แต่นิดเดียว คนที่ดูแลแพลตฟอร์ม GCV ด้วย Linux distro แบบคัสตอมคงไม่เลือกวิธี “เอาส่วนขยายคัสตอมที่เราสร้างไปใส่ไว้ใน Chrome ทุกชุดที่ติดตั้งทั่วโลก” เพื่อรายงานสถิติของเครื่องหรอก
      ลองทำเองได้จากหน้า *.google.com ใด ๆ:
      chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });
    • ผมไม่ค่อยเข้าใจความต่างระหว่าง “Google ตรวจสอบ Chrome ทุกอินสแตนซ์ทั่วโลกได้หรือไม่ หรือทำได้เฉพาะบน google.com”
      ดูเหมือน API จะถูกเปิดให้เฉพาะคอนเทนต์ที่รันบน *.google.com แต่ถึงอย่างนั้นก็แทบเท่ากับว่า “Google ตรวจสอบ Chrome ทุกอินสแตนซ์ที่เข้าชมไซต์ของตัวเองได้” อยู่ดี ต่อให้ไม่ได้ใช้บริการ Google หน้าแท็บใหม่ของ Chrome โดยค่าเริ่มต้นก็ดึงคอนเทนต์จาก Google ดังนั้นในทางปฏิบัติแทบจะใกล้ 100% ผมไม่ได้คิดว่าจะถูกใช้ในทางร้าย แต่ถ้า Google สามารถวินิจฉัยปัญหาด้วยวิธีนี้ได้ ในขณะที่คู่แข่งในตลาดเดียวกันทำไม่ได้ มันก็ยังเป็นปัญหาอยู่ดี Zoom ไม่มี API แบบนี้ใช่ไหม?
    • ผมไม่เคยทำงานที่ Google แต่คำอธิบายนี้ฟังไม่ค่อยขึ้น
      หมายความว่าเพื่อสังเกตการใช้งาน CPU บนอุปกรณ์ภายในของแพลตฟอร์มวิดีโอคอนเฟอเรนซ์ภายใน เลยใส่ปลั๊กอินแบบบันเดิลนี้เข้าไปใน Google Chrome สำหรับผู้ใช้ทั่วไปงั้นเหรอ?
    • น่าสนใจ บางทีแม้แต่คนส่วนใหญ่ใน Google เองก็อาจไม่รู้มาก่อนว่าทำแบบนี้ได้
      ตอนนี้คงมีผู้จัดการผลิตภัณฑ์หลายสิบคนกำลังเดินไปหาหัวหน้าฝ่ายเทคนิคของผลิตภัณฑ์ตัวเองแล้วพูดว่า “เอาล่ะ ฟังก่อนนะ…”

  • ฟีเจอร์นี้ดูเหมือนจะถูกเพิ่มเข้ามาในเดือนตุลาคม 2013: https://github.com/chromium/chromium/commit/422c736b82e7ee76...
    เป็นคอมมิตที่บันเดิลส่วนขยาย Hangouts Services เข้ากับ Chrome BUG=291271, URL รีวิว: https://codereview.chromium.org/35873003 URL รีวิวดังกล่าวคือ https://codereview.chromium.org/35873003

  • ไม่รู้แน่ชัดว่า API นี้คืออะไรและมีไว้ทำไม แต่ Firefox ก็ทำอะไรคล้าย ๆ กัน
    มี API พิเศษที่ใช้ได้เฉพาะบนโดเมนของ Mozilla และ Firefox เช่น สำหรับช่วยติดตั้งส่วนขยายหรือช่วยประสบการณ์การใช้งานครั้งแรก ไม่ถึง 12 เดือนก่อนมีบล็อกโพสต์ที่เกี่ยวข้องขึ้น Hacker News แต่หายาก

    • ไม่ใช่เรื่องเดียวกันเสียทีเดียว
      API เปิดเผยต่อสาธารณะและมีเอกสารประกอบ ส่วนรายการโดเมนที่อนุญาตก็อยู่ใน UI และ about:config เวอร์ชัน Android Play Store เป็นข้อยกเว้น เพราะซ่อนทุกอย่างไว้ราวกับตั้งใจจะทำให้เบราว์เซอร์กลายเป็นขยะล้วน ๆ และถ้ายกกรณีการใช้งานที่ดีแล้วไปขออย่างสุภาพใน Bugzilla นักพัฒนาก็น่าจะอย่างน้อยพิจารณาเพิ่มโดเมนเริ่มต้นให้
    • นั่นเป็นสำหรับเว็บไซต์ที่เกี่ยวข้องโดยตรงกับการทำงานของเบราว์เซอร์ ในขณะที่ Chrome เปิด API ที่ใช้ในผลิตภัณฑ์ Google แยกต่างหากอย่าง Google Meet
      นี่อาจเป็นการละเมิดกฎหมายต่อต้านการผูกขาด เพราะใช้การผูกขาดในตลาดหนึ่ง คือเบราว์เซอร์ เพื่อให้ได้เปรียบในอีกตลาดหนึ่ง คือวิดีโอคอนเฟอเรนซ์
    • ผมเคยเขียนเรื่องส่วน UITour ไว้นานแล้ว: https://www.mkelly.me/blog/content-uitourjs/
      ในหมู่เบราว์เซอร์ถือเป็นแนวทางที่ค่อนข้างเป็นมาตรฐาน ระดับความเสี่ยงควรใกล้เคียงกับกรณีที่มีใครปลอมโดเมนที่เบราว์เซอร์ใช้ดาวน์โหลดอัปเดตซอฟต์แวร์ และถ้าไม่ชอบจริง ๆ ก็ปิดได้ในการตั้งค่า
    • เดือนที่แล้วมีการแชร์คอมมิต Quirks.cpp ของ WebKit [0] อาจไม่ใช่สิ่งที่ตามหาอยู่ แต่ให้ความรู้สึกคล้ายกัน
      [0] https://news.ycombinator.com/item?id=40631439
    • API พวกนั้นเกี่ยวข้องกับฟีเจอร์ของเบราว์เซอร์และการเริ่มใช้งาน ไม่ได้ใส่เข้ามาเพื่อทำให้ผลิตภัณฑ์อื่นของ Mozilla ได้เปรียบเหนือผลิตภัณฑ์คล้ายกันของบริษัทอื่น

  • เผื่อเป็นข้อมูล ผมทำงานที่ Google แต่ไม่ได้ดูแล Chrome หรือ API นี้
    ผมมองว่าคำอธิบายค่อนข้างธรรมดา เช่น เปิด Google Meet แล้วเริ่มห้องประชุมเปล่า ๆ หรือ “ประชุมทันที” จากนั้นกด “การแก้ปัญหาและความช่วยเหลือ” ในเมนู “…” จะเห็นกราฟสถิติต่าง ๆ รวมถึงอัตราการใช้ CPU ดูเหมือนว่าระหว่างโทรผ่าน Meet ถ้าเครื่องมีโหลดสูง มันก็อาจเสนออย่างสุภาพให้ปิดแท็บด้วย ค่อนข้างมีประโยชน์ ผมเข้าไปดูเป็นครั้งคราว พอมาคิดอีกที ผมไม่แน่ใจว่ามีคำแนะนำให้ปิดแท็บจริงหรือไม่ สิ่งที่ผมเคยใช้จริงคือหน้าจอสถิติเท่านั้น

    • ตรงข้ามกับคำอธิบายว่า “ค่อนข้างธรรมดา” เรื่องนี้ไม่ธรรมดาเลย นี่เป็นตัวอย่างที่สมบูรณ์แบบของการให้ ความได้เปรียบในการแข่งขันอย่างไม่เป็นธรรม แก่ผลิตภัณฑ์ของตัวเอง
      ผู้ใช้ Meet จะได้รับคำแนะนำว่าทำไมการประชุมถึงทำงานไม่ดี แต่ถ้า Zoom, Teams, Slack ทำแบบเดียวกันไม่ได้ ประสบการณ์ใช้งาน Meet ก็ย่อมดีขึ้น ไม่แปลกที่บริการประชุมอื่น ๆ ทั้งหมดผลักดันให้ใช้แอปเดสก์ท็อปอย่างจริงจัง แอปเดสก์ท็อปของ Google Meet ก็คือ Chrome นั่นเอง
    • นั่นแหละคือประเด็น เครื่องมือวิดีโอคอนเฟอเรนซ์อื่น ๆ ไม่สามารถให้ ตัวเลือกดีบัก แบบนี้ได้ และอย่างที่เพิ่งพูดไป ฟีเจอร์นี้มีประโยชน์
    • คู่แข่งอย่าง Zoom มีเวอร์ชันบนเบราว์เซอร์ ใช้ API นี้เพื่อวินิจฉัยปัญหาประสิทธิภาพได้ไหม? ถ้าไม่ได้ หน่วยงานกำกับดูแลของยุโรปอาจสนใจ
      บางทีนี่อาจเป็นหนึ่งในเหตุผลที่ Meet ทำงานได้ดีบนเบราว์เซอร์แต่ Zoom ไม่เป็นเช่นนั้น โดยเฉพาะเมื่อมีผู้เข้าร่วมประชุมจำนวนมาก ผู้ใช้ Zoom ที่ต้องการประสิทธิภาพเหมาะสมจึงต้องหันไปใช้แอปเนทีฟ
    • เยี่ยมมากที่ Google สร้าง เบราว์เซอร์ที่ต่อต้านการแข่งขัน ซึ่งมีฟีเจอร์ที่เป็นประโยชน์เฉพาะกับตัวเอง
      ขอบคุณที่พนักงาน Google พูดส่วนที่คนอื่นคงปล่อยผ่านเงียบ ๆ ออกมาให้เอง
    • การถ่ายโอนอำนาจผูกขาด ไม่ใช่เรื่องธรรมดา แต่เป็นสิ่งผิดกฎหมาย

  • ดูเหมือนว่าตอนเปลี่ยนชื่อเรื่องที่ส่งมาจากต้นฉบับจะคลาดเคลื่อนไปเล็กน้อย เท่าที่ผมเข้าใจคือแบบนี้
    Chrome มีส่วนขยายในตัวที่ใช้ Chrome API สาธารณะ ซึ่งส่วนขยาย Chrome อื่น ๆ ก็ใช้ได้ง่ายเช่นกัน ปัญหาคือส่วนขยายนี้แชร์ข้อมูลดังกล่าวเมื่อสื่อสารกับโดเมนของ Google เอง แต่เว็บไซต์อื่นทำแบบนั้นไม่ได้ ไม่มี “API พิเศษที่ซ่อนอยู่”

    • ที่ว่า “พิเศษ” หมายถึงมัน ฝังอยู่ใน Chrome ไม่ใช่ส่วนขยายที่ผู้ใช้ติดตั้งเหมือนส่วนขยายอื่น ๆ
      ที่ว่า “ซ่อนอยู่” หมายถึงไปที่ chrome://extensions แล้วก็ไม่เห็นในรายการ และอย่างที่บอกไปแล้ว มันก็เป็น Chrome API ด้วย
    • ถ้าลองวางสิ่งนี้ลงในคอนโซล Chrome DevTools บนไซต์ของ Google จะดูเหมือนเป็น API พิเศษ:
      chrome.runtime.sendMessage( 'nkeimhogjdpnpccoofpliimaahmaaome', { method: 'cpu.getInfo' }, response => { console.log('CPU Info:\n', JSON.stringify(response, null, 2)); } );
    • แม้จะเป็น “ส่วนขยายในตัว” แต่ถ้าปิดใช้งานไม่ได้ มันก็ยังเป็นส่วนหนึ่งของเบราว์เซอร์อยู่ดี
    • มีคำอธิบายที่ไม่เป็นพิษภัยและเรียบง่ายได้เช่นกัน ลองนึกภาพว่าส่วนหนึ่งของฟีเจอร์เบราว์เซอร์ไม่ได้คอมไพล์/ลิงก์เป็น C++ แต่ถูก implement เป็นเว็บแอปที่เซ็นโดย google.com
      ถ้าโค้ดของเบราว์เซอร์ที่ implement เป็น PWA ต้องขอสิทธิ์พิเศษเพื่อเข้าถึงข้อมูลระบบ ก็คงแปลก เพราะมันเป็นส่วนหนึ่งของฟีเจอร์เบราว์เซอร์เอง การใช้งานอีกแบบของ API ส่วนตัวที่มีมานานคือการผสานเว็บไซต์เฉพาะของ Google ที่ให้ฟีเจอร์หลักอย่าง Chrome Web Store เข้ากับเบราว์เซอร์ Chrome เพื่อให้หน้าเว็บอนุญาตการติดตั้งและลบส่วนขยายได้
    • ในเชิงฟังก์ชันก็เป็นเรื่องเดียวกัน

  • นี่ดูเหมือนใช้ API chrome.system.cpu ซึ่ง extension ใด ๆ ก็เข้าถึงได้ถ้ามีสิทธิ์ "system.cpu"
    https://developer.chrome.com/docs/extensions/reference/api/s...
    สิทธิ์ทั้งหมดที่ extension นี้ร้องขอดูได้ที่นี่:
    https://source.chromium.org/chromium/chromium/src/+/main:chr...

    • ใช่ และนั่นแหละคือปัญหา Google ใส่ extension ที่ไม่เกี่ยวกับการทำงานของตัวเบราว์เซอร์เองมาแบบ bundled ใน Chrome เพื่อให้สิทธิ์เข้าถึงแบบพิเศษแก่ผลิตภัณฑ์อีกตัวอย่าง Hangouts
      แอปประชุมวิดีโออื่น ๆ ไม่มีสิทธิ์เข้าถึงแบบนี้ เว้นแต่ผู้ใช้จะผ่านขั้นตอนใหญ่ในการติดตั้ง extension แยกเองด้วยมือ

  • ไม่ค่อยน่าแปลกใจเท่าไร เป็นพฤติกรรมที่ Google มาก ๆ ประเด็นคือใน เบราว์เซอร์ Chromium ตัวอื่น ๆ มีสิ่งนี้ด้วยหรือเปล่า แล้ว Edge, Brave, Chromium, Ungoogled Chromium ล่ะ?

    • ตัวอื่นไม่รู้ แต่ ungoogled chromium น่าจะไม่มี เพราะจงใจสลับปนทุกส่วนในโค้ดที่มีสตริง "google" เพื่อหลีกเลี่ยงของพวกนี้
    • Edge เปิดใช้งานอยู่ ถ้าเปิดการแก้ปัญหา Google Meet บน Edge จะเห็น CPU ของระบบได้
      ถ้าลองบน Firefox จะขึ้นว่า “ถ้าต้องการดูการใช้งาน CPU ให้ลองใช้ Google Chrome”

  • Safari ก็มีฟีเจอร์เฉพาะของ Apple เช่นกัน ตัวอย่างเช่น เวลาล็อกอินเข้าเว็บไซต์อื่นด้วยบัญชี Apple สามารถเปิดกล่องโต้ตอบพิเศษที่ทำงานต่างจาก passkey หรือการเติมรหัสผ่านอัตโนมัติได้
    ส่วนเบราว์เซอร์อื่นจะให้ผ่าน flow แบบ redirect แทน ผมสงสัยมาตลอดว่าสิ่งนี้ถูก implement ใน JavaScript อย่างไร เป็นอะไรคล้าย WebAuthn ที่ใส่อาร์กิวเมนต์เฉพาะของตัวเองหรือเปล่า?

  • Google เคยทำแบบนี้มาก่อน รายละเอียดค่อนข้างเลือนรางแล้ว แต่เหมือนว่า Native Client เคยถูกตั้งค่าให้ทำงานได้เฉพาะใน Hangouts ผ่าน allowlist ระดับโดเมน หรืออะไรทำนองนั้น