یک عدد اپسیلون به‌تنهایی حریم خصوصی تفاضلی را ثابت نمی‌کند

یک تیم محصول از گفت‌وگوهای دستیار پشتیبانی، داشبورد هفتگی می‌سازد. نام و متن را حذف می‌کند، به شمارش‌ها نویز می‌افزاید و یک اپسیلون کنار خروجی می‌گذارد. اما یک کارمند صدها رویداد ساخته، دوازده داشبورد قبلی از همان داده تغذیه شده و ترکیب فیلترها واحدهای چهارنفره را جدا می‌کند. حالا حفاظت از «فرد» چه معنایی دارد؟

خروجی نویز دارد؛ ولی هنوز ثابت نشده است که حریم خصوصی تفاضلی دارد.

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

مسئله با عدد شروع نمی‌شود

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

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

راهنمای SP 800-226 مؤسسهٔ NIST که نسخهٔ نهایی آن در مارس ۲۰۲۵ منتشر شد، تضمین را به شکل یک هرم توضیح می‌دهد. پارامتر و واحد حفاظت فقط بخشی از آن‌اند. در لایه‌های دیگر، درستی الگوریتم، فایده و سوگیری، مدل پرس‌وجو و اعتماد، کنترل دسترسی، کانال‌های جانبی و افشای هنگام جمع‌آوری داده قرار دارند. اگر پایه ناقص باشد، یک عدد کوچک در رأس هرم آن را درست نمی‌کند.

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

منابع معتبر چه چیزی را ثابت می‌کنند؟

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

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

چارچوب برنامه‌نویسی OpenDP تضمین را از دامنهٔ ورودی، معیار فاصله، تبدیل، اندازه‌گیری تصادفی و نگاشت حریم خصوصی می‌سازد. چسباندن تابع نویز به تبدیلی با دامنه یا حساسیت نامعلوم، برنامه را اثبات نمی‌کند.

در نمونهٔ سرشماری آمریکا، شرح فنی TopDown تقسیم بودجه میان پرس‌وجوها و سطوح جغرافیایی، پس‌پردازش سازگار و سنجش فایده را توضیح می‌دهد. صورت تصمیم پارامترها نیز بازخورد کاربران و آزمون دقت را ثبت می‌کند. عدد سرشماری نسخهٔ آماده برای شرکت دیگری نیست.

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

این‌ها مواضع بررسی‌شدهٔ منابع‌اند. قرارداد انتشار، معماری و حالت‌های تصمیم در ادامه، جمع‌بندی عملیاتی ژرف است.

نخست بگویید چه کسی و تا چه زمانی محافظت می‌شود

تیم نمونه دادهٔ دستیار را از چند کانال جمع می‌کند. اگر واحد حفاظت «یک رویداد» باشد، ۴۹۹ رویداد دیگر همان کارمند همچنان رفتار او را آشکار می‌کنند. سطح حساب نیز کافی نیست اگر شناسه‌ای پایدار چند حساب را به یک نفر وصل کند؛ «کاربر-روز» هم در گزارش‌های یک‌سال بارها با خودش ترکیب می‌شود.

واحد را در دو جمله بنویسید:

1. عمل همسایگی: افزودن یا حذف یک واحد، یا جایگزینی تمام سهم آن واحد.
2. دامنهٔ واحد: یک فرد در کدام هویت‌ها، دستگاه‌ها، منابع، ویژگی‌ها و بازهٔ زمانی.

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

در دادهٔ بدون ساختار، یک گفت‌وگو ممکن است دربارهٔ چند نفر دیگر باشد. NIST تعیین واحد معنادار را گاهی دشوار یا ناممکن می‌داند. اگر حضور افراد به واحد وعده‌داده‌شده نگاشت نمی‌شود، ادعا باید محدود یا انتشار متوقف شود.

مرز اعتماد را روی نمودار سامانه بکشید

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

طراحی مرکزی اعتماد بیشتر و فایدهٔ آماری بالاتری می‌خواهد؛ طراحی محلی اعتماد مرکزی و اطلاعات قابل‌استفاده را کم می‌کند. انتخاب تابع تهدید و هدف است.

