API การเข้าถึงพื้นที่เก็บข้อมูล

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

สถานะการใช้งาน

Storage Access API พร้อมใช้งานในเบราว์เซอร์หลักทั้งหมด แต่มีความแตกต่างในการใช้งานเล็กน้อยระหว่างเบราว์เซอร์ เราได้ไฮไลต์ความแตกต่างเหล่านี้ไว้ในส่วนที่เกี่ยวข้องของโพสต์นี้

เราดำเนินการแก้ไขปัญหาการบล็อกที่เหลืออยู่ทั้งหมดอย่างต่อเนื่องก่อนที่จะกำหนดมาตรฐาน API

Storage Access API คืออะไร

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

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

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

กรณีการใช้งาน

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

กรณีการใช้งานมีดังนี้

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

กรณีการใช้งานเหล่านี้ส่วนมากเกี่ยวข้องกับการคงสิทธิ์เข้าถึงไว้เพื่อเข้าสู่ระบบใน iframe ที่ฝัง

เมื่อใดที่ควรใช้ Storage Access API เหนือ API อื่นๆ

Storage Access API เป็นหนึ่งในทางเลือกแทนการใช้คุกกี้และพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชัน คุณจึงต้องเข้าใจว่าเมื่อใดควรใช้ API นี้เมื่อเทียบกับ API อื่นๆ โดยมีไว้สำหรับ Use Case ที่ทั้ง 2 เงื่อนไขต่อไปนี้

• ผู้ใช้จะโต้ตอบกับเนื้อหาที่ฝัง กล่าวคือไม่ใช่ iframe แบบแพสซีฟหรือ iframe ที่ซ่อนอยู่
• ผู้ใช้ได้ไปที่ต้นทางที่ฝังอยู่ในบริบทระดับบนสุด กล่าวคือเมื่อต้นทางนั้นไม่ได้ฝังอยู่ในเว็บไซต์อื่น

มี API อื่นๆ สำหรับกรณีการใช้งานที่หลากหลาย ดังนี้

• คุกกี้ที่มีสถานะพาร์ติชันอิสระ (CHIPS) ช่วยให้นักพัฒนาซอฟต์แวร์เลือกใช้คุกกี้ในพื้นที่เก็บข้อมูล "ที่แบ่งพาร์ติชันแล้ว" โดยมีโถคุกกี้แยกต่างหากของแต่ละเว็บไซต์ระดับบนสุด ตัวอย่างเช่น วิดเจ็ตแชทบนเว็บของบุคคลที่สามอาจใช้การตั้งค่าคุกกี้เพื่อบันทึกข้อมูลเซสชัน ข้อมูลเซสชันจะได้รับการบันทึกไว้ในแต่ละเว็บไซต์ ดังนั้นคุกกี้ที่กำหนดโดยวิดเจ็ตจึงไม่ต้องเข้าถึงบนเว็บไซต์อื่นๆ ที่มีการฝังคุกกี้ไว้เช่นกัน Storage Access API จะมีประโยชน์เมื่อวิดเจ็ตของบุคคลที่สามที่ฝังไว้ต้องใช้การแชร์ข้อมูลเดียวกันในต้นทางต่างๆ (เช่น รายละเอียดหรือค่ากำหนดเซสชันที่มีการเข้าสู่ระบบ)
• การแบ่งพาร์ติชันพื้นที่เก็บข้อมูล คือวิธีที่ iframe แบบข้ามเว็บไซต์สามารถใช้กลไกพื้นที่เก็บข้อมูล JavaScript ที่มีอยู่ในขณะที่แบ่งพื้นที่เก็บข้อมูลเบื้องหลังของแต่ละเว็บไซต์ เพื่อป้องกันไม่ให้มีการเข้าถึงพื้นที่เก็บข้อมูลที่ฝังในเว็บไซต์หนึ่งโดยการฝังเดียวกันบนเว็บไซต์อื่น
• ชุดเว็บไซต์ที่เกี่ยวข้อง (RWS) เป็นวิธีการหนึ่งสำหรับองค์กรในการประกาศความสัมพันธ์ระหว่างเว็บไซต์ต่างๆ เพื่อให้เบราว์เซอร์อนุญาตการเข้าถึงคุกกี้และพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชันสำหรับวัตถุประสงค์ที่เฉพาะเจาะจง เว็บไซต์ยังคงต้องขอสิทธิ์เข้าถึงด้วย Storage Access API แต่สำหรับเว็บไซต์ภายในชุด คุณจะให้สิทธิ์เข้าถึงได้โดยไม่ต้องมีข้อความแจ้งผู้ใช้
• การจัดการการรับรองแบบรวมศูนย์ (Federated Credential Management หรือ FedCM) คือแนวทางรักษาความเป็นส่วนตัวสำหรับบริการระบุตัวตนแบบรวมศูนย์ Storage Access API จะจัดการกับการเข้าถึงคุกกี้และพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชันหลังการเข้าสู่ระบบ สำหรับกรณีการใช้งานบางกรณี FedCM มีโซลูชันทางเลือกสำหรับ Storage Access API และอาจดีกว่าเนื่องจากมีข้อความแจ้งของเบราว์เซอร์ซึ่งเน้นการเข้าสู่ระบบมากกว่า อย่างไรก็ตาม การปรับใช้ FedCM มักจะต้องเปลี่ยนแปลงโค้ดของคุณเพิ่มเติม เช่น เพื่อรองรับปลายทาง HTTP
• นอกจากนี้ยังมี API ป้องกันการประพฤติมิชอบ เกี่ยวกับโฆษณา และการวัด นอกจากนี้ Storage Access API ก็ไม่ได้มีไว้เพื่อแก้ไขข้อกังวลดังกล่าว

