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

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

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

যোগ করা গোলমাল সহ সারাংশ রিপোর্ট

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

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

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

অবদান বাজেট

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

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

রিপোর্ট ব্যাচিং জন্য কৌশল

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

"কোন নকল নেই" নিয়ম

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

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

একই রিপোর্ট শুধুমাত্র প্রতি ব্যাচে একবার ব্যবহার করা যেতে পারে।
চিত্র 1. যদি একটি ব্যাচে একটি প্রতিবেদন একাধিকবার উপস্থিত হয়, তাহলে সমষ্টিটি প্রথম দৃষ্টান্ত অন্তর্ভুক্ত করে এবং একই ID সহ পরবর্তী প্রতিবেদনগুলি বাতিল করে।

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

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

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

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

নিম্নলিখিত shared_info ক্ষেত্রের উদাহরণে, আপনি API, attribution_destination (অ্যাট্রিবিউশন রিপোর্টিংয়ের জন্য), reporting_origin , scheduled_report_time , source_registration_time (অ্যাট্রিবিউশন রিপোর্টিংয়ের জন্য) এবং 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"
}

রিপোর্ট 1 এর জন্য নির্ধারিত রিপোর্টের সময়গুলি হল "ফেব্রুয়ারি 19, 2024 9:08:10 PM" এবং Report2 এর জন্য "ফেব্রুয়ারি 19, 2024 9:55:10 PM"৷ যেহেতু scheduled_report_time ক্ষেত্রের মান ঘন্টায় কাটা হয়েছে, উভয় প্রতিবেদনেই scheduled_report_time ক্ষেত্রের মান হিসাবে 1708376890 ("ফেব্রুয়ারি 19, 2024 9 PM" এর জন্য এনকোড করা মান) রয়েছে।

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

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

একটি সাধারণ শেয়ার করা আইডি সহ রিপোর্টগুলি একই ব্যাচে অন্তর্ভুক্ত করা উচিত।
চিত্র 2. ব্যাচ 2-এ এমন একটি প্রতিবেদন রয়েছে যার একটি শেয়ার্ড আইডি ব্যাচ 1-এর একটি প্রতিবেদনের সাথে মিল রয়েছে, তাই ব্যাচ 2 ব্যর্থ হয়।

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

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

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

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

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

অ্যাগ্রিগেশন সার্ভিসে একটি গোপনীয়তা ব্যাচ।
চিত্র 3. একটি সারাংশ প্রতিবেদনে শুধুমাত্র পূর্ব-ঘোষিত কী রয়েছে, যা বালতি নামেও পরিচিত।

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