Storage Access API

Pemblokiran cookie pihak ketiga oleh browser, setelan pengguna, dan partisi penyimpanan menimbulkan tantangan bagi situs dan layanan yang mengandalkan cookie dan penyimpanan lainnya dalam konteks sematan, untuk perjalanan pengguna seperti autentikasi. Storage Access API (SAA) memungkinkan kasus penggunaan ini terus berfungsi, sekaligus membatasi pelacakan lintas situs sebanyak mungkin.

Status penerapan

Storage Access API tersedia di semua browser utama, tetapi ada sedikit perbedaan implementasi antar-browser. Perbedaan ini telah ditandai di bagian yang relevan dalam postingan ini.

Kami terus berupaya menyelesaikan semua masalah penghambat yang tersisa, sebelum menyeragamkan API.

Apa itu Storage Access API?

Storage Access API adalah JavaScript API yang memungkinkan iframe meminta izin akses penyimpanan jika akses akan ditolak oleh setelan browser. Penyematan dengan kasus penggunaan yang bergantung pada pemuatan resource lintas situs dapat menggunakan API untuk meminta izin akses dari pengguna, sesuai kebutuhan.

Jika permintaan penyimpanan diberikan, iframe akan memiliki akses ke cookie dan penyimpanan yang tidak dipartisi, yang juga tersedia saat pengguna mengunjunginya sebagai situs tingkat teratas.

Storage Access API memungkinkan akses penyimpanan dan cookie tanpa partisi tertentu diberikan dengan beban minimal kepada pengguna akhir, sekaligus mencegah akses penyimpanan dan cookie tanpa partisi umum seperti yang sering digunakan untuk pelacakan pengguna.

Kasus penggunaan

Beberapa sematan pihak ketiga memerlukan akses ke cookie atau penyimpanan yang tidak dipartisi untuk memberikan pengalaman yang lebih baik kepada pengguna—sesuatu yang tidak akan tersedia saat cookie pihak ketiga dibatasi dan partisi penyimpanan diaktifkan.

Kasus penggunaan mencakup:

• Widget komentar tersemat yang memerlukan detail sesi login.
• Tombol "Suka" media sosial yang memerlukan detail sesi login.
• Dokumen tersemat yang memerlukan detail sesi login.
• Pengalaman premium yang diberikan ke sematan video (misalnya, agar tidak menampilkan iklan untuk pengguna yang login, atau untuk mengetahui preferensi pengguna terkait teks tertutup atau membatasi jenis video tertentu).
• Sistem pembayaran tersemat.

Banyak kasus penggunaan ini melibatkan mempertahankan akses login di iframe sematan.

Waktu yang tepat untuk menggunakan Storage Access API dibandingkan API lainnya

Storage Access API adalah salah satu alternatif untuk menggunakan cookie dan penyimpanan tanpa partisi, jadi penting untuk memahami kapan harus menggunakan API ini dibandingkan dengan yang lain. API ini ditujukan untuk kasus penggunaan saat kedua hal berikut terpenuhi:

• Pengguna akan berinteraksi dengan konten yang disematkan—yaitu, bukan iframe pasif atau iframe tersembunyi.
• Pengguna telah mengunjungi origin yang disematkan dalam konteks tingkat teratas—yaitu, saat origin tersebut tidak disematkan di situs lain.

Ada API alternatif untuk berbagai kasus penggunaan:

• Cookie dengan Status Partisi Independen (CHIPS) memungkinkan developer mengikutsertakan cookie ke penyimpanan "yang dipartisi", dengan toples cookie terpisah per situs tingkat teratas. Misalnya, widget chat web pihak ketiga mungkin mengandalkan penetapan cookie untuk menyimpan informasi sesi. Informasi sesi disimpan per situs, sehingga cookie yang ditetapkan oleh widget tidak perlu diakses di situs lain tempat widget tersebut juga disematkan. Storage Access API berguna saat widget pihak ketiga yang disematkan bergantung pada berbagi informasi yang sama di berbagai origin (misalnya untuk detail atau preferensi sesi login).
• Partisi Penyimpanan adalah cara bagi iframe lintas situs untuk menggunakan mekanisme penyimpanan JavaScript yang ada sambil membagi penyimpanan pokok per situs. Tindakan ini mencegah penyimpanan sematan di satu situs diakses oleh sematan yang sama di situs lain.
• Set Situs Terkait (RWS) adalah cara bagi organisasi untuk menyatakan hubungan antar-situs, sehingga browser mengizinkan akses penyimpanan dan cookie tanpa partisi yang terbatas untuk tujuan tertentu. Situs masih perlu meminta akses dengan Storage Access API, tetapi untuk situs dalam set, akses dapat diberikan tanpa perintah pengguna.
• Federated Credential Management (FedCM) adalah pendekatan yang menjaga privasi untuk layanan identitas gabungan. Storage Access API menangani akses ke cookie dan penyimpanan tanpa partisi setelah login. Untuk beberapa kasus penggunaan, FedCM memberikan solusi alternatif untuk Storage Access API, dan mungkin lebih disukai karena menampilkan dialog browser yang lebih berorientasi pada login. Namun, penggunaan FedCM biasanya memerlukan perubahan tambahan pada kode Anda, misalnya untuk mendukung endpoint HTTP-nya.
• Ada juga API anti-penipuan, terkait iklan, dan pengukuran, dan Storage Access API tidak dimaksudkan untuk mengatasi masalah tersebut.

Menggunakan Storage Access API

Storage Access API memiliki dua metode berbasis promise:

• Document.hasStorageAccess() (juga tersedia dengan nama baru Document.hasUnpartitionedCookieAccess() mulai Chrome 125)
• Document.requestStorageAccess()

Class ini juga terintegrasi dengan Permissions API. Hal ini memungkinkan Anda memeriksa status izin akses penyimpanan dalam konteks pihak ketiga, yang menunjukkan apakah panggilan ke document.requestStorageAccess() akan otomatis diberikan:

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

Gunakan metode hasStorageAccess()

Saat situs dimuat pertama kali, situs dapat menggunakan metode hasStorageAccess() untuk memeriksa apakah akses ke cookie pihak ketiga telah diberikan.

// 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.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

Storage Access API hanya memberikan akses penyimpanan ke dokumen iframe setelah memanggil requestStorageAccess(), sehingga hasStorageAccess() mungkin menampilkan nilai salah pada awalnya, misalnya jika pengguna memblokir cookie pihak ketiga secara default. (Namun, setelan pengguna khusus situs juga dapat mengizinkan akses cookie di situs tertentu, meskipun pengguna memblokir cookie pihak ketiga secara default.) Akses penyimpanan menggunakan API ini dipertahankan di seluruh navigasi origin yang sama di dalam iframe secara khusus untuk memungkinkan pemuatan ulang setelah memberikan akses untuk halaman yang memerlukan cookie agar ada dalam permintaan awal untuk dokumen HTML.

Gunakan requestStorageAccess()

Jika tidak memiliki akses, iframe mungkin perlu meminta akses menggunakan metode requestStorageAccess():

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

Saat pertama kali diminta, pengguna mungkin perlu menyetujui akses ini dengan perintah browser, setelah itu promise akan diselesaikan, atau akan ditolak sehingga menghasilkan pengecualian jika await digunakan.

Untuk mencegah penyalahgunaan, perintah browser ini hanya akan ditampilkan setelah interaksi pengguna. Itulah sebabnya requestStorageAccess() awalnya perlu dipanggil dari handler peristiwa yang diaktifkan pengguna, bukan segera saat iframe dimuat:

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);

Dialog izin

