Integrasi dan pengoptimalan layanan Bidding dan Lelang

Proposal desain Bidding dan Layanan Lelang untuk Android menjelaskan detail eksekusi dan aliran data lelang yang berjalan di Android menggunakan server Bidding dan Lelang Tepercaya. Untuk memastikan data dalam pengiriman hanya ditangani oleh API yang menjaga privasi dan server tepercaya, data dienkripsi antara klien dan server menggunakan Enkripsi Kunci Publik Hybrid dua arah.

Untuk menjalankan lelang seperti yang diuraikan sebelumnya, teknologi iklan penjual di perangkat harus lakukan langkah-langkah berikut:

1. Mengumpulkan dan mengenkripsi data untuk lelang server
2. Mengirim permintaan ke Layanan Penjual Tidak Tepercaya
3. Menerima respons dari Layanan Penjual Tidak Tepercaya
4. Mendekripsi respons lelang Protected Audience dan mendapatkan hasil lelang

Protected Audience memperkenalkan dua API baru untuk mendukung lelang server yang sedang berjalan:

1. getAdSelectionData API mengumpulkan data untuk lelang server dan membuat payload terenkripsi yang berisi data lelang. Server Bidding dan Lelang menggunakan payload ini untuk menjalankan lelang, membuat hasil lelang, dan menampilkan hasil lelang.
2. Klien teknologi iklan di perangkat dapat memanggil persistAdSelectionResult API untuk mendekripsi hasil yang dibuat oleh lelang server dan mendapatkan URL rendering iklan pemenang.

Teknologi iklan penjual di perangkat perlu mengintegrasikan dan membuat hal berikut untuk menjalankan lelang:

1. Mengumpulkan dan mengenkripsi data untuk Penjual lelang server: Teknologi iklan harus memanggil getAdSelectionData API untuk mendapatkan payload terenkripsi.
2. Mengirim permintaan ke Pengiriman Layanan Penjual Tidak Tepercaya: Permintaan HTTP POST atau PUT berisi payload terenkripsi yang dihasilkan oleh getAdSelectionData API ke layanan dan data penjual tidak tepercaya diperlukan oleh layanan penjual tidak tepercaya untuk membuat hasil kontekstual.
3. Menerima respons dari Layanan Penjual Tidak Tepercaya: Respons dari layanan penjual tidak tepercaya akan berisi hasil lelang protected audience terenkripsi dan hasil lelang kontekstual.
4. Mendekripsi respons lelang protected audience dan mendapatkan hasil lelang: Untuk mendekripsi hasil lelang protected audience, teknologi iklan penjual harus memanggil API persistAdSelectionResult. Hasil yang dihasilkan oleh persistAdSelectionResult akan membantu teknologi iklan menentukan apakah konteks iklan atau iklan audiens yang dilindungi memenangkan lelang dan URI pemenang iklan audiens yang dilindungi jika berlaku.

Fitur yang didukung untuk lelang server

Kami ingin mendukung semua fitur yang saat ini tersedia untuk lelang di perangkat. Linimasa untuk mendukung fitur ini di lelang server adalah sebagai berikut:

Menjalankan Lelang Server menggunakan Protected Audience API

Di jalur Pratinjau Developer, AdSelectionManager mengekspos dua API baru: getAdSelectionData dan persistAdSelectionResult. API ini memungkinkan SDK teknologi iklan terintegrasi dengan server Bidding dan Lelang.

Mengumpulkan dan mengenkripsi data untuk lelang server

getAdSelectionData API menghasilkan input yang diperlukan untuk komponen Bidding dan Lelang seperti BuyerInput dan ProtectedAudienceInput, serta mengenkripsi data sebelum membuat hasil tersedia bagi pemanggil. Untuk mencegah kebocoran data di seluruh aplikasi, data ini berisi informasi dari semua pembeli yang ada di perangkat. Baca selengkapnya tentang keputusan ini di bagian pertimbangan privasi dan strategi untuk mengoptimalkannya di bagian pertimbangan ukuran.

