حفاظت از حریم خصوصی برای گزارش های جمع آوری

Aggregation Service گزارش‌های خلاصه‌ای از داده‌های تبدیل دقیق و اندازه‌گیری‌های دستیابی را از گزارش‌های انبوه‌سازی خام تولید می‌کند. برای حفظ خصوصی و ایمن نگه داشتن داده‌های کاربر، سرویس تجمیع از چارچوبی استفاده می‌کند که از حریم خصوصی متمایز (DP) پشتیبانی می‌کند تا مقدار اطلاعاتی را که این گزارش‌ها در مورد تک تک کاربران نشان می‌دهند را تعیین و محدود کند.

این راهنما درباره ابزارها و استراتژی‌هایی برای ایجاد گزارش‌های جمع‌آوری‌شده بحث می‌کند که به حفظ امنیت داده‌های مربوط به کاربران فردی کمک می‌کند:

گزارش های خلاصه با نویز اضافه شده

وقتی گزارش‌های جمع‌آوری‌شده را دسته‌بندی می‌کنید، سرویس تجمع یک گزارش خلاصه ایجاد می‌کند. این گزارش خلاصه مجموعه ای از تمام مشارکت های کلیدهای دامنه از پیش تعریف شده، با نویز آماری اضافه شده است.

نویز اضافه شده به گزارش‌ها به تعداد گزارش‌های جمع‌آوری‌شده، مقادیر گزارش‌های جداگانه یا مقادیر گزارش‌های انبوه بستگی ندارد. نویز از یک نسخه مجزا از توزیع لاپلاس گرفته می‌شود و به بودجه مشارکت (حساسیت L1 ) که توسط مشتری وابسته به API اندازه‌گیری مربوطه و epsilon پارامتر حریم خصوصی اعمال می‌شود، مقیاس‌بندی می‌شود.

برای کسب اطلاعات بیشتر در مورد نویز و پیامدهای آن برای داده های گزارش، به درک نویز در گزارش های خلاصه مراجعه کنید.

بودجه مشارکت

برای کنترل حساسیت گزارش خلاصه، تعداد مشارکت‌های ارسال شده در یک فراخوان به یک حد محدود سهم خاص، که به عنوان بودجه مشارکت نیز شناخته می‌شود، مرتبط است. بسته به اینکه از API گزارش Attribution یا Private Aggregation API استفاده می‌کنید، بودجه مشارکت متفاوت است.

برای کسب اطلاعات بیشتر درباره نحوه تنظیم بودجه مشارکت برای هر API، به بخش‌های مستند API زیر مراجعه کنید:

استراتژی های دسته بندی گزارش ها

هنگامی که گزارش‌های جمع‌آوری‌شده را دسته‌بندی می‌کنید، مهم است که استراتژی‌های دسته‌بندی را بهینه کنید تا از محدودیت‌های حریم خصوصی فراتر نرود. دو مفهوم مهم برای دسته‌بندی درست گزارش‌ها ، قانون «بدون تکرار» و ایده دسته‌های جدا از هم هستند.

قانون "بدون تکرار"

Aggregation Service قانون "بدون تکرار" را اجرا می کند. این قانون بیان می‌کند که یک گزارش جمع‌آوری‌شده، که به‌طور منحصربه‌فرد توسط report_id شناسایی می‌شود، تنها می‌تواند یک بار در یک دسته ظاهر شود. اگر یک گزارش جمع آوری بیش از یک بار در هر دسته ظاهر شود، اولین گزارش در تجمیع گنجانده می شود، گزارش های بعدی با همان report_id کنار گذاشته می شوند و دسته با موفقیت کامل می شود.

این قانون همچنین می گوید که یک گزارش نمی تواند در بیش از یک دسته ظاهر شود. اگر گزارشی قبلاً در یک دسته موفق قبلی گنجانده شده باشد، دسته بعدی که شامل همان گزارش نیز می شود شکست می خورد.

همان گزارش فقط یک بار در هر دسته قابل استفاده است.
شکل 1. اگر یک گزارش بیش از یک بار در یک دسته ظاهر شود، تجمیع شامل اولین نمونه می شود و گزارش های بعدی با همان شناسه را دور می اندازد.

بدون قانون «بدون تکرار»، مهاجم می‌تواند با دستکاری محتویات دسته‌ها از طریق گنجاندن کپی‌های تکراری یک گزارش در یک دسته یا چند دسته، بینشی نسبت به محتوای یک دسته خاص کسب کند.

برای کسب اطلاعات بیشتر در مورد اجرای قانون "بدون تکرار" در یک دسته از گزارش ها یا در چندین دسته، به گزارش های تکراری در دسته ها مراجعه کنید.

دسته های جدا

برای جلوگیری از موقعیت‌هایی که در آن‌ها بین دسته‌ها همپوشانی وجود دارد، سرویس تجمیع دسته‌های مجزا را اعمال می‌کند. این بدان معناست که دو یا چند دسته نمی‌توانند حاوی گزارش‌هایی باشند که یک شناسه مشترک مشترک دارند. شناسه مشترک ترکیبی از داده‌های جمع‌آوری‌شده از قسمت shared_info یک گزارش جمع‌آوری‌شده است.