دریافت‌کنندگان بیرون مرز را نام ببرید: عموم، مشتری، تحلیلگر، پیمانکار، ارائه‌دهندهٔ مدل، گزارش خودکار و سامانهٔ خطایابی. مقدار دقیق در ردگیری برنامه، خطای متفاوت، زمان پاسخ یا پیش‌نمایش مکرر نیز کانال جانبی می‌سازد.

کنترل دسترسی می‌گوید چه کسی دادهٔ خام را ببیند؛ حریم خصوصی تفاضلی اطلاعات خروجی مجاز را محدود می‌کند. جای یکدیگر را نمی‌گیرند.

سهم هر فرد را پیش از نویز محدود کنید

مقدار نویز به حساسیت وابسته است: با تغییر سهم یک واحد محافظت‌شده، پاسخ پرس‌وجو حداکثر چقدر تغییر می‌کند؟ اگر یک نفر بتواند بی‌نهایت ردیف یا مقدار وارد کند، حساسیت نیز حد مفیدی ندارد. نویز متناهی و مفید این قرارداد ورودی را نجات نمی‌دهد.

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

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

ممکن است تابع نویز درست باشد، اما برنامه بیش از سقف فرض‌شده به آن سهم بدهد. آن‌وقت تضمین اعلام‌شده به برنامهٔ واقعی تعلق ندارد.

بودجه باید یک دفتر کل اتمی باشد

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

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

شناسه انتشار + هدف + مالک
واحد حفاظت + همسایگی + افق زمانی
تبار داده و جمعیت
اثر انگشت پرس‌وجو یا پیکربندی آموزش
سازوکار + پارامترهای اصلی
حد تعداد سهم و حد مقدار
بودجه درخواستی + نسخه حسابگر
انتشارهای سازگار قبلی
مرز دریافت‌کننده + تاریخ انقضا
نتیجه فایده + تأیید + اثر انگشت خروجی

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

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

اپسیلون را از جدول جادویی انتخاب نکنید

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

تصویب پارامتر باید چهار پرسش را به هم وصل کند:

• سازمان دقیقاً می‌خواهد کدام استنباط دربارهٔ یک واحد را محدود کند؟
• در سراسر عمر داده، چه میزان افشا با توجه به حساسیت و دریافت‌کنندگان پذیرفتنی است؟
• تصمیم موردنظر به چه دقتی نیاز دارد، به‌ویژه در گروه‌های کوچک یا آسیب‌پذیر؟
• آیا انتشار درشت‌تر، دفعات کمتر، تحلیل محدود، محاسبهٔ امن یا عدم انتشار هدف را بهتر برآورده می‌کند؟

در حریم خصوصی تفاضلی تقریبی، اپسیلون و دلتا را با هم و در قالب اصلی حسابگری گزارش کنید. دلتا «درصد افرادی که حریم خصوصی‌شان از بین می‌رود» نیست؛ بازبین باید روش و پارامترهای مبدأ را ببیند.

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

مثال: داشبورد را از نو تعریف کنید

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

بازبینی حریم خصوصی محصول را تغییر می‌دهد:

1. واحد حفاظت «یک کارمند در همهٔ حساب‌های متصل طی افق سالانه» می‌شود، نه یک پیام.
2. سهم هر کارمند و دامنهٔ امتیاز رضایت پیش از تجمیع محدود می‌شود.
3. دسته‌های موضوعی از فهرستی عمومی می‌آیند تا مشارکت یک نفر دستهٔ خصوصی را آشکار نکند.
4. دفتر پرس‌وجوهای ثابت و انتشار کم‌دفعات‌تر جای فیلتر آزاد را می‌گیرد.
5. مخزن خام، نگاشت هویت و محدودسازی در مرز گردآورنده می‌مانند؛ خدمت عمومی فقط اندازه‌گیری تأییدشده می‌گیرد.
6. پیش‌نمایش‌هایی که بیرون مرز دیده شده‌اند در حساب خطر می‌آیند.
7. بودجه میان تصمیم‌های ضروری تقسیم و هر انتشار با حسابگر مجوز می‌گیرد.
8. خطا و سوگیری بر حسب اندازهٔ واحد و زبان سنجیده می‌شود؛ موضوع نادر به نمودار عمومی نمی‌رود.

