সমষ্টিগত প্রতিবেদনের জন্য গোপনীয়তা সুরক্ষা

অ্যাগ্রিগেশন সার্ভিস কাঁচা অ্যাগ্রিগেটেবল রিপোর্ট থেকে বিস্তারিত রূপান্তর ডেটা এবং নাগালের পরিমাপের সারসংক্ষেপ প্রতিবেদন তৈরি করে। ব্যবহারকারীর ডেটা গোপন এবং সুরক্ষিত রাখতে, অ্যাগ্রিগেশন সার্ভিস একটি কাঠামো ব্যবহার করে যা ডিফারেনশিয়াল প্রাইভেসি (DP) সমর্থন করে যাতে এই প্রতিবেদনগুলি পৃথক ব্যবহারকারীদের সম্পর্কে প্রকাশিত তথ্যের পরিমাণ পরিমাপ এবং সীমাবদ্ধ করে।

এই নির্দেশিকাটিতে সমষ্টিগত প্রতিবেদন তৈরির জন্য সরঞ্জাম এবং কৌশল নিয়ে আলোচনা করা হয়েছে যা পৃথক ব্যবহারকারীদের তথ্য সুরক্ষিত রাখতে সহায়তা করে:

• অতিরিক্ত শব্দ সহ সারাংশ প্রতিবেদন তৈরি করুন
• একটি অবদান বাজেট সেট করুন
• রিপোর্ট ব্যাচিংয়ের কৌশল
  • ব্যাচে ডুপ্লিকেট রিপোর্ট পরিচালনা করুন
  • একটি সাধারণ শেয়ার্ড আইডি দিয়ে রিপোর্ট পরিচালনা করুন
• পূর্বে ঘোষিত একত্রীকরণ কী ব্যবহার করুন

অতিরিক্ত শব্দ সহ সারাংশ প্রতিবেদন

যখন আপনি সমষ্টিগত প্রতিবেদনগুলিকে ব্যাচ করেন, তখন সমষ্টিগত পরিষেবা একটি সারাংশ প্রতিবেদন তৈরি করে। এই সারাংশ প্রতিবেদনটি সমস্ত পূর্বনির্ধারিত ডোমেন কীগুলির সমস্ত অবদানের একটি সমষ্টি, অতিরিক্ত পরিসংখ্যানগত শব্দ সহ।

রিপোর্টে যোগ করা শব্দ সমষ্টিগত প্রতিবেদনের সংখ্যা, পৃথক প্রতিবেদনের মান, অথবা সমষ্টিগত প্রতিবেদনের মানের উপর নির্ভর করে না। শব্দ Laplace বিতরণের একটি পৃথক সংস্করণ থেকে নেওয়া হয় এবং অবদান বাজেট ( L1 সংবেদনশীলতা) পর্যন্ত স্কেল করা হয় যা ক্লায়েন্ট দ্বারা সংশ্লিষ্ট পরিমাপ API এবং গোপনীয়তা পরামিতি epsilon উপর নির্ভর করে প্রয়োগ করা হয়।

রিপোর্ট ডেটার উপর শব্দ এবং এর প্রভাব সম্পর্কে আরও জানতে, সারাংশ প্রতিবেদনে শব্দ বোঝা দেখুন।

অবদান বাজেট

একটি সারাংশ প্রতিবেদনের সংবেদনশীলতা নিয়ন্ত্রণ করার জন্য, একটি কলে পাস করা অবদানের সংখ্যা একটি নির্দিষ্ট অবদানের সীমার সাথে আবদ্ধ করা হয়, যা অবদান বাজেট নামেও পরিচিত। আপনি অ্যাট্রিবিউশন রিপোর্টিং API নাকি ব্যক্তিগত সমষ্টি API ব্যবহার করছেন তার উপর নির্ভর করে অবদান বাজেট পরিবর্তিত হয়।

প্রতিটি API-এর জন্য অবদান বাজেট কীভাবে সেট করবেন সে সম্পর্কে আরও জানতে, নিম্নলিখিত API ডকুমেন্টেশন বিভাগগুলি দেখুন:

• অ্যাট্রিবিউশন রিপোর্টিং API অবদান বাউন্ডিং এবং বাজেটিং
• ব্যক্তিগত সমষ্টি API অবদানের সীমা
• প্রাইভেট এগ্রিগেশন এপিআই অবদান বাউন্ডিং এবং বাজেটিং

রিপোর্ট ব্যাচিংয়ের কৌশল