Untuk mengakses API, akses ke Protected Audience API harus diaktifkan, dan izin ACCESS_ADSERVICES_CUSTOM_AUDIENCE harus ditentukan di manifes pemanggil.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. Pemanggil harus menetapkan kolom seller dalam permintaan karena digunakan untuk menjalankan pemeriksaan pendaftaran sebelum melayani permintaan.
2. Kolom coordinatorOriginUri bersifat opsional.
   1. Jika disetel, ini harus sama dengan skema, nama host, dan porta URL koordinator yang dikonfigurasi saat men-deploy server B&A penjual.
   2. Koordinator harus termasuk dalam daftar koordinator yang disetujui:

      Penyedia	URI	Asal URI	Default
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	Ya
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	Tidak

   3. Jika asal koordinator tidak diberikan, koordinator default akan digunakan.
   4. Meskipun kecil kemungkinan URL Koordinator akan berubah, sangat disarankan untuk menerapkan mekanisme untuk mengelola URL ini secara dinamis. Hal ini memastikan bahwa setiap perubahan berikutnya pada URL dapat diakomodasi tanpa memerlukan rilis SDK baru.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

Setelah permintaan divalidasi, data pembeli di perangkat disusun menjadi BuyerInput dan ProtectedAudienceInput. Objek payload akhir kemudian dienkripsi menggunakan Enkripsi Kunci Publik Hybrid dua arah.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome dibuat sebagai hasil dari getAdSelectionData API. Isinya adalah sebagai berikut:

1. adSelectionId: bilangan bulat buram untuk mengidentifikasi pemanggilan getAdSelectionData ini. Klien teknologi iklan harus mempertahankan nilai adSelectionId ini karena bertindak sebagai pointer ke panggilan getAdSelectionData. ID ini diperlukan oleh persistAdSelectionResult API untuk mendekripsi hasil lelang dari server Bidding dan Lelang serta diperlukan oleh API reportImpression dan reportEvent.
2. adSelectionData: Ini adalah data lelang terenkripsi yang akan diperlukan oleh server Bidding dan Lelang untuk menjalankan lelang. Metode ini berisi:
   1. Data Audiens Kustom yang difilter didasarkan pembatasan frekuensi, filter penginstalan aplikasi, dan persyaratan lelang server untuk Audiens Kustom.
   2. Pada versi mendatang, versi ini akan berisi data penginstalan aplikasi.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Penanganan error, pengecualian, dan kegagalan

Jika pembuatan data pemilihan iklan tidak berhasil diselesaikan karena alasan seperti argumen tidak valid, waktu tunggu habis, atau konsumsi resource berlebih, callback OutcomeReceiver.onError() akan memberikan AdServicesException dengan perilaku berikut:

1. Jika getAdSelectionData dimulai dengan argumen yang tidak valid, AdServicesException` akan menunjukkan IllegalArgumentException sebagai penyebabnya.
2. Semua error lainnya akan menerima AdServicesException dengan IllegalStateException sebagai penyebabnya.

Mengirim permintaan ke layanan penjual tidak tepercaya

Dengan AdSelectionData, SDK di perangkat dapat mengirim permintaan ke layanan iklan penjualnya dengan menyertakan data dalam permintaan POST atau PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
...
})

SDK di perangkat bertanggung jawab untuk mengenkode data ini. Sebaiknya gunakan solusi yang hemat ruang seperti mengirim permintaan ke layanan iklan penjual sebagai multibagian/formulir data.

Menerima respons dari layanan penjual tidak tepercaya

Seperti yang dijelaskan dalam Penjelasan Server Bidding dan Lelang, saat layanan penjual tidak tepercaya menerima permintaan, layanan akan melakukan panggilan ke pembeli partner untuk iklan kontekstual.

Layanan penjual tidak tepercaya meneruskan adSelectionData dan AuctionConfig yang dienkripsi ke layanan SellerFrontEnd server Bidding dan Lelang yang berjalan dalam TEE.

Saat lelang Protected Audience selesai, layanan SellerFrontEnd mengenkripsi hasil lelang dan menampilkannya sebagai respons terhadap layanan penjual tidak tepercaya.

Layanan penjual tidak tepercaya mengirimkan respons ke perangkat yang berisi iklan kontekstual dan/atau hasil lelang Protected Audience terenkripsi.

Saat menerima respons, kode teknologi iklan penjual di perangkat dapat memilih untuk hanya menggunakan iklan kontekstual dalam respons atau jika dianggap ada nilai inkremental dalam mendapatkan hasil Protected Audience, kode tersebut dapat memilih untuk mendekripsi hasil Protected Audience dengan memanggil PersistAdSelectionResult API.

PersistAdSelectionResult API

Untuk mendekripsi hasil Protected Audience, teknologi iklan penjual dapat memanggil Protected Audience API persistAdSelectionResult kedua. API mendekripsi hasil dan menampilkan AdSelectionOutcome, objek yang sama seperti yang ditampilkan dari lelang di perangkat saat ini.

Untuk mengakses API, pemanggil harus mengaktifkan akses ke Protected Audience API dan menentukan izin ACCESS_ADSERVICES_CUSTOM_AUDIENCE di manifesnya.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

Pemanggil harus menetapkan hal berikut dalam permintaan:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: ID buram yang dihasilkan oleh panggilan getAdSelectionData yang hasilnya ingin didekripsi oleh pemanggil.
2. seller: ID teknologi iklan penjual harus ditetapkan dalam permintaan untuk menjalankan pemeriksaan pendaftaran sebelum melayani permintaan.
3. adSelectionResult: Hasil lelang terenkripsi yang dihasilkan oleh server Bidding dan Lelang yang ingin didekripsi oleh pemanggil.

Respons AdSelectionOutcome

Jika ada pemenang Protected Audience, AdSelectionOutcome akan menampilkan URI rendering iklan pemenang. Setelah adSelectionResult didekripsi, data pelaporan akan disimpan secara internal. Callback OutcomeReceiver.onResult() menampilkan AdSelectionOutcome yang berisi:

• URI: Jika ada iklan Protected Audience yang menang, URL rendering iklan untuk iklan pemenang akan ditampilkan. Jika tidak ada pemenang Protected Audience, `Uri.EMPTY akan ditampilkan.
• adSelectionId: adSelectionId yang terkait dengan berjalannya lelang server ini.