Saat pengguna mengklik tombol untuk pertama kalinya, perintah browser akan otomatis muncul dalam sebagian besar kasus, biasanya di kolom URL. Screenshot berikut menampilkan contoh perintah Chrome, tetapi browser lain memiliki UI yang serupa:

Dialog mungkin dilewati oleh browser dan izin diberikan secara otomatis dalam keadaan tertentu:

• Jika halaman dan iframe telah digunakan dalam 30 hari terakhir setelah menyetujui perintah.
• Jika iframe yang disematkan adalah bagian dari Set Situs Terkait.
• Jika FedCM digunakan sebagai sinyal kepercayaan untuk akses penyimpanan.
• Di Firefox, perintah juga dilewati untuk situs yang dikenal (situs yang telah Anda ajak berinteraksi di tingkat teratas) untuk lima upaya pertama.

Atau, metode dapat ditolak secara otomatis tanpa menampilkan perintah dalam keadaan tertentu:

• Jika pengguna belum pernah mengunjungi dan berinteraksi dengan situs yang memiliki iframe sebagai dokumen tingkat teratas, bukan di iframe. Artinya, Storage Access API hanya berguna untuk situs sematan yang sebelumnya dikunjungi pengguna dalam konteks pihak pertama.
• Jika metode requestStorageAccess() dipanggil di luar peristiwa interaksi pengguna tanpa persetujuan sebelumnya atas dialog setelah interaksi.

Meskipun pengguna akan diminta saat penggunaan awal, kunjungan berikutnya dapat menyelesaikan requestStorageAccess() tanpa perintah dan tanpa memerlukan interaksi pengguna di Chrome dan Firefox. Perhatikan bahwa Safari selalu memerlukan interaksi pengguna.

Karena akses cookie dan penyimpanan dapat diberikan tanpa perintah, atau interaksi pengguna, sering kali akses cookie atau penyimpanan tanpa partisi dapat diperoleh sebelum interaksi pengguna di browser yang mendukungnya (Chrome dan Firefox) dengan memanggil requestStorageAccess() saat halaman dimuat. Hal ini dapat memungkinkan Anda mengakses cookie dan penyimpanan tanpa partisi secara langsung dan memberikan pengalaman yang lebih lengkap, bahkan sebelum pengguna berinteraksi dengan iframe. Hal ini dapat memberikan pengalaman pengguna yang lebih baik dalam beberapa situasi daripada menunggu interaksi pengguna.

FedCM sebagai sinyal kepercayaan untuk SAA

FedCM (Federated Credential Management) adalah pendekatan yang menjaga privasi untuk layanan identitas gabungan (seperti "Login dengan...") yang tidak mengandalkan cookie pihak ketiga atau pengalihan navigasi.

Saat pengguna login ke Pihak Tepercaya (RP) yang memiliki beberapa konten sematan dari penyedia identitas (IdP) pihak ketiga dengan FedCM, konten IdP sematan dapat otomatis mendapatkan akses penyimpanan ke cookie tingkat teratasnya sendiri yang tidak dipartisi. Untuk mengaktifkan akses penyimpanan otomatis dengan FedCM, kondisi berikut harus dipenuhi:

• Autentikasi FedCM (status login pengguna) harus aktif.
• RP telah memilih untuk mengaktifkan izin identity-credentials-get dengan menyetelnya, misalnya:

<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>

Misalnya, iframe idp.example disematkan di rp.example. Saat pengguna login dengan FedCM, iframe idp.example dapat meminta akses penyimpanan untuk cookie tingkat teratasnya sendiri.

rp.example membuat panggilan FedCM untuk login pengguna dengan penyedia identitas idp.example:

// The user will be asked to grant FedCM permission.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
});

Setelah pengguna login, IdP dapat memanggil requestStorageAccess() dari dalam iframe idp.example, selama RP telah mengizinkan hal ini secara eksplisit dengan Permissions Policy. Penyematan akan otomatis diberi akses penyimpanan ke cookie tingkat teratasnya sendiri, tanpa aktivasi pengguna atau memerlukan dialog izin lain:

