Chrome กำลังยุติการสนับสนุนคุกกี้ของบุคคลที่สามเพื่อลดการติดตามข้ามเว็บไซต์ ซึ่งถือเป็นความท้าทายอย่างมากสำหรับเว็บไซต์และบริการที่ต้องอาศัยคุกกี้ในบริบทที่ฝังไว้ในเส้นทางของผู้ใช้ เช่น การตรวจสอบสิทธิ์ Storage Access API (SAA) ช่วยให้ Use Case เหล่านี้ทำงานต่อไปได้และจํากัดการติดตามข้ามเว็บไซต์ให้ได้มากที่สุด
สถานะการใช้งาน
Storage Access API พร้อมใช้งานในเบราว์เซอร์หลักๆ ทั้งหมด แต่มีความแตกต่างในการใช้งานเล็กน้อยระหว่างเบราว์เซอร์ต่างๆ ความแตกต่างเหล่านี้ได้รับการไฮไลต์ไว้ในส่วนที่เกี่ยวข้องของโพสต์นี้
งานยังคงแก้ไขปัญหาการบล็อกที่เหลืออยู่ทั้งหมดอย่างต่อเนื่องก่อนที่จะทำให้ API เป็นมาตรฐาน
Storage Access API คืออะไร
Storage Access API คือ JavaScript API ที่อนุญาตให้ iframe ขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลเมื่อการตั้งค่าเบราว์เซอร์อาจปฏิเสธการเข้าถึง ฝังพร้อม Use Case ที่ขึ้นอยู่กับการโหลดทรัพยากรข้ามเว็บไซต์จะใช้ API เพื่อขอสิทธิ์เข้าถึงจากผู้ใช้ตามความจำเป็นได้
หากคำขอพื้นที่เก็บข้อมูลได้รับอนุมัติ iframe จะมีสิทธิ์เข้าถึงคุกกี้ข้ามเว็บไซต์ ซึ่งพร้อมใช้งานเมื่อผู้ใช้เข้าชมในฐานะเว็บไซต์ระดับบนสุด
Storage Access API ช่วยให้ผู้ใช้ปลายทางเข้าถึงคุกกี้ข้ามเว็บไซต์ได้โดยสร้างภาระให้ผู้ใช้ปลายทางน้อยที่สุด ในขณะเดียวกันก็ยังป้องกันไม่ให้มีการเข้าถึงคุกกี้ข้ามเว็บไซต์ทั่วไปเหมือนอย่างที่ใช้ในการติดตามผู้ใช้
Use Case
การฝังของบุคคลที่สามบางรายการต้องมีสิทธิ์เข้าถึงคุกกี้ข้ามเว็บไซต์เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีขึ้น ซึ่งเป็นสิ่งที่จะใช้ไม่ได้หลังจากที่เลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว
กรณีการใช้งานมีดังนี้
- วิดเจ็ตการแสดงความคิดเห็นแบบฝังซึ่งต้องดูรายละเอียดเซสชันการลงชื่อเข้าใช้
- ปุ่ม "ชอบ" บนโซเชียลมีเดียซึ่งต้องมีรายละเอียดเซสชันการเข้าสู่ระบบ
- เอกสารที่ฝังซึ่งต้องมีรายละเอียดเซสชันการเข้าสู่ระบบ
- ประสบการณ์การใช้งานระดับพรีเมียมที่มีให้สำหรับการฝังวิดีโอ (เช่น เพื่อไม่แสดงโฆษณาสำหรับผู้ใช้ที่ลงชื่อเข้าสู่ระบบ หรือต้องการทราบค่ากำหนดของผู้ใช้สำหรับคำบรรยายหรือจำกัดวิดีโอบางประเภท)
- ระบบการชำระเงินแบบฝัง
กรณีการใช้งานเหล่านี้จำนวนมากเกี่ยวข้องกับการเข้าสู่ระบบใน iframe ที่ฝังไว้
กรณีที่ควรใช้ Storage Access API มากกว่า API อื่นๆ
Storage Access API เป็นทางเลือกหนึ่งนอกเหนือจากการใช้คุกกี้ของบุคคลที่สาม คุณจึงควรทราบว่าเมื่อใดควรใช้ API นี้เมื่อเทียบกับตัวอื่นๆ แต่มีไว้สำหรับกรณีการใช้งานที่ทั้งสองกรณีต่อไปนี้เป็นจริง
- ผู้ใช้จะโต้ตอบกับเนื้อหาที่ฝัง ซึ่งหมายความว่าไม่ใช่ iframe แบบแพสซีฟหรือ iframe ที่ซ่อนอยู่
- ผู้ใช้เข้าชมต้นทางที่ฝังในบริบทระดับบนสุด กล่าวคือ เมื่อต้นทางนั้นไม่ได้ฝังในเว็บไซต์อื่น
เรามี API ทางเลือกสำหรับการใช้งานที่หลากหลาย ดังนี้
- คุกกี้ที่มีสถานะพาร์ติชันอิสระ (CHIPS) ช่วยให้นักพัฒนาซอฟต์แวร์เลือกใช้คุกกี้ในพื้นที่เก็บข้อมูลที่ "แบ่งพาร์ติชันแล้ว" โดยมีโถคุกกี้แยกต่างหากสำหรับแต่ละเว็บไซต์ระดับบนสุด เช่น วิดเจ็ตแชทบนเว็บของบุคคลที่สามอาจอาศัยการตั้งค่าคุกกี้เพื่อบันทึกข้อมูลเซสชัน ข้อมูลเซสชันจะได้รับการบันทึกไว้ตามเว็บไซต์นั้นๆ ดังนั้น คุกกี้ที่ตั้งค่าโดยวิดเจ็ตจึงไม่จําเป็นต้องมีการเข้าถึงในเว็บไซต์อื่นๆ ที่มีการฝังไว้เช่นกัน Storage Access API จะมีประโยชน์เมื่อวิดเจ็ตของบุคคลที่สามที่ฝังอยู่อาศัยการแชร์ข้อมูลเดียวกันในต้นทางต่างๆ (เช่น รายละเอียดหรือค่ากำหนดเซสชันที่เข้าสู่ระบบ)
- ชุดเว็บไซต์ที่เกี่ยวข้อง (RWS) เป็นวิธีสำหรับองค์กรในการประกาศความสัมพันธ์ระหว่างเว็บไซต์ เพื่อให้เบราว์เซอร์อนุญาตการเข้าถึงคุกกี้ของบุคคลที่สามแบบจำกัดเพื่อวัตถุประสงค์บางอย่าง เว็บไซต์ยังคงต้องขอสิทธิ์เข้าถึงด้วย Storage Access API แต่เว็บไซต์ภายในชุดจะให้สิทธิ์เข้าถึงได้โดยไม่ต้องมีข้อความแจ้งจากผู้ใช้
- การจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์ (FedCM) คือแนวทางการรักษาความเป็นส่วนตัวของบริการระบุตัวตนแบบรวมศูนย์ Storage Access API จะจัดการกับคุกกี้หลังการเข้าสู่ระบบ สำหรับการใช้งานในบางกรณี FedCM เป็นโซลูชันทางเลือกสำหรับ Storage Access API และอาจเหมาะสมกว่าเนื่องจากมีข้อความแจ้งของเบราว์เซอร์ที่เน้นการเข้าสู่ระบบมากกว่า อย่างไรก็ตาม การนำ FedCM มาใช้มักต้องเปลี่ยนแปลงโค้ดเพิ่มเติม เช่น เพื่อรองรับปลายทาง HTTP
- นอกจากนี้ยังมี API ป้องกันการฉ้อโกง ที่เกี่ยวข้องกับโฆษณา และการวัดผลด้วย และ Storage Access API ไม่ได้มีไว้เพื่อแก้ปัญหาดังกล่าว
การใช้ Storage Access API
Storage Access API มีวิธีการตามที่สัญญาไว้ 2 วิธีดังนี้
และยังผสานรวมกับ Permissions API ด้วย วิธีนี้จะช่วยให้คุณตรวจสอบสถานะของสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลในบริบทของบุคคลที่สามได้ ซึ่งจะระบุว่าการเรียก document.requestStorageAccess() จะได้รับโดยอัตโนมัติหรือไม่
การใช้เมธอด hasStorageAccess()
เมื่อโหลดเว็บไซต์เป็นครั้งแรก เว็บไซต์จะใช้เมธอด hasStorageAccess() เพื่อตรวจสอบว่าได้ให้สิทธิ์เข้าถึงคุกกี้ของบุคคลที่สามแล้วหรือยัง
// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;
async function handleCookieAccessInit() {
if (!document.hasStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
hasAccess = true;
} else {
// Check whether access has been granted via the Storage Access API.
// Note on page load this will always be false initially so we could be
// skipped in this example, but including for completeness for when this
// is not so obvious.
hasAccess = await document.hasStorageAccess();
if (!hasAccess) {
// Handle the lack of access (covered later)
}
}
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
ระบบจะให้สิทธิ์เข้าถึงพื้นที่เก็บข้อมูลแก่เอกสาร iframe หลังจากเรียกใช้ requestStorageAccess(), เท่านั้น ดังนั้น hasStorageAccess() จะแสดงผลเป็นเท็จในขั้นต้นเสมอ ยกเว้นเมื่อเอกสารต้นทางเดียวกันอื่นใน iframe เดียวกันได้รับสิทธิ์เข้าถึงแล้ว การให้สิทธิ์นี้ยังคงอยู่สำหรับการไปยังส่วนต่างๆ ต้นทางเดียวกันภายใน iframe โดยเฉพาะเพื่อให้มีการโหลดซ้ำหลังจากที่ให้สิทธิ์เข้าถึงหน้าที่ต้องใช้คุกกี้ในคำขอเริ่มต้นสำหรับเอกสาร HTML แล้ว
การใช้เมธอด requestStorageAccess()
หาก iframe ไม่มีสิทธิ์เข้าถึง คุณอาจต้องขอสิทธิ์เข้าถึงโดยใช้เมธอด requestStorageAccess() ดังนี้
if (!hasAccess) {
try {
await document.requestStorageAccess();
} catch (err) {
// Access was not granted and it may be gated behind an interaction
return;
}
}
ครั้งแรกที่มีการส่งคำขอนี้ ผู้ใช้อาจต้องอนุมัติการเข้าถึงนี้ด้วยข้อความแจ้งของเบราว์เซอร์ หลังจากนั้นระบบจะแก้ไขสัญญา หรือระบบจะปฏิเสธหากเป็นข้อยกเว้น หากใช้ await
เพื่อป้องกันการละเมิด ข้อความแจ้งของเบราว์เซอร์นี้จะแสดงหลังการโต้ตอบของผู้ใช้เท่านั้น นั่นจึงเป็นเหตุผลที่ requestStorageAccess() ต้องมีการเรียกจากเครื่องจัดการเหตุการณ์ที่เปิดใช้งานโดยผู้ใช้แทนที่จะเรียกทันทีที่ iframe โหลด
async function doClick() {
// Only do this extra check if access hasn't already been given
// based on the hasAccess variable.
if (!hasAccess) {
try {
await document.requestStorageAccess();
hasAccess = true; // Can assume this was true if above did not reject.
} catch (err) {
// Access was not granted.
return;
}
}
if (hasAccess) {
// Use the cookies
}
}
document.querySelector('#my-button').addEventListener('click', doClick);
ข้อความแจ้งเกี่ยวกับสิทธิ์
เมื่อผู้ใช้คลิกปุ่มเป็นครั้งแรก ข้อความแจ้งของเบราว์เซอร์จะปรากฏโดยอัตโนมัติ โดยปกติจะอยู่ในแถบที่อยู่ ด้านล่างคือตัวอย่างข้อความแจ้งของ Chrome แต่เบราว์เซอร์อื่นๆ ก็มี UI ที่คล้ายกัน
เบราว์เซอร์อาจข้ามข้อความแจ้งและได้รับสิทธิ์โดยอัตโนมัติในบางสถานการณ์ต่อไปนี้
- มีการใช้หน้าเว็บและ iframe ในช่วง 30 วันที่ผ่านมาหลังจากยอมรับข้อความแจ้ง
- หาก iframe ที่ฝังเป็นส่วนหนึ่งของชุดเว็บไซต์ที่เกี่ยวข้อง
- ใน Firefox ระบบจะข้ามข้อความแจ้งสำหรับเว็บไซต์ที่รู้จัก (เว็บไซต์ที่คุณได้โต้ตอบด้วยในระดับบนสุด) สำหรับความพยายาม 5 ครั้งแรกด้วย
อีกทางเลือกหนึ่งคือ วิธีการอาจถูกปฏิเสธโดยอัตโนมัติโดยไม่แสดงข้อความแจ้งในบางสถานการณ์ต่อไปนี้
- หากผู้ใช้ยังไม่เคยเข้าชมและโต้ตอบกับเว็บไซต์ที่เป็นเจ้าของ iframe ในแบบเอกสารระดับบนสุด ไม่ใช่ใน iframe ซึ่งหมายความว่า Storage Access API จะมีประโยชน์กับเว็บไซต์ที่ฝังอยู่ซึ่งผู้ใช้เคยเข้าชมก่อนหน้านี้ในบริบทของบุคคลที่หนึ่ง
- หากมีการเรียกใช้เมธอด
requestStorageAccess()นอกเหตุการณ์การโต้ตอบของผู้ใช้ โดยไม่ได้รับอนุมัติก่อนพรอมต์หลังการโต้ตอบ
แม้ว่าผู้ใช้จะได้รับข้อความแจ้งเกี่ยวกับการใช้งานครั้งแรก แต่การเข้าชมครั้งต่อๆ มาจะสามารถแก้ไขปัญหา requestStorageAccess() ได้โดยไม่ต้องมีข้อความแจ้งและไม่จำเป็นต้องมีการโต้ตอบของผู้ใช้ใน Chrome และ Firefox โปรดทราบว่า Safari ต้องการการโต้ตอบของผู้ใช้เสมอ
เนื่องจากการเข้าถึงคุกกี้อาจได้รับสิทธิ์เข้าถึงโดยไม่มีข้อความแจ้งหรือไม่มีการโต้ตอบจากผู้ใช้ จึงมักเป็นไปได้ที่จะรับสิทธิ์เข้าถึงคุกกี้ของบุคคลที่สามก่อนการโต้ตอบของผู้ใช้ในเบราว์เซอร์ที่รองรับฟีเจอร์นี้ (Chrome และ Firefox) โดยการเรียกใช้ requestStorageAccess() เมื่อโหลดหน้าเว็บ ซึ่งอาจทำให้คุณเข้าถึงคุกกี้ข้ามเว็บไซต์ของบุคคลที่สามได้ทันทีและมอบประสบการณ์การใช้งานที่สมบูรณ์มากขึ้น แม้แต่ก่อนที่ผู้ใช้จะโต้ตอบกับ iframe การทำเช่นนี้อาจเป็นประสบการณ์ของผู้ใช้ที่ดีกว่าในบางสถานการณ์เมื่อเทียบกับการรอการโต้ตอบจากผู้ใช้
กำลังใช้การค้นหาสิทธิ์ storage-access
หากต้องการตรวจสอบว่าจะให้สิทธิ์เข้าถึงโดยไม่ต้องมีการโต้ตอบของผู้ใช้ได้หรือไม่ ให้ตรวจสอบสถานะของสิทธิ์ storage-access และเรียก requestStoreAccess() ก่อนๆ เฉพาะในกรณีที่ผู้ใช้ไม่จำเป็นต้องดำเนินการใดๆ แทนการเรียกโฆษณาแล้วจะดำเนินการไม่สำเร็จเมื่อต้องมีการโต้ตอบ
วิธีนี้ยังช่วยให้คุณจัดการกับความต้องการล่วงหน้าด้วยการแสดงเนื้อหาต่างๆ ได้ เช่น ปุ่มเข้าสู่ระบบ
โค้ดต่อไปนี้จะเพิ่มการตรวจสอบสิทธิ์ storage-access ในตัวอย่างก่อนหน้านี้:
// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;
async function hasCookieAccess() {
// Check if Storage Access API is supported
if (!document.requestStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
return true;
}
// Check if access has already been granted
if (await document.hasStorageAccess()) {
return true;
}
// Check the storage-access permission
// Wrap this in a try/catch for browsers that support the
// Storage Access API but not this permission check
// (e.g. Safari and older versions of Firefox).
let permission;
try {
permission = await navigator.permissions.query(
{name: 'storage-access'}
);
} catch (error) {
// storage-access permission not supported. Assume no cookie access.
return false;
}
if (permission) {
if (permission.state === 'granted') {
// Permission has previously been granted so can just call
// requestStorageAccess() without a user interaction and
// it will resolve automatically.
try {
await document.requestStorageAccess();
return true;
} catch (error) {
// This shouldn't really fail if access is granted, but return false
// if it does.
return false;
}
} else if (permission.state === 'prompt') {
// Need to call requestStorageAccess() after a user interaction
// (potentially with a prompt). Can't do anything further here,
// so handle this in the click handler.
return false;
} else if (permission.state === 'denied') {
// Currently not used. See:
// https://github.com/privacycg/storage-access/issues/149
return false;
}
}
// By default return false, though should really be caught by one of above.
return false;
}
async function handleCookieAccessInit() {
hasAccess = await hasCookieAccess();
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
iframe ที่แซนด์บ็อกซ์
เมื่อใช้ Storage Access API ใน iframe ที่ทำแซนด์บ็อกซ์ คุณต้องมีสิทธิ์แซนด์บ็อกซ์ต่อไปนี้
- ต้องใช้
allow-storage-access-by-user-activationเพื่ออนุญาตการเข้าถึง Storage Access API - ต้องมี
allow-scriptsเพื่ออนุญาตให้ใช้ JavaScript ในการเรียก API - ต้องใช้
allow-same-originเพื่ออนุญาตการเข้าถึงคุกกี้ต้นทางเดียวกันและพื้นที่เก็บข้อมูลอื่น
เช่น
<iframe sandbox="allow-storage-access-by-user-activation
allow-scripts
allow-same-origin"
src="..."></iframe>
ข้อกำหนดของคุกกี้
หากต้องการเข้าถึงด้วย Storage Access API ใน Chrome คุณต้องตั้งค่าคุกกี้ข้ามเว็บไซต์ด้วยแอตทริบิวต์ 2 รายการต่อไปนี้
SameSite=None- ซึ่งจำเป็นสำหรับการทำเครื่องหมายคุกกี้เป็นข้ามเว็บไซต์Secure- ช่วยให้มั่นใจว่าจะเข้าถึงได้เฉพาะคุกกี้ที่เว็บไซต์ HTTPS กำหนด
ใน Firefox และ Safari คุกกี้จะมีค่าเริ่มต้นเป็น SameSite=None และไม่จำกัด SSA ไว้เฉพาะคุกกี้ Secure จึงไม่จำเป็นต้องมีแอตทริบิวต์เหล่านี้ เราขอแนะนำให้มีแอตทริบิวต์ SameSite ที่ชัดเจนและใช้คุกกี้ Secure เสมอ
การเข้าถึงหน้าระดับบนสุด
Storage Access API มีไว้เพื่อเปิดใช้การเข้าถึงคุกกี้ของบุคคลที่สามภายใน iframe ที่ฝัง
นอกจากนี้ยังมีกรณีการใช้งานอื่นๆ เมื่อหน้าระดับบนสุดต้องการเข้าถึงคุกกี้ของบุคคลที่สาม ตัวอย่างเช่น รูปภาพหรือสคริปต์ที่ถูกจำกัดโดยคุกกี้ ซึ่งเจ้าของเว็บไซต์อาจต้องการรวมไว้ในเอกสารระดับบนสุดโดยตรงแทนที่จะรวมไว้ใน iframe เพื่อจัดการกับกรณีการใช้งานนี้ Chrome ได้เสนอส่วนขยายให้กับ Storage Access API โดยเพิ่มเมธอด requestStorageAccessFor()
เมธอด requestStorageAccessFor()
เมธอด requestStorageAccessFor() ทำงานคล้ายกับ requestStorageAccess() แต่ใช้กับทรัพยากรระดับบนสุด และใช้ได้กับเว็บไซต์ในชุดเว็บไซต์ที่เกี่ยวข้องเท่านั้น เพื่อป้องกันการให้สิทธิ์เข้าถึงทั่วไปแก่คุกกี้ของบุคคลที่สาม
โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับวิธีใช้ requestStorageAccessFor() ที่ชุดเว็บไซต์ที่เกี่ยวข้อง: คู่มือนักพัฒนาซอฟต์แวร์
การค้นหาสิทธิ์ top-level-storage-access
การสนับสนุนเบราว์เซอร์
- 119
- 119
- x
- x
ต้องมีสิทธิ์ top-level-storage-access เพื่อตรวจสอบว่าจะให้สิทธิ์เข้าถึงแก่ requestStorageAccessFor() ได้หรือไม่ ซึ่งคล้ายกับสิทธิ์ storage-access
Storage Access API แตกต่างอย่างไรเมื่อใช้กับ RWS
เมื่อใช้ชุดเว็บไซต์ที่เกี่ยวข้องกับ Storage Access API ความสามารถเพิ่มเติมบางส่วนจะพร้อมใช้งานตามรายละเอียดในตารางต่อไปนี้
| ไม่มี RWS | พร้อม RWS | |
|---|---|---|
| ต้องใช้ท่าทางสัมผัสของผู้ใช้เพื่อเริ่มคำขอการเข้าถึงพื้นที่เก็บข้อมูล | ||
| กำหนดให้ผู้ใช้ไปที่ต้นทางพื้นที่เก็บข้อมูลที่ขอในบริบทระดับบนสุดก่อนให้สิทธิ์เข้าถึง | ||
| สามารถข้ามข้อความแจ้งของผู้ใช้ครั้งแรกได้ | ||
ไม่จำเป็นต้องเรียกใช้ requestStorageAccess หากเคยให้สิทธิ์การเข้าถึงแล้ว |
||
| ให้สิทธิ์เข้าถึงโดเมนอื่นๆ ในเว็บไซต์ที่เกี่ยวข้องโดยอัตโนมัติ | ||
รองรับ requestStorageAccessFor สำหรับการเข้าถึงหน้าในระดับบนสุด |
การสาธิต: การตั้งค่าและการเข้าถึงคุกกี้
การสาธิตต่อไปนี้แสดงให้เห็นว่าคุณสามารถเข้าถึงคุกกี้ที่ตั้งค่าไว้ในหน้าจอแรกของการสาธิตได้อย่างไรในเฟรมที่ฝังในเว็บไซต์ที่ 2 ของเดโม
storage-access-api-demo.glitch.me
การสาธิตนี้ต้องใช้เบราว์เซอร์ที่ปิดใช้คุกกี้ของบุคคลที่สาม
- Chrome 118 ขึ้นไปที่ตั้งค่า Flag
chrome://flags/#test-third-party-cookie-phaseoutและรีสตาร์ทเบราว์เซอร์แล้ว - Firefox
- Safari