Penanganan error, pengecualian, dan kegagalan

Jika pembuatan data pemilihan iklan tidak berhasil diselesaikan karena alasan seperti argumen tidak valid, waktu tunggu habis, atau konsumsi resource berlebih, callback OutcomeReceiver.onError() akan memberikan AdServicesException dengan perilaku berikut:

1. Jika getAdSelectionData dimulai dengan argumen yang tidak valid, AdServicesException akan menunjukkan IllegalArgumentException sebagai penyebabnya.
2. Semua error lainnya akan menerima AdServicesException dengan IllegalStateException sebagai penyebabnya.

Pertimbangan Privasi

adSelectionData dienkripsi untuk memastikan bahwa data dalam pengiriman hanya dapat diakses oleh PPAPI dan server tepercaya.

Meskipun ada enkripsi, kebocoran data dapat terjadi karena ukuran adSelectionData. Ukuran adSelectionData dapat bervariasi karena:

1. Perubahan pada data CustomAudience ada di perangkat.
2. Perubahan pada logika pemfilteran CustomAudience.
3. Perubahan pada input untuk panggilan getAdSelectionData.

Perubahan ukuran adSelectionData dapat digunakan untuk membuat ID lintas-aplikasi seperti yang disebutkan dalam diskusi kebocoran 1-bit. Banyak mitigasi yang berlaku untuk kebocoran 1-bit juga berlaku di sini.

Untuk mengelola kebocoran ini, kami berencana membuat adSelectionData yang sama untuk semua panggilan ke getAdSelectionData API. Dalam rilis awal, semua CustomAudiences di perangkat digunakan untuk membuat adSelectionData dan payload terenkripsi akan ditambahkan ke variasi ukuran mask. Kami juga akan membatasi pengaruh parameter input GetAdSelectionData pada adSelectionData yang dihasilkan.

Namun, membuat adSelectionData yang sama untuk semua teknologi iklan yang menggunakan semua data lelang di perangkat menghasilkan payload besar yang sekarang perlu ditransfer dalam setiap panggilan ke server teknologi iklan. Penggunaan semua audiens kustom di perangkat untuk membuat payload lelang juga akan membuka ekosistem untuk penyalahgunaan dari entitas berbahaya. Kita telah membahas masalah ini di bagian Pengoptimalan ukuran dan Mitigasi penyalahgunaan di bawah.

Pengoptimalan ukuran

SDK klien teknologi iklan diharapkan untuk memaketkan byte terenkripsi adSelectionData ke dalam panggilan kontekstual HTTP PUT/POST yang dilakukan ke server teknologi iklan. Untuk latensi dan biaya waktu round-trip yang lebih rendah, Anda perlu mengurangi ukuran adSelectionData sebanyak mungkin tanpa memengaruhi utilitas.