// Make this call within the embedded IdP iframe:

// No user gesture is needed, and the storage access will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

Izin akan diberikan secara otomatis hanya selama pengguna login dengan FedCM. Setelah autentikasi tidak aktif, persyaratan SAA standar berlaku untuk memberikan akses penyimpanan.

Storage Access API untuk penyimpanan non-cookie

Anda dapat meminta akses ke penyimpanan lokal yang tidak dipartisi dengan meneruskan parameter types ke panggilan requestStorageAccess Anda. Misalnya, untuk meminta akses ke penyimpanan lokal yang tidak dipartisi, Anda dapat memanggil requestStorageAccess({localStorage: true}).

Jika cookie pihak ketiga diaktifkan, metode ini akan memberikan akses tanpa memerlukan aktivasi pengguna atau perintah izin apa pun. Jika pengguna telah menonaktifkan cookie pihak ketiga, pengguna harus diminta izinnya sebelum akses penyimpanan diberikan.

Pertama, periksa apakah browser sudah memiliki akses penyimpanan:

async function hasCookieAccess(){
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported, so we assume it's an older browser that doesn't partition storage.
    throw new Error("requestStorageAccess is not supported")
  }

  // Check if access has already been granted or if the user has 3-party cookies enabled
  return document.hasStorageAccess();
}

Jika cookie pihak ketiga diaktifkan, minta akses penyimpanan:

// Request storage access and return the storage handle
async function requestStorageHandle(){
// You can request for multiple types of non-cookie storage
// at once, or request for all of them with all:true
return document.requestStorageAccess({all:true});
}

Jika cookie pihak ketiga diblokir (misalnya, dalam mode Samaran), periksa izin kueri untuk memutuskan apakah perintah pengguna diperlukan. Status izin navigator.permissions.query({name: 'storage-access'}) dapat memiliki nilai berikut:

• granted. Pengguna telah memberikan akses. Panggil requestStorageAccess untuk mendapatkan akses penyimpanan yang tidak dipartisi tanpa memerlukan perintah pengguna tambahan.
• prompt. Pengguna belum memberikan akses. Tetapkan click listener dan panggil requestStorageAccess lagi setelah interaksi pengguna.
• error. Izin tidak didukung. Jika Storage Access API didukung, izin ini kemungkinan juga didukung.

// Returns `granted`, or `prompt`; or throws an error if storage-access
// permission is not supported
async function getStorageAccessPermission(){
  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
    return navigator.permissions.query({name: 'storage-access'});
}

Alur lengkap untuk menangani penyimpanan yang dipartisi non-cookie dapat diterapkan sebagai berikut:

async function getStorageHandle() {
    // Check if the user has 3-party cookie access
    if (await hasCookieAccess()) {
    // If the user has access, requestStorageAccess() will resolve automatically
        return requestStorageHandle();
    }

    // If the browser blocks third party cookies, check if the user has
    // accepted the prompt and granted access. If they have,
    // requestStorageAccess() will resolve automatically
    const permission = await getStorageAccessPermission();
    if (permission == 'granted') { // User has seen prompt and granted access
        return requestStorageHandle();
    }

    // Wait for user activation to prompt the user again
    // (or put your silent failure logic here instead)
    return new Promise((resolve, reject) => {
        document.querySelector('#myButton').addEventListener(e => {
            requestStorageHandle().then(resolve, reject);
        })
    })
}

// Use your storage
getStorageHandle().then(handle=>{
    handle.indexedDB.open(...);
}).catch(() => {
    // If the promise is rejected, you can use regular partitioned storage
    indexedDB.open(...);
})

Pemuatan berikutnya dengan Header Akses Penyimpanan

