HTML Permission Element ใหม่ของ Chrome เผชิญการต่อต้านอย่างแรงจาก Firefox และ Safari

ทีมบรรณาธิการ BigGo

HTML Permission Element ใหม่ของ Chrome เผชิญการต่อต้านอย่างแรงจาก Firefox และ Safari

Google Chrome กำลังดำเนินการต่อกับ HTML <permission> element ใหม่ที่ถือเป็นที่ถกเถียง แม้จะเผชิญการต่อต้านอย่างแรงจากทั้ง Mozilla Firefox และ Apple Safari ฟีเจอร์นี้ซึ่งอยู่ในช่วง origin trials เริ่มตั้งแต่ Chrome 122 มีเป้าหมายเพื่อแทนที่ permission pop-ups แบบเดิมด้วย inline declarative HTML elements ที่เว็บไซต์สามารถฝังลงในหน้าเว็บของตนได้โดยตรง

element ใหม่นี้ช่วยให้นักพัฒนาสามารถขอ browser permissions เช่น การเข้าถึงกล้อง ไมโครโฟน และตำแหน่งที่ตั้งผ่าน HTML markup แทนที่จะใช้ JavaScript calls แทนที่จะเป็น modal dialogs ที่คุ้นเคยซึ่งขัดจังหวะการเรียกดูเว็บของผู้ใช้ <permission> element จะแสดงเป็นส่วนหนึ่งของเนื้อหาเว็บเพจ โดยแสดงสถานะต่างๆ ตามว่าการอนุญาตได้รับการอนุมัติ ปฏิเสธ หรือรอดำเนินการ

ประเภทสิทธิ์การเข้าถึงที่รองรับ ( Chrome 122 Trial )

การเข้าถึงกล้อง
การเข้าถึงไมโครโฟน
ข้อมูลตำแหน่งทางภูมิศาสตร์

ตำแหน่งของผู้จำหน่ายเบราว์เซอร์

** Chrome **: กำลังดำเนินการใน origin trials
** Firefox **: มีตำแหน่งคัดค้านอย่างเป็นทางการ
** Safari / WebKit **: มีตำแหน่งคัดค้านอย่างเป็นทางการ


คำแนะนำสำหรับการเปิดใช้งานการเข้าถึงไมโครโฟนในเบราว์เซอร์ของคุณขณะใช้งาน Google Meet

ความขัดแย้งในกระบวนการมาตรฐาน

ความกังวลที่สำคัญที่สุดที่ชุมชนนักพัฒนาได้ยกขึ้นคือการตัดสินใจของ Google ที่จะดำเนินการต่อกับการพัฒนาแม้จะเผชิญการต่อต้านอย่างเป็นทางการจากผู้ให้บริการเบราว์เซอร์รายใหญ่อื่นๆ ทั้ง Mozilla และ WebKit ได้ออกแถลงการณ์คัดค้านมาตรฐานนี้ แต่ Chrome ยังคงพัฒนาต่อผ่าน origin trials แนวทางนี้ได้รับการวิพากษ์วิจารณ์ว่าอาจทำให้เกิดการแตกแยกของมาตรฐานเว็บและสร้างฟีเจอร์เฉพาะ Chrome ที่เบราว์เซอร์อื่นอาจไม่เคยรองรับ

สถานการณ์นี้เน้นย้ำความตึงเครียดที่เกิดขึ้นอย่างต่อเนื่องในการกำกับดูแลมาตรฐานเว็บ นักวิจารณ์โต้แย้งว่าส่วนแบ่งตลาดที่เหนือกว่าของ Chrome ทำให้ Google สามารถบังคับการยอมรับฟีเจอร์ต่างๆ ได้โดยไม่คำนึงถึงฉันทามติของอุตสาหกรรม ซึ่งทำลายกระบวนการมาตรฐานแบบร่วมมือที่เคยควบคุมการพัฒนาเว็บมาโดยตลอด

ความกังวลด้านความปลอดภัยและประสบการณ์ผู้ใช้

การอพิปรายของนักพัฒนาเผยให้เห็นความสงสัยอย่างลึกซึ้งเกี่ยวกับผลกระทบด้านความปลอดภัยของการย้าย permission requests เข้าไปในเนื้อหาเว็บเพจ ลักษณะ inline ของ element นี้ทำให้เกิดความกังวลเกี่ยวกับการโจมตี clickjacking ซึ่งเว็บไซต์ที่เป็นอันตรายสามารถวาง elements ที่มองไม่เห็นทับซ้อนเพื่อหลอกให้ผู้ใช้อนุญาต permissions โดยไม่ตั้งใจ