Kami berencana untuk mengeksplorasi dan berpotensi memperkenalkan pengoptimalan berikut dalam rilis mendatang untuk mengurangi ukuran adSelectionData:

1. Payload yang dihasilkan dalam set ukuran bucket tetap dengan padding: Untuk meminimalkan kebocoran dari variasi ukuran sekaligus tetap memungkinkan payload yang lebih rendah, sebaiknya gunakan bucket ukuran tetap untuk payload yang dihasilkan. Dengan mempertahankan jumlah bucket yang kecil, misalnya 7, jumlah entropi yang bocor per panggilan ke getAdSelectionData kurang dari 3 bit.

   Jika data di perangkat melebihi ukuran bucket maksimum, strategi yang disebutkan di bawah seperti nilai prioritas akan digunakan untuk memutuskan data mana yang dihapus.

2. Konfigurasi Pembeli: Kami sedang menilai kelayakan untuk mengizinkan pembeli menyiapkan konfigurasi payload per pembeli. Konfigurasi ini akan berguna untuk mengidentifikasi lelang mana yang ingin diikuti oleh pembeli. Jika memungkinkan, selama pendaftaran, teknologi iklan pembeli dapat mendaftarkan endpoint tempat Protected Audience akan mengambil konfigurasi payload dengan ritme reguler harian. Atau, API yang menjaga privasi akan mengekspos API untuk memungkinkan teknologi iklan pembeli mendaftarkan endpoint ini.

   Konfigurasi ini kemudian akan digunakan untuk menilai kontribusi pembeli pada adSelectionData yang dihasilkan untuk setiap permintaan getAdSelectionData.

   Konfigurasi payload pembeli akan memungkinkan pembeli untuk menentukan:

   1. Daftar penjual yang diizinkan: CustomAudiences Pembeli akan ditambahkan ke payload hanya jika panggilan getAdSelectionData dimulai oleh penjual dalam daftar yang diizinkan. Kami akan mengambil konfigurasi payload pada ritme harian agar daftar yang diizinkan terus diperbarui.
   2. Batas ukuran per penjual: Pembeli dapat menetapkan batas ukuran per penjual untuk menentukan ukuran data yang akan dikirim dalam payload saat lelang dimulai oleh penjual tertentu. Hal ini akan berguna jika pembeli ingin menyediakan lebih banyak resource untuk memproses data lelang dari penjual tertentu. SellerFrontendService hanya meneruskan data khusus pembeli ke setiap BuyerFrontendService. Jadi, dengan menentukan batas ukuran per penjual, pembeli dapat secara eksplisit mengontrol jumlah data yang diserap dan diproses oleh BuyerFrontendService server Lelang dan Pembeli untuk lelang yang dijalankan oleh penjual.

3. Konfigurasi Penjual: Kami menilai kelayakan konfigurasi lelang per penjual yang memungkinkan penjual menentukan parameter lelang untuk mengontrol ukuran payload dan peserta lelang. Jika memungkinkan, selama pendaftaran, teknologi iklan penjual dapat menentukan endpoint tempat Protected Audience dapat mengambil konfigurasi lelang per penjual dengan ritme reguler. Selanjutnya, konfigurasi ini akan digunakan untuk menentukan komposisi dan batas adSelectionData yang dihasilkan untuk setiap permintaan getAdSelectionData.

   Serupa dengan konfigurasi pembeli, konfigurasi per penjual akan memungkinkan penjual menentukan kumpulan pembeli mana yang akan dilihat di lelang dan menentukan batas kontribusi per pembeli terhadap ukuran payload.

   Konfigurasi lelang penjual akan memungkinkan penjual untuk menentukan:

   1. Daftar pembeli yang diizinkan: Untuk lelang yang dimulai oleh penjual tertentu, hanya pembeli dalam daftar yang diizinkan yang dapat memberikan kontribusi CustomAudiences untuk lelang. Konfigurasi lelang harus diperbarui setiap hari agar daftar yang diizinkan tetap diperbarui dengan daftar pembeli sisi server yang diizinkan.
   2. Batas ukuran per pembeli: Penjual dapat menentukan batas per pembeli untuk mengatur ukuran data yang diupload oleh setiap pembeli ke dalam payload yang dikirim ke SellerFrontendService. Jika pembeli melebihi batas ukuran per pembeli, prioritas CustomAudience yang ditetapkan dalam konfigurasi payload pembeli akan digunakan untuk mendapatkan data dalam batas yang diharapkan.
   3. Prioritas per pembeli: Mengizinkan penjual menetapkan prioritas per pembeli. Prioritas pembeli akan digunakan untuk mengidentifikasi data pembeli mana yang harus disimpan dalam payload jika ukuran payload melebihi batas ukuran payload.
   4. Batas ukuran maksimum untuk payload: Penjual yang berbeda mungkin memiliki alokasi resource yang berbeda dan mungkin ingin menetapkan batas ukuran maksimum untuk payload lelang per permintaan. Batas ukuran maksimum akan mengikuti bucket ukuran tetap yang ditetapkan oleh Protected Audience API.