যখন আপনি ব্যাচ অ্যাগ্রিগেটেবল রিপোর্ট তৈরি করেন, তখন ব্যাচিং কৌশলগুলি অপ্টিমাইজ করা গুরুত্বপূর্ণ যাতে গোপনীয়তার সীমা অতিক্রম না হয়। রিপোর্টগুলি সঠিকভাবে ব্যাচ করার জন্য দুটি গুরুত্বপূর্ণ ধারণা হল "নো ডুপ্লিকেট" নিয়ম এবং ডিসজয়েন্ট ব্যাচের ধারণা।

"কোনও সদৃশ নয়" নিয়ম

অ্যাগ্রিগেশন সার্ভিস "নো ডুপ্লিকেট" নিয়ম প্রয়োগ করে। এই নিয়মে বলা হয়েছে যে একটি অ্যাগ্রিগেটেবল রিপোর্ট, যা report_id দ্বারা অনন্যভাবে চিহ্নিত করা হয়, শুধুমাত্র একটি ব্যাচে একবারই প্রদর্শিত হতে পারে। যদি একটি অ্যাগ্রিগেটেবল রিপোর্ট প্রতি ব্যাচে একাধিকবার প্রদর্শিত হয়, তাহলে প্রথম রিপোর্টটি অ্যাগ্রিগেটে অন্তর্ভুক্ত করা হয়, একই report_id সহ পরবর্তী রিপোর্টগুলি বাতিল করা হয় এবং ব্যাচটি সফলভাবে সম্পন্ন হয়।

নিয়মটিতে আরও বলা হয়েছে যে একই শেয়ার্ড আইডি একাধিক ব্যাচে উপস্থিত হতে পারবে না। যদি একটি শেয়ার্ড আইডি ইতিমধ্যেই পূর্ববর্তী সফল ব্যাচে অন্তর্ভুক্ত করা হয়ে থাকে, তাহলে পরবর্তী ব্যাচে একই শেয়ার্ড আইডি অন্তর্ভুক্ত করা ব্যর্থ হবে।

"কোনও সদৃশ নয়" নিয়ম ছাড়া, একজন আক্রমণকারী একটি নির্দিষ্ট ব্যাচের বিষয়বস্তু সম্পর্কে অন্তর্দৃষ্টি অর্জন করতে পারে, ব্যাচের বিষয়বস্তুতে হেরফের করে, একটি প্রতিবেদনের সদৃশ কপি একটি একক ব্যাচ বা একাধিক ব্যাচে অন্তর্ভুক্ত করে।

এক ব্যাচের রিপোর্টের মধ্যে বা একাধিক ব্যাচ জুড়ে "কোনও সদৃশ নয়" নিয়ম প্রয়োগ করার বিষয়ে আরও জানতে, ব্যাচের মধ্যে সদৃশ প্রতিবেদন দেখুন।

বিচ্ছিন্ন ব্যাচ

ব্যাচগুলির মধ্যে ওভারল্যাপের পরিস্থিতি এড়াতে, অ্যাগ্রিগেশন সার্ভিস ডিসজয়েন্ট ব্যাচগুলিকে কার্যকর করে। এর অর্থ হল দুই বা ততোধিক ব্যাচে এমন রিপোর্ট থাকতে পারে না যা একটি সাধারণ শেয়ার্ড আইডি শেয়ার করে। একটি শেয়ার্ড আইডি হল একটি অ্যাগ্রিগেটেবল রিপোর্টের shared_info ফিল্ড থেকে সংগৃহীত ডেটার সংমিশ্রণ, এবং কাজের অনুরোধ থেকে ফিল্টারিং আইডি । যদি কোনও ফিল্টারিং আইডি নির্দিষ্ট না করা থাকে, তাহলে ডিফল্ট 0 ব্যবহার করা হয়।

নিম্নলিখিত shared_info ক্ষেত্রের উদাহরণে, আপনি API, attribution_destination (Attribution Reporting এর জন্য), reporting_origin , scheduled_report_time , source_registration_time (Attribution Reporting এর জন্য) এবং 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, version, attribution_destination , reporting_origin এবং source_registration_time একই। যেহেতু report_id শেয়ার করা আইডির অংশ নয়, আপনি এই পার্থক্যটি উপেক্ষা করতে পারেন।

নিম্নলিখিত উদাহরণগুলিতে Report1 এবং Report2 এর জন্য, scheduled_report_time মান একই।

Report1 শেয়ার করা তথ্য:

"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 ক্ষেত্রের মান ঘন্টায় ছোট করা হয়েছে, তাই উভয় প্রতিবেদনেই scheduled_report_time ক্ষেত্রের মান হিসেবে 1708376890 ("১৯ ফেব্রুয়ারী, ২০২৪ ৯ রাত" এর জন্য এনকোড করা মান) আছে।

