แนวทางปฏิบัติแนะนำสำหรับสิทธิ์บนเว็บ

ข้อความแจ้งสิทธิ์เป็นกลไกหลักของเว็บในการปกป้องความสามารถที่มีประสิทธิภาพซึ่งอาจเป็นอันตรายต่อความเป็นส่วนตัวและความปลอดภัยของผู้ใช้ พรอมต์สิทธิ์ช่วยให้เบราว์เซอร์มั่นใจว่าผู้ใช้ตั้งใจที่จะอนุญาตให้เว็บไซต์ที่ขอเข้าถึงความสามารถดังกล่าว ข้อความแจ้งสิทธิ์จะใช้กับ API จํานวนหนึ่ง ซึ่งรวมถึงการจับภาพสื่อ (กล้องและไมโครโฟน) ตําแหน่งทางภูมิศาสตร์ การเข้าถึงพื้นที่เก็บข้อมูล MIDI และการแจ้งเตือน (ดูข้อมูลเพิ่มเติมในเอกสารประกอบ Permissions API ใน MDN)

คู่มือนี้จะกล่าวถึงแนวทางปฏิบัติแนะนำในการแสดงข้อความแจ้งสิทธิ์แก่ผู้ใช้โดยอิงตามสถิติการใช้งาน Chrome และการวิจัยผู้ใช้ เมื่อทำตามแนวทางปฏิบัติแนะนำเหล่านี้ ผู้ใช้ควรเห็นข้อความแจ้งที่ไม่จำเป็นน้อยลง ซึ่งจะทำให้นักพัฒนาแอปได้รับคำตัดสิน "บล็อก" น้อยลง บทความจะจบลงด้วยรูปแบบโค้ดบางส่วนสําหรับการทํางานกับ API ที่มีการกำหนดสิทธิ์ และแนวทางปฏิบัติแนะนำในการช่วยให้ผู้ใช้กู้คืนจากสถานะที่ถูกบล็อก

แนวทางปฏิบัติแนะนำเกี่ยวกับพรอมต์

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

ไม่ต้องถามเมื่อโหลดหน้าเว็บหรือไม่มีการโต้ตอบของผู้ใช้

การขอสิทธิ์จากผู้ใช้ในการโหลดหน้าเว็บจะเทียบเท่ากับการขอข้อมูลที่ละเอียดอ่อนจากลูกค้าในขณะที่เดินเข้าไปในกิจการที่มีหน้าร้านจริง การเห็นข้อความแจ้งเกี่ยวกับสิทธิ์ (ซึ่งอาจรวมถึงข้อความแจ้งอื่นๆ เกี่ยวกับการสมัครรับจดหมายข่าวและความยินยอมในการใช้คุกกี้) เป็นประสบการณ์ที่น่าประหลาดใจ ผู้ใช้จะไม่เข้าใจเหตุผลที่ระบบขอและประโยชน์ที่จะได้รับ

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

สถานการณ์ที่ไม่ดีเช่นเดียวกันกับการขอสิทธิ์คือการไม่ให้มีการโต้ตอบกับผู้ใช้ก่อนหน้านี้ (หรือที่เรียกว่าการเปิดใช้งานผู้ใช้ชั่วคราว) การตรวจวัดระยะไกลของ Chrome แสดงให้เห็นว่า 77% ของข้อความแจ้งสิทธิ์บนเดสก์ท็อป Chrome แสดงขึ้นโดยไม่มีสัญญาณพื้นฐานที่บอกถึงความตั้งใจของผู้ใช้ ดังนั้นจึงมีเพียง 12% ของพรอมต์ดังกล่าวที่ได้รับอนุญาต หลังจากการโต้ตอบของผู้ใช้ อัตราอนุญาตจะเพิ่มขึ้นเป็น 30% ดังนั้น ให้ขอสิทธิ์หลังจากที่ผู้ใช้โต้ตอบกับหน้าเว็บแล้ว

ขอเฉพาะเมื่อผู้ใช้เข้าใจเหตุผลที่คุณขอ

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

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