Header Akses Penyimpanan adalah cara yang direkomendasikan dan lebih berperforma untuk mengaktifkan pemuatan konten sematan, termasuk resource non-iframe. Fitur ini tersedia mulai Chrome 133. Dengan Header Akses Penyimpanan, browser dapat mengenali saat pengguna telah memberikan izin storage-access ke origin pihak ketiga dalam konteks saat ini, dan dapat memuat resource dengan akses ke cookie tanpa partisi selama kunjungan berikutnya.

Alur header akses penyimpanan

Dengan Header Akses Penyimpanan, kunjungan halaman berikutnya akan memicu alur berikut:

1. Pengguna sebelumnya telah mengunjungi website.example yang menyematkan resource calendar.example dan memberikan storage-access dengan panggilan document.requestStorageAccess().
2. Pengguna mengunjungi website.example yang memiliki resource calendar.example yang disematkan lagi. Permintaan ini belum memiliki akses ke cookie, seperti sebelumnya. Namun, pengguna sebelumnya telah memberikan izin storage-access, dan fetch menyertakan header Sec-Fetch-Storage-Access: inactive, untuk menunjukkan bahwa akses cookie tanpa partisi tersedia tetapi tidak diaktifkan.
3. Server calendar.example merespons dengan header Activate-Storage-Access: retry; allowed-origin='<origin>' (dalam hal ini, <origin> adalah https://website.example), untuk menunjukkan bahwa pengambilan resource memerlukan penggunaan cookie yang tidak dipartisi dengan izin storage-access.
4. Browser mencoba kembali permintaan, kali ini termasuk cookie yang tidak dipartisi (mengaktifkan izin storage-access untuk pengambilan ini dan pengambilan berikutnya).
5. Server calendar.example merespons dengan konten iframe yang dipersonalisasi. Respons menyertakan header Activate-Storage-Access: load, untuk menunjukkan bahwa browser harus memuat konten dengan izin storage-access diaktifkan (dengan kata lain, memuat dengan akses cookie yang tidak dipartisi, seolah-olah document.requestStorageAccess() telah dipanggil).
6. Agen pengguna memuat konten iframe dengan akses cookie yang tidak dipartisi menggunakan izin storage-access. Setelah langkah ini, widget dapat berfungsi seperti yang diharapkan.

Menggunakan header akses penyimpanan

Tabel berikut mencantumkan header Akses Penyimpanan.

Misalnya, Header Akses Penyimpanan dapat digunakan untuk memuat gambar dari pihak ketiga:

  // On the client side
  <img src="https://server.example/image">

Dalam hal ini, server.example harus menerapkan logika berikut di sisi server:

  app.get('/image', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // The user needs to grant permission, trigger a prompt

    // Check if the requesting origin is allowed
    // to send credentialed requests to this server.
    // Assuming the `validate_origin(origin)` method is previously defined:
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(req.headers.origin +
        ' is not allowed to send credentialed requests to this server.');
      return;
    }
    // 'retry' header value indicates that the content load request should be re-sent after the user has granted permissions
    res.set('Activate-Storage-Access', `retry; allowed-origin='${req.headers.origin}'`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

Demo Storage Access API menyematkan konten pihak ketiga (termasuk gambar non-iframe) menggunakan Header Akses Penyimpanan.

Menggunakan kueri izin storage-access

Untuk memeriksa apakah akses dapat diberikan tanpa interaksi pengguna, Anda dapat memeriksa status izin storage-access dan hanya melakukan panggilan requestStoreAccess() lebih awal jika tidak ada tindakan pengguna yang diperlukan, daripada memanggilnya dan membuatnya gagal saat interaksi diperlukan.

Hal ini juga memungkinkan Anda menangani kebutuhan perintah di awal dengan menampilkan konten yang berbeda—misalnya, tombol login.

Kode berikut menambahkan pemeriksaan izin storage-access ke contoh sebelumnya:

// 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 dengan sandbox

Saat menggunakan Storage Access API di iframe dengan sandbox, izin sandbox berikut diperlukan:

• allow-storage-access-by-user-activation diperlukan untuk mengizinkan akses ke Storage Access API.
• allow-scripts diperlukan untuk mengizinkan penggunaan JavaScript guna memanggil API.
• allow-same-origin diperlukan untuk mengizinkan akses ke cookie dan penyimpanan lainnya yang berasal dari origin yang sama.

Contoh:

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

Persyaratan cookie

Agar dapat diakses dengan Storage Access API di Chrome, cookie lintas situs harus ditetapkan dengan dua atribut berikut:

• SameSite=None - yang diperlukan untuk menandai cookie sebagai lintas situs
• Secure - yang memastikan hanya cookie yang ditetapkan oleh situs HTTPS yang dapat diakses.

Di Firefox dan Safari, cookie secara default ditetapkan ke SameSite=None dan tidak membatasi SAA ke cookie Secure sehingga atribut ini tidak diperlukan. Sebaiknya tetapkan atribut SameSite secara eksplisit dan selalu gunakan cookie Secure.

Akses halaman tingkat teratas

Storage Access API ditujukan untuk mengaktifkan akses ke cookie pihak ketiga dalam iframe sematan.

Ada juga kasus penggunaan lain saat halaman tingkat teratas memerlukan akses ke cookie pihak ketiga. Misalnya, gambar atau skrip yang dibatasi oleh cookie, yang mungkin ingin disertakan langsung oleh pemilik situs dalam dokumen tingkat teratas, bukan dalam iframe. Untuk menangani kasus penggunaan ini, Chrome telah mengusulkan ekstensi pada Storage Access API yang menambahkan metoderequestStorageAccessFor().

Metode requestStorageAccessFor()

Metode requestStorageAccessFor() berfungsi dengan cara yang serupa dengan requestStorageAccess(), tetapi untuk resource tingkat teratas. API ini hanya dapat digunakan untuk situs dalam Set Situs Terkait guna mencegah pemberian akses umum ke cookie pihak ketiga.

Untuk mengetahui detail selengkapnya tentang cara menggunakan requestStorageAccessFor(), baca Set Situs Terkait: panduan developer.

Kueri izin top-level-storage-access

Mirip dengan izin storage-access, ada izin top-level-storage-access untuk memeriksa apakah akses dapat diberikan untuk requestStorageAccessFor().

Apa perbedaan Storage Access API saat digunakan dengan RWS?

Jika Set Situs Terkait digunakan dengan Storage Access API, kemampuan tambahan tertentu akan tersedia seperti yang dijelaskan dalam tabel berikut:

Demo: menyetel dan mengakses cookie

Demo berikut menunjukkan cara mengakses cookie yang Anda tetapkan sendiri di layar pertama demo dalam frame sematan di situs kedua demo:

storage-access-api-demo.glitch.me

Demo ini memerlukan browser dengan cookie pihak ketiga yang dinonaktifkan:

• Chrome 118 atau yang lebih baru dengan setelan flag chrome://flags/#test-third-party-cookie-phaseout dan browser dimulai ulang.
• Firefox
• Safari

Demo: menyetel Penyimpanan Lokal

Demo berikut menunjukkan cara mengakses Channel Siaran yang tidak dipartisi dari iframe pihak ketiga menggunakan Storage Access API:

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

Demo ini memerlukan Chrome 125 atau yang lebih baru dengan tanda test-third-party-cookie-phaseout yang diaktifkan.

Resource

• Baca spesifikasi yang memberikan akses cookie pihak ketiga atau ikuti dan ajukan masalah.
• Baca spesifikasi yang menyediakan akses penyimpanan yang tidak dipartisi atau ikuti dan ajukan masalah.
• Dokumentasi API dan panduan.
• Dokumentasi Chrome tentang penggunaan Storage Access API di Set Situs Terkait