ข้อจำกัดในการจัดรูปแบบที่กำหนดให้กับ element นี้สร้างความท้าทายเพิ่มเติม แม้ว่า Google จะจำกัดวิธีที่เว็บไซต์สามารถปรับแต่งรูปลักษณ์เพื่อป้องกันการใช้ในทางที่ผิด แต่นักพัฒนากังวลว่าสิ่งนี้จะสร้างประสบการณ์ผู้ใช้ที่ไม่ลงตัวซึ่งปุ่ม permission ไม่เข้ากับการออกแบบไซต์ ข้อจำกัดเหล่านี้ดูเหมือนจะไม่เพียงพอในการป้องกันการโจมตี social engineering ที่ซับซ้อน

มันทำให้ผู้ใช้เปิดใช้งาน permissions ได้ง่ายขึ้น รวมถึงการเปิดโดยบังเอิญด้วย จึงลดความปลอดภัยและความเป็นส่วนตัว ผลิตภัณฑ์ของ Google ถูกออกแบบมาเพื่อใช้ประโยชน์จากสิ่งนั้น

ปัญหาการใช้งานทางเทคนิค

ชุมชนได้ระบุปัญหาทางเทคนิคหลายประการกับข้อเสนอปัจจุบัน พฤติกรรมของ element ดูเหมือนจะไม่สอดคล้องกับรูปแบบ HTML มาตรฐาน และลักษณะ declarative ของมันถูกตั้งคำถามเนื่องจาก permissions พื้นฐานยังคงต้องใช้ JavaScript เพื่อให้ทำงานได้อย่างมีความหมาย

นักพัฒนายังสังเกตเห็นการขาดฟังก์ชันการทำงานเมื่อเปรียบเทียบกับ permission APIs ที่มีอยู่ เวอร์ชัน trial ขาดตัวเลือกสำหรับการบล็อก permissions อย่างถาวร โดยมีเพียงตัวเลือก allow on every visit และ allow this time เท่านั้น ความไม่สมดุลนี้ชี้ให้เห็นว่าฟีเจอร์นี้อาจถูกออกแบบมาเพื่อส่งเสริมการให้ permission มากกว่าที่จะปรับปรุงการควบคุมของผู้ใช้อย่างแท้จริง

ตัวอย่างไวยากรณ์ของ Permission Element

&lt;permission name="camera"&gt;
  &lt;span&gt;อนุญาตการเข้าถึงแล้ว&lt;/span&gt;
  &lt;span slot="denied"&gt;ปฏิเสธการเข้าถึง&lt;/span&gt;
  &lt;button slot="prompt"&gt;ขอสิทธิ์การเข้าถึง&lt;/button&gt;
&lt;/permission&gt;

คุณสมบัติหลัก

name: ประเภทของสิทธิ์การเข้าถึง (camera, microphone, geolocation)
granted: เนื้อหาที่แสดงเมื่อได้รับอนุญาตให้เข้าถึง
denied: เนื้อหาที่แสดงเมื่อถูกปฏิเสธการเข้าถึง
prompt: เนื้อหาที่แสดงเมื่อสถานะการอนุญาตยังไม่ทราบแน่ชัด

ผลกระทบต่อตลาดและแนวโน้มในอนาคต

ความขัดแย้งนี้สะท้อนความกังวลที่กว้างขึ้นเกี่ยวกับอิทธิพลของ Google ต่อมาตรฐานเว็บผ่านการครอบงำตลาดของ Chrome นักพัฒนาหลายคนกลัวว่าการใช้งานฟีเจอร์เฉพาะ Chrome ที่ประสบความสำเร็จจะกดดันให้เบราว์เซอร์อื่นๆ ต้องนำไปใช้ย้อนหลัง โดยไม่คำนึงถึงคุณค่าทางเทคนิคหรือความกังวลด้านความปลอดภัย

สถานการณ์นี้สะท้อนกรณีก่อนหน้านี้ที่ Google แนะนำฟีเจอร์ต่างๆ แบบเดี่ยว ซึ่งภายหลังบังคับให้อุตสาหกรรมต้องยอมรับ เมื่อนักพัฒนาเว็บพึ่งพา Chrome-specific APIs มากขึ้นเรื่อยๆ permission element อาจกลายเป็นอีกตัวอย่างหนึ่งของการสร้างมาตรฐานแบบ de facto ผ่านอำนาจตลาดมากกว่าการพัฒนาที่อิงฉันทามติ

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

อ้างอิง: An origin trial for a new HTML element

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

‌

‌
‌

‌

‌
‌

‌