অন্যান্য সমস্ত ক্ষেত্র এবং ফিল্টারিং আইডি একই থাকায়, উভয় প্রতিবেদনেরই একই শেয়ার্ড আইডি রয়েছে। এবং যেহেতু উভয় প্রতিবেদনেরই একই শেয়ার্ড আইডি রয়েছে, তাই উভয়কেই একই ব্যাচে অন্তর্ভুক্ত করতে হবে।

যদি Report1 পূর্ববর্তী সফল ব্যাচে ব্যাচ করা হয় এবং Report2 পরবর্তী ব্যাচে প্রক্রিয়াজাত করা হয়, তাহলে Report2 সহ ব্যাচটি PRIVACY_BUDGET_EXHAUSTED ত্রুটির সাথে ব্যর্থ হয়। যদি এটি ঘটে, তাহলে পূর্ববর্তী ব্যাচে সফলভাবে ব্যাচ করা হয়েছে এমন শেয়ার করা আইডি সহ প্রতিবেদনগুলি সরিয়ে আবার চেষ্টা করুন। এই ত্রুটি সম্পর্কে আরও তথ্যের জন্য, Aggregation Service এর জন্য ত্রুটি কোড এবং প্রশমন দেখুন।

পূর্ব-ঘোষিত একত্রীকরণ কী

যখন আপনি অ্যাগ্রিগেশন সার্ভিসে একটি ব্যাচ জমা দেন, তখন এতে রিপোর্টিং অরিজিন এবং আউটপুট ডোমেন ফাইল থেকে প্রাপ্ত অ্যাগ্রিগেটেবল রিপোর্ট উভয়ই অন্তর্ভুক্ত থাকতে হবে। আউটপুট ডোমেনে কী, বা বাকেট থাকে, যা অ্যাগ্রিগেটেবল রিপোর্ট থেকে পুনরুদ্ধার করা হয়।

গোপনীয়তার দৃষ্টিকোণ থেকে, আউটপুট ডোমেনে পূর্বে ঘোষিত সমস্ত কীতে নয়েজ যোগ করা হয়, এমনকি যখন কোনও প্রকৃত প্রতিবেদন কোনও নির্দিষ্ট কী-এর সাথে মেলে না। আউটপুট ডোমেন নির্দিষ্ট করা এমন একটি আক্রমণ থেকে রক্ষা করে যেখানে আউটপুটে একটি কী-এর উপস্থিতি একটি একক ব্যবহারকারী বা ইভেন্ট সম্পর্কে কিছু প্রকাশ করে। উদাহরণস্বরূপ, যদি আপনি শুধুমাত্র একজন ব্যবহারকারীকে একটি প্রচারণা দেখিয়ে থাকেন, তাহলে আউটপুটে একটি কী গ্রহণ করলে দেখা যায় যে ব্যবহারকারী পরে রূপান্তরিত হয়েছে, এমনকি শব্দ যোগ করা সত্ত্বেও। প্রথমে এই ডোমেনটি নির্দিষ্ট করে, আপনি নিশ্চিত হতে পারেন যে এটি ব্যবহারকারীর অবদান সম্পর্কে কিছুই প্রকাশ করে না।

আপনি এই ১২৮-বিট কীগুলি অ্যাট্রিবিউশন রিপোর্টিং API অথবা প্রাইভেট অ্যাগ্রিগেশন API- তে ঘোষণা করতে পারেন এবং আপনি যে মাত্রাগুলি ট্র্যাক করতে চান তা এনকোড করতে ব্যবহার করতে পারেন।

শুধুমাত্র পূর্ব-ঘোষিত কীগুলিকে একত্রিতকরণের জন্য বিবেচনা করা হয় এবং সারাংশ প্রতিবেদনে অন্তর্ভুক্ত করা হয়। সারাংশ প্রতিবেদনে বাকেটগুলির সমষ্টিগত মানগুলিতে পরিসংখ্যানগত নয়েজ যোগ করা হয়েছে, যা তৈরি সারাংশ প্রতিবেদনে প্রতিফলিত হয়।

যদি আউটপুট ডোমেন ফাইলে একটি অ্যাগ্রিগেশন কী অন্তর্ভুক্ত থাকে কিন্তু ব্যাচ রিপোর্টে না থাকে, এমনকি যদি অ্যাগ্রিগেটেড মান শূন্য হয়, তাহলে গোপনীয়তা রক্ষার জন্য অতিরিক্ত শব্দের কারণে চূড়ান্ত সারাংশ রিপোর্টটি সম্ভবত শূন্য নয়।