ชุดเว็บไซต์ที่เกี่ยวข้อง (RWS) เป็นกลไกแพลตฟอร์มเว็บที่ช่วยให้เบราว์เซอร์เข้าใจความสัมพันธ์ในกลุ่มโดเมนต่างๆ ซึ่งช่วยให้เบราว์เซอร์ตัดสินใจเรื่องสำคัญเพื่อเปิดใช้ฟังก์ชันบางอย่างของเว็บไซต์ (เช่น จะอนุญาตให้เข้าถึงคุกกี้ข้ามเว็บไซต์หรือไม่) และนำเสนอข้อมูลนี้แก่ผู้ใช้
เมื่อ Chrome เลิกใช้งานคุกกี้ของบุคคลที่สาม เป้าหมายของเราคือการคง Use Case หลักๆ ไว้บนเว็บไปพร้อมๆ กับปรับปรุงความเป็นส่วนตัวสำหรับผู้ใช้ ตัวอย่างเช่น หลายเว็บไซต์ใช้หลายโดเมนเพื่อมอบประสบการณ์ของผู้ใช้เดียว องค์กรอาจต้องการรักษาโดเมนระดับบนสุดที่แตกต่างกันไว้สำหรับการใช้งานหลายๆ กรณี เช่น โดเมนเฉพาะประเทศ หรือโดเมนบริการสำหรับการโฮสต์รูปภาพหรือวิดีโอ ชุดเว็บไซต์ที่เกี่ยวข้องช่วยให้เว็บไซต์แชร์ข้อมูลข้ามโดเมนได้ โดยมีการควบคุมที่เฉพาะเจาะจง
ชุดเว็บไซต์ที่เกี่ยวข้องคืออะไร
ในระดับสูง ชุดเว็บไซต์ที่เกี่ยวข้องคือชุดของโดเมน ซึ่งมี "ชุดหลัก" ชุดเดียวและอาจมี "สมาชิกในชุด" หลายรายการ
ในตัวอย่างต่อไปนี้ primary จะแสดงโดเมนหลัก และ associatedSites แสดงโดเมนที่ตรงกับข้อกำหนดของชุดย่อยที่เกี่ยวข้อง
{
"primary": "https://primary.com",
"associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}
รายการชุดเว็บไซต์ที่เกี่ยวข้องกับ Canonical คือรายการที่ดูได้แบบสาธารณะในรูปแบบไฟล์ JSON ที่โฮสต์ในที่เก็บ GitHub สำหรับชุดเว็บไซต์ที่เกี่ยวข้อง ซึ่งทำหน้าที่เป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับชุดทั้งหมด Chrome จะใช้ไฟล์นี้เพื่อทำงาน
มีเพียงผู้ที่ควบคุมการดูแลระบบของโดเมนเท่านั้นที่สามารถสร้างชุดด้วยโดเมนนั้นได้ ผู้ส่งต้องประกาศความสัมพันธ์ระหว่าง "สมาชิกในชุด" แต่ละรายกับ "สมาชิกหลัก" สมาชิกในชุดอาจรวมโดเมนประเภทต่างๆ และต้องเป็นส่วนหนึ่งของส่วนย่อยตามกรณีการใช้งาน
หากแอปพลิเคชันของคุณต้องใช้การเข้าถึงคุกกี้ข้ามเว็บไซต์ (หรือที่เรียกว่าคุกกี้ของบุคคลที่สาม) ในเว็บไซต์ต่างๆ ภายในชุดเว็บไซต์ที่เกี่ยวข้องชุดเดียวกัน คุณจะใช้ 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 จะไม่ตรวจสอบการโต้ตอบในเอกสารระดับบนสุดภายใน 30 วันที่ผ่านมา เนื่องจากผู้ใช้อยู่ในหน้าเว็บแล้ว ซึ่งต่างจาก requestStorageAccess()
ตรวจสอบสิทธิ์ในการเข้าถึงพื้นที่เก็บข้อมูล
การเข้าถึงบางฟีเจอร์ของเบราว์เซอร์ เช่น กล้องหรือตำแหน่งทางภูมิศาสตร์ จะขึ้นอยู่กับสิทธิ์ที่ผู้ใช้ให้ไว้ Permissions 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 แบบข้ามต้นทางที่ฝัง
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() ในเว็บไซต์ระดับบนสุดสำหรับต้นทางอื่นเว็บไซต์ระดับบนสุดจะใช้ 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 หรือแอตทริบิวต์ข้ามต้นทาง เว็บไซต์จึงอาจต้องรอก่อนที่จะเรียกใช้คำขอ
โดยคำขอต้องใช้ตัวเลือก 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 ขึ้นไปที่เปิดจากบรรทัดคำสั่ง และเปิดใช้ test-third-party-cookie-phaseout Chrome Flag
เปิดใช้ Chrome Flag
หากต้องการเปิดใช้งาน Chrome Flag ที่จำเป็น ให้ไปที่ 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 จะโฮสต์รายการชุดเว็บไซต์ที่เกี่ยวข้องกับ Canonical (ต้องมีบัญชี GitHub เพื่อสร้าง PR และคุณจะต้องลงนามในข้อตกลงการอนุญาตให้ใช้สิทธิของ Contributor (CLA) เพื่อมีส่วนร่วมในรายการ)
เมื่อสร้างการประชาสัมพันธ์แล้ว ระบบจะตรวจสอบหนึ่งชุดเพื่อให้แน่ใจว่าเป็นไปตามข้อกำหนดในขั้นตอนที่ 2
หากยืนยันสำเร็จ PR จะระบุว่าผ่านการตรวจสอบแล้ว PR ที่ได้รับอนุมัติจะรวมกันเป็นกลุ่มในรายการชุดเว็บไซต์ที่เกี่ยวข้องตามรูปแบบบัญญัติด้วยตนเองสัปดาห์ละครั้ง (วันอังคารเวลา 12.00 น. เวลาตะวันออก)
หากการตรวจสอบรายการใดไม่สำเร็จ ผู้ส่งจะได้รับแจ้งผ่านความล้มเหลวในการประชาสัมพันธ์ใน GitHub ผู้ส่งสามารถแก้ไขข้อผิดพลาดและอัปเดตการประชาสัมพันธ์ โดยมีข้อควรทราบดังนี้
- เมื่อการประชาสัมพันธ์ไม่สำเร็จ ข้อความแสดงข้อผิดพลาดจะให้ข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุที่การส่งโฆษณาล้มเหลว (ตัวอย่าง)
- การตรวจสอบทางเทคนิคทั้งหมดที่ควบคุมการส่งชุดเนื้อหาจะดำเนินการใน GitHub ดังนั้นคุณสามารถดูความล้มเหลวทั้งหมดที่ส่งมาจากการตรวจสอบทางเทคนิคบน GitHub
นโยบายองค์กร
Chrome มีนโยบายระดับองค์กร 2 ข้อดังต่อไปนี้เพื่อตอบสนองความต้องการของผู้ใช้ระดับองค์กร
- ระบบที่อาจผสานรวมกับชุดเว็บไซต์ที่เกี่ยวข้องไม่ได้สามารถปิดใช้ฟีเจอร์ชุดเว็บไซต์ที่เกี่ยวข้องใน Chrome ทุกอินสแตนซ์ระดับองค์กรที่ใช้นโยบาย
RelatedWebsiteSetsEnabledได้ - ระบบขององค์กรบางระบบจะมีเว็บไซต์ภายในเท่านั้น (เช่น อินทราเน็ต) ซึ่งมีโดเมนที่จดทะเบียนได้ซึ่งแตกต่างจากโดเมนในชุดเว็บไซต์ที่เกี่ยวข้อง หากจำเป็นต้องปฏิบัติต่อเว็บไซต์เหล่านี้โดยเป็นส่วนหนึ่งของชุดเว็บไซต์ที่เกี่ยวข้องโดยไม่เปิดเผยต่อสาธารณะ (เนื่องจากโดเมนอาจเป็นความลับ) ลูกค้าสามารถเพิ่มหรือลบล้างลิสต์ชุดเว็บไซต์ที่เกี่ยวข้องแบบสาธารณะได้โดยใช้นโยบาย
RelatedWebsiteSetsOverrides
แก้ปัญหาชุดเว็บไซต์ที่เกี่ยวข้อง
"ข้อความแจ้งผู้ใช้" และ "ท่าทางสัมผัสของผู้ใช้"
"ข้อความแจ้งของผู้ใช้" และ "ท่าทางสัมผัสของผู้ใช้" เป็นสิ่งที่ต่างกัน Chrome จะไม่แสดงข้อความแจ้งเกี่ยวกับสิทธิ์แก่ผู้ใช้สำหรับเว็บไซต์ที่อยู่ในชุดเว็บไซต์ที่เกี่ยวข้องเดียวกัน แต่ Chrome ยังคงกำหนดให้ผู้ใช้ต้องโต้ตอบกับหน้าเว็บ ก่อนที่จะให้สิทธิ์ Chrome ต้องใช้ท่าทางสัมผัสของผู้ใช้ หรือที่เรียกว่า "การโต้ตอบของผู้ใช้" หรือ "การเปิดใช้งานผู้ใช้" นั่นเป็นเพราะการใช้งาน Storage Access API นอกบริบทชุดเว็บไซต์ที่เกี่ยวข้อง (กล่าวคือ requestStorageAccess()) จำเป็นต้องใช้ท่าทางสัมผัสของผู้ใช้ด้วย เนื่องจากเป็นหลักการออกแบบแพลตฟอร์มเว็บ
เข้าถึงคุกกี้หรือพื้นที่เก็บข้อมูลของเว็บไซต์อื่น
ชุดเว็บไซต์ที่เกี่ยวข้องจะไม่ผสานรวมพื้นที่เก็บข้อมูลสําหรับเว็บไซต์ต่างๆ เพียงแต่ช่วยให้เรียกใช้ requestStorageAccess() ได้ง่ายขึ้น (ไม่มีข้อความแจ้ง) เว็บไซต์ที่เกี่ยวข้อง
ตั้งค่าเพียงการลดความยุ่งยากในการใช้ Storage Access API แต่ไม่กำหนดว่าควรทำอย่างไรหลังจากกู้คืนการเข้าถึงแล้ว หาก ก และ ข เป็นเว็บไซต์ที่แตกต่างกันในชุดเว็บไซต์ที่เกี่ยวข้องชุดเดียวกัน และ ก ฝัง ข ไว้ ข จะเรียกใช้ requestStorageAccess() และรับสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลจากบุคคลที่หนึ่งได้โดยไม่ต้องแจ้งผู้ใช้ ชุดเว็บไซต์ที่เกี่ยวข้องจะไม่ทำการสื่อสารข้ามเว็บไซต์ เช่น การตั้งค่าชุดเว็บไซต์ที่เกี่ยวข้องจะไม่ทำให้ระบบเริ่มส่งคุกกี้ที่เป็นของ B ไปยัง A หากต้องการแชร์ข้อมูลดังกล่าว คุณจะต้องแชร์ข้อมูลดังกล่าวด้วยตนเอง เช่น การส่ง window.postMessage จาก iframe แบบ B ไปยังเฟรม A
การเข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชันโดยค่าเริ่มต้น
ชุดเว็บไซต์ที่เกี่ยวข้องไม่อนุญาตให้มีการเข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชันโดยนัยโดยไม่มีการเรียกใช้ API คุกกี้ข้ามเว็บไซต์จะไม่พร้อมให้ใช้งานโดยค่าเริ่มต้นค่าเริ่มต้นภายในชุด แต่ชุดเว็บไซต์ที่เกี่ยวข้องจะอนุญาตให้เว็บไซต์ภายในชุดข้ามข้อความแจ้งสิทธิ์ของ Storage Access API
iframe จะต้องเรียกใช้ document.requestStorageAccess() หากต้องการเข้าถึงคุกกี้ หรือหน้าระดับบนสุดจะเรียก document.requestStorageAccessFor() ได้
แสดงความคิดเห็น
การส่งชุดไฟล์บน GitHub และการทำงานกับ Storage Access API และ requestStorageAccessFor API เป็นโอกาสในการแชร์ประสบการณ์ของคุณเกี่ยวกับกระบวนการและปัญหาที่คุณพบ
หากต้องการเข้าร่วมการสนทนาเกี่ยวกับชุดเว็บไซต์ที่เกี่ยวข้อง ให้ทำดังนี้
- เข้าร่วมรายชื่ออีเมลสาธารณะสำหรับชุดเว็บไซต์ที่เกี่ยวข้อง
- นำเสนอปัญหาและติดตามการสนทนาในหัวข้อที่เก็บ GitHub สำหรับชุดเว็บไซต์ที่เกี่ยวข้อง