ใช้ Storage Access API

Storage Access API มีวิธีการตามที่สัญญาไว้ 2 วิธี ได้แก่

• Document.hasStorageAccess() (ใช้ชื่อใหม่ว่า Document.hasUnpartitionedCookieAccess() ใน Chrome 125)
• Document.requestStorageAccess()

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

• navigator.permissions.query({name: "storage-access"});

ใช้เมธอด 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 using 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 requestStorageAccess() did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  if (hasAccess) {
    // Use the cookies
  }
}

document.querySelector('#my-button').addEventListener('click', doClick);

หากคุณจำเป็นต้องใช้พื้นที่เก็บข้อมูลในเครื่องแทนคุกกี้ คุณสามารถดำเนินการต่อไปนี้

let handle = null;

async function doClick() {
  if (!handle) {
    try {
      handle = await document.requestStorageAccess({localStorage: true});
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  // Use handle to access unpartitioned local storage.
  handle.localStorage.setItem('foo', 'bar');
}

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 earlier 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') {
            // Not used: see https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by earlier tests.
  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 และจะไม่จำกัด SAA ไว้เฉพาะคุกกี้ Secure ดังนั้นจึงไม่จำเป็นต้องระบุแอตทริบิวต์เหล่านี้ เราขอแนะนำให้ใช้แอตทริบิวต์ SameSite อย่างชัดแจ้งและใช้คุกกี้ Secure เสมอ

การเข้าถึงหน้าเว็บระดับบนสุด

Storage Access API มีไว้เพื่อเปิดใช้การเข้าถึงคุกกี้ของบุคคลที่สามภายใน iframe ที่ฝังไว้

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

เมธอด requestStorageAccessFor()

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

โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับวิธีใช้ requestStorageAccessFor() ในชุดเว็บไซต์ที่เกี่ยวข้อง: คู่มือนักพัฒนาซอฟต์แวร์

การค้นหาสิทธิ์ top-level-storage-access

ซึ่งคล้ายกับสิทธิ์ storage-access คือมีสิทธิ์ top-level-storage-access ในการตรวจสอบว่าสามารถให้สิทธิ์เข้าถึงสำหรับ requestStorageAccessFor() ได้หรือไม่

Storage Access API จะต่างออกไปอย่างไรเมื่อใช้ร่วมกับ RWS

เมื่อใช้ชุดเว็บไซต์ที่เกี่ยวข้องกับ Storage Access API ความสามารถเพิ่มเติมบางอย่างจะพร้อมใช้งานตามรายละเอียดในตารางต่อไปนี้

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

การสาธิต: การตั้งค่าและการเข้าถึงคุกกี้

การสาธิตต่อไปนี้แสดงวิธีการเข้าถึงคุกกี้ที่ตั้งค่าด้วยตัวคุณเองในหน้าจอแรกของการสาธิตในเฟรมแบบฝังในเว็บไซต์ที่ 2 ของการสาธิต

storage-access-api-demo.glitch.me

เดโมต้องใช้เบราว์เซอร์ที่ปิดใช้คุกกี้ของบุคคลที่สาม

• Chrome 118 ขึ้นไปโดยตั้งค่าแฟล็ก chrome://flags/#test-third-party-cookie-phaseout แล้วและรีสตาร์ทเบราว์เซอร์
• Firefox
• Safari

การสาธิต: การตั้งค่าพื้นที่เก็บข้อมูลในเครื่อง

การสาธิตต่อไปนี้แสดงวิธีการเข้าถึงช่องการออกอากาศที่ไม่ได้แบ่งพาร์ติชันจาก iframe ของบุคคลที่สามโดยใช้ Storage Access API

https://saa-beyond-cookies.glitch.me/

การสาธิตต้องใช้ Chrome 125 ขึ้นไปที่เปิดใช้ Flag test-third-party-cookie-phaseout

แหล่งข้อมูล

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