محصول نهایی شاید روند فصلی سازمان باشد، نه ذره‌بین هفتگی هر واحد. این شکست نیست؛ تطبیق تضمین با تصمیمی است که داده پشتیبانی می‌کند.

فایده را با تصمیم واقعی بسنجید

خروجی خصوصیِ بی‌فایده ارزش انتشار ندارد. آزمون را پیش از راه‌اندازی با دادهٔ عمومی، مصنوعی یا اعتبارسنجی تحت حاکمیت طراحی کنید؛ تنظیم پارامتر نباید پاسخ دقیق حساس را دوباره به تحلیلگر نشان دهد.

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

آزمون پذیرش را پیشاپیش بنویسید. آیا مدیر عملیات با شاخص نویزی مشکل پایدار ظرفیت را از نوسان جدا می‌کند؟ اگر هدف یافتن فرد یا رخداد بسیار نادر است، رابط تجمیعی تفاضلی احتمالاً مناسب نیست؛ ICO نیز افت فایده برای ناهنجاری و الگوهای جزئی را گوشزد می‌کند.

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

مسیر انتشار باید میان‌بر را ببندد

معماری مناسب، دورزدن کنترل را دشوار می‌کند:

مخزن خام + نگاشت هویت
        ↓ دسترسی محدود
دامنه و تبار اعتبارسنجی‌شده
        ↓
محدودسازی سهم و مقدار
        ↓
پرس‌وجوی ثبت‌شده یا طرح آموزش مصوب
        ↓
اندازه‌گیری تفاضلی آزموده‌شده
        ↔ حسابگر اتمی بودجه
        ↓
آزمون فایده، سوگیری و حمله
        ↓
دروازه انتشار + رسید امضاشده
        ↓
خروجی عمومی یا دریافت‌کننده محدود

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

کتابخانهٔ سرتاسری آزموده‌شده بر تابع نویز دست‌ساز برتری دارد. جزء سطح پایین گوگل ممکن است حد سهم را فرض کند، اما خط لولهٔ بالاتر بخشی از گروه‌بندی و محدودسازی را اجرا می‌کند. نسخه‌ها را ثابت و مسائل شناخته‌شده را پیگیری کنید؛ تغییر عددی یا وابستگی تصمیم را باز می‌کند.

ممیزی تجربی مثال نقض پیدا می‌کند، اما به گفتهٔ NIST نبودن مثال نقض اثبات ریاضی نیست. آزمون باید کنار تحلیل تضمین و بازبینی کد باشد.

به خروجی رسید بدهید، نه نشان تبلیغاتی

رسید انتشار باید هدف، واحد و همسایگی، افق، جمعیت و تبار، مدل اعتماد، سازوکار، پارامترها، حسابگر، حد سهم، بودجهٔ تجمعی، آزمون فایده، سوگیری، انتشارهای مرتبط، دریافت‌کنندگان و تأییدکننده را ثبت کند.

بنویسید: «این جدول با سازوکار مشخص، همسایگی افزودن/حذف در سطح کاربر، جمعیت و افق معلوم و با احتساب انتشارهای قبلی تولید شد.» عبارت‌هایی چون «خطر صفر است» یا «کل داده ناشناس شد» دامنهٔ تضمین را پنهان می‌کنند.

نویز، جمع‌آوری بی‌رویه، پردازش غیرمنصفانه یا مخزن ناامن را مشروع نمی‌کند. رسید باید کنار خروجی و در زنجیرهٔ شواهد ممیزی بماند.

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

چهار تصمیم، نه یک چراغ سبز مبهم

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

خطاهایی که در ظاهر آرامش‌بخش‌اند