در مثال فیلد shared_info زیر، می‌توانید API، attribution_destination (برای گزارش Attribution)، reporting_origin ، scheduled_report_time ، source_registration_time (برای گزارش Attribution) و version ببینید. این فیلدها، به جز report_id ، به شناسه مشترک کمک می کنند.

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://privacy-sandbox-demos-shop.dev",
  "report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
  "reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
  "scheduled_report_time": "1707786751",
  "source_registration_time": "0",
  "version": "0.1"
}

از آنجایی که source_registration_time بر حسب روز و scheduled_report_time بر حسب ساعت کوتاه می‌شود، گزارش‌هایی وجود دارند که شناسه مشترک یکسانی دارند. در این مثال، Report1 و Report2 دارای فیلدهای اطلاعات مشترک هستند. هر دو گزارش دارای API، نسخه، attribution_destination ، reporting_origin و source_registration_time یکسان هستند. از آنجایی که report_id بخشی از شناسه مشترک نیست، می توانید این تفاوت را نادیده بگیرید.

در مثال‌های زیر برای Report1 و Report2 ، مقدار scheduled_report_time یکسان است.

گزارش 1 اطلاعات به اشتراک گذاشته شده:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

Report2 اطلاعات به اشتراک گذاشته شده:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

زمان‌های گزارش برنامه‌ریزی‌شده «۱۹ فوریه ۲۰۲۴، ۹:۰۸:۱۰ بعد از ظهر» برای Report1 و «۱۹ فوریه ۲۰۲۴، ۹:۵۵:۱۰ بعد از ظهر» برای Report2 است. از آنجایی که مقدار فیلد scheduled_report_time به ساعت کوتاه شده است، هر دو گزارش دارای 1708376890 (مقدار رمزگذاری شده برای "19 فوریه 2024، ساعت 9 عصر") به عنوان مقدار برای فیلد scheduled_report_time هستند.

همه فیلدهای دیگر یکسان هستند، بنابراین هر دو گزارش دارای شناسه مشترک یکسانی هستند. و از آنجایی که هر دو گزارش دارای شناسه مشترک یکسانی هستند، هر دو باید در یک دسته گنجانده شوند.

اگر Report1 در دسته‌ای که قبلاً موفق بود دسته‌بندی شده باشد و Report2 در دسته‌ای بعدی پردازش شود، دسته با Report2 با خطای PRIVACY_BUDGET_EXHAUSTED شکست می‌خورد. اگر این اتفاق افتاد، گزارش‌هایی را با شناسه مشترک که در دسته‌های قبلی با موفقیت دسته‌بندی شده‌اند حذف کنید و دوباره امتحان کنید. برای اطلاعات بیشتر در مورد این خطا، کدهای خطا و اقدامات کاهشی برای Aggregation Service را ببینید.

گزارش‌های دارای شناسه مشترک مشترک باید در همان دسته گنجانده شوند.
شکل 2. دسته 2 حاوی گزارشی است که دارای شناسه مشترک با گزارش دسته 1 است، بنابراین دسته 2 با شکست مواجه می شود.

کلیدهای تجمع از پیش اعلام شده

هنگامی که دسته ای را به سرویس تجمیع ارسال می کنید، باید شامل گزارش های جمع آوری شده ای باشد که از مبدا گزارش و فایل دامنه خروجی دریافت می شود. دامنه خروجی شامل کلیدها یا سطل‌هایی است که از گزارش‌های جمع‌آوری‌شده بازیابی می‌شوند.

از نقطه نظر حفظ حریم خصوصی، نویز به تمام کلیدهای از پیش اعلام شده در حوزه خروجی اضافه می شود، حتی زمانی که هیچ گزارش واقعی با کلید خاصی مطابقت نداشته باشد. تعیین دامنه خروجی در برابر حمله ای که وجود یک کلید در خروجی چیزی را در مورد یک کاربر یا رویداد مشخص می کند محافظت می کند. برای مثال، اگر یک کمپین را فقط به یک کاربر نشان دهید، دریافت یک کلید در خروجی نشان می‌دهد که کاربر بعداً تبدیل شده است، حتی با اضافه شدن نویز. با مشخص کردن این دامنه ابتدا می توانید مطمئن شوید که چیزی در مورد مشارکت کاربران فاش نمی شود.

شما می توانید این کلیدهای 128 بیتی را در API گزارش Attribution یا Private Aggregation API اعلام کنید و از آنها برای رمزگذاری ابعادی که می خواهید ردیابی کنید استفاده کنید.

فقط کلیدهای از پیش اعلام شده برای تجمیع در نظر گرفته شده و در گزارش خلاصه گنجانده شده است. مقادیر تجمیع سطل ها در گزارش خلاصه دارای نویز آماری اضافه شده است که در گزارش خلاصه ایجاد شده منعکس می شود.

دسته ای از حریم خصوصی در سرویس تجمع.
شکل 3. گزارش خلاصه فقط حاوی کلیدهای از پیش اعلام شده است که به عنوان سطل نیز شناخته می شوند.

اگر یک کلید تجمیع در فایل دامنه خروجی گنجانده شده باشد اما در یک گزارش دسته ای قرار نداشته باشد، حتی اگر مقدار تجمیع شده صفر باشد، گزارش خلاصه نهایی احتمالاً غیر صفر خواهد بود زیرا نویز اضافه شده برای حفظ حریم خصوصی است.