ชุดเว็บไซต์ที่เกี่ยวข้อง (RWS) เป็นกลไกแพลตฟอร์มเว็บที่ช่วยให้เบราว์เซอร์เข้าใจความสัมพันธ์ระหว่างกลุ่มโดเมน ซึ่งช่วยให้เบราว์เซอร์สามารถทำการตัดสินใจสำคัญเพื่อเปิดใช้ฟังก์ชันบางอย่างของเว็บไซต์ (เช่น จะอนุญาตให้เข้าถึงคุกกี้ข้ามเว็บไซต์หรือไม่) และนำเสนอข้อมูลนี้ต่อผู้ใช้
Chrome เลิกใช้งานคุกกี้ของบุคคลที่สามโดยมีเป้าหมายเพื่อรักษา Use Case หลักๆ ในเว็บไปพร้อมกับปรับปรุงความเป็นส่วนตัวของผู้ใช้ ตัวอย่างเช่น เว็บไซต์จำนวนมากใช้หลายโดเมนเพื่อแสดงประสบการณ์การใช้งานเดียวของผู้ใช้ องค์กรอาจต้องการรักษาโดเมนระดับบนสุดที่แตกต่างกันไว้สำหรับการใช้งานหลายกรณี เช่น โดเมนเฉพาะประเทศหรือโดเมนบริการสำหรับการโฮสต์รูปภาพหรือวิดีโอ ชุดเว็บไซต์ที่เกี่ยวข้องช่วยให้เว็บไซต์แชร์ข้อมูลในโดเมนต่างๆ ผ่านการควบคุมที่เจาะจงได้
ชุดเว็บไซต์ที่เกี่ยวข้องคืออะไร
ในระดับสูง ชุดเว็บไซต์ที่เกี่ยวข้องคือคอลเล็กชันของโดเมน ซึ่งมี "ชุดเว็บไซต์หลัก" ชุดเดียว และ "สมาชิกในชุด" ได้หลายคน
ในตัวอย่างต่อไปนี้ primary
จะแสดงโดเมนหลัก และ associatedSites
จะแสดงโดเมนที่เป็นไปตามข้อกำหนดของชุดย่อยที่เชื่อมโยง
{
"primary": "https://primary.com",
"associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}
รายการชุดเว็บไซต์ที่เกี่ยวข้องซึ่งเป็นที่ยอมรับคือรายการที่ดูได้แบบสาธารณะในรูปแบบไฟล์ JSON ซึ่งโฮสต์อยู่ในที่เก็บ GitHub ของชุดเว็บไซต์ที่เกี่ยวข้อง ซึ่งทำหน้าที่เป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับชุดทั้งหมด Chrome จะใช้ไฟล์นี้เพื่อให้มีผลกับลักษณะการทำงาน
มีเพียงผู้ที่ควบคุมการดูแลระบบในโดเมนเท่านั้นที่สามารถสร้างชุดด้วยโดเมนนั้นได้ ผู้ส่งต้องประกาศความสัมพันธ์ระหว่าง "สมาชิกชุด" แต่ละคน เป็น "ตั้งค่าหลัก" สมาชิกใน Set อาจรวมช่วงของโดเมนประเภทต่างๆ และต้องเป็นส่วนหนึ่งของส่วนย่อยตามกรณีการใช้งาน
หากแอปพลิเคชันของคุณต้องอาศัยการเข้าถึงคุกกี้ข้ามเว็บไซต์ (หรือที่เรียกว่าคุกกี้ของบุคคลที่สาม) ข้ามเว็บไซต์ต่างๆ ภายในชุดเว็บไซต์ที่เกี่ยวข้องเดียวกัน คุณสามารถใช้ Storage Access API (SAA) และ requestStorageAccessFor API เพื่อขอสิทธิ์เข้าถึงคุกกี้เหล่านั้นได้ เบราว์เซอร์อาจจัดการคำขอแตกต่างกันไป ทั้งนี้ขึ้นอยู่กับชุดย่อยของแต่ละเว็บไซต์
ดูข้อมูลเพิ่มเติมเกี่ยวกับขั้นตอนและข้อกำหนดในการส่งชุดได้ที่หลักเกณฑ์ในการส่ง ชุดที่ส่งจะเข้าสู่การตรวจสอบทางเทคนิคต่างๆ เพื่อตรวจสอบความถูกต้องของการส่ง
กรณีการใช้งานชุดเว็บไซต์ที่เกี่ยวข้อง
ชุดเว็บไซต์ที่เกี่ยวข้องจะเหมาะสมในกรณีที่องค์กรต้องการรูปแบบอัตลักษณ์ที่มีร่วมกันในเว็บไซต์ระดับบนสุดต่างๆ
ตัวอย่างกรณีการใช้งานสำหรับชุดเว็บไซต์ที่เกี่ยวข้องมีดังนี้
- การปรับแต่งประเทศ การใช้ประโยชน์จากเว็บไซต์ที่แปลแล้วในขณะที่อาศัยโครงสร้างพื้นฐานที่ใช้ร่วมกัน (example.co.uk อาจใช้บริการที่โฮสต์โดย example.ca)
- การผสานรวมโดเมนบริการ ใช้ประโยชน์จากโดเมนบริการที่ผู้ใช้ไม่เคยโต้ตอบด้วยโดยตรง แต่ให้บริการในเว็บไซต์ขององค์กรเดียวกัน (example-cdn.com)
- การแยกเนื้อหาของผู้ใช้ การเข้าถึงข้อมูลในโดเมนต่างๆ ที่แยกเนื้อหาที่ผู้ใช้อัปโหลดออกจากเนื้อหาอื่นๆ ของเว็บไซต์ด้วยเหตุผลด้านความปลอดภัย ขณะที่อนุญาตให้โดเมนแซนด์บ็อกซ์เข้าถึงคุกกี้การตรวจสอบสิทธิ์ (และคุกกี้อื่นๆ) หากแสดงเนื้อหาที่ผู้ใช้อัปโหลดที่ไม่ได้ใช้งาน คุณยังโฮสต์เนื้อหาดังกล่าวในโดเมนเดียวกันได้อย่างปลอดภัยโดยทำตามแนวทางปฏิบัติแนะนำ
- เนื้อหาที่ตรวจสอบสิทธิ์แล้วที่ฝัง รองรับเนื้อหาที่ฝังจากผลิตภัณฑ์และบริการที่เป็นพาร์ทเนอร์ (วิดีโอ เอกสาร หรือแหล่งข้อมูลที่จำกัดไว้สำหรับผู้ใช้ที่ลงชื่อเข้าใช้ในเว็บไซต์ระดับบนสุด)
- ลงชื่อเข้าใช้ รองรับการลงชื่อเข้าใช้ในผลิตภัณฑ์และบริการที่เชื่อมโยง FedCM API อาจเหมาะสำหรับการใช้งานในบางกรณีด้วย
- Analytics การใช้ข้อมูลวิเคราะห์และการวัดผลเส้นทางของผู้ใช้ในพร็อพเพอร์ตี้ที่เชื่อมโยงเพื่อปรับปรุงคุณภาพของบริการ
รายละเอียดการผสานรวมชุดเว็บไซต์ที่เกี่ยวข้อง
Storage Access API
Storage Access API (SAA) เป็นช่องทางให้เนื้อหาแบบข้ามต้นทางแบบฝังสามารถเข้าถึงพื้นที่เก็บข้อมูล ซึ่งตามปกติจะเข้าถึงได้ในบริบทของบุคคลที่หนึ่งเท่านั้น
ทรัพยากรที่ฝังสามารถใช้เมธอด SAA เพื่อตรวจสอบว่าบุคคลเหล่านั้นมีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลหรือไม่ และขอสิทธิ์เข้าถึงจาก User Agent
เมื่อบล็อกคุกกี้ของบุคคลที่สาม แต่เปิดใช้ชุดเว็บไซต์ที่เกี่ยวข้อง (RWS) อยู่ Chrome จะให้สิทธิ์ในบริบทภายใน RWS โดยอัตโนมัติ และจะแสดงข้อความแจ้งแก่ผู้ใช้หากไม่เปิดใช้ ("บริบทภายใน RWS" คือบริบท เช่น iframe ซึ่งมีเว็บไซต์ที่ฝังและเว็บไซต์ระดับบนสุดอยู่ใน RWS เดียวกัน)
ตรวจสอบและขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล
หากต้องการตรวจสอบว่าผู้ใช้มีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลหรือไม่ เว็บไซต์ที่ฝังจะใช้เมธอด Document.hasStorageAccess()
ได้
เมธอดจะแสดงสัญญาที่แก้ไขด้วยค่าบูลีนที่ระบุว่าเอกสารมีสิทธิ์เข้าถึงคุกกี้แล้วหรือไม่ คำสัญญายังส่งคืนค่าที่เป็นจริงหาก iframe มีต้นทางเดียวกับเฟรมบนสุด
หากต้องการขอสิทธิ์เข้าถึงคุกกี้ในเว็บไซต์ที่ฝังไว้ซึ่งมีบริบทข้ามเว็บไซต์ ให้ใช้ Document.requestStorageAccess()
(rSA)
requestStorageAccess()
API มีจุดประสงค์ให้เรียกใช้จากใน iframe iframe ดังกล่าวจะต้องเพิ่งได้รับการโต้ตอบของผู้ใช้ (ท่าทางสัมผัสของผู้ใช้ ซึ่งเบราว์เซอร์ทั้งหมดต้องใช้) แต่ Chrome ยังกำหนดให้ในช่วง 30 วันที่ผ่านมา ผู้ใช้ได้เข้าชมเว็บไซต์ที่เป็นเจ้าของ iframe นั้นและได้โต้ตอบกับเว็บไซต์นั้นโดยเฉพาะในฐานะเอกสารระดับบนสุด ไม่ใช่ใน iframe
requestStorageAccess()
จะแสดงผลสัญญาที่แก้ไขหากได้รับสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล คำสัญญาถูกปฏิเสธโดยอ้างอิงเหตุผลหากมีการปฏิเสธการเข้าถึงไม่ว่าด้วยเหตุผลใดก็ตาม
requestStorageAccessFor ใน Chrome
Storage Access API อนุญาตให้เว็บไซต์ที่ฝังสามารถขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลจากภายในองค์ประกอบ <iframe>
ที่ได้รับการโต้ตอบจากผู้ใช้เท่านั้น
จึงเป็นความท้าทายในการใช้งาน Storage Access API สําหรับเว็บไซต์ระดับบนสุดที่ใช้รูปภาพข้ามเว็บไซต์หรือแท็กสคริปต์ที่ต้องใช้คุกกี้
ในการแก้ปัญหานี้ Chrome จึงได้นำ Document.requestStorageAccessFor()
(rSAFor) มาใช้เพื่อให้เว็บไซต์ระดับบนสุดขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลในนามของต้นทางที่เจาะจง
document.requestStorageAccessFor('https://target.site')
requestStorageAccessFor()
API มีไว้เพื่อเรียกโดยเอกสารระดับบนสุด เอกสารนั้นต้องได้รับการโต้ตอบจากผู้ใช้ด้วย แต่ Chrome ต่างจาก requestStorageAccess()
ตรงที่จะไม่ตรวจสอบการโต้ตอบในเอกสารระดับบนสุดในช่วง 30 วันที่ผ่านมา เพราะผู้ใช้อยู่ในหน้านั้นอยู่แล้ว
ตรวจสอบสิทธิ์ในการเข้าถึงพื้นที่เก็บข้อมูล
การเข้าถึงบางฟีเจอร์ของเบราว์เซอร์ เช่น กล้องหรือตำแหน่งทางภูมิศาสตร์ จะขึ้นอยู่กับสิทธิ์ที่ผู้ใช้มอบให้ สิทธิ์ API มีวิธีตรวจสอบสถานะสิทธิ์ในการเข้าถึง API ไม่ว่าจะเป็นการได้รับ ปฏิเสธ หรือจำเป็นต้องมีการโต้ตอบจากผู้ใช้ในรูปแบบบางอย่าง เช่น การคลิกพรอมต์หรือการโต้ตอบกับหน้าเว็บ
คุณค้นหาสถานะสิทธิ์ได้โดยใช้ navigator.permissions.query()
วิธีตรวจสอบสิทธิ์การเข้าถึงพื้นที่เก็บข้อมูลสำหรับบริบทปัจจุบันที่คุณต้องส่งในสตริง 'storage-access'
navigator.permissions.query({name: 'storage-access'})
หากต้องการตรวจสอบสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลสำหรับต้นทางที่ระบุ คุณต้องส่งสตริง 'top-level-storage-access'
ดังนี้
navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})
โปรดทราบว่าวิธีนี้จะตรวจสอบเฉพาะสิทธิ์ที่ได้รับจากเอกสารระดับบนสุดโดยใช้ document.requestStorageAccessFor
เท่านั้น เพื่อปกป้องความสมบูรณ์ของต้นทางที่ฝัง
สิทธิ์จะแสดง prompt
หรือ granted
โดยขึ้นอยู่กับว่าให้สิทธิ์ได้โดยอัตโนมัติหรือต้องใช้ท่าทางสัมผัสของผู้ใช้
โมเดลต่อเฟรม
การให้สิทธิ์ rSA จะมีผลต่อเฟรม การให้สิทธิ์ rSA และ rSAFor จะถือเป็นสิทธิ์แยกกัน
เฟรมใหม่แต่ละเฟรมจะต้องขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลทีละรายการ และเฟรมจะได้รับสิทธิ์เข้าถึงโดยอัตโนมัติ เฉพาะคำขอแรกเท่านั้นที่ต้องใช้ท่าทางสัมผัสของผู้ใช้ คำขอที่ตามมาใดๆ ที่เริ่มต้นโดย iframe เช่น การนำทางหรือทรัพยากรย่อย จะไม่ต้องรอท่าทางสัมผัสของผู้ใช้ เนื่องจากคำขอเริ่มต้นจะได้รับสำหรับเซสชันการท่องเว็บ
หากต้องการรีเฟรช โหลดซ้ำ หรือสร้าง iframe ใหม่ คุณจะต้องขอสิทธิ์เข้าถึงอีกครั้ง
ข้อกำหนดของคุกกี้
คุกกี้ต้องระบุทั้งแอตทริบิวต์ SameSite=None
และ Secure
เป็น rSA เท่านั้น ให้สิทธิ์การเข้าถึงสำหรับคุกกี้ที่มีการทำเครื่องหมายไว้สำหรับการใช้งานในบริบทแบบข้ามเว็บไซต์แล้ว
คุกกี้ที่มี SameSite=Lax
, SameSite=Strict
หรือไม่มีแอตทริบิวต์ SameSite
มีไว้สำหรับการใช้งานของบุคคลที่หนึ่งเท่านั้นและจะไม่แชร์ในบริบทแบบข้ามเว็บไซต์โดยไม่คำนึงถึง rSA
ความปลอดภัย
สำหรับ rSAFor คำขอทรัพยากรย่อยต้องมีส่วนหัวการแชร์ทรัพยากรข้ามต้นทาง (CORS) หรือแอตทริบิวต์ crossorigin
ในทรัพยากร ทั้งนี้เพื่อให้แน่ใจว่ามีการเลือกใช้อย่างชัดเจน
ตัวอย่างการติดตั้งใช้งาน
ขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลจาก iframe แบบข้ามต้นทางที่ฝัง
![แผนภาพแสดงเว็บไซต์ที่ฝังในเว็บไซต์ระดับบนสุด](https://developers.google.cn/static/privacy-sandbox/assets/images/SV7SXAQRcVnBZEgjgxYc.png?authuser=19&hl=th)
requestStorageAccess()
ในการฝังในเว็บไซต์อื่นตรวจสอบว่าคุณมีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลหรือไม่
หากต้องการตรวจสอบว่าคุณมีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลอยู่แล้วหรือไม่ ให้ใช้ document.hasStorageAccess()
หากคำสัญญาเป็นจริง คุณจะเข้าถึงพื้นที่เก็บข้อมูลในบริบทแบบข้ามเว็บไซต์ได้ หากแก้ไขได้ "เท็จ" คุณจะต้องขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล
document.hasStorageAccess().then((hasAccess) => {
if (hasAccess) {
// You can access storage in this context
} else {
// You have to request storage access
}
});
ขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล
หากต้องการขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล ก่อนอื่นให้ตรวจสอบสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล navigator.permissions.query({name: 'storage-access'})
เพื่อดูว่าต้องใช้ท่าทางสัมผัสของผู้ใช้หรือมีการให้สิทธิ์โดยอัตโนมัติหรือไม่
หากสิทธิ์คือgranted
คุณสามารถเรียกใช้ document.requestStorageAccess()
ได้ และควรดำเนินการสำเร็จโดยไม่ต้องใช้ท่าทางสัมผัสของผู้ใช้
หากสถานะสิทธิ์คือ prompt
คุณจะต้องเริ่มการโทรผ่าน document.requestStorageAccess()
หลังจากท่าทางสัมผัสของผู้ใช้ เช่น การคลิกปุ่ม
ตัวอย่าง
navigator.permissions.query({name: 'storage-access'}).then(res => {
if (res.state === 'granted') {
// Permission has already been granted
// You can request storage access without any user gesture
rSA();
} else if (res.state === 'prompt') {
// Requesting storage access requires user gesture
// For example, clicking a button
const btn = document.createElement("button");
btn.textContent = "Grant access";
btn.addEventListener('click', () => {
// Request storage access
rSA();
});
document.body.appendChild(btn);
}
});
function rSA() {
if ('requestStorageAccess' in document) {
document.requestStorageAccess().then(
(res) => {
// Use storage access
},
(err) => {
// Handle errors
}
);
}
}
คำขอที่ตามมาจากภายในเฟรม การนำทาง หรือทรัพยากรย่อย จะได้รับอนุญาตให้เข้าถึงคุกกี้ข้ามเว็บไซต์โดยอัตโนมัติ hasStorageAccess()
จะแสดงผลคุกกี้จริงและคุกกี้ข้ามเว็บไซต์จากชุดเว็บไซต์ที่เกี่ยวข้องชุดเดียวกันตามคําขอเหล่านั้นโดยไม่มีการเรียก JavaScript เพิ่มเติม
เว็บไซต์ระดับบนสุดที่ขอการเข้าถึงคุกกี้ในนามของเว็บไซต์แบบข้ามต้นทาง
![แผนภาพแสดง requestStorageAccessFor() ที่ใช้ในเว็บไซต์ระดับบนสุดและไม่ใช่ภายในการฝัง](https://developers.google.cn/static/privacy-sandbox/assets/images/jRgDgWl7yb1cEcwpcdMo.png?authuser=19&hl=th)
requestStorageAccessFor()
ในเว็บไซต์ระดับบนสุดสำหรับต้นทางอื่นเว็บไซต์ระดับบนสุดสามารถใช้ requestStorageAccessFor()
เพื่อขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลในนามของต้นทางที่เจาะจงได้
hasStorageAccess()
จะตรวจสอบเพียงว่าเว็บไซต์ที่เรียกตัวเองว่ามีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลหรือไม่ ดังนั้นเว็บไซต์ระดับบนสุดจึงตรวจสอบสิทธิ์สำหรับต้นทางอื่นได้
หากต้องการดูว่าผู้ใช้จะได้รับข้อความแจ้งหรือไม่ หรือให้สิทธิ์เข้าถึงพื้นที่เก็บข้อมูลแก่ต้นทางที่ระบุแล้ว โปรดโทรหา navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})
หากสิทธิ์คือgranted
คุณสามารถโทรหา document.requestStorageAccessFor('https://target.site')
ควรดำเนินการให้สำเร็จโดยไม่ต้องใช้ท่าทางสัมผัสของผู้ใช้
หากสิทธิ์คือprompt
คุณจะต้องเกี่ยวเนื่องกับการเรียก document.requestStorageAccessFor('https://target.site')
หลังท่าทางสัมผัสของผู้ใช้ เช่น การคลิกปุ่ม
ตัวอย่าง
navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
if (res.state === 'granted') {
// Permission has already been granted
// You can request storage access without any user gesture
rSAFor();
} else if (res.state === 'prompt') {
// Requesting storage access requires user gesture
// For example, clicking a button
const btn = document.createElement("button");
btn.textContent = "Grant access";
btn.addEventListener('click', () => {
// Request storage access
rSAFor();
});
document.body.appendChild(btn);
}
});
function rSAFor() {
if ('requestStorageAccessFor' in document) {
document.requestStorageAccessFor().then(
(res) => {
// Use storage access
},
(err) => {
// Handle errors
}
);
}
}
หลังจากการเรียกใช้ requestStorageAccessFor()
สำเร็จ คำขอข้ามเว็บไซต์จะรวมคุกกี้หากมี CORS หรือแอตทริบิวต์ Crossorigin ดังนั้นเว็บไซต์อาจต้องรอก่อนเรียกใช้คำขอ
คำขอต้องใช้ตัวเลือก credentials: 'include'
และทรัพยากรต้องมีแอตทริบิวต์ crossorigin="use-credentials"
function checkCookie() {
fetch('https://related-website-sets.glitch.me/getcookies.json', {
method: 'GET',
credentials: 'include'
})
.then((response) => response.json())
.then((json) => {
// Do something
});
}
วิธีทดสอบในเครื่อง
ข้อกำหนดเบื้องต้น
หากต้องการทดสอบชุดเว็บไซต์ที่เกี่ยวข้องในเครื่อง ให้ใช้ Chrome 119 ขึ้นไปที่เรียกใช้จากบรรทัดคำสั่งและเปิดใช้Flag ของ Chrome test-third-party-cookie-phaseout
เปิดใช้ Chrome Flag
หากต้องการเปิดใช้การตั้งค่าสถานะ Chrome ที่จำเป็น ให้ไปยัง chrome://flags#test-third-party-cookie-phaseout
จากแถบที่อยู่และเปลี่ยนค่าสถานะเป็น Enabled
อย่าลืมรีสตาร์ทเบราว์เซอร์หลังจากมีการเปลี่ยนแปลงสถานะแล้ว
เปิดใช้ Chrome ด้วยชุดเว็บไซต์ที่เกี่ยวข้องในพื้นที่
หากต้องการเปิดใช้งาน Chrome ด้วยชุดเว็บไซต์ที่เกี่ยวข้องที่ประกาศไว้ในเครื่อง ให้สร้างออบเจ็กต์ JSON ที่มี URL ที่เป็นสมาชิกของชุดและส่งไปยัง --use-related-website-set
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีเรียกใช้ Chromium แบบมี Flag
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
ตัวอย่าง
หากต้องการเปิดใช้ชุดเว็บไซต์ที่เกี่ยวข้องในเครื่อง คุณต้องเปิดใช้ test-third-party-cookie-phaseout
ใน chrome://flags
และเรียกใช้ Chrome จากบรรทัดคำสั่งที่มีแฟล็ก --use-related-website-set
พร้อมออบเจ็กต์ JSON ที่มี URL ที่เป็นสมาชิกของชุด
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
ยืนยันว่าคุณมีสิทธิ์เข้าถึงคุกกี้ข้ามเว็บไซต์
เรียกใช้ API (rSA หรือ rSAFor) จากเว็บไซต์ที่กำลังทดสอบและตรวจสอบสิทธิ์การเข้าถึงคุกกี้ข้ามเว็บไซต์
กระบวนการส่งชุดเว็บไซต์ที่เกี่ยวข้อง
หากต้องการประกาศความสัมพันธ์ระหว่างโดเมนและระบุชุดย่อยของโดเมน ให้ทำตามขั้นตอนต่อไปนี้
- ระบุโดเมนที่เกี่ยวข้อง ซึ่งรวมถึงสมาชิกเซ็ตหลักและสมาชิกในเซ็ตที่จะเป็นส่วนหนึ่งของชุดเว็บไซต์ที่เกี่ยวข้อง รวมถึงระบุประเภทสับเซ็ตของแต่ละสมาชิกในชุดนั้นๆ
- ตรวจสอบว่าได้ตั้งค่าข้อกำหนดการสร้างและตั้งค่าข้อกำหนดการตรวจสอบแล้ว
- ประกาศชุดเว็บไซต์ที่เกี่ยวข้องในรูปแบบ JSON ที่ถูกต้อง
- ส่งชุดเว็บไซต์ที่เกี่ยวข้องโดยสร้างคำขอพุล (PR) ไปยัง
related_website_sets.JSON
ที่ Chrome จะโฮสต์รายการชุดเว็บไซต์ที่เกี่ยวข้องตามรูปแบบบัญญัติ (ต้องใช้บัญชี GitHub ในการสร้าง PR และคุณจะต้องลงนามในข้อตกลงใบอนุญาตของ Contributor (CLA) เพื่อร่วมให้ข้อมูล)
เมื่อสร้าง PR แล้ว ชุดการตรวจสอบต่างๆ จะปรากฏขึ้นเพื่อตรวจสอบว่าข้อกำหนดจากขั้นตอนที่ 2 นั้นมีให้แล้ว
หากผ่านการตรวจสอบ PR จะระบุว่าผ่านการตรวจสอบแล้ว ระบบจะรวม PR ที่ได้รับอนุมัติด้วยตนเองเป็นชุดๆ ไปยังรายการชุดเว็บไซต์ที่เกี่ยวข้องตามรูปแบบบัญญัติสัปดาห์ละครั้ง (วันอังคาร เวลา 12:00 น. ตามเวลาตะวันออก)
หากการตรวจสอบใดล้มเหลว ผู้ส่งจะได้รับการแจ้งเตือนผ่าน PR ที่ล้มเหลวบน GitHub ผู้ส่งสามารถแก้ไขข้อผิดพลาดและอัปเดตการประชาสัมพันธ์ได้ และโปรดทราบว่า
- เมื่อการประชาสัมพันธ์ไม่สำเร็จ ข้อความแสดงข้อผิดพลาดจะให้ข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุที่การส่งโฆษณาไม่สำเร็จ (ตัวอย่าง)
- การตรวจสอบทางเทคนิคทั้งหมดที่ควบคุมการส่งชุดจะดำเนินการใน GitHub และผลที่การส่งไม่สำเร็จซึ่งเกิดจากการตรวจสอบทางเทคนิคจะดูได้บน GitHub
นโยบายองค์กร
Chrome มี 2 นโยบายที่ใช้เพื่อตอบสนองความต้องการของผู้ใช้ระดับองค์กร:
- ระบบที่อาจผสานรวมกับชุดเว็บไซต์ที่เกี่ยวข้องไม่ได้อาจปิดใช้ฟีเจอร์ชุดเว็บไซต์ที่เกี่ยวข้องในอินสแตนซ์ระดับองค์กรทั้งหมดของ Chrome ที่มีนโยบาย
RelatedWebsiteSetsEnabled
- ระบบขององค์กรบางระบบมีเว็บไซต์เฉพาะภายใน (เช่น อินทราเน็ต) ซึ่งมีโดเมนที่จดทะเบียนได้ซึ่งต่างจากโดเมนในชุดเว็บไซต์ที่เกี่ยวข้อง หากพาร์ทเนอร์จำเป็นต้องปฏิบัติต่อเว็บไซต์เหล่านี้เป็นส่วนหนึ่งของชุดเว็บไซต์ที่เกี่ยวข้องโดยไม่เปิดเผยต่อสาธารณะ (เนื่องจากโดเมนอาจเป็นความลับ) พาร์ทเนอร์จะเพิ่มหรือลบล้างลิสต์ชุดเว็บไซต์ที่เกี่ยวข้องแบบสาธารณะได้โดยใช้นโยบาย
RelatedWebsiteSetsOverrides
Chrome แก้ไขจุดร่วมของชุดสาธารณะและชุด Enterprise ใน 1 จาก 2 ชุด
โดยขึ้นอยู่กับว่ามีการระบุ replacemements
หรือ additions
ไว้หรือไม่
ตัวอย่างเช่น สำหรับชุดสาธารณะ {primary: A, associated: [B, C]}
:
replacements : |
{primary: C, associated: [D, E]} |
ชุด Enterprise จะซึมซับไซต์ทั่วไปเพื่อสร้างชุดใหม่ | |
ชุดผลลัพธ์: | {primary: A, associated: [B]} {primary: C, associated: [D, E]} |
additions : |
{primary: C, associated: [D, E]} |
ระบบจะรวมชุด Public และ Enterprise | |
ชุดผลลัพธ์: | {primary: C, associated: [A, B, D, E]} |
แก้ปัญหาชุดเว็บไซต์ที่เกี่ยวข้อง
"ข้อความแจ้งจากผู้ใช้" และ "ท่าทางสัมผัสของผู้ใช้"
"ข้อความแจ้งจากผู้ใช้" และ "ท่าทางสัมผัสของผู้ใช้" เป็นคนละเรื่องกัน Chrome จะไม่แสดง
ข้อความแจ้งเกี่ยวกับสิทธิ์
สำหรับผู้ใช้สำหรับเว็บไซต์ต่างๆ ที่อยู่ในชุดเว็บไซต์ที่เกี่ยวข้องเดียวกัน แต่ Chrome ยังคง
ผู้ใช้ต้องโต้ตอบกับหน้าเว็บ ก่อนให้สิทธิ์
Chrome จำเป็นต้องมี
ท่าทางสัมผัสของผู้ใช้
หรือที่เรียกว่า "การโต้ตอบของผู้ใช้" หรือ "การเปิดใช้งานผู้ใช้" เนื่องจากการใช้
Storage Access API นอกบริบทชุดเว็บไซต์ที่เกี่ยวข้อง (ได้แก่
requestStorageAccess()
) ต้องใช้ท่าทางสัมผัสของผู้ใช้ด้วย เนื่องจาก
หลักการออกแบบแพลตฟอร์มเว็บ
เข้าถึงของเว็บไซต์อื่น คุกกี้หรือพื้นที่เก็บข้อมูล
ชุดเว็บไซต์ที่เกี่ยวข้องจะไม่ผสานพื้นที่เก็บข้อมูลของเว็บไซต์ต่างๆ: แต่ช่วยให้
การโทรด้วย requestStorageAccess()
ที่ง่ายขึ้น (ไม่ต้องแจ้งเตือน) เว็บไซต์ที่เกี่ยวข้อง
การตั้งค่าจะช่วยลดความติดขัดของผู้ใช้ในการใช้ Storage Access API เท่านั้น
ระบุสิ่งที่ต้องทำเมื่อกู้คืนสิทธิ์เข้าถึงได้แล้ว หาก ก และ ข อยู่คนละเว็บไซต์กัน
ในชุดเว็บไซต์ที่เกี่ยวข้องเดียวกัน และ A ฝัง B และ B สามารถเรียก
requestStorageAccess()
และรับสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลจากบุคคลที่หนึ่งโดยไม่ต้องแจ้งเตือน
ผู้ใช้รายนั้น ชุดเว็บไซต์ที่เกี่ยวข้องจะไม่ทำการสื่อสารข้ามเว็บไซต์ใดๆ สำหรับ
ตัวอย่างเช่น การตั้งค่าชุดเว็บไซต์ที่เกี่ยวข้องจะไม่ทำให้คุกกี้ที่อยู่ภายใต้
ถึง B เพื่อเริ่มส่งไปยัง A หากคุณ
และต้องการแชร์ข้อมูลดังกล่าว คุณจะต้องแชร์ข้อมูลด้วยตัวเอง เช่น
กำลังส่ง window.postMessage
จาก iframe แบบ B ไปยัง
กรอบรูป
การเข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชันโดยค่าเริ่มต้น
ชุดเว็บไซต์ที่เกี่ยวข้องไม่อนุญาตการเข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชันโดยนัย
โดยไม่ต้องเรียกใช้ API ใดๆ คุกกี้ข้ามเว็บไซต์ไม่พร้อมใช้งาน
default ภายในชุด ชุดเว็บไซต์ที่เกี่ยวข้องเพียงแค่อนุญาตให้เว็บไซต์ภายในชุดเป็น
ข้ามข้อความแจ้งเกี่ยวกับสิทธิ์ Storage Access API
iframe ต้องเรียก document.requestStorageAccess()
หากต้องการเข้าถึง iframe
หรือหน้าระดับบนสุดสามารถเรียก document.requestStorageAccessFor()
แชร์ความคิดเห็น
การส่งชุดบน GitHub และการทำงานกับ Storage Access API และ requestStorageAccessFor
API เป็นโอกาสในการแชร์ประสบการณ์เกี่ยวกับกระบวนการดังกล่าวและปัญหาที่พบ
วิธีเข้าร่วมการสนทนาเกี่ยวกับชุดเว็บไซต์ที่เกี่ยวข้อง
- เข้าร่วมรายชื่ออีเมลสาธารณะในชุดเว็บไซต์ที่เกี่ยวข้อง
- หยิบยกปัญหาและติดตามการสนทนาในที่เก็บ GitHub ของชุดเว็บไซต์ที่เกี่ยวข้อง