4. Perubahan Audiens Kustom

   1. Menentukan prioritas Audiens Kustom: Izinkan pembeli menentukan nilai prioritas dalam Audiens Kustom. Kolom priority akan digunakan untuk mengidentifikasi audiens kustom yang harus disertakan dalam lelang jika kumpulan audiens kustom pembeli melebihi batas ukuran per penjual atau per pembeli. Nilai prioritas yang tidak ditentukan dalam Audiens Kustom akan ditetapkan secara default ke 0.0.

5. Perubahan Data Payload

   1. Kurangi data yang dikirim dalam payload: Seperti yang dijelaskan dalam Pengoptimalan payload layanan Bidding dan Lelang, payload yang lebih tinggi didorong oleh data ads audiens kustom, sinyal bidding pengguna, sinyal Android. Payload yang lebih tinggi dapat diturunkan dengan:
      1. Meminta klien mengirim ID render iklan (bukan objek iklan) dalam payload.
      2. Meminta klien untuk tidak mengirimkan data iklan dalam payload.
      3. Tidak mengirim sinyal bidding pengguna dalam payload klien.

Meskipun strategi yang disebutkan di atas memungkinkan teknologi iklan untuk menentukan konfigurasi guna mengelola komposisi dan batas payload adSelectionData, strategi tersebut juga dapat menjadi faktor untuk memodulasi ukuran adSelectionData dengan mengubah parameter konfigurasi. Untuk menghindarinya, konfigurasi akan diambil setiap hari oleh Protected Audience dari endpoint yang dikonfigurasi.

Pengoptimalan latensi

Agar lelang server memiliki tingkat utilitas yang diinginkan, kita perlu memastikan bahwa getAdSelectionData API dan persistAdSelectionResult API memiliki latensi rendah per panggilan. Meskipun kami berencana memberikan dukungan fitur untuk API pada tahun 2023, rilis berikutnya akan berfokus pada tolok ukur latensi dan pengoptimalan untuk API.

Kami sedang mempelajari strategi berikut untuk menjaga latensi dalam batas yang dapat diterima:

1. Pra-pembuatan data Protected Audience per penjual: Karena konfigurasi lelang penjual dan konfigurasi payload pembeli akan stabil selama durasi yang cukup lama (harian), platform dapat melakukan pra-komputasi dan menyimpan data Protected Audience yang memenuhi syarat.

   Tindakan ini akan mengharuskan platform membuat mekanisme untuk memantau pembaruan audiens kustom dan mengubah data Protected Audience yang dihasilkan sebelumnya berdasarkan pembaruan tersebut. Platform ini juga perlu mendeklarasikan SLO pada perlombaan penundaan yang bisa diharapkan teknologi iklan antara pembaruan audiens kustom dan perubahan di adSelectionData` yang dibuat untuk lelang server.

   Karena perangkat menyediakan model komputasi resource terbatas dengan prioritas proses yang bervariasi, kami menyadari bahwa penyediaan fasilitas pra-pembuatan ini harus disertai dengan keandalan dan jaminan SLO yang tinggi.

   Pra-pembuatan data Protected Audience akan didasarkan pada

   1. Keikutsertaan penjual untuk pra-pembuatan data Protected Audience.
   2. Pembeli yang memenuhi syarat untuk berpartisipasi dalam lelang yang dimulai oleh penjual tertentu.
   3. Mengidentifikasi audiens kustom per pembeli yang akan menjadi bagian dari payload berdasarkan:
      1. Batas ukuran per pembeli, prioritas per pembeli, dan batas ukuran maksimum yang ditentukan dalam konfigurasi penjual,
      2. Batas ukuran per penjual, prioritas audiens kustom yang ditentukan dalam konfigurasi pembeli.

2. Penerapan pemfilteran negatif yang lebih menarik: Jika dipilih oleh penjual, platform dapat menghitung adSelectionData terlebih dahulu dengan melakukan pra-pembuatan data Protected Audience dan menerapkan pemfilteran negatif dari data panggilan getAdSelectionData. Dengan demikian, penjual dapat menyeimbangkan pengurangan latensi sekaligus menerima penghentian pemfilteran negatif.

   Platform ini dapat memberikan dukungan ini dengan memberikan opsi default dalam Konfigurasi penjual dengan batas penghentian dan opsi penggantian di getAdSelectionData untuk memungkinkan komputasi terbaru jika diperlukan. Atau, platform dapat memberikan API inisialisasi tambahan yang akan dipanggil sebelum getAdSelectionData untuk menyiapkan lelang.

3. Komputasi payload untuk beberapa lelang: Dalam skenario tertentu, mungkin sebaiknya gunakan API yang memiliki performa latensi baik dengan mengorbankan peningkatan penghentian data. Untuk menyediakan hal ini, platform dapat memperkenalkan API inisialisasi untuk melakukan komputasi seluruh payload dan memberikan referensi ke payload yang dikomputasi ke pemanggil.

   Untuk panggilan berikutnya ke getAdSelectionData, pemanggil dapat memberikan referensi ke payload yang telah dikomputasi sebelumnya yang akan digunakan untuk pembuatan adSelectionData.

Ketiga strategi yang disebutkan di atas berada pada tahap eksplorasi awal dan dimaksudkan untuk mendeskripsikan arah yang mungkin diambil platform tersebut untuk mengoptimalkan latensi. Selagi terus mempelajari profil latensi API dan persyaratan teknologi iklan yang lebih mendetail, kami akan terus mengusulkan strategi tambahan.

Mitigasi dan identifikasi penyalahgunaan

Seperti disebutkan dalam pertimbangan Privasi, adSelectionData dibuat menggunakan semua data pembeli di perangkat.

Namun, jika semua data pembeli pada perangkat digunakan untuk membuat output adSelectionData, maka entitas berbahaya dapat berpura-pura sebagai pembeli dan membuat data pembeli yang menipu untuk menurunkan performa Android, menggelembungkan payload hingga menaikkan biaya teknologi iklan untuk menjalankan lelang atau bidding, dan sebagainya.

Mitigasi

Beberapa tindakan yang disebutkan di bagian pertimbangan ukuran seperti konfigurasi payload pembeli yang berisi daftar penjual yang diizinkan dan konfigurasi lelang penjual yang berisi pembeli yang diizinkan akan membantu mengecualikan data yang tidak terduga dalam payload.

Tindakan pertimbangan ukuran lain seperti mengizinkan SSP menentukan prioritas pembeli, menempatkan kuota per pembeli di payload yang dihasilkan, dan menetapkan ukuran maksimum per payload lelang juga dapat membantu mengurangi dampak penggelembungan payload yang berbahaya. Tindakan ini dimaksudkan untuk memungkinkan teknologi iklan menentukan teknologi iklan lain yang berkolaborasi dengannya, serta untuk menetapkan batas yang dapat diterima pada payload yang perlu diproses.

Seperti yang disebutkan sebelumnya, semua mitigasi yang diperkenalkan untuk anti-penyalahgunaan dan pembatasan ukuran harus mematuhi pertimbangan privasi.

Identifikasi entitas berbahaya

Meskipun mitigasi yang disebutkan di atas melindungi pembuatan adSelectionData untuk lelang server, mitigasi tidak membantu mengidentifikasi entitas berbahaya atau melindungi platform dari penyalahgunaan seperti pembuatan jumlah audiens kustom yang belum pernah ada sebelumnya dari pembeli.

Untuk memastikan stabilitas dan kesehatan platform, kami perlu menemukan mekanisme untuk mengidentifikasi entitas berbahaya, mengidentifikasi vektor penyalahgunaan, dan mengidentifikasi motivasi untuk serangan tertentu. Dalam rilis selanjutnya, kami akan memperkenalkan penjelasan yang memberikan detail potensi vektor dan perlindungan terhadap penyalahgunaan untuk melawannya.