เสนอวิธีอื่นในฟังก์ชันการทำงานเดียวกันนี้เมื่อเป็นไปได้

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

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

อย่าทำให้ตัวเองอยู่ในสถานะที่ถูกบล็อก เพราะจะกู้คืนได้ยาก

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

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

ให้ความสำคัญกับเนื้อหาของบุคคลที่สาม

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

กรณีที่ควรขอสิทธิ์

ต่อไปนี้เป็นตัวอย่างของช่วงเวลาที่เหมาะในการขอสิทธิ์ โดยทำตามแนวทางปฏิบัติแนะนำที่อธิบายไว้แล้ว

  • หลังจากผู้ใช้คลิกปุ่ม "ใช้ตำแหน่งของฉัน" ข้างช่องแบบฟอร์มสำหรับป้อนที่อยู่ด้วยตนเอง
  • หลังจากผู้ใช้ติดตามช่องวิดีโอหรือโพสต์ และคลิกปุ่ม "ตกลง" ในกล่องโต้ตอบที่อธิบายว่าระบบอาจส่งข้อมูลอัปเดตเป็นอีเมลหรือการแจ้งเตือนไปยังโทรศัพท์หรือเดสก์ท็อป
  • หลังจากที่ผู้ใช้มาถึงหน้าที่เตรียมพร้อมให้เข้าร่วมวิดีโอคอลและตอบว่าต้องการให้เห็นและได้ยินเสียงของตนในพรอมต์ก่อนเข้าร่วม (ดูกรณีศึกษานี้จาก Google Meet)

รูปแบบโค้ดสำหรับการขอสิทธิ์

การรับสิทธิ์ในการใช้ API นั้นทำได้หลายวิธี โดยขึ้นอยู่กับ API นั้นๆ API บางรายการ (โดยทั่วไปคือ API เวอร์ชันเก่า) ใช้รูปแบบที่เบราว์เซอร์จะขอสิทธิ์โดยอัตโนมัติเมื่อคุณพยายามใช้ API เป็นครั้งแรก ตัวอย่างหนึ่งคือ Geolocation API เมื่อเรียกใช้ navigator.geolocation.getCurrentPosition()

try {
  navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
  console.error(error);
}

API อื่นๆ ใช้รูปแบบที่คุณต้องขอสิทธิ์อย่างชัดเจนก่อนโดยใช้เมธอดแบบคงที่ ตัวอย่างที่ดีคือ Notification.requestPermission() สำหรับการอนุญาตการแจ้งเตือน หรือ DeviceOrientationEvent.requestPermission() ที่พบไม่บ่อยนัก ซึ่งเป็นส่วนหนึ่งของ Device Orientation Events API โปรดทราบว่าเบราว์เซอร์บางตัวอาจให้สิทธิ์แก่ API บางรายการโดยอัตโนมัติ ตัวอย่างเช่น Chrome อนุญาตให้เข้าถึงการวางแนวของอุปกรณ์เสมอ ในขณะที่ Safari จะแสดงข้อความแจ้ง

const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
  /* Use the API. */
}

วิธีตรวจสอบสถานะสิทธิ์

หากต้องการตรวจสอบว่าคุณใช้ API บางรายการได้หรือไม่ ให้ใช้เมธอด navigator.permissions.query() จาก Permissions API

const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
  // Use the API.
}

การรองรับเบราว์เซอร์

  • Chrome: 43.
  • Edge: 79
  • Firefox: 46
  • Safari: 16

แหล่งที่มา

ช่วยให้ผู้ใช้กู้คืนจากสถานะที่ถูกบล็อก

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

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

การควบคุมเว็บไซต์ในเบราว์เซอร์ Chrome

ข้อความแจ้งให้โหลดซ้ำหลังจากเปลี่ยนสิทธิ์โดยใช้การควบคุมเว็บไซต์

UI ที่คล้ายกันสำหรับการควบคุมสิทธิ์มีอยู่ในเบราว์เซอร์อื่นๆ (เช่น ดูวิธีการทำงานของส่วนนี้ใน Firefox)