• نویز بدون تعریف همسایگی: معلوم نیست حضور چه کسی محافظت می‌شود.
• فروش حفاظت رویداد به‌جای فرد: رخدادهای هم‌بسته رفتار فرد را بازمی‌سازند.
• حد روی کاغذ: برنامه بیش از حساسیت فرض‌شده به تابع سهم می‌دهد.
• بودجهٔ جدا برای هر داشبورد: چند محصول از همان جمعیت خرج می‌کنند و همدیگر را نمی‌بینند.
• تکرار تا رسیدن به نتیجهٔ زیبا: چند خروجی تصادفی دیده و فقط مطلوب‌ترین منتشر می‌شود.
• افشای دستهٔ خصوصی: ظاهرشدن یک گروه، خودِ حضور مشارکت‌کننده را نشان می‌دهد.
• عدد دقیق کنار جدول خصوصی: انتشار دیگر، فضای پاسخ‌های ممکن را تنگ می‌کند.
• خرید اپسیلون: عددی کوچک بدون دلتا، واحد، افق، سازوکار و تهدید انتخاب می‌شود.
• میانگین فایده: کل قابل‌قبول است ولی گروه کوچک خطای تصمیم‌ساز دارد.
• کتابخانه به‌عنوان گواهی: جزء درست در خط لولهٔ غلط نصب می‌شود.
• برچسب مصنوعی: مولد بدون آموزش یا انتشار تفاضلی، خصوصی فرض می‌شود.
• ردگیری خام: گزارش خطا همان اطلاعاتی را بیرون می‌برد که خروجی محافظت می‌کند.

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

چه چیزی را پایش و چه زمانی تصمیم را باز کنیم؟

فرایند تصمیم را نیز پایش کنید:

• بودجهٔ رزروشده، مصرف‌شده و باقی‌ماندهٔ هر جمعیت و افق؛
• خروجی یا پیش‌نمایشی که ورودی متناظر در دفتر ندارد؛
• سهم کاربران و مقادیری که محدودسازی روی آن‌ها اثر گذاشته است؛
• خطا، سوگیری و تغییر تصمیم در برش‌های معنادار؛
• پرس‌وجوهای ردشده به‌علت دستهٔ کم‌جمعیت یا ترکیب ناسازگار؛
• دسترسی به دادهٔ خام یا میانی بیرون مرز گردآورنده؛
• نسخهٔ حسابگر، سازوکار، کتابخانه و پیکربندی؛
• یافتهٔ پیاده‌سازی و زمان پس‌گرفتن خروجی متاثر؛
• تغییر جمعیت، تطبیق هویت، دریافت‌کننده، هدف یا دادهٔ کمکی.

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

پرسش آخر «اپسیلون چند بود؟» نیست. بپرسید چه کسی در برابر کدام تمایز و انتشارهای انباشته، زیر چه فرض اعتماد و پیاده‌سازی محافظت می‌شود؛ و خروجی کدام تصمیم را پشتیبانی می‌کند. بدون رسید و دروازه، اپسیلون فقط عددی کنار نویز است.

یادداشت منابع — بازبینی ۳ سپتامبر ۲۰۲۶

• مؤسسهٔ NIST، SP 800-226: راهنمای ارزیابی تضمین‌های حریم خصوصی تفاضلی: نسخهٔ نهایی مارس ۲۰۲۵؛ منبع واحد حفاظت، ترکیب، فایده، پیاده‌سازی، اعتماد و محدودیت ممیزی.
• دفتر کمیسر اطلاعات بریتانیا، فصل پنجم راهنمای فناوری‌های تقویت‌کنندهٔ حریم خصوصی: راهنمای نهاد ناظر دربارهٔ مدل مرکزی و محلی، بودجه، فایده و ناشناس‌سازی.
• OpenDP، چارچوب برنامه‌نویسی: مستندات پایدار جاری دربارهٔ دامنه، معیار، تبدیل، اندازه‌گیری، نگاشت پایداری، نگاشت حریم خصوصی و ترکیب.
• ادارهٔ سرشماری آمریکا، الگوریتم TopDown سرشماری ۲۰۲۰: گزارش فنی مارس ۲۰۲۳ دربارهٔ تخصیص بودجه، پس‌پردازش و محصول داده.
• ادارهٔ سرشماری آمریکا، تعیین پارامترهای کلیدی نتایج ۲۰۲۰: صورت تصمیم ۹ ژوئن ۲۰۲۱ دربارهٔ بازخورد، دقت و بده‌بستان‌ها؛ نه توصیه‌ای عددی برای دیگران.
• گوگل، کتابخانه‌های حریم خصوصی تفاضلی: مستندات سازوکارها، خط لوله‌ها، حسابگر، ممیزی و مسئولیت محدودسازی سهم؛ محصول رسمی پشتیبانی‌شدهٔ گوگل نیست.