2022 Q4-এর ত্রৈমাসিক রিপোর্ট গোপনীয়তা স্যান্ডবক্স প্রস্তাব এবং Chrome-এর প্রতিক্রিয়ার উপর প্রাপ্ত ইকোসিস্টেম প্রতিক্রিয়ার সারসংক্ষেপ।
CMA এর প্রতি তার প্রতিশ্রুতির অংশ হিসাবে, Google তার গোপনীয়তা স্যান্ডবক্স প্রস্তাবগুলির জন্য স্টেকহোল্ডার জড়িত থাকার প্রক্রিয়ার ত্রৈমাসিক প্রতিবেদন প্রকাশ্যে প্রদান করতে সম্মত হয়েছে ( প্রতিশ্রুতিগুলির 12 এবং 17(c)(ii) অনুচ্ছেদ দেখুন)। এই গোপনীয়তা স্যান্ডবক্স প্রতিক্রিয়া সারাংশ প্রতিবেদনগুলি প্রতিক্রিয়া ওভারভিউতে তালিকাভুক্ত বিভিন্ন উত্স থেকে Chrome দ্বারা প্রাপ্ত প্রতিক্রিয়ার সমষ্টি দ্বারা তৈরি করা হয়, যার মধ্যে রয়েছে কিন্তু এতে সীমাবদ্ধ নয়: GitHub সমস্যা, privacysandbox.com- এ উপলব্ধ প্রতিক্রিয়া ফর্ম, শিল্প স্টেকহোল্ডারদের সাথে মিটিং এবং ওয়েব স্ট্যান্ডার্ড ফোরাম। ক্রোম ইকোসিস্টেম থেকে প্রাপ্ত প্রতিক্রিয়াকে স্বাগত জানায় এবং ডিজাইনের সিদ্ধান্তে শেখার একীভূত করার উপায়গুলি সক্রিয়ভাবে অন্বেষণ করছে৷
ফিডব্যাক থিমগুলি এপিআই প্রতি ব্যাপকতা অনুসারে র্যাঙ্ক করা হয়। Chrome টিম একটি প্রদত্ত থিমের আশেপাশে যে পরিমাণ প্রতিক্রিয়া পেয়েছে তার একত্রিতকরণ এবং পরিমাণের ক্রমানুসারে সাজানোর মাধ্যমে এটি করা হয়। সাধারণ প্রতিক্রিয়া থিমগুলি জনসাধারণের মিটিং (W3C, PatCG, IETF), সরাসরি প্রতিক্রিয়া, GitHub এবং Google-এর অভ্যন্তরীণ দল এবং পাবলিক ফর্মগুলির মাধ্যমে সাধারণভাবে জিজ্ঞাসিত প্রশ্নগুলির পর্যালোচনা করে চিহ্নিত করা হয়েছিল।
আরও নির্দিষ্টভাবে, ওয়েব স্ট্যান্ডার্ড সংস্থার মিটিংগুলির জন্য মিটিং মিনিটগুলি পর্যালোচনা করা হয়েছিল এবং সরাসরি প্রতিক্রিয়ার জন্য, 1:1 স্টেকহোল্ডার মিটিংয়ের Google এর রেকর্ড, পৃথক ইঞ্জিনিয়ারদের দ্বারা প্রাপ্ত ইমেলগুলি, API মেলিং তালিকা এবং সর্বজনীন প্রতিক্রিয়া ফর্ম বিবেচনা করা হয়েছিল৷ Google তারপর প্রতিটি API-এর সাথে উদ্ভূত থিমগুলির আপেক্ষিক ব্যাপকতা নির্ধারণ করতে এই বিভিন্ন প্রচার কার্যক্রমের সাথে জড়িত দলগুলির মধ্যে সমন্বয় করে।
প্রতিক্রিয়ার জন্য Chrome এর প্রতিক্রিয়াগুলির ব্যাখ্যাগুলি প্রকাশিত প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী, স্টেকহোল্ডারদের দ্বারা উত্থাপিত সমস্যাগুলির প্রকৃত প্রতিক্রিয়া এবং এই পাবলিক রিপোর্টিং অনুশীলনের উদ্দেশ্যে বিশেষভাবে একটি অবস্থান নির্ধারণ করে তৈরি করা হয়েছিল৷ উন্নয়ন এবং পরীক্ষার বর্তমান ফোকাস প্রতিফলিত করে, বিশেষ করে বিষয়, ফ্লেজ এবং অ্যাট্রিবিউশন রিপোর্টিং API-এর ক্ষেত্রে প্রশ্ন এবং প্রতিক্রিয়া পাওয়া গেছে।
বর্তমান প্রতিবেদনের সময়কাল শেষ হওয়ার পরে প্রাপ্ত প্রতিক্রিয়াতে এখনও বিবেচিত Chrome প্রতিক্রিয়া নাও থাকতে পারে।
সংক্ষিপ্ত শব্দের শব্দকোষ
- চিপস
- স্বাধীন বিভাজিত রাষ্ট্র থাকার কুকিজ
- ডিএসপি
- ডিমান্ড-সাইড প্ল্যাটফর্ম
- ফেডসিএম
- ফেডারেটেড শংসাপত্র ব্যবস্থাপনা
- FPS
- প্রথম পক্ষের সেট
- আইএবি
- ইন্টারেক্টিভ বিজ্ঞাপন ব্যুরো
- আইডিপি
- পরিচয় প্রদানকারী
- আইইটিএফ
- ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স
- আইপি
- ইন্টারনেট প্রোটোকল ঠিকানা
- openRTB
- রিয়েল-টাইম বিডিং
- OT
- অরিজিন ট্রায়াল
- প্যাটসিজি
- প্রাইভেট অ্যাডভার্টাইজিং টেকনোলজি কমিউনিটি গ্রুপ
- আরপি
- ভরসা পার্টি
- এসএসপি
- সাপ্লাই সাইড প্ল্যাটফর্ম
- TEE
- বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট
- UA
- ইউজার এজেন্ট স্ট্রিং
- UA-CH
- ব্যবহারকারী-এজেন্ট ক্লায়েন্ট ইঙ্গিত
- W3C
- ওয়ার্ল্ড ওয়াইড ওয়েব কনসোর্টিয়াম
- ডব্লিউআইপিবি
- ইচ্ছাকৃত আইপি অন্ধত্ব
সাধারণ প্রতিক্রিয়া, কোনো নির্দিষ্ট API/প্রযুক্তি
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| (প্রায় 3 এও রিপোর্ট করা হয়েছে) বিভিন্ন ধরনের স্টেকহোল্ডারদের জন্য উপযোগিতা | উদ্বেগ যে গোপনীয়তা স্যান্ডবক্স প্রযুক্তি বৃহত্তর বিকাশকারীদের পক্ষপাতী এবং কুলুঙ্গি (ছোট) সাইটগুলি জেনেরিক (বড়) সাইটের চেয়ে বেশি অবদান রাখে | আমাদের প্রতিক্রিয়া Q3 থেকে অপরিবর্তিত: "গোপনীয়তা স্যান্ডবক্স প্রস্তাবনাগুলিকে এমনভাবে ডিজাইন ও বাস্তবায়ন করতে Google প্রতিশ্রুতিবদ্ধ হয়েছে যাতে Google-এর নিজস্ব ব্যবসাকে স্ব-অভিরুচি দিয়ে প্রতিযোগিতাকে বিকৃত না করে, এবং ডিজিটাল বিজ্ঞাপনে এবং প্রকাশক এবং বিজ্ঞাপনদাতাদের আকার নির্বিশেষে প্রতিযোগিতার উপর প্রভাব বিবেচনা করে। আমাদের কাজ এই প্রতিশ্রুতিগুলি মেনে চলে তা নিশ্চিত করতে আমরা CMA এর সাথে ঘনিষ্ঠভাবে কাজ চালিয়ে যাচ্ছি৷ গোপনীয়তা স্যান্ডবক্সের পরীক্ষা যেমন এগিয়ে চলেছে, আমরা যে মূল প্রশ্নগুলি মূল্যায়ন করব তা হল নতুন প্রযুক্তিগুলি বিভিন্ন ধরনের স্টেকহোল্ডারদের জন্য কীভাবে কাজ করে। প্রতিক্রিয়া এই ক্ষেত্রে গুরুত্বপূর্ণ, বিশেষ করে নির্দিষ্ট এবং কার্যকর প্রতিক্রিয়া যা আমাদের প্রযুক্তিগত নকশাগুলিকে আরও উন্নত করতে সাহায্য করতে পারে। আমরা পরিমাণগত পরীক্ষার প্রতি আমাদের দৃষ্টিভঙ্গি বিকাশের জন্য CMA-এর সাথে কাজ করেছি, এবং বাজার অংশগ্রহণকারীদের আরও তথ্য প্রদান করতে এবং প্রস্তাবিত পদ্ধতির উপর মন্তব্য করার সুযোগ দেওয়ার জন্য CMA-এর পরীক্ষার নকশার উপর একটি নোট প্রকাশ করাকে সমর্থন করি।" |
| (প্রায় 3 এও রিপোর্ট করা হয়েছে) ডকুমেন্টেশন অনুরোধ | পরীক্ষা, বিশ্লেষণ এবং বাস্তবায়ন কীভাবে পরিচালনা করতে হয় তার বিশদ বিবরণ দিয়ে আরও সংস্থানের জন্য অনুরোধ | Q4 আপডেট: আমরা প্রশংসা করি যে ডেভেলপাররা আমাদের বর্তমান উপাদানটিকে সহায়ক বলে মনে করেছেন, এবং আরও উপাদান প্রদানের জন্য প্রতিশ্রুতিবদ্ধ হতে চলেছেন যাতে বিকাশকারীরা বুঝতে পারে যে নতুন প্রযুক্তিগুলি তাদের জন্য কীভাবে কাজ করতে পারে৷ গত ত্রৈমাসিকে, আমরা privacysandbox.com- এ একটি "সংবাদ ও আপডেট" বিভাগ যোগ করেছি এবং কীভাবে গোপনীয়তা স্যান্ডবক্স ভবিষ্যতে বিজ্ঞাপনের প্রাসঙ্গিকতা বাড়াতে সাহায্য করতে পারে তার একটি বিস্তৃত পর্যালোচনা প্রকাশ করেছি। লাইভ আলোচনা/প্রশ্নের অনুমতি দেওয়ার জন্য প্রোডাক্ট এবং ইঞ্জিনিয়ারিং লিডের সাথে প্রশ্নোত্তর সেশন সহ আমরা সর্বোত্তম অনুশীলন এবং ডেমো শেয়ার করার জন্য পাবলিক ডেভেলপার অফিস সময়ের সেশনগুলিও আয়োজন করেছি। |
| কোর ওয়েব ভাইটাল | গোপনীয়তা স্যান্ডবক্স এপিআই লেটেন্সি কোর ওয়েব ভাইটালকে কীভাবে প্রভাবিত করে? | গোপনীয়তা স্যান্ডবক্স এপিআই-এর একটি মূল নকশা লক্ষ্য হল ন্যূনতম লেটেন্সি রাখা। আমাদের বর্তমান প্রত্যাশা হল API লেটেন্সি একটি সাইটের মূল ওয়েব ভাইটালগুলিতে ন্যূনতম প্রভাব ফেলবে, কারণ বেশিরভাগ API-কে ওয়েবসাইটটির প্রাথমিক রেন্ডারিংয়ের পরে কল করা হয়। আমরা প্রতিটি API-এর জন্য লেটেন্সি আরও কমাতে নিরীক্ষণ এবং উন্নতি করতে থাকি এবং ক্রমাগত পরীক্ষা এবং প্রতিক্রিয়াকে উৎসাহিত করি। রিয়েল টাইম বিডিং প্রক্রিয়ার লেটেন্সি "ফ্লেজ নিলামের পারফরম্যান্স" এর অধীনে FLEDGE বিভাগে সম্বোধন করা হয়েছে |
| ইন্টারঅপারেবিলিটি | অন্যান্য সম্ভাব্য সমাধানের সাথে ইন্টারঅপারেবিলিটি সংক্রান্ত উদ্বেগ | গোপনীয়তা স্যান্ডবক্সের লক্ষ্য হল ওয়েব ইকোসিস্টেমের প্রয়োজনীয়তা সমর্থন করার সময় ক্রস-সাইট ট্র্যাকিং থেকে ব্যবহারকারীদের রক্ষা করা। আমরা লিগ্যাসি ব্রাউজার প্রযুক্তিগুলি থেকে দূরে সরে গিয়ে এটি সম্পাদন করতে চাই যা এই ধরনের ক্রস-সাইট ট্র্যাকিং সক্ষম করে, যেমন তৃতীয় পক্ষের কুকি, এবং তাদের জায়গায় নির্দিষ্ট ব্যবহারের ক্ষেত্রে সমর্থন করার উদ্দেশ্যে নির্মিত নতুন প্রযুক্তি প্রদান করে। গোপনীয়তা স্যান্ডবক্স প্রস্তাবনাগুলি ব্যবহারকারীর ডিভাইসে থাকা ডেটা সীমিত করে গোপনীয়তা উন্নত করে৷ প্রস্তাবগুলি ব্রাউজার থেকে একবার সংগ্রহ করা ডেটা শেয়ার করার বা অন্যথায় প্রক্রিয়া করার ক্ষমতার উপর প্রযুক্তিগত সীমাবদ্ধতা রাখে না। প্রযুক্তিগুলি তাই কোম্পানীগুলিকে "ডেটা স্টুয়ার্ডশিপ" চুক্তি বা অন্য কোন অনুরূপ চুক্তিগত সম্পর্কগুলিতে প্রবেশ করতে বাধা দেয় না। একইভাবে, তারা ব্যবহারকারীদের অন্যান্য উপায়ে তাদের ডেটা ভাগ করে নেওয়ার সম্মতি দেওয়ার ক্ষমতাকে সীমাবদ্ধ করে না। স্পষ্টতার জন্য, Google প্রোডাক্ট এবং পরিষেবা সহ সমস্ত ওয়েবসাইটে একইভাবে গোপনীয়তা স্যান্ডবক্স প্রযুক্তি প্রয়োগ করতে প্রতিশ্রুতিবদ্ধ। Chrome তৃতীয় পক্ষের কুকিগুলির জন্য সমর্থন শেষ করার পরে, প্রতিশ্রুতিগুলি আরও স্পষ্ট করে যে Google অন্যান্য ব্যক্তিগত ডেটা ব্যবহার করবে না, যেমন ব্যবহারকারীদের সিঙ্ক করা Chrome ব্রাউজিং ইতিহাস, ডিজিটাল বিজ্ঞাপনের লক্ষ্য বা পরিমাপের জন্য ব্যবহারকারীদের ট্র্যাক করতে। |
প্রাসঙ্গিক বিষয়বস্তু ও বিজ্ঞাপন দেখান
বিষয়
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| গুগল সার্চ র্যাঙ্কিং এর উপর প্রভাব | একটি ওয়েবসাইটের বিষয় API সমর্থন Google অনুসন্ধান ফলাফল র্যাঙ্কিংয়ের সম্ভাব্য সংকেত হিসাবে ব্যবহার করা হবে কিনা সে বিষয়ে অনুসন্ধান | কিছু ওয়েবসাইট টপিক API থেকে অপ্ট-আউট করতে বেছে নিতে পারে। গোপনীয়তা স্যান্ডবক্স টিম অনুসন্ধান সংস্থার কাছ থেকে সমন্বয় বা অনুরোধ করেনি যে তারা ওয়েবসাইটগুলিকে বিষয় API গ্রহণ করার জন্য একটি প্রণোদনা হিসাবে পৃষ্ঠা র্যাঙ্কিং ব্যবহার করে। Google CMA-কে নিশ্চিত করেছে যে Google অনুসন্ধান একটি র্যাঙ্কিং সংকেত হিসাবে বিষয় API থেকে অপ্ট-আউট করার সাইটের সিদ্ধান্ত ব্যবহার করবে না। |
| বিষয় শ্রেণিবিন্যাসকারী | বিভিন্ন স্টেকহোল্ডারদের জন্য ইউটিলিটি উন্নত করার জন্য একটি ওয়েবপৃষ্ঠার বিষয় নির্ধারণ করতে হোস্টনাম ছাড়াও url এবং পৃষ্ঠা বিষয়বস্তু যোগ করুন। | একটি ব্যবহারকারীর ব্রাউজিং ইতিহাস বর্তমানে একটি ওয়েবসাইটের হোস্টনাম ব্যবহার করে শ্রেণীবদ্ধ করা হয়৷ Chrome বিষয়ের শ্রেণীবিভাগে পৃষ্ঠা স্তরের মেটাডেটা (যেমন পৃষ্ঠার URL এর সমস্ত বা কিছু উপাদান এবং/অথবা বিষয়বস্তু) বিবেচনা করার বিকল্পগুলি মূল্যায়ন করে চলেছে৷ যেকোন ইউটিলিটি উন্নতি অবশ্যই গোপনীয়তা এবং অপব্যবহারের ঝুঁকির বিরুদ্ধে ওজন করা উচিত। উদাহরণস্বরূপ, বিশেষ করে মেটাডেটার ক্ষেত্রে, কয়েকটি ঝুঁকির মধ্যে রয়েছে: - বিষয়গুলিতে বিভিন্ন (এবং সম্ভাব্য সংবেদনশীল) অর্থ এনকোড করার পদ্ধতি হিসাবে পৃষ্ঠা-স্তরের মেটাডেটা পরিবর্তন করে সাইটগুলি; - সাইটগুলি আর্থিক লাভের জন্য তাদের বিষয়গুলিকে ভুলভাবে উপস্থাপন করতে পৃষ্ঠা-স্তরের মেটাডেটা পরিবর্তন করে; - সাইটগুলি ক্রস-সাইট ট্র্যাকিংয়ের পদ্ধতি হিসাবে গতিশীলভাবে পৃষ্ঠা-স্তরের মেটাডেটা পরিবর্তন করে |
| (প্রায় 3 এও রিপোর্ট করা হয়েছে) প্রথম পক্ষের সংকেতের উপর প্রভাব | বিষয় সংকেত অত্যন্ত মূল্যবান হতে পারে এবং ফলস্বরূপ অন্যান্য প্রথম-পক্ষের আগ্রহ-ভিত্তিক সংকেতকে অবমূল্যায়ন করে। | আমাদের প্রতিক্রিয়া Q3 থেকে অপরিবর্তিত: "আমরা বিশ্বাস করি যে সুদ-ভিত্তিক বিজ্ঞাপন ওয়েবের জন্য একটি গুরুত্বপূর্ণ ব্যবহারের ক্ষেত্রে, এবং বিষয়গুলি সেই ব্যবহারের ক্ষেত্রে সমর্থন করার জন্য ডিজাইন করা হয়েছে৷ [আমাদের Q3 প্রতিবেদনে] যেমন বর্ণনা করা হয়েছে, অন্যান্য ইকোসিস্টেম স্টেকহোল্ডাররা উদ্বেগ প্রকাশ করেছেন যে বিষয়গুলি মূল্য প্রদানের জন্য যথেষ্ট কার্যকর নাও হতে পারে৷ সমস্ত ক্ষেত্রে, শ্রেণীকরণের উন্নতি একটি চলমান প্রচেষ্টা, এবং আমরা আশা করি যে শ্রেণীবিন্যাস এবং পরীক্ষায় বিকশিত হবে৷ |
| শ্রেণীবিন্যাস আপডেট করা হচ্ছে | কিভাবে শ্রেণীবিন্যাস তালিকা আপডেট করা হবে? | আমরা সক্রিয়ভাবে শ্রেণীবিন্যাস সম্পর্কে প্রতিক্রিয়া চাচ্ছি যা বাস্তুতন্ত্রের জন্য সবচেয়ে উপযোগী হবে। প্রাথমিক বিষয় এপিআই প্রস্তাবে অন্তর্ভুক্ত শ্রেণীবিন্যাসটি কার্যকরী পরীক্ষা সক্ষম করার জন্য ডিজাইন করা হয়েছিল। শ্রেণীবিন্যাস আপডেট করার জন্য Chrome সক্রিয়ভাবে একাধিক পন্থা বিবেচনা করছে। উদাহরণস্বরূপ, ভবিষ্যতের পুনরাবৃত্তিতে কোন বিভাগটি অন্তর্ভুক্ত করা হবে তা নির্ধারণ করতে Chrome প্রতিটি বিষয়ের জন্য বাণিজ্যিক মূল্যের ধারণা ব্যবহার করতে পারে। |
| বিষয় আঞ্চলিক ক্লাসিফায়ার কর্মক্ষমতা | আঞ্চলিক ডোমেনে প্রসঙ্গ শ্রেণীবদ্ধকারী খারাপভাবে কাজ করছে | শ্রেণিবিন্যাসকারীর উন্নতি একটি চলমান প্রচেষ্টা। আমরা যে প্রতিক্রিয়া পেয়েছি তার উপর ভিত্তি করে, বিবেচনাধীন একটি সম্ভাবনা হল বিষয় ওভাররাইড তালিকা প্রসারিত করা, যা আমাদের বিশ্লেষণ দেখায় বিশ্বব্যাপী কভারেজ বৃদ্ধি করবে এবং নির্ভুলতা উন্নত করবে। ব্যাখ্যা করার জন্য, টপিক এপিআই শ্রেণীবিভাগের দুটি প্রাসঙ্গিক উপাদান রয়েছে: (1) শীর্ষস্থানীয় 10k সাইট এবং তাদের বিষয়গুলি সম্বলিত একটি ওভাররাইড তালিকা এবং (2) একটি অন-ডিভাইস এমএল মডেল যা হোস্টনামগুলিকে বিষয়গুলিতে শ্রেণীবদ্ধ করে৷ ওভাররাইড তালিকা (1) প্রসারিত করে, আমরা সেই অঞ্চলগুলির জন্য শ্রেণীবিভাগের কার্যকারিতা উন্নত করতে পারি যেখানে শ্রেণীবদ্ধকারী খারাপভাবে পারফর্ম করতে পারে। |
| এক সপ্তাহের যুগ | স্বল্পমেয়াদী সিদ্ধান্ত নিতে চাওয়া ব্যবহারকারীদের জন্য এক সপ্তাহের যুগ অনেক দীর্ঘ। | যুগের উপযুক্ত দৈর্ঘ্য কী হওয়া উচিত তা আমরা সক্রিয়ভাবে দেখছি এবং বাস্তুতন্ত্রের জন্য আরও ভাল যুগ কী হবে সে সম্পর্কে আমরা আরও প্রতিক্রিয়াকে স্বাগত জানাই। |
| HTTP হেডার পুনরুদ্ধার | বিষয়গুলির HTTP শিরোনাম পুনরুদ্ধার সংক্রান্ত পর্যাপ্ত তথ্য নেই বলে উদ্বেগ | হেডার এবং ফেচ() এর জন্য কাজ চলছে। আমরা এখানে তথ্য উপলব্ধ আছে. আমরা ব্যাখ্যাকারীকে স্কিপ অবজারভেশন তথ্যও যোগ করেছি । |
| বিষয়ের উদ্দেশ্য শুধুমাত্র বিজ্ঞাপনদাতাদের সাহায্য করা, ব্যবহারকারীদের নয় | বিষয়/গোপনীয়তা স্যান্ডবক্স একটি শিল্প কেন্দ্রীভূত পদ্ধতি বলে মনে হচ্ছে। ব্যবহারকারীদের জন্য সুবিধা শিল্পের সুবিধার মতো স্পষ্ট নয়। | আমরা বিশ্বাস করি যে ব্যবহারকারীদের জন্য সুবিধা হল বিষয়গুলি আগ্রহ-ভিত্তিক বিজ্ঞাপনগুলিকে সমর্থন করে যা ওয়েবকে বিনামূল্যে এবং উন্মুক্ত রাখে এবং আমরা এটাও বিশ্বাস করি যে এটি তৃতীয় পক্ষের কুকিজের তুলনায় গোপনীয়তাকে উল্লেখযোগ্যভাবে উন্নত করে ৷ কার্যকর বিকল্প ছাড়া তৃতীয় পক্ষের কুকি অপসারণ প্রকাশকদের নেতিবাচকভাবে প্রভাবিত করতে পারে এবং আরও খারাপ পদ্ধতির দিকে নিয়ে যেতে পারে যেগুলি কম ব্যক্তিগত, স্বচ্ছ নয় এবং বাস্তবসম্মতভাবে পুনরায় সেট করা যায় না বা ব্যবহারকারীদের দ্বারা নিয়ন্ত্রিত হয় না৷ অনেক কোম্পানি সক্রিয়ভাবে বিষয় এবং স্যান্ডবক্স এপিআই পরীক্ষা করছে, এবং আমরা গোপনীয়তা অগ্রসর করতে এবং ওয়েবকে সমর্থন করার জন্য টুল প্রদান করতে প্রতিশ্রুতিবদ্ধ। W3C টেকনিক্যাল আর্কিটেকচার গ্রুপ সম্প্রতি টপিক এপিআই সম্পর্কে তার প্রাথমিক দৃষ্টিভঙ্গি প্রকাশ করেছে, যা আমরা সর্বজনীনভাবে প্রতিক্রিয়া জানাব। এই পর্যায়ে, যেহেতু Google ইকোসিস্টেম থেকে প্রশ্ন পেয়েছে যে এই পর্যালোচনাটি টপিক API-এর বিকাশ এবং লঞ্চের জন্য কী বোঝাতে পারে, তাই আমরা এই বছর Chrome Stable-এ এটি উপলব্ধ করার জন্য আমাদের পরিকল্পনার পুনর্নিশ্চিত করতে চাই। যদিও Googles W3C টেকনিক্যাল আর্কিটেকচার গ্রুপের ইনপুটকে প্রশংসা করে, এটি CMA এবং ইকোসিস্টেমের সাথে আলোচনা করে বিষয়গুলির বিকাশ এবং পরীক্ষা করার প্রচেষ্টা চালিয়ে যাওয়াকে সর্বোত্তম গুরুত্ব বলে মনে করে। |
| ডেটা ফাঁস | বিষয়গুলি অনুমতি ছাড়াই অন্যান্য সাইটে ফাঁস হতে পারে বলে উদ্বেগ | টপিকস এপিআই-এর ডিজাইন এটিকে একেবারে অসম্ভাব্য করে তোলে যে একটি একক প্রকাশকের (এবং প্রকাশকদের একটি ছোট গোষ্ঠীর) থেকে ডেটা যে কোনও উপায়ে ফাঁস হতে পারে। প্রকাশক ওয়েবসাইটগুলিও বিষয় API-এর উপর সম্পূর্ণ নিয়ন্ত্রণে রয়েছে এবং তারা অনুমতি নীতির মাধ্যমে এই API-তে অ্যাক্সেস নিষিদ্ধ করতে পারে। |
| পরীক্ষার জন্য বিজ্ঞাপনদাতাদের অভাব | প্রকাশকরা উদ্বিগ্ন যে তারা বর্তমানে বিজ্ঞাপনদাতাদের কাছে বিষয়ের মান প্রদর্শন করতে অক্ষম৷ | 2023 সালের দ্বিতীয়ার্ধে, আমরা ইন্টিগ্রেশন পরীক্ষার জন্য সমস্ত বিজ্ঞাপন সম্পর্কিত API গুলি উপলব্ধ করার পরিকল্পনা করছি এবং বিজ্ঞাপনদাতাদের জন্য বিষয়গুলির মূল্যের ইকোসিস্টেম বিশ্লেষণ সক্ষম করব। ফলাফলের পরীক্ষা এবং প্রকাশনা CMA দ্বারা তত্ত্বাবধান করা হবে, যা ডেটা, বিশ্লেষণ এবং পদ্ধতি পর্যালোচনা করবে। ইকোসিস্টেমকে Google এবং CMA-এর সাথে প্রতিক্রিয়া শেয়ার করার জন্য উৎসাহিত করা হয়। |
| বিষয় এবং FLEDGE | FLEDGE এর বিডিং লজিকের মধ্যে বিষয়গুলি কীভাবে ব্যবহার করবেন সে সম্পর্কে আরও তথ্যের জন্য অনুরোধ করুন৷ | FLEDGE এর বিডিং লজিকের মধ্যে বিষয়গুলি ব্যবহার করা সম্ভব। একটি ইন্টিগ্রেশন গাইডও চলছে, এবং এতে বাস্তবায়নের অতিরিক্ত বিবরণ অন্তর্ভুক্ত থাকবে। |
| বিষয় কলার জন্য কাস্টম র্যাঙ্কিং | র্যাঙ্কিং কলার দ্বারা উপযোগী করার অনুমতি দিন | প্রতিটি বিজ্ঞাপন প্রযুক্তির জন্য কাস্টম টপিক র্যাঙ্কিং বা মানগুলির সাথে চ্যালেঞ্জ হল যে এটি এমন একটি পদ্ধতিতে পরিণত হতে পারে যার মাধ্যমে একটি বিজ্ঞাপন প্রযুক্তি ফেরত দেওয়া বিষয়গুলিকে প্রভাবিত করতে পারে, তাই একটি ফিঙ্গারপ্রিন্টিং ভেক্টর৷ |
| বিষয় কলার অগ্রাধিকার তালিকা | কলারদের এমন বিষয়গুলির একটি র্যাঙ্ক করা অগ্রাধিকার তালিকা প্রদান করার অনুমতি দিন যা বিষয় API যোগ্যতার ভিত্তিতে ফেরত দেবে। | আমরা বর্তমানে এই ধারণাটি আরও আলোচনা করছি এবং অতিরিক্ত ইনপুটগুলিকে স্বাগত জানাই৷ |
FLEDGE
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| গুগল অ্যাড ম্যানেজার | উদ্বেগ যে Google Ad Manager হল FLEDGE নিলামের চূড়ান্ত সিদ্ধান্তকারী এবং Google প্রকাশক ট্যাগ এবং Google বিজ্ঞাপন ব্যবস্থাপককে সমর্থন করবে৷ | FLEDGE প্রতিটি প্রকাশককে শীর্ষ-স্তরের এবং উপাদান বিক্রেতাদের পছন্দ সহ নিলামের কাঠামো বেছে নেওয়ার অনুমতি দেয়৷ একটি উপাদান নিলামে প্রতিটি ক্রেতা এবং বিক্রেতা জানেন যে শীর্ষ-স্তরের বিক্রেতা কে, এবং বিড করবেন কি না তা চয়ন করতে পারেন। |
| পর্যাপ্ত অংশগ্রহণকারীরা FLEDGE পরীক্ষা করছে না | FLEDGE পরীক্ষা করার জন্য আরও কোম্পানিকে উৎসাহিত করার অনুরোধ, উদাহরণস্বরূপ API-এর কার্যকারিতা উন্নত করে এবং আঙ্গুলের ছাপের মতো গোপনীয়তা-অনুপ্রবেশকারী বিকল্পগুলিকে নিরুৎসাহিত করে | গোপনীয়তা স্যান্ডবক্স ধাপে ধাপে এগিয়ে চলেছে, CMA এবং ICO-এর নির্দেশনার সাথে ঘনিষ্ঠ অংশীদারিত্বে, এবং কার্যকরী FLEDGE পরীক্ষা প্রয়োজনীয় স্থিতিশীলতা এবং সক্ষমতা প্রদর্শন করেছে। Google স্যান্ডবক্স এপিআই পরীক্ষা করার জন্য ইকোসিস্টেমকে উৎসাহিত করে চলেছে, সম্প্রতি তার " বিজ্ঞাপন প্রাসঙ্গিকতা সর্বাধিক করুন " ডকুমেন্টেশন প্রকাশ করেছে তা দেখানোর জন্য কীভাবে FLEDGE এবং অন্যান্য APIগুলি তৃতীয়-পক্ষ কুকি অবচয় করার পরে বিজ্ঞাপন শিল্পের জন্য সমালোচনামূলক ব্যবহারের ক্ষেত্রে সহায়তা করতে পারে৷ গোপনীয়তা স্যান্ডবক্সের অন্যান্য অংশগুলি ইতিমধ্যেই ট্র্যাকিং কভার করতে প্রশমনকে সমর্থন করে (দেখুন UA-CH, IP সুরক্ষা, এবং বাউন্স ট্র্যাকিং মিটিগেশন) এবং সময়ের সাথে সাথে উন্নতি করতে থাকবে। Google-এর লক্ষ্য হল FLEDGE-কে একমাত্র কার্যকর টার্গেটিং সমাধান করা নয়, বরং ক্রোম ব্রাউজারে সেরা গোপনীয়তা-সংরক্ষণকারী বিজ্ঞাপন প্রযুক্তিগুলি চালানোর জন্য শিল্প এবং নিয়ন্ত্রকদের সাথে অংশীদারিত্বে কাজ করতে প্রতিশ্রুতিবদ্ধ। |
| মেশিন লার্নিং ব্যবহারের ক্ষেত্রে | নিলাম বিডিং অ্যালগরিদম প্রশিক্ষণের জন্য মেশিন লার্নিং কীভাবে কেস ব্যবহার করে সে সম্পর্কে আরও নির্দেশিকা FLEDGE এবং অ্যাট্রিবিউশন রিপোর্টিং-এ সমর্থিত হবে | আমরা পরীক্ষকদের গোপনীয়তা স্যান্ডবক্স প্রযুক্তিগুলি প্রয়োগ করার সবচেয়ে দরকারী উপায়গুলি খুঁজে পেতে সহায়তা করার প্রয়োজনীয়তা স্বীকার করি৷ আমরা মেশিন লার্নিং-এ ইনপুট হিসাবে গোপনীয়তা স্যান্ডবক্স API-এর বিভিন্ন দিক ব্যবহারের সাথে সম্পর্কিত নির্দেশিকা প্রকাশ করতে শুরু করেছি। সবচেয়ে সাম্প্রতিক অংশ, ম্যাক্সিমাইজ অ্যাড প্রাসঙ্গিকতা , কীভাবে বিজ্ঞাপন শিল্প মেশিন লার্নিংয়ের জন্য এই সংকেতগুলি ব্যবহার করতে পারে তা নিয়ে আলোচনা করে এবং আমরা ভবিষ্যতে এই ধরনের নির্দেশিকা প্রকাশ করা চালিয়ে যাওয়ার পরিকল্পনা করছি। |
| FLEDGE কী মান (K/V) সার্ভারের জন্য অনুসন্ধান করা হচ্ছে | কেন K/V সার্ভার সর্বজনীনভাবে জিজ্ঞাসাযোগ্য? | K/V সার্ভারের লক্ষ্য FLEDGE নিলামে রিয়েল টাইম সংকেত প্রদান করা। যেমন, K/V সার্ভারকে অ্যাক্সেসযোগ্য হতে হবে যেখান থেকে সেই FLEDGE নিলামগুলি চালানো হয়, যা ব্যবহারকারীর ডিভাইসে রয়েছে, এটি সর্বজনীনভাবে উপলব্ধ হওয়া প্রয়োজন। K/V সার্ভারে সঞ্চিত একটি মান শুধুমাত্র একটি পক্ষের দ্বারা পুনরুদ্ধার করা যেতে পারে যার ইতিমধ্যেই এর কী আছে — তাই যদি একটি বিজ্ঞাপন প্রযুক্তি শুধুমাত্র স্বার্থ গোষ্ঠীতে থাকা ব্রাউজারগুলিতে কীগুলি দেয় এবং এলোমেলোভাবে অনুমান করা যায় এমন কীগুলি ব্যবহার না করে, তাহলে শুধুমাত্র ব্রাউজারগুলিকে তাদের নিলাম চালানোর জন্য মান প্রয়োজন তারা এটি পুনরুদ্ধার করতে সক্ষম হবে৷ |
| তারিখ/সময় টার্গেটিং কিভাবে করবেন? | বিডিং লজিক ফাংশনে তারিখ অবজেক্টের জন্য সমর্থন। | এটি করার একাধিক উপায় আছে। ক্রেতারা তাদের বিক্রেতাকে বর্তমান তারিখ এবং সময় প্রদান করতে বলতে পারেন এবং বিক্রেতাদের পক্ষে সমস্ত ক্রেতাদের এই তথ্য প্রদান করা সহজ হওয়া উচিত। ক্রেতারা তাদের রিয়েল টাইম কী-ভ্যালু রেসপন্সে তারিখ এবং সময়ও দিতে পারে। অবশেষে, ক্রেতারা প্রতি-ক্রেতা-সংকেতে তাদের প্রাসঙ্গিক প্রতিক্রিয়ার অংশ হিসাবে তারিখ এবং সময় প্রদান করতে পারে, যা একজন বিক্রেতা ক্রেতার জেনারেটবিড স্ক্রিপ্টে পাঠাতে পারে। |
| ব্যবহারকারীর পছন্দ | FLEDGE বা বিকল্প সমাধানের মাধ্যমে পরিবেশন করার সময় ব্যবহারকারীদের বিজ্ঞাপনদাতার দ্বারা ক্রিয়েটিভগুলিকে ব্লক করতে বেছে নেওয়ার ক্ষমতা। | ব্যবহারকারীদের Chrome-এ বিজ্ঞাপন API গুলি অপ্ট আউট করার ক্ষমতা রয়েছে৷ নির্দিষ্ট বিজ্ঞাপনের জন্য, কোন ক্রিয়েটিভ দেখানো হবে বা কীভাবে সেগুলি বেছে নেওয়া হবে তার উপর নিয়ন্ত্রণ অফার করার জন্য প্রাসঙ্গিক বিজ্ঞাপন প্রযুক্তি হল সর্বোত্তম অবস্থান। |
| আরও পরিষ্কার সময়রেখা | FLEDGE-এ গোপনীয়তা সুরক্ষার প্রাপ্যতা সম্পর্কে আরও তথ্যের জন্য অনুরোধ করুন, যেমন ফেন্সড ফ্রেমের প্রয়োজন৷ | আমরা Q1 এ আরো বিস্তারিত সময়রেখা প্রকাশ করার পরিকল্পনা করছি। |
| বিভ্রান্তির প্রতিবেদন করা | কিভাবে FLEDGE রিপোর্টিং অন্যান্য API যেমন Fenced Frames এবং Private Aggregation API-এর সাথে কাজ করবে সে সম্পর্কে আরও স্পষ্টতার জন্য অনুরোধ করুন। | আমরা আগামী সপ্তাহে প্রাইভেট অ্যাগ্রিগেশন API, FLEDGE এবং ফেন্সড ফ্রেমগুলির মধ্যে মিথস্ক্রিয়া সম্পর্কে একটি ব্যাখ্যাকারী প্রকাশ করার পরিকল্পনা করছি৷ |
| রিয়েল-টাইম বিডিং এবং FLEDGE | FLEDGE কিভাবে স্ট্যান্ডার্ড রিয়েল-টাইম বিডিংয়ের সাথে একত্রিত হয় তার নির্দেশিকা। | দুটি প্রধান জিনিস যা একটি বিজ্ঞাপন প্রযুক্তির রিয়েল-টাইম বিডিং করার ক্ষমতাকে জটিল করে তোলে তা হল ইভেন্ট স্তরের ডেটাতে অ্যাক্সেস এবং ARA-তে সহজে একীকরণ। আমরা Q1 এ উভয়ের উপর আপডেট এবং ব্যাখ্যাকারী পাঠানোর পরিকল্পনা করছি। |
| FLEDGE নিলামের কর্মক্ষমতা | পরীক্ষকদের থেকে রিপোর্ট যে FLEDGE নিলামে উচ্চ বিলম্ব হয় | আমরা পরীক্ষকদের তাদের ফলাফল এবং ব্যবহারের ক্ষেত্রে শেয়ার করা প্রতিবেদনের প্রশংসা করি এবং FLEDGE-এর কার্যকারিতা কীভাবে উন্নত করা যায় সে সম্পর্কে কিছু পরামর্শ শেয়ার করেছি। সমান্তরালভাবে, আমরা ব্রাউজারে টুলিং যোগ করেছি যা ডেভেলপারদের আরও ভালভাবে নির্ণয় করতে দেয় যে কি নিলামকে ধীর করে দিচ্ছে , এবং পরিলক্ষিত বিলম্বের প্রাথমিক উত্সগুলিকে পদ্ধতিগতভাবে সম্বোধন করছি৷ সাম্প্রতিক উন্নতিগুলির মধ্যে রয়েছে ধীর নিলামের সময়সীমা , একটি দ্রুত বিডার ফিল্টারিং কৌশল , স্টার্টআপ খরচ পরিশোধ এড়াতে FLEDGE ওয়ার্কলেটগুলি পুনরায় ব্যবহার করার একটি উপায়, এবং প্রাসঙ্গিক বিজ্ঞাপন অনুরোধ FLEDGE স্টার্টআপ সময় এবং নেটওয়ার্ক আনয়নের সাথে সমান্তরালভাবে চালানোর জন্য চলমান কাজ। আমরা আশা করি যে লেটেন্সি অপ্টিমাইজেশান ক্রোম ডেভেলপার এবং FLEDGE পরীক্ষকদের মধ্যে চলমান কথোপকথন হিসাবে তাদের API ব্যবহার করে বাস্তব-বিশ্বের অভিজ্ঞতার ভিত্তিতে চালিয়ে যাবে৷ |
| সুদের গ্রুপ আকার মেমরি সীমা | একটি একক স্বার্থ গোষ্ঠীর আকারের সীমা 50kB থেকে বাড়ানোর অনুরোধ করুন৷ | আমরা সক্রিয়ভাবে অনুরোধটি বিবেচনা করছি এবং কোন সীমা মান কাজ করে তার প্রতিক্রিয়া খুঁজছি । |
| প্রথম পক্ষের কুকির সাথে FLEDGE পরিবেশিত ডেটা একত্রিত করা | FLEDGE কি একজন বিজ্ঞাপনদাতার প্রথম পক্ষের ডেটার সাথে একীকরণ সমর্থন করবে? | FLEDGE একটি বিজ্ঞাপনদাতার ইতিমধ্যেই থাকা প্রথম পক্ষের ডেটা ব্যবহার করে বিজ্ঞাপন সমর্থন করার জন্য তৈরি করা হয়েছিল৷ যাইহোক, FLEDGE একজন বিজ্ঞাপনদাতাকে বিজ্ঞাপনদাতার নিজস্ব সাইট ব্যতীত অন্য কোনো ওয়েবসাইটে একজন ব্যক্তির ব্রাউজিং আচরণ শেখার জন্য সমর্থন করতে চায় না। প্রথম পক্ষের ডেটাতে অফ-সাইট ব্রাউজিং আচরণ সংযুক্ত করা গোপনীয়তা স্যান্ডবক্সের লক্ষ্যগুলির বিপরীত। আমরা আগামী সপ্তাহে FLEDGE কীভাবে প্রথম পক্ষের ডেটার সাথে একীকরণকে সমর্থন করবে সে সম্পর্কে আরও বিশদ সহ ইন্টিগ্রেশন গাইড শেয়ার করার পরিকল্পনা করছি৷ |
| K-অনামী মান | কিভাবে "K" থেকে "k-anon" মান নির্ধারণ করা হবে এবং এটি প্রকাশ করা হবে? | "K" মান এখনও চূড়ান্ত করা হচ্ছে এবং আমাদের পরিকল্পনাগুলি বিকাশের সাথে সাথে আমরা আরও তথ্য ভাগ করব৷ আমরা কীভাবে একটি অজানা k মান FLEDGE প্রস্তুতি এবং স্কোপিং ML মডেল প্রশিক্ষণকে বাধাগ্রস্ত করতে পারে সে সম্পর্কে আরও জানতে আগ্রহী এবং আমরা এই বিষয়ে অতিরিক্ত প্রতিক্রিয়াকে স্বাগত জানাই। |
| একাধিক এসএসপি সমর্থন করে | FLEDGE-তে কীভাবে একাধিক SSP সমর্থিত হবে? | এই প্রস্তাবে উল্লিখিত হিসাবে FLEDGE বহু-বিক্রেতার নিলাম সমর্থন করে৷ |
| বিডিং যুক্তির দৃশ্যমানতা | উদ্বেগ যে DSP বিডিং যুক্তি জাভাস্ক্রিপ্ট উন্মুক্ত করা হবে | বর্তমান ডিজাইন বিডিং লজিক জাভাস্ক্রিপ্ট অন্যদের দ্বারা অ্যাক্সেস করা যেতে পারে, কিন্তু কেন এটি DSP-এর জন্য উদ্বেগের কারণ হতে পারে সে সম্পর্কে আমরা আরও প্রতিক্রিয়াকে স্বাগত জানাই। |
| prebid.js | FLEDGE-তে prebid.js সমর্থন করার টাইমলাইন কী? | শুধুমাত্র Prebid.js এর 7.14 এবং পরবর্তী সংস্করণ FLEDGE মডিউল সমর্থন করে। পরীক্ষায় আগ্রহী যেকোনো প্রকাশককে অবশ্যই FLEDGE মডিউল যোগ করতে হবে এবং তাদের প্রিবিড উদাহরণ আপগ্রেড করতে হবে। |
| FLEDGE এ ব্যবহারকারীর সংজ্ঞায়িত ফাংশন | কিভাবে ব্যবহারকারী সংজ্ঞায়িত ফাংশন (UDF) FLEDGE এ সমর্থিত হবে? এগুলি এমন ফাংশন যা API এর কার্যকারিতা প্রসারিত করতে শেষ ব্যবহারকারীদের দ্বারা প্রোগ্রাম করা যেতে পারে। | ব্যাখ্যাকারী এখানে উপলব্ধ। এটি এখনও তৈরি করা হচ্ছে তাই আমরা ব্যবহারের ক্ষেত্রে অতিরিক্ত প্রতিক্রিয়া স্বাগত জানাই। |
| ইন্টারেস্ট গ্রুপ রিসোর্সে একই-অরিজিন সীমাবদ্ধতা শিথিল করা | নির্দিষ্ট বিজ্ঞাপন প্রযুক্তি ব্যবহারের ক্ষেত্রে সক্ষম করার জন্য আগ্রহ গোষ্ঠীর সংস্থানগুলিতে একই-উৎস সীমাবদ্ধতা শিথিল করার অনুরোধ করুন | FLEDGE-এর বর্তমান বাস্তবায়নে, biddingLogicUrl , biddingWasmHelperUrl , dailyUpdateUrl এবং trustedBiddingSignalsUrl অবশ্যই স্বার্থ গোষ্ঠীর মালিকের মতো একই উত্স থাকতে হবে৷আক্রমণকারীদের দ্বারা নির্দিষ্ট শোষণ প্রতিরোধ করার জন্য সীমাবদ্ধতা বিদ্যমান, যেমনটি এখানে ব্যাখ্যা করা হয়েছে। |
| স্বার্থ গোষ্ঠীর মালিকানা | একটি বিজ্ঞাপন প্রযুক্তি সাইট জুড়ে একই আগ্রহের গ্রুপের জন্য joinInterestGroup ব্যবহার করতে পারে কিনা তা সীমিত করার অনুরোধ করুন | আমাদের ফোকাস হল শ্রোতাদের কীভাবে ব্যবহার করা হয়, কীভাবে তৈরি করা হয় তা নয়। আমরা সম্ভাব্য পন্থা নিয়ে আলোচনা করছি এবং অতিরিক্ত ইনপুটকে স্বাগত জানাচ্ছি। |
| কী ভ্যালু সার্ভার কী মেয়াদ শেষ | সংশ্লিষ্ট স্বার্থ গোষ্ঠীর মেয়াদ শেষ হয়ে গেলে সার্ভার কীগুলি সরানোর বিষয়ে আলোচনা | আমরা কী মেয়াদ শেষ করার উপায়গুলি অন্বেষণ করছি এবং প্রতিক্রিয়া খুঁজছি৷ |
ডিজিটাল বিজ্ঞাপন পরিমাপ
অ্যাট্রিবিউশন রিপোর্টিং (এবং অন্যান্য API)
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| মূল ট্রায়াল ট্রাফিক | বর্তমান অরিজিন ট্রায়াল ট্রাফিক ইউটিলিটি পরীক্ষা পরিচালনা করার জন্য যথেষ্ট নয়। | বর্তমান অরিজিন ট্রায়ালগুলি ইকোসিস্টেম প্লেয়ারদের জন্য কার্যকরী পরীক্ষা পরিচালনা করার জন্য বোঝানো হয়েছে যাতে APIটি উদ্দেশ্য অনুসারে কাজ করছে তা নিশ্চিত করতে। আমরা বুঝতে পারি যে বিভিন্ন গোপনীয়তা স্যান্ডবক্স API এর বিকাশ আরও পরিপক্ক হওয়ার পরে ইউটিলিটি পরীক্ষা করার জন্য বড় পরিমাণে ট্র্যাফিকের প্রয়োজন হবে। বর্তমান পরীক্ষার টাইমলাইন ধারণা করে যে এটি সাধারণ উপলব্ধতার দ্বারা ঘটবে (অর্থাৎ যখন ব্যবহারের ক্ষেত্রে প্রযুক্তিগুলি চালু হবে এবং 100% Chrome ট্র্যাফিকের জন্য উপলব্ধ হবে) Q3 তে ( privacysandbox.com-এ আমাদের আপ-টু-ডেট টাইমলাইন দেখুন)। আমরা অতিরিক্ত ট্র্যাফিকের প্রয়োজনের ক্ষেত্রে ব্যবহারের ক্ষেত্রে যেকোনও অতিরিক্ত প্রতিক্রিয়াকে স্বাগত জানাই। |
| বিভিন্ন গোপনীয়তা স্যান্ডবক্স পরিমাপ API-এর কার্যকারিতা ওভারল্যাপ | গোপনীয়তা স্যান্ডবক্সের মাধ্যমে একাধিক পরিমাপ পদ্ধতি ওভারল্যাপ হওয়ার বিষয়ে উদ্বেগ জটিলতা বাড়াবে, উদাহরণস্বরূপ, অ্যাট্রিবিউশন রিপোর্টিং এপিআই এবং প্রাইভেট অ্যাগ্রিগেশন এপিআই। | আমরা API-এর জন্য বিভিন্ন ব্যবহারের ক্ষেত্রে স্পষ্ট করার জন্য আরও ভাল ডকুমেন্টেশন নিয়ে কাজ করছি, এবং কোন কোন ক্ষেত্রে ব্যাখ্যার অভাব রয়েছে সে সম্পর্কে অতিরিক্ত প্রতিক্রিয়াকে স্বাগত জানাই । উদাহরণস্বরূপ, অ্যাট্রিবিউশন রিপোর্টিং API বিশেষভাবে রূপান্তর পরিমাপকে সমর্থন করার উদ্দেশ্যে তৈরি করা হয়েছে, যেখানে ব্যক্তিগত একত্রিত API এবং ভাগ করা সঞ্চয়স্থান হল সাধারণ-উদ্দেশ্যের API যা ক্রস-সাইট পরিমাপ ব্যবহার-কেসগুলির একটি বিস্তৃত পরিসরকে সমর্থন করার উদ্দেশ্যে। |
| ব্যর্থ রিপোর্ট অনুরোধ পুনরায় চেষ্টা করুন | একটি প্রতিবেদনের অনুরোধ ব্যর্থ হলে কতবার চেষ্টা করা হয় তার ব্যাখ্যা। | আমরা এই বিষয়ে নির্দেশিকা প্রকাশ করেছি । সংক্ষিপ্তভাবে বলা যায়, প্রতিবেদনগুলি শুধুমাত্র তখনই পাঠানো হয় যখন ব্রাউজার চালু/অনলাইনে থাকে। পাঠাতে প্রথম ব্যর্থতার পরে, রিপোর্টটি 5 মিনিট পরে পুনরায় চেষ্টা করা হয়। দ্বিতীয় ব্যর্থতার পরে, 15 মিনিটের পরে প্রতিবেদনটি পুনরায় চেষ্টা করা হয়। এরপর আর রিপোর্ট পাঠানো হয় না। |
| রিপোর্টিং বিলম্ব | প্রত্যাশিত রিপোর্টিং বিলম্ব কি? | আমরা সমান্তরালভাবে এই বিলম্বগুলি আরও মূল্যায়ন করার জন্য ডেটা সংগ্রহ করার সময় তারা যে কোনও রিপোর্টিং বিলম্বের বিষয়ে ইকোসিস্টেম থেকে আরও প্রতিক্রিয়া শুনতে চাই। |
| প্রি-রেন্ডার পেজ | ARA অ্যাট্রিবিউশন কি প্রি-রেন্ডার পৃষ্ঠাগুলিতে কাজ করবে? | অ্যাট্রিবিউশন রেজিস্ট্রেশন প্রি-রেন্ডার পৃষ্ঠাগুলিতে স্থগিত করা হয় যতক্ষণ না সক্রিয়করণ (প্রকৃত ক্লিক বা ভিউ সঞ্চালিত হয়)। এর মানে আমরা `attributionsrc` রিকোয়েস্ট পিং পিছিয়ে দেব। |
| রূপান্তর লিফট পরিমাপ | একই ডোমেনে AB পরীক্ষার মাধ্যমে রূপান্তর উত্তোলন কীভাবে পরিমাপ করবেন | ওয়েবসাইটগুলি অ্যাট্রিবিউশন রিপোর্টিংয়ের মাধ্যমে একই ডোমেনে A/B পরীক্ষার মাধ্যমে রূপান্তর উত্তোলন পরিমাপ করতে পারে। তারা সমষ্টি API ব্যবহার করে কী হিসাবে তাদের A/B প্যারামিটারগুলিকে এনকোড করতে পারে এবং তারপরে সেই কী বালতিগুলির দ্বারা রূপান্তর মানগুলির জন্য সারসংক্ষেপ প্রতিবেদনগুলি গ্রহণ করতে পারে৷ |
| (প্রায় 3-এও রিপোর্ট করা হয়েছে) ক্রস-ডোমেন রূপান্তর | 2 বা তার বেশি গন্তব্যের মতো ক্রস ডোমেন রূপান্তরগুলি কীভাবে ট্র্যাক করবেন | Q4 আপডেট: আমরা ল্যান্ডিং পৃষ্ঠার গন্তব্য সীমাবদ্ধতা সরানোর জন্য একটি প্রস্তাব প্রকাশ করেছি যা ক্রস ডোমেন কথোপকথনগুলিকে ট্র্যাক করতে সক্ষম করে৷ এই প্রস্তাব বাস্তবায়ন করা হয়েছে। |
| (প্রায় 3 এও রিপোর্ট করা হয়েছে) রূপান্তর প্রতিবেদনে মেয়াদ শেষ হওয়ার সেটিং | 24 ঘন্টার কম সময়ের জন্য রিপোর্ট ফিল্টার / মেয়াদ শেষ করার জন্য সমর্থন করার জন্য অনুরোধ করুন | Q4 আপডেট: আমরা এই পুল অনুরোধটি শেয়ার করেছি যা রিপোর্টিং বিলম্ব বনাম রূপান্তর মেয়াদ শেষ হওয়ার ট্রেড অফ কমানোর জন্য মেয়াদ শেষ এবং রিপোর্টিং উইন্ডোগুলিকে দ্বিগুণ করবে। এটি এখন M110 এ লঞ্চ করা হয়েছে। |
| প্রতারণা এবং অপব্যবহার | বিজ্ঞাপনদাতা এবং বিপণনকারীদের কাছ থেকে অনুরোধগুলি প্রকাশকের সাইটের উপর ভিত্তি করে ডেটা টুকরো টুকরো করতে এবং একত্রিত করতে সক্ষম হবে যেখানে তাদের বিজ্ঞাপনগুলি পরিবেশিত হয়, যা সম্ভাব্য জালিয়াতিমূলক বিজ্ঞাপন অনুশীলনের আরও অন্তর্দৃষ্টি দেবে | এই প্রতিক্রিয়া সক্রিয়ভাবে এখানে আলোচনা করা হচ্ছে এবং আমরা অতিরিক্ত ইনপুট স্বাগত জানাই. |
| (এছাড়াও Q3 এ রিপোর্ট করা হয়েছে) ইভেন্ট লেভেল রিপোর্টিং বিলম্ব | ইভেন্ট লেভেল রিপোর্টিংয়ে 2-30 দিনের বিলম্ব নির্দিষ্ট ব্যবহারের ক্ষেত্রে খুব দীর্ঘ হতে পারে। | ইভেন্ট লেভেল রিপোর্টিং এর ডিফল্ট রিপোর্টিং উইন্ডো আছে 2, 7, এবং 30 দিনের। এটি "মেয়াদ শেষ" প্যারামিটার ব্যবহার করে সংশোধন করা যেতে পারে। Ad-techs 2 দিনের কম সময়ে সম্ভাব্য রিপোর্ট পেতে ন্যূনতম 1 দিনের সাথে মেয়াদ শেষ হওয়ার কনফিগার করতে পারে। আমরা একটি গোপনীয়তা সুরক্ষা ব্যবস্থা হিসাবে মেয়াদ শেষ হওয়ার গ্রানুলারিটি 1 দিনের মধ্যে সীমাবদ্ধ করি, কারণ আরও সূক্ষ্ম প্রতিবেদনের ফলে সময় আক্রমণ হতে পারে। উপরন্তু, আমরা ইভেন্ট লেভেল এবং সামগ্রিক রিপোর্টের জন্য স্বাধীন "মেয়াদ শেষ" প্যারামিটার সেট করার অনুমতি দিই। এখানে দেখুন. উপরন্তু, Google Ads এমন কোনো বিশেষ রিপোর্টিং উইন্ডো পাবে না যা অন্যান্য অ্যাড-টেকগুলি অ্যাট্রিবিউশন রিপোর্টিং API-এর মাধ্যমে পায় না। |
| একই রিপোর্টিং মূল প্রয়োজন | সোর্স রেজিস্ট্রেশনের জন্য প্রয়োজনীয়তা অপসারণের অনুরোধ যাতে কনভার্সন রেজিস্ট্রেশনের মূলের মতোই হয় | আমরা এই ব্যবহার-কেস সমাধানের জন্য নিবন্ধন অর্পণ করার জন্য HTTP পুনঃনির্দেশ ব্যবহার করার প্রস্তাব করছি। আমরা নতুন নির্দেশিকা উপর কোনো অতিরিক্ত প্রতিক্রিয়া স্বাগত জানাই. |
| রূপান্তর ট্র্যাকিং | বিজ্ঞাপনদাতার নির্ধারিত নির্দিষ্ট সময়ের আগে/পরে রূপান্তর ঘটেছে কিনা তা পার্থক্য করতে হবে | অ্যাট্রিবিউশন রিপোর্টিং API একটি মেয়াদোত্তীর্ণ উইন্ডো সেট করতে এবং উত্স অ্যাট্রিবিউশনের জন্য অগ্রাধিকার সমর্থন করে৷ উভয়ই ব্যবহার করে, X-এর পরে ঘটে যাওয়া একটি রূপান্তর থেকে X দিনের উইন্ডোর মধ্যে ঘটে যাওয়া একটি রূপান্তরকে টেকনিক্যালি অ্যাট্রিবিউট করা সম্ভব হবে৷ |
| নয়েজ সিমুলেশন | কম রূপান্তর সহ বিজ্ঞাপনদাতাদের উপর প্রভাব বোঝার জন্য বালতি প্রতি রূপান্তরের বিভিন্ন ভলিউম অনুকরণ করতে সক্ষম হওয়ার অনুরোধ করুন | আমরা নয়েজ ল্যাবের ভবিষ্যত সংস্করণগুলিতে এটি অনুকরণ করার উপায়গুলি যুক্ত করতে চাইছি৷ আমরা কোনো অতিরিক্ত প্রতিক্রিয়া স্বাগত জানাই. |
| মোবাইলে রিপোর্টিং | ক্রোম মোবাইলে ব্যাকগ্রাউন্ডে চলমান অবস্থায় কি রিপোর্ট পাঠানো হবে? | এই মুহুর্তে, এমনকি মোবাইলেও, Chrome ব্যাকগ্রাউন্ডে থাকলে রিপোর্ট পাঠানো হবে না। এপিআই যখন অ্যান্ড্রয়েড প্রাইভেসি স্যান্ডবক্সের সাথে একীভূত হয় তখন এটি পরিবর্তন হতে পারে। এখানে দেখুন. মনে রাখবেন যে Android গোপনীয়তা স্যান্ডবক্স CMA দ্বারা স্বীকৃত প্রতিশ্রুতির অংশ নয়। |
| ডেটা প্রাপ্যতা | উদ্বেগ যে গোপনীয়তা স্যান্ডবক্স API-এর মাধ্যমে Google-এর ডেটাতে অতিরিক্ত অ্যাক্সেস থাকবে | প্রথমত, Google Ads অ্যাট্রিবিউশন রিপোর্টিং এপিআই বা অন্যান্য গোপনীয়তা স্যান্ডবক্স এপিআই থেকে ডেটাতে কোনো পছন্দের অ্যাক্সেস পায় না। এই সমস্যাটি "ইন্টারঅপারেবিলিটি" এর অধীনে সাধারণ প্রতিক্রিয়া বিভাগেও সম্বোধন করা হয়েছে যা Google-এর প্রতিশ্রুতিগুলির আরও বিশদ অন্তর্ভুক্ত করে৷ দ্বিতীয়ত, বৃহত্তর এবং ছোট সাইটগুলির মধ্যে পার্থক্যের বিষয়ে, Google স্বীকার করে যে শব্দ-ভিত্তিক গোপনীয়তা সুরক্ষাগুলি ছোট ডেটা স্লাইসগুলিতে আরও বেশি প্রভাব ফেলতে পারে। যাইহোক, কিছু সম্ভাব্য প্রশমন রয়েছে: উদাহরণস্বরূপ, দীর্ঘ সময়ের জন্য একত্রিত করার মতো পদ্ধতিগুলি এই সমস্যার সমাধান করবে। তাতে বলা হয়েছে, খুব ছোট ডেটা স্লাইসের (যেমন এক বা দুটি কেনাকাটার) উপর ভিত্তি করে উপসংহারগুলি বিজ্ঞাপনদাতাদের জন্য আদৌ অর্থবহ কিনা তা স্পষ্ট নয়। অরিজিন ট্রায়ালের সময়, Google পরীক্ষকদের বিস্তৃত গোপনীয়তা এবং শব্দের প্যারামিটার নিয়ে পরীক্ষা করার ক্ষমতার সুবিধা নিতে উৎসাহিত করেছে যাতে তারা এই বিষয়ে আরও নির্দিষ্ট প্রতিক্রিয়া দিতে পারে। |
প্রচ্ছন্ন ট্র্যাকিং সীমাবদ্ধ করুন
ব্যবহারকারী-এজেন্ট হ্রাস
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| ওয়েব ইকোসিস্টেম আরও প্রস্তুত না হওয়া পর্যন্ত ব্যবহারকারী-এজেন্ট হ্রাস বিলম্ব করুন | আসন্ন ব্যবহারকারী-এজেন্ট হ্রাস পরিবর্তনের সাথে মানিয়ে নেওয়ার জন্য পর্যাপ্ত সময় নেই। | আমরা "সিএমএর সাথে Google এর মিথস্ক্রিয়া" শিরোনামের বিভাগে "স্টেকহোল্ডার কনসার্নস" এর অধীনে সম্পূর্ণ প্রতিবেদনে এই প্রতিক্রিয়াটি সম্বোধন করি। |
| ওয়েব ইকোসিস্টেম আরও প্রস্তুত না হওয়া পর্যন্ত ব্যবহারকারী-এজেন্ট হ্রাস বিলম্ব করুন | স্ট্রাকচার্ড ইউজার এজেন্ট (SUA) মোতায়েন না হওয়া পর্যন্ত ইউজার-এজেন্ট রিডাকশন রোলআউট বিলম্বিত করার অনুরোধ | Google Ads টিম 2021 সালের অক্টোবরে OpenRTB-তে স্ট্রাকচার্ড ইউজার-এজেন্ট সংযোজনের ( স্পেসিফিকেশন দেখুন) প্রস্তাব করেছিল এবং এটি এপ্রিল 2022-এ প্রকাশিত 2.6 বিশেষ আপডেটে অন্তর্ভুক্ত করা হয়েছিল। আমাদের কাছে কিছু প্রমাণ আছে যে SUA আজ নিয়োজিত এবং উপলব্ধ রয়েছে, যেমনটি Scientia Mobile ব্লগ পোস্ট দ্বারা দেখানো হয়েছে যে কীভাবে একটি SUA তৈরি করতে UA-CH এবং WURFL API ব্যবহার করতে হয়। |
###
ব্যবহারকারী-এজেন্ট ক্লায়েন্ট ইঙ্গিত
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| অন্যান্য অ্যান্টি-কভারট ট্র্যাকিং কৌশলগুলির সাথে UA-CH পরীক্ষা করুন | সমস্ত গোপনীয়তা স্যান্ডবক্স API এবং ফিঙ্গারপ্রিন্টিং কৌশলগুলিকে কীভাবে একটি সামগ্রিক পদ্ধতিতে একসাথে প্রস্তাবিত পরীক্ষা করা যায় তার নির্দেশিকা | আমাদের পরীক্ষার পরিকল্পনাটি স্যান্ডবক্স প্রস্তাবের বাকি অংশের বিপরীতে কিছু অ্যান্টি-ফিঙ্গারপ্রিন্টিং ব্যবস্থা বিকাশের জন্য অ্যাসিঙ্ক্রোনাস টাইমলাইনগুলিকে প্রতিফলিত করার জন্য ডিজাইন করা হয়েছিল। এটি বাস্তবতাকে সম্বোধন করে যে কিছু অ্যান্টি-ফিঙ্গারপ্রিন্টিং ব্যবস্থা (যেমন গোপনীয়তা বাজেট, আইপি সুরক্ষা এবং বাউন্স ট্র্যাকিং মিটিগেশন) সম্পূর্ণরূপে বিকশিত হবে এবং তৃতীয় পক্ষের কুকি অবচয় করার পরেই সাধারণ উপলব্ধতায় লঞ্চের জন্য প্রস্তুত হবে। যদিও সেই আঙ্গুলের ছাপ-বিরোধী ব্যবস্থাগুলি পরিমাণগত পরীক্ষায় অন্তর্ভুক্ত করা হবে না, তারা স্ট্যান্ডস্টিলের সময়ে উপলব্ধ তথ্যের উপর ভিত্তি করে গুণগত মূল্যায়নের বিষয় হবে। |
| (এছাড়াও Q2 এ রিপোর্ট করা হয়েছে) কর্মক্ষমতা | Critical-CH এর মাধ্যমে ইঙ্গিত পাওয়ার বিলম্ব সম্পর্কে উদ্বেগ (প্রথম পৃষ্ঠা লোডে) | নীচে উত্সর্গীকৃত UA-CH বিভাগ দেখুন |
| অপর্যাপ্ত প্রতিক্রিয়া | UA-CH পরিবর্তন সম্পর্কে বাস্তুতন্ত্র থেকে প্রতিক্রিয়া যথেষ্ট নাও হতে পারে, যা ইকোসিস্টেম থেকে সচেতনতার অভাব সম্পর্কে উদ্বেগের দিকে পরিচালিত করে। | আমরা সতর্কতার সাথে রোলআউট নিশ্চিত করার জন্য আমাদের পরিকল্পনাগুলি সক্রিয়ভাবে ভাগ করে নিয়েছি যা বিঘ্ন কম করে। ইউজার-এজেন্ট রিডাকশন এবং UA-CH API-এর পরিকল্পনাগুলি 18শে মার্চ, 2022-এ W3C অ্যান্টি-ফ্রড কমিউনিটি গ্রুপের কাছে এবং 20শে জানুয়ারী, 2022-এ ওয়েব পেমেন্ট ওয়ার্কিং গ্রুপ এবং ওয়েব পেমেন্ট সিকিউরিটি ইন্টারেস্ট গ্রুপ উভয়ের কাছে উপস্থাপন করা হয়েছিল। উপস্থাপনাগুলির সময় বা পরে কোনও উল্লেখযোগ্য উদ্বেগ উত্থাপিত হয়নি। প্রতিক্রিয়া পাওয়ার জন্য Google সক্রিয়ভাবে 100 টিরও বেশি সাইট অপারেটরের সাথে যুক্ত হয়েছে৷ উপরন্তু, Google ইকোসিস্টেম স্টেকহোল্ডারদের প্রতিক্রিয়ার ভিত্তিতে সর্বজনীনভাবে ব্যবহারকারী-এজেন্ট হ্রাসের রোল-আউটের সাথে যোগাযোগ করতে ব্লিঙ্ক-দেভ চ্যানেলগুলি ব্যবহার করেছে। |
| টাইমিং | রোলআউটের সময় এবং শিল্প প্রস্তুতির বিষয়ে উদ্বেগ উত্থাপিত হয়েছে | নীচে উত্সর্গীকৃত UA-CH বিভাগ দেখুন |
| ক্রোম প্ল্যাটফর্ম স্থিতি | UA-CH-এর জন্য ক্রোমেস্ট্যাটাস পৃষ্ঠা আপডেট করার অনুরোধ করা হয়েছে | ক্রোমেস্ট্যাটাস এন্ট্রি 19 ডিসেম্বর "মিশ্র সংকেত" এ আপডেট করা হয়েছিল। |
আইপি সুরক্ষা (পূর্বে Gnatcatcher)
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| অপ্ট ইন বা অপ্ট আউট | আইপি ঠিকানা গোপনীয়তা অপ্ট ইন বা অপ্ট আউট? | আমাদের লক্ষ্য হল সমস্ত ব্যবহারকারীদের আইপি সুরক্ষা প্রদান করা। সেই লক্ষ্যটি মাথায় রেখে, আমরা বর্তমানে আইপি সুরক্ষার জন্য ব্যবহারকারীর পছন্দের বিকল্পগুলি মূল্যায়ন করছি৷ |
| প্রথম পক্ষের ডেটার জন্য আইপি ঠিকানা ব্যবহারের ক্ষেত্রে | আইপি সুরক্ষার পরে প্রথম পক্ষের ডোমেন জুড়ে ব্যবহারকারীর যাত্রা একসাথে সেলাই করতে আইপি ঠিকানাগুলি ব্যবহার করা কি সম্ভব? | পূর্বে প্রকাশিত হিসাবে, আইপি সুরক্ষা প্রাথমিকভাবে তৃতীয় পক্ষের প্রসঙ্গে ট্র্যাকিংয়ের দিকে মনোনিবেশ করবে, যার অর্থ প্রথম পক্ষের ডোমেনগুলি প্রভাবিত হবে না। |
| বিজ্ঞাপন প্রযুক্তি ব্যবহারের ক্ষেত্রে | কীভাবে সংস্থাগুলি আইপি সুরক্ষা সহ বিরোধী বিরোধী ব্যবস্থা সেট আপ করতে পারে? | আমরা আজকের ওয়েবে বিরোধী-বিরোধী প্রচেষ্টার সংকেত হিসাবে আইপি ঠিকানার গুরুত্বকে স্বীকৃতি দিই। সিএমএর প্রতি আমাদের প্রতিশ্রুতির অংশ হিসাবে (অনুচ্ছেদ 20), আমরা বলেছি যে আমরা ওয়েবসাইটগুলির স্প্যাম অ্যান্টি-স্প্যাম এবং বিরোধী বিরোধী প্রচেষ্টা চালানোর ক্ষমতা সমর্থন করার জন্য যুক্তিসঙ্গত প্রচেষ্টা না করে আইপি সুরক্ষা বাস্তবায়ন করব না। আমাদের শীর্ষস্থানীয় অগ্রাধিকারগুলির মধ্যে একটি হ'ল আইপি সুরক্ষা কীভাবে অ্যান্টি-ফ্রেড ব্যবহার করে এবং সনাক্তকরণের ক্ষমতাগুলি প্রভাবিত করে তা বোঝা, যাতে আমরা গোপনীয়তা সংরক্ষণে আরও বিনিয়োগ করতে পারি যা সংস্থাগুলি ওয়েব সুরক্ষা সংরক্ষণে সহায়তা করে। সময়ের সাথে সংকেত পরিবর্তিত হওয়ার সাথে সাথে আমরা সুরক্ষা এবং বিরোধী-বিরোধী সংস্থাগুলির প্রয়োজনগুলিকে সমর্থন করার লক্ষ্যে নতুন প্রস্তাবগুলিতে প্রতিক্রিয়া এবং ইনপুটকে উত্সাহিত করি । |
| জালিয়াতি এবং অপব্যবহার | আইপি সুরক্ষা কি পরিষেবা অস্বীকার (ডস) সুরক্ষা অন্তর্ভুক্ত? | ওয়েবকে সুরক্ষিত রাখার সময় আমরা গোপনীয়তার উন্নতির জন্য প্রতিশ্রুতিবদ্ধ, এবং অস্বীকার-পরিষেবা আক্রমণ থেকে রক্ষা করা একটি গুরুত্বপূর্ণ অনর্থক বিরোধী ব্যবহারের ক্ষেত্রে ডিজাইন করার জন্য। আমরা আশা করি আইপি সুরক্ষা নিজেই এবং নতুন অ্যান্টি-অপব্যবহার সমাধানের মাধ্যমে উভয়ই ডস সুরক্ষাগুলিতে প্রভাব হ্রাস করব। যেহেতু আইপি সুরক্ষা প্রাথমিকভাবে তৃতীয় পক্ষের এম্বেড থাকা পরিষেবাগুলিতে মনোনিবেশ করা হয়েছে, কিছু স্টেকহোল্ডার ইঙ্গিত করেছেন যে এটি প্রথম পক্ষের সাইটগুলির জন্য ডস সুরক্ষায় সীমিত প্রভাব ফেলতে হবে। তবে আমরা ডস ব্যবহারের ক্ষেত্রে, বিশেষত তৃতীয় পক্ষের এম্বেড থাকা পরিষেবাগুলিতে ঝুঁকি নির্ধারণের জন্য জনসাধারণের প্রতিক্রিয়া জিজ্ঞাসা করতে থাকি । সমান্তরালভাবে, আমরা অপব্যবহার-প্রতিক্রিয়া এবং ক্লায়েন্ট-ব্লকিং প্রক্রিয়াগুলি অন্বেষণ করছি যা ব্যবহারকারীকে সনাক্ত না করে কোনও স্প্যামি ব্যবহারকারীকে অবরুদ্ধ করতে কোনও সাইট বা পরিষেবা সক্ষম করে। |
| বিষয়বস্তু ফিল্টারিং | আইপি সুরক্ষা সহ সামগ্রী ফিল্টারিং | ফিল্টারিং সামগ্রী এবং ব্যবহারকারীর অভিজ্ঞতা কাস্টমাইজ করার ক্ষেত্রে বিভিন্ন সংস্থার বিভিন্ন প্রয়োজন রয়েছে। এই জাতীয় অনেকগুলি ব্যবহারের ক্ষেত্রে বর্তমানে আইপি ঠিকানার উপর নির্ভর করে না এবং তাই আইপি সুরক্ষা দ্বারা প্রভাবিত হওয়া উচিত। উদাহরণস্বরূপ, কোনও প্রকাশক এর বিষয়বস্তু তৈরি করতে এবং আরও বেশি ব্যস্ততা চালানোর জন্য খুঁজছেন এমন একজন প্রকাশকের সাথে ব্যবহারকারীর আগ্রহ এবং পূর্ববর্তী মিথস্ক্রিয়া বোঝার জন্য প্রথম পক্ষের কুকিজ বা তৃতীয় পক্ষের পার্টিশনযুক্ত কুকিজ (চিপস) ব্যবহার করতে পারে। বা সঠিক ব্যবহারকারীর কাছে সঠিক বিজ্ঞাপন সরবরাহ করার দিকে মনোনিবেশ করা কোনও বিজ্ঞাপন প্রযুক্তির অংশীদার ফ্লেজ এবং বিষয়গুলি অন্তর্ভুক্ত করতে পারে, উদাহরণস্বরূপ, তৃতীয় পক্ষের কুকিজ বা অন্যান্য ক্রস-সাইট ট্র্যাকিং প্রযুক্তিগুলির সাথে আজ যেমন করে তারা একই বিজ্ঞাপনের ফলাফলগুলি সরবরাহ করতে পারে। আমরা আইপি সুরক্ষায় নতুন গোপনীয়তা-সংরক্ষণের ক্ষমতাগুলি যেমন মোটা জিওলোকেশন, আরও বিষয়বস্তু ফিল্টারিং সমর্থন করার জন্য যেখানে বিদ্যমান ব্যবস্থাগুলি অপর্যাপ্ত হতে পারে সেখানে আরও সমর্থন করার জন্যও অনুসন্ধান করছি। আমরা সামগ্রী ফিল্টারিং ব্যবহারের ক্ষেত্রে অতিরিক্ত প্রতিক্রিয়া স্বাগত জানাই যা আইপি সুরক্ষা দ্বারা প্রভাবিত হতে পারে। |
| (Q3 এও রিপোর্ট করা হয়েছে) জিওলোকেশন ব্যবহারের ক্ষেত্রে | আইপি সুরক্ষা ভবিষ্যতে বৈধ ভূতাত্ত্বিক ব্যবহারের কেসগুলিকে কাজ করা থেকে বিরত রাখতে পারে, যেমন ভূ -কেন্দ্রের উপর ভিত্তি করে সামগ্রী ব্যক্তিগতকরণ। | প্রশ্ন 4 আপডেট: ক্রোম আইপি ঠিকানাগুলির জন্য বৈধ ব্যবহারের ক্ষেত্রে সমর্থন অব্যাহত রাখে তা নিশ্চিত করার জন্য আমরা স্টেকহোল্ডারদের সাথে কাজ করছি। আমরা এখানে আইপি জিওলোকেশন গ্রানুলারিটির বিষয়ে বাস্তুতন্ত্রের প্রতিক্রিয়া চাইছি। |
গোপনীয়তা বাজেট
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| পরিষ্কার ডকুমেন্টেশন | আরও উদাহরণ তাই স্টেকহোল্ডাররা অনুমান করতে পারে যে গোপনীয়তা বাজেট কার্যকর হওয়ার পরে কীভাবে জিনিসগুলি সীমাবদ্ধ হতে পারে | গোপনীয়তা বাজেটের প্রস্তাবটি এখনও সক্রিয় আলোচনায় রয়েছে এবং কোনও ব্রাউজার দ্বারা প্রয়োগ করা হয়নি। স্কেলড প্রাপ্যতার প্রাথমিকতম তারিখটি যখন গোপনীয়তার বাজেট প্রয়োগ করা যেতে পারে তখন প্রাথমিকতম তারিখের প্রতিনিধিত্ব করে। ২০২৪ সালে তৃতীয় পক্ষের কুকিজ অপসারণের আগে এটি ঘটবে না। এই মুহুর্তে ভাগ করার জন্য আমাদের কোনও অতিরিক্ত ডকুমেন্টেশন নেই। প্রস্তাবটি আরও চূড়ান্ত হয়ে গেলে আমরা অতিরিক্ত বিবরণ ভাগ করে নেব। এরই মধ্যে, আমরা প্রস্তাবের বিকাশে সহায়তা করতে পারে এমন কোনও প্রতিক্রিয়া ভাগ করে নেওয়ার জন্য স্টেকহোল্ডারদের স্বাগত জানাই। |
ক্রস-সাইট গোপনীয়তা সীমানা শক্তিশালী করুন
প্রথম পক্ষের সেট
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| (কিউ 3 এও প্রতিবেদন করা হয়েছে) ডোমেন সীমা | সম্পর্কিত ডোমেনের সংখ্যা প্রসারিত করার অনুরোধ | প্রশ্ন 4 আপডেট: আমরা স্থানীয় পরীক্ষার জন্য এফপিএস প্রকাশ করেছি, গিটহাবের উপর একটি মক সেট জমা দেওয়ার প্রক্রিয়া এবং স্থানীয়ভাবে আরএসএ এবং আরএসএএফআর পরীক্ষা করার জন্য একটি পতাকা সহ। সম্পর্কিত সাবসেটের ব্যবহারের ক্ষেত্রে সম্পর্কে প্রশ্নগুলি সম্বোধন করতে আমরা এফপিএসের বিকাশকারীদের জন্য দুটি উন্মুক্ত সভাও হোস্ট করেছি। আমরা বিকাশকারীদের তাদের ব্যবহারের ক্ষেত্রে এফপিএসের ব্যবহারযোগ্যতার উপর কীভাবে প্রভাব ফেলবে সে সম্পর্কে প্রতিক্রিয়া জানাতে এফপিএস কার্যকারিতা পরীক্ষা করতে উত্সাহিত করি। আমরা ডাব্লুআইসিজি কলগুলিতে স্পষ্ট করে দিয়েছি যে ক্রোম ব্যবহারকারীদের গোপনীয়তার আগ্রহকেও বিবেচনা করে এমন একটি ব্যবহারযোগ্য সমাধান সরবরাহ করতে প্রতিশ্রুতিবদ্ধ। এই শিরাতে, আমরা ডোমেন সীমা দ্বারা প্রভাবিত হতে পারে এমন নির্দিষ্ট ব্যবহারের ক্ষেত্রে সম্প্রদায়ের কাছ থেকে প্রতিক্রিয়ার প্রশংসা করব, যাতে দলটি ব্যবহারকারীর গোপনীয়তা রক্ষা করার সময় এই ব্যবহারের ক্ষেত্রে সমাধান করার উপায়গুলি বিবেচনা করতে পারে। |
| অপব্যবহার প্রশমন ব্যবস্থা সম্পর্কে আরও তথ্যের জন্য অনুরোধ | যদি তারা কোনও সেটে কোনও ডোমেন যুক্ত করা হয় তবে কী হবে? | আমরা এখানে 2 ডিসেম্বর, 2022 এ প্রথম পক্ষের সেটগুলির জন্য জমা দেওয়ার নির্দেশিকা প্রকাশ করেছি। জমা দেওয়ার নির্দেশিকাগুলিতে যেমন ব্যাখ্যা করা হয়েছে, যে কোনও সেট পরিবর্তন ব্যবস্থাপনার মালিকানা সম্পর্কিত বৈধতা সহ গিটহাবের উপর একটি বৈধতা প্রক্রিয়া অনুসরণ করা হবে এবং সম্মান করা হবে, যা এই ঝুঁকি হ্রাস করতে পারে। |
| অপব্যবহার প্রশমন | উদ্বেগ যে প্রথম পক্ষের সেট ফর্মেশনগুলি কাজে লাগানো যেতে পারে | আমরা সাবসেট ধরণের জন্য প্রযুক্তিগত চেকগুলি প্রসারিত করার উপায়গুলি খুঁজছি এবং সক্রিয়ভাবে এখানে সম্প্রদায়ের কাছ থেকে অতিরিক্ত ইনপুট চাইছি। |
| বিজ্ঞাপনগুলি কেস ব্যবহার করে | প্রথম পক্ষের সেটগুলি বিজ্ঞাপন টার্গেটকে সমর্থন করার জন্য ব্যবহার করা উচিত কিনা তা নিয়ে প্রশ্নগুলি | আমরা প্রথম পক্ষের সেটগুলির জন্য ব্যবহারের ক্ষেত্রে লক্ষ্যমাত্রার বিজ্ঞাপনগুলি সমর্থন করার চেষ্টা করছি না এবং আমরা এই জাতীয় ব্যবহারের ক্ষেত্রে উপলব্ধ বিজ্ঞাপনগুলি এপিআইগুলি ব্যবহার করার পরামর্শ দিই। |
| (কিউ 3 এও প্রতিবেদন করা হয়েছে) নীতি | উদ্বেগ যে এফপিএস "প্রযোজ্য ডেটা সুরক্ষা আইন" সম্পর্কিত সিএমএ প্রতিশ্রুতিগুলির সাথে সামঞ্জস্যপূর্ণ নয়, ভিত্তিতে যে জিডিপিআর একটি সেটে সাইটের সংখ্যার উপর সীমা চাপিয়ে দেয় না যখন এফপিএস 3 এর সীমা কল্পনা করে | আমাদের প্রতিক্রিয়া Q3 থেকে অপরিবর্তিত: "গুগল গোপনীয়তা স্যান্ডবক্স প্রস্তাবগুলি এমনভাবে ডিজাইন ও বাস্তবায়নের জন্য সিএমএর কাছে প্রতিশ্রুতিবদ্ধ যা গুগলের নিজস্ব ব্যবসায়কে স্ব-পছন্দসই করে প্রতিযোগিতা বিকৃত করে না, এবং ডিজিটাল বিজ্ঞাপন, প্রকাশক এবং বিজ্ঞাপনদাতাদের প্রতিযোগিতার উপর প্রভাবের পাশাপাশি গোপনীয়তার ফলাফলের উপর প্রভাব এবং প্রযোজ্য ডেটা সুরক্ষা অধ্যক্ষের সাথে সম্মতি প্রয়োগের ক্ষেত্রে প্রযোজ্য তথ্য সংরক্ষণের উপর নির্ভর করে। আমাদের কাজটি এই প্রতিশ্রুতিগুলি মেনে চলে তা নিশ্চিত করার জন্য আমরা সিএমএর সাথে ঘনিষ্ঠভাবে কাজ চালিয়ে যাচ্ছি। " |
| বিকল্প প্রস্তাব | জিডিপিআর বৈধ সেট | "জিডিপিআর বৈধতাযুক্ত সেটগুলি গ্রহণ করার প্রস্তাবের বিষয়ে বাস্তুতন্ত্রের দ্বারা সরবরাহিত প্রতিক্রিয়া ছাড়াও, ক্রোমের এই বিকল্প প্রস্তাবের নিম্নলিখিত সীমাবদ্ধতা সম্পর্কে উদ্বেগ রয়েছে:
যেহেতু এই বিকল্পটি উত্থাপিত হয়েছিল, ক্রোম প্রথম পক্ষের সেট প্রস্তাবগুলি আপডেট করেছে এবং নতুন সেট তৈরির জন্য জমা দেওয়ার নির্দেশিকা প্রকাশ করেছে। |
বেড়া ফ্রেম API
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| ওটি চলাকালীন বেড়া ফ্রেমের বিধিনিষেধ | মূল পরীক্ষার সময়কালের জন্য বেড়া ফ্রেমের চারপাশে বর্তমান বিধিনিষেধগুলি কী কী? | আমরা বিধিনিষেধ এবং বাস্তবায়নের স্থিতিতে ডকুমেন্টেশনে কাজ করছি এবং 2023 এর মধ্যে এটি ভাগ করে নেওয়ার পরিকল্পনা করছি। |
| একক বেড়া ফ্রেমে একাধিক বিজ্ঞাপন | একটি নিলামে একটি বেড়া ফ্রেমে একাধিক বিজ্ঞাপনদাতাদের প্রদর্শন করার অনুরোধ | বর্তমানে, এই অনুরোধটি সক্রিয়ভাবে বিকাশ করা হচ্ছে না, তবে বাস্তুতন্ত্রের খেলোয়াড়রা বৈশিষ্ট্যটিকে গুরুত্বপূর্ণ মনে করলে আমরা অতিরিক্ত প্রতিক্রিয়া স্বাগত জানাই। |
| ওয়েব বান্ডিল | বেড়া ফ্রেম সহ ওয়েব বান্ডিলগুলির জন্য প্রয়োজনীয় প্রয়োজনীয়তা এবং সমর্থনগুলি কী কী? | ভবিষ্যতে এটি প্রয়োজনীয়তা হবে কিনা সে সম্পর্কে আমাদের বর্তমানে কোনও আপডেট নেই। যে কোনও পরিবর্তন আগেই ঘোষণা করা হবে এবং তৃতীয় পক্ষের কুকির অবমূল্যায়নের আগে প্রয়োগ করা হবে না। বর্তমান স্থিতির জন্য দয়া করে এই ব্যাখ্যাকারী দেখুন। |
শেয়ার্ড স্টোরেজ API
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| বিজ্ঞাপন প্রযুক্তির জন্য ভাগ করা স্টোরেজ | বিজ্ঞাপন প্রযুক্তি ব্যবহারের ক্ষেত্রে ভাগ করে নেওয়া স্টোরেজ ব্যবহারকে ঘিরে অনিশ্চয়তা | ভাগ করা স্টোরেজ এবং বেসরকারী সমষ্টি এপিআই বিভিন্ন ধরণের পরিমাপের উদ্দেশ্যে ব্যবহার করা যেতে পারে যা ক্রস-সাইট স্টোরেজ পরিমাপের প্রয়োজন। কিছু উদাহরণ এখানে তালিকাভুক্ত করা হয়েছে। আমরা বিজ্ঞাপন ব্যবহারের ক্ষেত্রে প্রধান ইন্টিগ্রেটার হিসাবে ডিএসপি এবং পরিমাপ সমাধান সরবরাহকারীদের পূর্বাভাস দিচ্ছি। |
চিপস
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| (কিউ 3 এও রিপোর্ট করা হয়েছে) বিভাজনযুক্ত প্রয়োজনীয়তা | প্রথম পক্ষের কুকিগুলিতে "বিভাজনযুক্ত" বৈশিষ্ট্যের জন্য সুস্পষ্ট আচরণের প্রয়োজনীয়তা যুক্ত করুন। | প্রশ্ন 4 আপডেট: গিটহাব এবং গোপনীয়তার কলগুলিতে আলোচনার পরে, আমরা যে আচরণটি সারিবদ্ধ করেছি তা হ'ল প্রথম পক্ষের কুকিগুলিতে সেট করা পার্টিশনযুক্ত কুকিজ (ক, ক) এর একটি পার্টিশন কী ব্যবহার করবে যেখানে "এ" শীর্ষ-স্তরের সাইট। আমরা এই আচরণটি ব্যাখ্যাকারী এবং নির্দিষ্টকরণের উপর নথিভুক্ত করব। |
| কুকি ব্যবস্থাপনা | প্রথম পক্ষ বা তৃতীয় পক্ষের কুকিজ পরিচালনা/পরিচালনা করার জন্য কি সরঞ্জাম রয়েছে? | ক্রোম ডিভটুলস এবং নেটলগ তৃতীয় পক্ষের কুকি ব্লকিং সক্ষম করে সাইটগুলি পরীক্ষা করতে ব্যবহার করা যেতে পারে। ব্যবহারকারী কনফিগারেশনের কারণে কুকিগুলি অবরুদ্ধ করা হলে উভয় সরঞ্জামই রিপোর্ট করে। আমরা কী ধরণের অতিরিক্ত নিরীক্ষণ ওয়েবসাইটগুলি দেখতে চাইবে সে সম্পর্কে প্রতিক্রিয়া স্বাগত জানাই। |
ফেডসিএম
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| আইডিপির জন্য একটি সেশনের অনুমতি দেওয়ার জন্য আরপি জ্ঞান প্রয়োজন | যখন কোনও ব্যবহারকারী দুটি ভিন্ন আরপি থেকে ফাইড আইডিপিতে লগ ইন করার চেষ্টা করছেন তখন ইস্যু করুন | আমরা এই ইস্যুটির সম্ভাব্য সমাধানগুলি নিয়ে আলোচনা করছি। |
| ইন্টারঅপারেবিলিটি | ফেডসিএম এর প্রভাব সম্পর্কিত উদ্বেগগুলি ব্যবহারকারী এবং তারা ফেডসিএম ব্যবহার করে লগ ইন করা ওয়েবসাইটগুলির মধ্যে সম্পর্ক এবং ওয়েবসাইটগুলির মধ্যে "আন্তঃব্যবহারযোগ্যতা" | ফেডসিএমের লক্ষ্য হ'ল ফেডারেটেড-পরিচয় পরিষেবাগুলিকে সমর্থন করা চালিয়ে যাওয়া যা বর্তমানে তৃতীয় পক্ষের কুকিজের উপর নির্ভর করে তৃতীয় পক্ষের কুকিজ ক্রোম থেকে সরানো হয়। আমরা আশা করি যে ফেডসিএম এই জাতীয় পরিষেবার জন্য কেবল একটি বিকল্প উপলব্ধ হবে; পরিচয় সরবরাহকারী (আইডিপি) এবং নির্ভরকারী দলগুলি (আরপিএস) অন্যান্য প্রযুক্তি ব্যবহার করতে বিনামূল্যে যা তাদের প্রয়োজন অনুসারে আরও ভাল মানায়। এটি প্রদর্শিত হয় যে ব্যবহারকারী-আরপি সম্পর্ক এবং "আন্তঃব্যবহারযোগ্যতা" সম্পর্কিত উদ্বেগগুলি FEDCM প্রস্তাবের ভুল বোঝাবুঝির কাছে। ফেডসিএম কোনও আরপি -র সাথে কোন তথ্য ভাগ করে নেওয়ার সিদ্ধান্ত নিতে এবং কোন আকারে, ব্যবহারকারী একবার সেই আরপি -র সাইটে সাইন ইন করতে বেছে নিলে তা সিদ্ধান্ত নিতে আইডিপিতে ছেড়ে যায়। ফেডসিএমের আইডিপিগুলির প্রয়োজন নেই "প্রতিটি [আরপি] যার সাথে ব্যবহারকারী প্রমাণীকরণ করে তার জন্য একটি অনন্য ছদ্মনাম সনাক্তকারী তৈরি করতে"। বরং, ফেডসিএম প্রতিটি আইডিপির জন্য ব্যবহারকারীর প্রকৃত শনাক্তকারী, সেই শনাক্তকারীর প্রতি সাইট সংস্করণ বা এই তথ্যের অন্য কোনও সংস্করণ ভাগ করে নেওয়ার জন্য এটি বেছে নেওয়ার জন্য উন্মুক্ত। (ফেডসিএম স্পেসিফিকেশন এপিআইয়ের সাথে সম্পর্কিত গোপনীয়তা ঝুঁকি হিসাবে ক্রস-সাইট পারস্পরিক সম্পর্ককে চিহ্নিত করে এবং নির্দেশিত (প্রতি সাইট) সনাক্তকারীদের একটি সম্ভাব্য প্রশমন হিসাবে আলোচনা করে। তবে, নির্দেশিত সনাক্তকারী ব্যবহার করবেন কিনা তা আইডিপিগুলিতে রেখে দেওয়া হয়েছে, ব্রাউজার দ্বারা আরোপিত নয়।) ফেডসিএম ইতিমধ্যে পরিচয়ের ক্ষেত্রে ব্যবহারকারীর পছন্দের জন্য সরবরাহ করে। উদাহরণস্বরূপ, যদি কোনও ব্যবহারকারীর একই আইডিপি (যেমন, একটি কাজের প্রোফাইল এবং একটি ব্যক্তিগত প্রোফাইল) এর সাথে একাধিক পরিচয় থাকে তবে ফেডসিএম ব্যবহারকারীকে আরপির সাইটে লগ ইন করতে কোনটি ব্যবহার করতে চান তা নির্বাচন করার একটি উপায় সরবরাহ করে। এর বাইরে, প্রতিটি আরপি নিজের জন্য সিদ্ধান্ত নেয় যে কোন আইডিপিগুলি তার সাইটে সমর্থন করবে। এই সিদ্ধান্তের একটি দিক হ'ল কোনও আইডিপি নির্ভর করে এমন প্রক্রিয়াটি বিবেচনা করা যা সে ফেডসিএম বা অন্য কোনও প্রযুক্তি। আবার, ব্রাউজারটি আরপিএস বা আইডিপিগুলির জন্য এই পছন্দগুলি নির্দেশ করে না। |
স্প্যাম এবং জালিয়াতির সাথে লড়াই করুন
ব্যক্তিগত রাষ্ট্র টোকেন এপিআই
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| হ্যান্ডলিং বট | ইস্যুকারী যদি আবিষ্কার করেন যে বেসরকারী স্টেট টোকেনগুলি বটকে জারি করা হয়েছে তবে কী হবে? | দীর্ঘ সময়ের জন্য বাস্তুতন্ত্রের মধ্যে থাকা থেকে বটকে জারি করা টোকেনগুলি এড়াতে, ইস্যুকারীদের নিয়মিত টোকেনগুলিতে সাইন ইন করার জন্য যে কীগুলি ব্যবহার করা হয় সেগুলি ঘোরানো উচিত যাতে সম্ভাব্য ভাঙা জারি করা যুক্তির মেয়াদে জারি করা পুরানো টোকেনগুলি আপডেট হওয়া জারি যুক্তির সাথে নতুন টোকেনগুলি খালাস করে। |
| একই সাইট ফর্ম সাবমিশন | বেসরকারী স্টেট টোকেনগুলি কি একই সাইট ফর্ম সাবমিশনগুলির জন্য ব্যবহার করা যেতে পারে যা পূর্ণ পৃষ্ঠা নেভিগেশন (অর্থাত্ সামগ্রী-প্রকার: অ্যাপ্লিকেশন/এক্স-ডাব্লুডাব্লুডাব্লু-ফর্ম-আর্লেনকোডেড) জড়িত থাকে যা ফেচ/এক্সএমএলএইচটিটিপিআরকোয়েস্ট এপিআইগুলির অনুরোধের পরিবর্তে? | এটি বর্তমানে বেসরকারী স্টেট টোকেনের প্রথম সংস্করণে সমর্থিত নয়। আমরা যদি এই ব্যবহারের ক্ষেত্রে শক্তিশালী চাহিদা থাকে তবে আমরা বাস্তুতন্ত্রের কাছ থেকে প্রতিক্রিয়া স্বাগত জানাই । |
| সার্ভার-সাইড যাচাইকরণ | বেসরকারী স্টেট টোকেনগুলি সার্ভার সাইড যাচাই করা যায় কিনা তা নিয়ে প্রশ্নগুলি | টোকেনগুলি ইস্যুকারীদের বিরুদ্ধে খালাস করা হয়, এবং তারপরে ইস্যুকারী একটি খালাস রেকর্ড তৈরি করে যা টোকেন নিজেই থাকতে পারে বা টোকেন থেকে প্রাপ্ত কিছু স্বাক্ষরিত মান থাকতে পারে, সার্ভারগুলি টোকেনের সত্যতা যাচাই করতে সেই ছাড়পত্র রেকর্ডটি ব্যবহার করতে পারে এবং আমরা আশা করি যে তাদের হ্রাসের বিবরণগুলির জন্য বিভিন্ন মানদণ্ডের জন্য বিভিন্ন মানদণ্ডে আসবে। |
গোপনীয়তা স্যান্ডবক্স প্রস্তাব এবং ক্রোমের প্রতিক্রিয়াতে প্রাপ্ত বাস্তুতন্ত্রের প্রতিক্রিয়া সংক্ষিপ্ত করে 2022 কিউ 4 এর ত্রৈমাসিক প্রতিবেদন।
সিএমএর প্রতিশ্রুতিবদ্ধতার অংশ হিসাবে, গুগল তার গোপনীয়তা স্যান্ডবক্স প্রস্তাবগুলির জন্য স্টেকহোল্ডার ব্যস্ততা প্রক্রিয়া সম্পর্কে ত্রৈমাসিক প্রতিবেদনগুলি প্রকাশ্যে সরবরাহ করতে সম্মত হয়েছে ( প্রতিশ্রুতিগুলির 12 এবং 17 (সি) (ii) অনুচ্ছেদ দেখুন)। এই গোপনীয়তা স্যান্ডবক্স প্রতিক্রিয়া সংক্ষিপ্ত প্রতিবেদনগুলি প্রতিক্রিয়া ওভারভিউতে তালিকাভুক্ত বিভিন্ন উত্স থেকে ক্রোম দ্বারা প্রাপ্ত প্রতিক্রিয়া একত্রিত করে তৈরি করা হয়, তবে সীমাবদ্ধ নয়: গিটহাব ইস্যুগুলি, প্রাইভেস্যান্ডবক্স.কম এ উপলব্ধ করা প্রতিক্রিয়া ফর্ম, শিল্পের স্টেকহোল্ডারদের সাথে সভা এবং ওয়েব স্ট্যান্ডার্ড ফোরামগুলি। ক্রোম ইকোসিস্টেম থেকে প্রাপ্ত প্রতিক্রিয়াটিকে স্বাগত জানায় এবং নকশার সিদ্ধান্তগুলিতে শিক্ষাকে সংহত করার জন্য সক্রিয়ভাবে উপায়গুলি অন্বেষণ করছে।
প্রতিক্রিয়া থিমগুলি প্রতি এপিআই প্রতি প্রসার দ্বারা র্যাঙ্ক করা হয়। এটি ক্রোম টিম একটি প্রদত্ত থিমের আশেপাশে যে পরিমাণ প্রতিক্রিয়া পেয়েছে এবং পরিমাণের অবতরণ ক্রমে সংগঠিত করে তা সমষ্টি গ্রহণ করে এটি করা হয়। সাধারণ প্রতিক্রিয়া থিমগুলি জনসভা (ডাব্লু 3 সি, প্যাটসিজি, আইইটিএফ), সরাসরি প্রতিক্রিয়া, গিটহাব এবং সাধারণভাবে জিজ্ঞাসিত প্রশ্নাবলীর মাধ্যমে গুগলের অভ্যন্তরীণ দল এবং পাবলিক ফর্মগুলির মাধ্যমে প্রকাশিত প্রশ্নগুলি পর্যালোচনা করে চিহ্নিত করা হয়েছিল।
আরও সুনির্দিষ্টভাবে, ওয়েব স্ট্যান্ডার্ড বডি মিটিংগুলির জন্য সভার মিনিটগুলি পর্যালোচনা করা হয়েছিল এবং সরাসরি প্রতিক্রিয়ার জন্য, গুগলের 1: 1 স্টেকহোল্ডার সভাগুলির রেকর্ড, পৃথক ইঞ্জিনিয়ারদের দ্বারা প্রাপ্ত ইমেলগুলি, এপিআই মেলিং তালিকা এবং পাবলিক ফিডব্যাক ফর্মটি বিবেচনা করা হয়েছিল। গুগল তারপরে প্রতিটি এপিআইয়ের সাথে উদ্ভূত থিমগুলির আপেক্ষিক প্রসার নির্ধারণের জন্য এই বিভিন্ন আউটরিচ ক্রিয়াকলাপের সাথে জড়িত দলগুলির মধ্যে সমন্বয় করে।
প্রতিক্রিয়ার প্রতি ক্রোমের প্রতিক্রিয়াগুলির ব্যাখ্যাগুলি প্রকাশিত এফএকিউগুলি থেকে, স্টেকহোল্ডারদের দ্বারা উত্থাপিত ইস্যুতে করা প্রকৃত প্রতিক্রিয়াগুলি এবং এই পাবলিক রিপোর্টিং অনুশীলনের উদ্দেশ্যে বিশেষত একটি অবস্থান নির্ধারণ করে তৈরি করা হয়েছিল। উন্নয়ন এবং পরীক্ষার বর্তমান ফোকাসকে প্রতিফলিত করে, প্রশ্নগুলি এবং প্রতিক্রিয়াগুলি বিশেষত বিষয়গুলি, ফ্লেজ এবং অ্যাট্রিবিউশন রিপোর্টিং এপিআইগুলির ক্ষেত্রে প্রাপ্ত হয়েছিল।
বর্তমান প্রতিবেদনের সময় শেষ হওয়ার পরে প্রাপ্ত প্রতিক্রিয়া এখনও বিবেচিত ক্রোম প্রতিক্রিয়া নাও থাকতে পারে।
সংক্ষিপ্ত শব্দগুলির শব্দকোষ
- চিপস
- কুকিজ স্বাধীন বিভাজনিত রাষ্ট্র রয়েছে
- ডিএসপি
- ডিমান্ড-সাইড প্ল্যাটফর্ম
- ফেডসিএম
- ফেডারেটেড শংসাপত্র ব্যবস্থাপনা
- FPS
- প্রথম পার্টি সেট
- আইএবি
- ইন্টারেক্টিভ বিজ্ঞাপন ব্যুরো
- আইডিপি
- পরিচয় প্রদানকারী
- আইইটিএফ
- ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স
- আইপি
- ইন্টারনেট প্রোটোকল ঠিকানা
- ওপেনআরটিবি
- রিয়েল-টাইম বিডিং
- OT
- অরিজিন ট্রায়াল
- PATCG
- ব্যক্তিগত বিজ্ঞাপন প্রযুক্তি সম্প্রদায় গোষ্ঠী
- আরপি
- ভরসা পার্টি
- এসএসপি
- সাপ্লাই-সাইড প্ল্যাটফর্ম
- TEE
- বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট
- UA
- ব্যবহারকারী এজেন্ট স্ট্রিং
- ইউএ-সিএইচ
- ব্যবহারকারী-এজেন্ট ক্লায়েন্ট ইঙ্গিত
- W3C
- ওয়ার্ল্ড ওয়াইড ওয়েব কনসোর্টিয়াম
- ডব্লিউআইপিবি
- ইচ্ছাকৃত আইপি অন্ধত্ব
সাধারণ প্রতিক্রিয়া, কোনও নির্দিষ্ট এপিআই/প্রযুক্তি নেই
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| (Q3 এও রিপোর্ট করা হয়েছে) বিভিন্ন ধরণের স্টেকহোল্ডারদের জন্য উপযোগিতা | উদ্বেগ যে গোপনীয়তা স্যান্ডবক্স প্রযুক্তিগুলি বৃহত্তর বিকাশকারীদের পক্ষে এবং সেই কুলুঙ্গি (ছোট) সাইটগুলি জেনেরিক (বৃহত্তর) সাইটের চেয়ে বেশি অবদান রাখে | আমাদের প্রতিক্রিয়া Q3 থেকে অপরিবর্তিত: "গুগল সিএমএর কাছে গোপনীয়তা স্যান্ডবক্স প্রস্তাবগুলি এমনভাবে ডিজাইন ও বাস্তবায়নের প্রতিশ্রুতিবদ্ধ করেছে যা গুগলের নিজস্ব ব্যবসায়কে স্ব-পছন্দসই করে প্রতিযোগিতা বিকৃত করে না, এবং ডিজিটাল বিজ্ঞাপনে প্রতিযোগিতায় এবং প্রকাশক এবং বিজ্ঞাপনদাতাদের উপর তাদের আকার নির্বিশেষে বিবেচনা করার জন্য, আমরা সিএমএর সাথে নিবিড়ভাবে কাজ চালিয়ে যাচ্ছি যাতে আমাদের কাজগুলি এই প্রতিশ্রুতিগুলির সাথে সম্মতি জানায়। গোপনীয়তা স্যান্ডবক্সের পরীক্ষা করার সাথে সাথে আমরা যে মূল প্রশ্নগুলি মূল্যায়ন করব তার মধ্যে একটি হ'ল নতুন প্রযুক্তিগুলি বিভিন্ন ধরণের স্টেকহোল্ডারদের জন্য কীভাবে সম্পাদন করে। প্রতিক্রিয়া এই ক্ষেত্রে গুরুত্বপূর্ণ, বিশেষত নির্দিষ্ট এবং কার্যক্ষম প্রতিক্রিয়া যা আমাদের প্রযুক্তিগত নকশাগুলি আরও উন্নত করতে সহায়তা করতে পারে। আমরা পরিমাণগত পরীক্ষার প্রতি আমাদের পদ্ধতির বিকাশের জন্য সিএমএর সাথে কাজ করেছি এবং বাজারের অংশগ্রহণকারীদের আরও তথ্য সরবরাহ করার জন্য এবং প্রস্তাবিত পদ্ধতির বিষয়ে মন্তব্য করার সুযোগ দেওয়ার জন্য সিএমএর পরীক্ষামূলক নকশায় একটি নোট প্রকাশের সমর্থক। " |
| (Q3 এও রিপোর্ট করা হয়েছে) ডকুমেন্টেশন অনুরোধ | পরীক্ষা, বিশ্লেষণ এবং বাস্তবায়ন কীভাবে পরিচালনা করবেন তা বিশদ আরও সংস্থার জন্য অনুরোধ | প্রশ্ন 4 আপডেট: আমরা প্রশংসা করি যে বিকাশকারীরা আমাদের বর্তমান উপাদানগুলিকে সহায়ক বলে মনে করেছে এবং আরও বেশি উপাদান সরবরাহ করতে প্রতিশ্রুতিবদ্ধ হতে চলেছে যাতে বিকাশকারীরা বুঝতে পারে যে কীভাবে নতুন প্রযুক্তিগুলি তাদের জন্য কাজ করতে পারে। গত কোয়ার্টারে, আমরা প্রাইভেস্যান্ডবক্স.কম এ একটি "নিউজ অ্যান্ড আপডেটস" বিভাগ যুক্ত করেছি এবং গোপনীয়তা স্যান্ডবক্স কীভাবে ভবিষ্যতে বিজ্ঞাপনের প্রাসঙ্গিকতা চালাতে সহায়তা করতে পারে তার একটি বিস্তৃত পর্যালোচনা প্রকাশ করেছি। আমরা পণ্য এবং প্রকৌশল সহ প্রশ্নোত্তর সেশন সহ সেরা অনুশীলন এবং ডেমোগুলি ভাগ করে নেওয়ার জন্য পাবলিক ডেভেলপার অফিস আওয়ার সেশনগুলিও রেখেছি, লাইভ আলোচনা/প্রশ্নের জন্য অনুমতি দেয়। |
| কোর ওয়েব ভাইটাল | গোপনীয়তা স্যান্ডবক্স এপিআই লেটেন্সি কীভাবে কোর ওয়েব ভিটালগুলি প্রভাব ফেলে? | ন্যূনতম দিকে বিলম্ব রাখা গোপনীয়তা স্যান্ডবক্স এপিআইগুলির একটি মূল নকশা লক্ষ্য। আমাদের বর্তমান প্রত্যাশা হ'ল এপিআই ল্যাটেন্সির কোনও সাইটের মূল ওয়েব ভাইটালগুলিতে ন্যূনতম প্রভাব ফেলতে হবে, কারণ বেশিরভাগ এপিআইকে ওয়েবসাইটের প্রাথমিক রেন্ডারিংয়ের পরে ডাকা হয়। আমরা প্রতিটি এপিআইয়ের জন্য আরও বিলম্বতা হ্রাস করতে নিরীক্ষণ এবং উন্নতি করতে থাকি এবং অব্যাহত পরীক্ষা এবং প্রতিক্রিয়া উত্সাহিত করি। রিয়েল টাইম বিডিং প্রক্রিয়াতে লেটেন্সি "ফ্লেজ নিলামের পারফরম্যান্স" এর অধীনে ফ্লেজ বিভাগে সম্বোধন করা হয়েছে |
| ইন্টারঅপারেবিলিটি | অন্যান্য সম্ভাব্য সমাধানগুলির সাথে আন্তঃব্যবহারযোগ্যতা সম্পর্কিত উদ্বেগ | গোপনীয়তা স্যান্ডবক্সের লক্ষ্য হ'ল ওয়েব ইকোসিস্টেমের প্রয়োজনীয়তা সমর্থন করার সময় ব্যবহারকারীদের ক্রস-সাইট ট্র্যাকিং থেকে রক্ষা করা। আমরা তৃতীয় পক্ষের কুকিজের মতো এই জাতীয় ক্রস-সাইট ট্র্যাকিংকে সক্ষম করে এবং তাদের জায়গায় নির্দিষ্ট ব্যবহারের ক্ষেত্রে সমর্থন করার জন্য নতুন প্রযুক্তির উদ্দেশ্য-নির্মিত সরবরাহ করে এমন ক্রস-সাইট ট্র্যাকিংকে সক্ষম করে এমন লিগ্যাসি ব্রাউজার প্রযুক্তিগুলি থেকে দূরে সরে গিয়ে এটি সম্পাদন করার চেষ্টা করি। গোপনীয়তা স্যান্ডবক্সের প্রস্তাবগুলি কোনও ব্যবহারকারীর ডিভাইস ছেড়ে দেয় এমন ডেটা সীমাবদ্ধ করে গোপনীয়তার উন্নতি করে। প্রস্তাবগুলি ব্রাউজার থেকে সংগৃহীত একবারে ডেটা ভাগ করে নেওয়ার বা অন্যথায় প্রক্রিয়া করার জন্য কোনও ওয়েবসাইটের ক্ষমতার উপর প্রযুক্তিগত বিধিনিষেধ রাখে না। প্রযুক্তিগুলি তাই সংস্থাগুলিকে "ডেটা স্টুয়ার্ডশিপ" চুক্তি বা অন্য কোনও অনুরূপ চুক্তিভিত্তিক সম্পর্কের ক্ষেত্রে প্রবেশ করতে বাধা দেয় না। তেমনিভাবে, তারা ব্যবহারকারীদের অন্যান্য উপায়ে তাদের ডেটা ভাগ করে নেওয়ার সম্মতি জানাতে সক্ষমতা সীমাবদ্ধ করে না। স্পষ্টতার জন্য, গুগল গুগল পণ্য এবং পরিষেবাদি সহ সমস্ত ওয়েবসাইটে একইভাবে গোপনীয়তা স্যান্ডবক্স প্রযুক্তি প্রয়োগ করার প্রতিশ্রুতিবদ্ধ। ক্রোম তৃতীয় পক্ষের কুকিজের সমর্থন শেষ করার পরে, প্রতিশ্রুতিগুলি আরও স্পষ্ট করে দেয় যে গুগল অন্যান্য ব্যক্তিগত ডেটা যেমন ব্যবহারকারীদের সিঙ্কড ক্রোম ব্রাউজিংয়ের ইতিহাস ব্যবহার করবে না, ডিজিটাল বিজ্ঞাপনের লক্ষ্য বা পরিমাপের জন্য ব্যবহারকারীদের ট্র্যাক করতে। |
প্রাসঙ্গিক সামগ্রী এবং বিজ্ঞাপনগুলি দেখান
বিষয়
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| গুগল অনুসন্ধান র্যাঙ্কিংয়ে প্রভাব | কোনও ওয়েবসাইটের বিষয়গুলি এপিআই সমর্থন গুগল অনুসন্ধানের ফলাফল র্যাঙ্কিংয়ের সম্ভাব্য সংকেত হিসাবে ব্যবহৃত হবে কিনা সে সম্পর্কে অনুসন্ধান করুন | কিছু ওয়েবসাইট এপিআই বিষয়গুলি বেছে নিতে বেছে নিতে পারে। গোপনীয়তা স্যান্ডবক্স দল অনুসন্ধান সংস্থার কাছ থেকে সমন্বিত বা অনুরোধ করেনি যে তারা ওয়েবসাইটগুলির এপিআই গ্রহণের জন্য ওয়েবসাইটগুলির জন্য উত্সাহ হিসাবে পৃষ্ঠা র্যাঙ্কিং ব্যবহার করে। গুগল সিএমএকে নিশ্চিত করেছে যে গুগল অনুসন্ধান এপিআই থেকে র্যাঙ্কিং সিগন্যাল হিসাবে কোনও সাইটের সিদ্ধান্ত গ্রহণের জন্য কোনও সাইটের সিদ্ধান্ত ব্যবহার করবে না। |
| বিষয়গুলি শ্রেণিবদ্ধ | বিভিন্ন স্টেকহোল্ডারদের জন্য ইউটিলিটি উন্নত করার জন্য একটি ওয়েবপৃষ্ঠার বিষয় নির্ধারণের জন্য হোস্টনাম ছাড়াও ইউআরএল এবং পৃষ্ঠা সামগ্রী যুক্ত করুন। | একজন ব্যবহারকারীর ব্রাউজিং ইতিহাস বর্তমানে কোনও ওয়েবসাইটের হোস্টনাম ব্যবহার করে শ্রেণিবদ্ধ করা হয়েছে। ক্রোম বিষয়ের শ্রেণিবিন্যাসে পৃষ্ঠা স্তরের মেটাডেটা (যেমন পৃষ্ঠা URL এবং/অথবা সামগ্রীর কিছু উপাদান) বিবেচনা করার জন্য বিকল্পগুলি মূল্যায়ন করে চলেছে। কোনও ইউটিলিটি উন্নতি অবশ্যই গোপনীয়তা এবং অপব্যবহারের ঝুঁকির বিরুদ্ধে ওজন করা উচিত। উদাহরণস্বরূপ, বিশেষত মেটাডেটার বিষয়ে, কয়েকটি ঝুঁকির মধ্যে রয়েছে: - সাইটগুলি পৃষ্ঠা-স্তরের মেটাডেটাকে বিষয়গুলিতে বিভিন্ন (এবং সম্ভাব্য সংবেদনশীল) অর্থগুলি এনকোড করার পদ্ধতি হিসাবে সংশোধন করে; - সাইটগুলি আর্থিক লাভের জন্য তাদের বিষয়গুলিকে ভুলভাবে উপস্থাপনের জন্য পৃষ্ঠা-স্তরের মেটাডেটা সংশোধন করে; -ক্রস-সাইট ট্র্যাকিংয়ের পদ্ধতি হিসাবে গতিশীলভাবে পৃষ্ঠা-স্তরের মেটাডেটা সংশোধনকারী সাইটগুলি |
| (Q3 এও রিপোর্ট করা হয়েছে) প্রথম পক্ষের সংকেত উপর প্রভাব | বিষয়গুলি সিগন্যাল অত্যন্ত মূল্যবান হতে পারে এবং ফলস্বরূপ অন্যান্য প্রথম পক্ষের আগ্রহ-ভিত্তিক সংকেতগুলিকে অবমূল্যায়ন করে। | আমাদের প্রতিক্রিয়া Q3 থেকে অপরিবর্তিত: "আমরা বিশ্বাস করি আগ্রহ-ভিত্তিক বিজ্ঞাপন ওয়েবের জন্য একটি গুরুত্বপূর্ণ ব্যবহারের কেস, এবং বিষয়গুলি সেই ব্যবহারের ক্ষেত্রে সমর্থন করার জন্য ডিজাইন করা হয়েছে। [আমাদের কিউ 3 প্রতিবেদনে] বর্ণিত হিসাবে, অন্যান্য বাস্তুতন্ত্রের স্টেকহোল্ডাররা উদ্বেগ প্রকাশ করেছেন যে বিষয়গুলি মূল্য প্রদানের পক্ষে যথেষ্ট কার্যকর নাও হতে পারে। সব ক্ষেত্রেই করের উন্নতি হ'ল একটি চলমান প্রচেষ্টা, এবং আমরা ইকোসিস্টেমের টেস্টের সাথে বিকশিত হওয়ার প্রত্যাশা করি।" |
| ট্যাক্সোনমি আপডেট করা | কীভাবে শ্রেণীবদ্ধ তালিকা আপডেট করা হবে? | আমরা তাত্ত্বিকতার জন্য সবচেয়ে কার্যকর হবে এমন টেকনোমি সম্পর্কে সক্রিয়ভাবে প্রতিক্রিয়া চাইছি । প্রাথমিক বিষয়গুলিতে অন্তর্ভুক্ত টেকনোমিটি এপিআই প্রস্তাবটি কার্যকরী পরীক্ষা সক্ষম করার জন্য ডিজাইন করা হয়েছিল। ক্রোম সক্রিয়ভাবে ট্যাক্সনোমি আপডেট করার জন্য একাধিক পদ্ধতির বিবেচনা করছে। উদাহরণস্বরূপ, ক্রোম ভবিষ্যতের পুনরাবৃত্তিতে কোন বিভাগটি অন্তর্ভুক্ত করতে পারে তা নির্ধারণ করতে প্রতিটি বিষয়ের জন্য বাণিজ্যিক মানের একটি ধারণা ব্যবহার করতে পারে। |
| বিষয়গুলি আঞ্চলিক শ্রেণিবদ্ধ কর্মক্ষমতা | বিষয়গুলি শ্রেণিবদ্ধকারী আঞ্চলিক ডোমেনগুলিতে খারাপ পারফর্ম করে | শ্রেণিবদ্ধের উন্নতি একটি চলমান প্রচেষ্টা। আমরা যে প্রতিক্রিয়া পেয়েছি তার ভিত্তিতে, বিবেচনাধীন একটি সম্ভাবনা হ'ল বিষয়গুলি ওভাররাইড তালিকাটি প্রসারিত করা, যা আমাদের বিশ্লেষণে বিশ্বব্যাপী কভারেজ বাড়িয়ে তুলবে এবং নির্ভুলতা উন্নত করবে। ব্যাখ্যা করার জন্য, বিষয়গুলির এপিআই শ্রেণিবিন্যাসের দুটি প্রাসঙ্গিক উপাদান রয়েছে: (1) শীর্ষ 10 কে সাইট এবং তাদের বিষয়গুলি সমন্বিত একটি ওভাররাইড তালিকা এবং (2) একটি অন-ডিভাইস এমএল মডেল যা হোস্টনামগুলিকে বিষয়গুলিতে শ্রেণিবদ্ধ করে। ওভাররাইড তালিকা (1) প্রসারিত করে, আমরা সেই অঞ্চলগুলিতে শ্রেণিবিন্যাসের কার্যকারিতা উন্নত করতে পারি যেখানে শ্রেণিবদ্ধকারী খারাপভাবে সম্পাদন করতে পারে। |
| এক সপ্তাহের যুগ | এক সপ্তাহের যুগটি স্বল্প মেয়াদী সিদ্ধান্ত নেওয়ার জন্য ব্যবহারকারীদের পক্ষে খুব দীর্ঘ। | আমরা যুগের উপযুক্ত দৈর্ঘ্যটি কী হওয়া উচিত তা সক্রিয়ভাবে দেখছি এবং বাস্তুতন্ত্রের জন্য আরও ভাল যুগ কী হবে সে সম্পর্কে আমরা আরও প্রতিক্রিয়া স্বাগত জানাই। |
| এইচটিটিপি শিরোনাম পুনরুদ্ধার | উদ্বেগ যে বিষয়গুলির এইচটিটিপি শিরোনাম পুনরুদ্ধার সম্পর্কিত পর্যাপ্ত তথ্য নেই | হেডার এবং আনার জন্য কাজ চলছে ()। আমাদের এখানে তথ্য উপলব্ধ রয়েছে। আমরা ব্যাখ্যাকারের কাছে স্কিপোবসার্ভেশন তথ্যও যুক্ত করেছি । |
| বিষয়গুলি কেবল বিজ্ঞাপনদাতাদের সহায়তা করা, ব্যবহারকারীদের নয় | বিষয়/গোপনীয়তা স্যান্ডবক্স একটি শিল্প কেন্দ্রিক পদ্ধতির হিসাবে উপস্থিত বলে মনে হয়। ব্যবহারকারীদের জন্য বেনিফিট শিল্পের সুবিধার মতো পরিষ্কার নয়। | আমরা ব্যবহারকারীদের সুবিধাটি বিশ্বাস করি যে বিষয়গুলি সুদ-ভিত্তিক বিজ্ঞাপনগুলি সমর্থন করে যা ওয়েবকে মুক্ত এবং উন্মুক্ত রাখে এবং আমরা এটিও বিশ্বাস করি যে এটি তৃতীয় পক্ষের কুকিজের তুলনায় গোপনীয়তার উল্লেখযোগ্য উন্নতি করে । টেকসই বিকল্প ছাড়াই তৃতীয় পক্ষের কুকিজ অপসারণ প্রকাশকদের নেতিবাচকভাবে প্রভাবিত করতে পারে এবং আরও খারাপ পদ্ধতির দিকে পরিচালিত করতে পারে যা কম ব্যক্তিগত, স্বচ্ছ নয় এবং ব্যবহারকারীরা বাস্তবসম্মতভাবে পুনর্বাসনযোগ্য বা নিয়ন্ত্রিত নয়। অনেক সংস্থা সক্রিয়ভাবে বিষয় এবং স্যান্ডবক্স এপিআই পরীক্ষা করছে এবং আমরা গোপনীয়তা অগ্রসর করার এবং ওয়েবকে সমর্থন করার জন্য সরঞ্জামগুলি সরবরাহ করতে প্রতিশ্রুতিবদ্ধ। ডাব্লু 3 সি টেকনিক্যাল আর্কিটেকচার গ্রুপ সম্প্রতি এপিআই বিষয়গুলি সম্পর্কে তার প্রাথমিক দৃষ্টিভঙ্গি প্রকাশ করেছে, যা আমরা প্রকাশ্যে প্রতিক্রিয়া জানাব। এই পর্যায়ে, যেহেতু গুগল এপিআই বিষয়গুলির বিকাশ এবং প্রবর্তনের জন্য এই পর্যালোচনাটি কী বোঝাতে পারে সে সম্পর্কে ইকোসিস্টেম থেকে প্রশ্ন পেয়েছে, তাই আমরা এই বছর ক্রোম স্থিতিশীলতে এটি উপলব্ধ করার জন্য আমাদের পরিকল্পনাটি পুনরায় নিশ্চিত করতে চাই। গুগলস যখন ডাব্লু 3 সি টেকনিক্যাল আর্কিটেকচার গ্রুপের ইনপুটটির প্রশংসা করে, এটি সিএমএ এবং বাস্তুতন্ত্রের সাথে পরামর্শে বিষয়গুলি বিকাশ এবং পরীক্ষা করার প্রচেষ্টা চালিয়ে যাওয়ার জন্য এটি সর্বজনীন গুরুত্ব হিসাবে বিবেচনা করে। |
| ডেটা ফাঁস | উদ্বেগ যে বিষয়গুলি অনুমতি ছাড়াই অন্যান্য সাইটে ফাঁস হতে পারে | বিষয়গুলি এপিআইয়ের নকশাটি এটিকে যথেষ্ট অসম্ভব করে তোলে যে কোনও একক প্রকাশকের (এবং এমনকি প্রকাশকদের একটি ছোট গ্রুপ) ডেটা কোনওভাবেই ফাঁস হতে পারে। প্রকাশক ওয়েবসাইটগুলি এপিআই বিষয়গুলির উপরও সম্পূর্ণ নিয়ন্ত্রণে রয়েছে এবং তারা অনুমতি নীতির মাধ্যমে এই এপিআইতে অ্যাক্সেস নিষিদ্ধ করতে পারে। |
| পরীক্ষার জন্য বিজ্ঞাপনদাতাদের অভাব | প্রকাশকরা উদ্বিগ্ন যে তারা বর্তমানে বিজ্ঞাপনদাতাদের কাছে বিষয়গুলির মূল্য প্রদর্শন করতে অক্ষম। | 2023 এর দ্বিতীয়ার্ধে, আমরা ইন্টিগ্রেশন পরীক্ষার জন্য সমস্ত বিজ্ঞাপন সম্পর্কিত এপিআই উপলব্ধ এবং বিজ্ঞাপনদাতাদের জন্য বিষয়গুলির মূল্য সম্পর্কিত বাস্তুতন্ত্র বিশ্লেষণ সক্ষম করার পরিকল্পনা করছি। ফলাফলগুলি পরীক্ষা ও প্রকাশনা সিএমএ দ্বারা তত্ত্বাবধান করা হবে, যা ডেটা, বিশ্লেষণ এবং পদ্ধতি পর্যালোচনা করবে। ইকোসিস্টেমটি গুগল এবং সিএমএর সাথে প্রতিক্রিয়া জানাতে উত্সাহিত করা হয়। |
| বিষয় এবং ঝাঁকুনি | ফ্লেজের বিডিং লজিকের মধ্যে কীভাবে বিষয়গুলি ব্যবহার করবেন সে সম্পর্কে আরও তথ্যের জন্য অনুরোধ করুন | ফ্লেজের বিডিং যুক্তির মধ্যে বিষয়গুলি ব্যবহার করা সম্ভব। একটি ইন্টিগ্রেশন গাইডও অগ্রগতিতে রয়েছে এবং বাস্তবায়নের বিষয়ে অতিরিক্ত বিশদ অন্তর্ভুক্ত করবে। |
| বিষয়গুলি কলারের জন্য কাস্টম র্যাঙ্কিং | র্যাঙ্কিংকে কলার দ্বারা তৈরি করার অনুমতি দিন | প্রতিটি বিজ্ঞাপন প্রযুক্তির জন্য কাস্টম টপিক র্যাঙ্কিং বা মানগুলির সাথে চ্যালেঞ্জটি হ'ল এটি এমন একটি ব্যবস্থায় পরিণত হতে পারে যার মাধ্যমে কোনও বিজ্ঞাপন প্রযুক্তি ফিরে আসে এমন বিষয়গুলিকে প্রভাবিত করতে পারে, সুতরাং একটি ফিঙ্গারপ্রিন্টিং ভেক্টর। |
| বিষয়গুলি কলার অগ্রাধিকার তালিকা | যোগ্যতার ভিত্তিতে এপিআই বিষয়গুলি যে বিষয়গুলি ফিরে আসবে এমন বিষয়গুলির একটি র্যাঙ্কড অগ্রাধিকার তালিকা সরবরাহ করার জন্য কলারদের অনুমতি দিন। | আমরা বর্তমানে এই ধারণাটি আরও নিয়ে আলোচনা করছি এবং অতিরিক্ত ইনপুটগুলিকে স্বাগত জানাই। |
চঞ্চল
| প্রতিক্রিয়া থিম | সারাংশ | ক্রোম প্রতিক্রিয়া |
|---|---|---|
| গুগল অ্যাড ম্যানেজার | উদ্বেগ যে গুগল অ্যাড ম্যানেজারটি ফ্লেজ নিলামের শেষ সিদ্ধান্ত এবং গুগল প্রকাশক ট্যাগ এবং গুগল বিজ্ঞাপন পরিচালকের পক্ষে। | ফ্লেজ প্রতিটি প্রকাশককে শীর্ষ-স্তরের এবং উপাদান বিক্রেতাদের পছন্দ সহ নিলামের কাঠামো চয়ন করতে দেয়। একটি উপাদান নিলামের প্রতিটি ক্রেতা এবং বিক্রেতা জানে যে শীর্ষ-স্তরের বিক্রেতা কে, এবং বিড করবেন কিনা তা চয়ন করতে পারেন। |
| পর্যাপ্ত অংশগ্রহণকারীরা ফ্লেজ পরীক্ষা করে না | আরও সংস্থাগুলি ফ্লেজ পরীক্ষা করতে উত্সাহিত করার অনুরোধ, উদাহরণস্বরূপ এপিআইয়ের কার্যকারিতা উন্নত করে এবং আঙুলের ছাপের মতো গোপনীয়তা-ইন্টারভেসিভ বিকল্পগুলি নিরুৎসাহ করে | গোপনীয়তা স্যান্ডবক্সটি সিএমএ এবং আইসিওর দিকনির্দেশনার সাথে ঘনিষ্ঠ অংশীদারিত্বের সাথে পর্যায়ক্রমে এগিয়ে চলেছে এবং কার্যকরী ফ্লেজ টেস্টিং প্রয়োজনীয় স্থিতিশীলতা এবং সক্ষমতা প্রদর্শন করেছে। গুগল স্যান্ডবক্স এপিআইগুলি পরীক্ষা করার জন্য বাস্তুতন্ত্রকে উত্সাহিত করে চলেছে, সম্প্রতি তৃতীয় পক্ষের কুকি অবমূল্যায়নের পরে কীভাবে ফ্লেজ এবং অন্যান্য এপিআই বিজ্ঞাপন শিল্পের জন্য সমালোচনামূলক ব্যবহারের ক্ষেত্রে সহায়তা করতে পারে তা প্রদর্শনের জন্য তার " সর্বাধিক বিজ্ঞাপন প্রাসঙ্গিকতা " ডকুমেন্টেশন প্রকাশ করে। গোপনীয়তা স্যান্ডবক্সের অন্যান্য অংশগুলি ইতিমধ্যে ট্র্যাকিংটি কভার করার জন্য প্রশমনকে সমর্থন করে (ইউএ-সিএইচ, আইপি সুরক্ষা এবং বাউন্স ট্র্যাকিং প্রশমিতকরণগুলি দেখুন) এবং সময়ের সাথে সাথে উন্নতি অব্যাহত থাকবে। গুগলের লক্ষ্য হ'ল ফ্লেজকে একমাত্র কার্যকর টার্গেটিং সমাধান করা নয়, বরং ক্রোম ব্রাউজারে সেরা গোপনীয়তা-সংরক্ষণকারী বিজ্ঞাপন প্রযুক্তি চালানোর জন্য শিল্প এবং নিয়ন্ত্রকদের সাথে অংশীদারিতে কাজ করার প্রতিশ্রুতিবদ্ধ রয়েছেন। |
| মেশিন লার্নিং ব্যবহারের ক্ষেত্রে | নিলাম বিডিং অ্যালগরিদমগুলি প্রশিক্ষণের জন্য কীভাবে মেশিন লার্নিং কেসগুলি ব্যবহার করে সে সম্পর্কে আরও গাইডেন্স ফ্লেজ এবং অ্যাট্রিবিউশন রিপোর্টিংয়ে সমর্থিত হবে | আমরা প্রাইভেসি স্যান্ডবক্স প্রযুক্তি প্রয়োগের সর্বাধিক দরকারী উপায়গুলি খুঁজে পেতে পরীক্ষার্থীদের সহায়তা করার প্রয়োজনীয়তা স্বীকার করি। আমরা বিশেষত মেশিন লার্নিংয়ের ইনপুট হিসাবে গোপনীয়তা স্যান্ডবক্স এপিআইগুলির বিভিন্ন দিক ব্যবহারের সাথে সম্পর্কিত গাইডেন্স প্রকাশ করতে শুরু করেছি। সর্বাধিক সাম্প্রতিক অংশটি, সর্বাধিক বিজ্ঞাপনের প্রাসঙ্গিকতার সাথে আলোচনা করা হয়েছে যে বিজ্ঞাপন শিল্প কীভাবে মেশিন লার্নিংয়ের জন্য এই সংকেতগুলি ব্যবহার করতে পারে এবং আমরা এ জাতীয় দিকনির্দেশনা প্রকাশ করা চালিয়ে যাওয়ার পরিকল্পনা করছি। |
| ফ্লেজ কী মান (কে/ভি) সার্ভারকে জিজ্ঞাসা করা | কে/ভি সার্ভার কেন প্রকাশ্যে জিজ্ঞাসাযোগ্য? | কে/ভি সার্ভারের লক্ষ্য নিলামে রিয়েল টাইম সিগন্যাল সরবরাহ করা। এই হিসাবে, কে/ভি সার্ভারটি অ্যাক্সেসযোগ্য হওয়া দরকার যেখান থেকে সেই ফ্লেজ নিলামগুলি কার্যকর করে, যা ব্যবহারকারী ডিভাইসে রয়েছে, এটি প্রকাশ্যে উপলব্ধ হওয়ার প্রয়োজন। কে/ভি সার্ভারে সঞ্চিত একটি মান কেবলমাত্র ইতিমধ্যে এর কী রয়েছে এমন একটি পক্ষ দ্বারা পুনরুদ্ধার করা যেতে পারে - সুতরাং যদি কোনও বিজ্ঞাপন প্রযুক্তি কেবল আগ্রহের গোষ্ঠীতে থাকা ব্রাউজারগুলিকে কীগুলি দেয় এবং এলোমেলোভাবে অনুমান করা যায় এমন কীগুলি ব্যবহার করে না, তবে কেবল তাদের নিলাম চালানোর জন্য মান প্রয়োজন ব্রাউজারগুলি এটি পুনরুদ্ধার করতে সক্ষম হবে। |
| কীভাবে তারিখ/সময় লক্ষ্য করা যায়? | বিডিং লজিক ফাংশনে তারিখের অবজেক্টের জন্য সমর্থন। | এটি করার একাধিক উপায় আছে। ক্রেতারা তাদের বিক্রেতাকে বর্তমান তারিখ এবং সময় সরবরাহ করতে বলতে পারেন এবং বিক্রেতাদের পক্ষে সমস্ত ক্রেতাদের এই তথ্য সরবরাহ করা সহজ হওয়া উচিত। ক্রেতারা তাদের রিয়েল টাইম কী-ভ্যালু প্রতিক্রিয়াতে তারিখ এবং সময়ও সরবরাহ করতে পারে। শেষ অবধি, ক্রেতারা প্রতি-বাইয়ার-সিগন্যালগুলিতে তাদের প্রাসঙ্গিক প্রতিক্রিয়ার অংশ হিসাবে তারিখ এবং সময় সরবরাহ করতে পারে, যা একজন বিক্রেতা ক্রেতার জেনারেটবিড স্ক্রিপ্টে যেতে পারে। |
| ব্যবহারকারীর পছন্দ | ফ্লেজ বা বিকল্প সমাধানগুলির মাধ্যমে পরিবেশন করার সময় ব্যবহারকারীদের বিজ্ঞাপনদাতাদের দ্বারা ক্রিয়েটিভগুলি অবরুদ্ধ করতে বেছে নেওয়ার ক্ষমতা। | ব্যবহারকারীদের ক্রোমে বিজ্ঞাপন এপিআই থেকে বেরিয়ে আসার ক্ষমতা রাখে। নির্দিষ্ট বিজ্ঞাপনগুলির জন্য, প্রাসঙ্গিক বিজ্ঞাপন প্রযুক্তি হ'ল সৃজনশীলদের দেখানো হয় বা কীভাবে তারা নির্বাচিত হয় তার উপর নিয়ন্ত্রণ সরবরাহ করার জন্য পার্টি সেরা অবস্থানে রয়েছে। |
| পরিষ্কার সময়সীমা | ফ্লেজে গোপনীয়তা সুরক্ষার প্রাপ্যতা সম্পর্কিত আরও তথ্যের জন্য অনুরোধ যেমন বেড়া ফ্রেমের প্রয়োজন। | আমরা কিউ 1 এ আরও বিস্তারিত সময়সীমা প্রকাশের পরিকল্পনা করছি। |
| বিভ্রান্তির প্রতিবেদন | কীভাবে ফ্লেজ রিপোর্টিং অন্যান্য এপিআই যেমন বেড়া ফ্রেম এবং বেসরকারী সমষ্টি এপিআইয়ের সাথে কাজ করবে সে সম্পর্কে আরও স্পষ্টতার জন্য অনুরোধ। | We plan to publish an explainer on the interaction between Private Aggregation API, FLEDGE, and Fenced Frames in the coming weeks. |
| Real-time bidding and FLEDGE | Guidance on how FLEDGE integrates with standard real-time bidding. | The two main things that complicate an ad-tech's ability to do real-time bidding are access to event level data and easier integration into ARA. We are planning on sending updates and explainers on both of these in Q1. |
| Performance of FLEDGE Auctions | Report from testers that FLEDGE auctions have high latency | We appreciate reports from testers sharing their results and use cases and have shared some suggestions on how to improve the performance of FLEDGE . In parallel, we have added tooling to the browser allowing developers to better diagnose what is making auctions slow , and have been systematically addressing the primary sources of latency observed. Recent improvements include timeouts for slow auctions , a fast bidder filtering technique , a way to reuse FLEDGE worklets to avoid paying startup costs , and ongoing work to allow the contextual ad request to run in parallel with the FLEDGE startup time and network fetches. We expect latency optimization to continue as an ongoing conversation between Chrome developers and FLEDGE testers based on their real-world experience using the API. |
| Interest Group size memory limit | Request to raise the limit on the size of a single interest group from 50kB. | We are actively considering the request and are looking for feedback on what limit value works . |
| Combining the FLEDGE served data with first-party cookie | Will FLEDGE support integration with an advertiser's first-party data? | FLEDGE was built to support advertising using the first-party data an advertiser already has. However, FLEDGE does not intend to support an advertiser learning a person's browsing behavior on any website other than the advertiser's own site. Attaching off-site browsing behavior to first-party data is contrary to the goals of Privacy Sandbox. We are planning to share integration guides with more details on how FLEDGE will support integration with first-party data in the coming weeks. |
| K-anonymity value | How will the value "K" to "k-anon" be decided and will it be published? | The "K" value is still being finalized and we will share more information as our plans develop. We are interested in learning more about how an unknown k value may hinder FLEDGE preparedness and scoping ML model training and we welcome additional feedback on this subject. |
| Supporting multiple SSPs | How will multiple SSPs be supported in FLEDGE? | FLEDGE supports multi-seller auctions as noted in this proposal . |
| Visibility of bidding logic | Concern that DSP bidding logic will be exposed in JavaScript | With the current design bidding logic JavaScript can be accessed by others, but we welcome more feedback as to why this could be a source of concern for DSPs. |
| prebid.js | What is the timeline in supporting prebid.js in FLEDGE? | Only versions 7.14 and later of Prebid.js support the FLEDGE module. Any publishers interested in testing must add the FLEDGE module and upgrade their Prebid instance. |
| User defined functions in FLEDGE | How will user defined functions (UDF) be supported in FLEDGE? These are functions that can be programmed by end users to extend the functionality of the API. | Explainer available here . This is still being fleshed out so we welcome additional feedback on use cases. |
| Relaxing same-origin constraint on Interest Group resources | Request to relax same-origin constraint on Interest Group resources to enable certain ad tech use cases | In the current implementation of FLEDGE, biddingLogicUrl , biddingWasmHelperUrl , dailyUpdateUrl and trustedBiddingSignalsUrl must have the same origin as the interest group owner.The constraint exists to prevent certain exploits by attackers, as explained here . |
| interestGroup Ownership | Request to limit whether an ad tech can use joinInterestGroup for the same Interest Groups across sites | Our focus is on how audiences are used, not how they are built. We are discussing potential approaches and welcome additional input. |
| Key Value Server Key Expiration | Discussion on removing server keys once the corresponding interest groups have expired | We are exploring ways to handle key expiration and are looking for feedback . |
Measuring Digital Ads
Attribution Reporting (and other APIs)
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Origin Trial traffic | Current Origin Trial traffic is not enough to conduct utility testing. | The current Origin Trials are meant for ecosystem players to conduct functional testing in order to ensure the API is working as intended. We understand that larger amounts of traffic will be required to perform utility testing once the development of the various Privacy Sandbox API is more mature. The current testing timeline envisages that this will occur by General Availability (ie when the technologies for the use cases will be launched and available for 100% of Chrome traffic) at Q3 2023 (see our up-to-date timeline on privacysandbox.com ).We welcome any additional feedback on use case testing that requires additional traffic. |
| Overlap in functionality of different Privacy Sandbox measurement APIs | Concerns in having multiple measurement approaches overlap through Privacy Sandbox will increase complexity, for example, Attribution Reporting API and Private Aggregation API. | We are working on better documentation to clarify the different use cases for the APIs, and welcome additional feedback on what areas are lacking explanation. For example, Attribution Reporting API is intended specifically to support conversion measurement, whereas Private Aggregation API and Shared Storage are general-purpose APIs intended to support a broader range of cross-site measurement use-cases. |
| Retry failed report request | Clarification on how many times a report request is attempted if it fails. | We have published guidance on this . To summarize, reports are only sent when the browser is running/online. After the first failure to send, the report is retried after 5 minutes. After the second failure, the report is retried after 15 minutes. After that the report is not sent. |
| Reporting Delay | What is the expected reporting delay? | We are looking to hear more feedback from the ecosystem on any reporting delays they are experiencing as we collect data to further assess these delays in parallel. |
| Prerender pages | Will ARA attribution work on prerender pages? | Attribution registration is deferred on prerender pages until activation (actual click or view takes place). This means we will defer the `attributionsrc` request ping. |
| রূপান্তর লিফট পরিমাপ | How to measure conversion lift with AB testing on the same domain | Websites can measure conversion lift with A/B testing on the same domain through attribution reporting. They can encode their A/B parameters as keys using the aggregate API and then receive summary reports for the conversion values by those key buckets. |
| (Also reported in Q3) Cross-domain conversions | How to track the conversions that are cross domain, such as with 2 or more destinations | Q4 Update: We have published a proposal to remove the landing page destination restriction which enables cross domain conversations to be tracked. This proposal has been implemented. |
| (Also reported in Q3) Expiry setting in conversion report | Request to support report filter / expiry for less than 24 hours | Q4 Update: We have shared this pull request which will decouple expiry and reporting windows to mitigate the trade off of reporting delay vs conversion expiry. This is now launched in M110. |
| Fraud and Abuse | Requests from advertisers and marketers to be able to slice and aggregate data based on publisher sites where their ads are served, which would also give more insight into potential fraudulent ad practices | This feedback is actively being discussed here and we welcome additional inputs. |
| (Also reported in Q3) Event level reporting delay | The delay of 2-30 days in event level reporting may be too long for certain use cases. | Event level reporting has default reporting windows of 2, 7, and 30 days. This can be modified by using the "expiry" parameter. Ad-techs could configure the expiry, with a minimum of 1 day, to get potential reports in less than 2 days. We limit the granularity of expiries to 1 day as a privacy protection mechanism, as more fine-grained reporting could result in timing attacks. Additionally, we allow setting independent "expiry" parameters for event level and aggregate reports. এখানে দেখুন. Additionally, Google Ads will not get any special reporting windows that other ad-techs do not get via the Attribution Reporting API. |
| Same reporting origin requirement | Request to remove requirement for source registration origin to be the same as the conversion registration origin | We propose using HTTP redirects to delegate registration to solve this use-case. We welcome any additional feedback on the new guidance. |
| রূপান্তর ট্র্যাকিং | Need to differentiate whether the conversion happened before/after certain hours set by the advertiser | Attribution Reporting API supports setting an expiry window and priority for source attribution. By using both, it will technically be possible to attribute a conversion that happened within X days window separately from a conversion that happened after X. |
| Noise simulation | Request to be able to simulate the different volume of conversions per bucket, to understand the impact on advertisers with less conversions | We are looking to add ways to simulate this in future versions of Noise Lab . We welcome any additional feedback. |
| Reporting on mobile | Will the report still be sent when Chrome is running in the background on mobile? | At the moment, even on mobile, the report will not be sent when Chrome is in the background. This is likely to change when the API integrates with Android Privacy Sandbox. এখানে দেখুন. Note that Android Privacy Sandbox is not part of the Commitments accepted by the CMA. |
| ডেটা প্রাপ্যতা | Concerns that Google will have additional access to data via Privacy Sandbox APIs | First, Google Ads does not receive any preferential access to data from the Attribution Reporting API or other Privacy Sandbox APIs. This issue is also addressed in the General Feedback section under "Interoperability" which includes more detail on Google's Commitments. Second, on the difference between larger and smaller sites, Google recognizes that noise-based privacy protections may have a greater impact on smaller data slices. However, there are some possible mitigations: for instance, methods like aggregating over longer periods of time would solve this problem. That said, it remains unclear if conclusions based on very small data slices (like one or two purchases) are meaningful at all to advertisers. During the origin trial, Google has encouraged testers to take advantage of the ability to experiment with a wide range of privacy and noise parameters so they can provide more specific feedback on this issue. |
Limit Covert Tracking
ব্যবহারকারী-এজেন্ট হ্রাস
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Delay User-Agent Reduction until web ecosystem is more ready | There is not sufficient time to adapt to the coming User-Agent Reduction changes. | We address this feedback in the full report under "Stakeholder Concerns" in the section titled "Google's interaction with the CMA". |
| Delay User-Agent Reduction until web ecosystem is more ready | Request to delay User-Agent Reduction rollout until Structured User Agents (SUA) is deployed | The Google Ads team proposed the Structured User-Agent addition (see specification ) to OpenRTB in October 2021 and it was incorporated in the 2.6 spec update released in April 2022. We have some evidence that SUA is deployed and available today, as demonstrated by the Scientia Mobile blog post demonstrating how to use UA-CH and the WURFL API to create a SUA. |
###
User-Agent Client Hints
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Test UA-CH with other anti-covert tracking techniques | Guidance on how to test all Privacy Sandbox APIs and fingerprinting techniques proposed together in a holistic approach | Our testing plan was designed in order to reflect the asynchronous timelines for developing some of the anti-fingerprinting measures as opposed to the rest of the Sandbox Proposals. It addresses the reality that some anti-fingerprinting measures (ie Privacy Budget, IP Protection and Bounce Tracking Mitigations) will be fully-developed and ready for launch to General Availability only after third-party cookie deprecation. While those anti-fingerprinting measures will not be included in quantitative tests, they will be subject to qualitative assessment based on the facts available at the time of Standstill. |
| (Also reported in Q2) কর্মক্ষমতা | Concerns about the latency of getting hints via Critical-CH (on the first page load) | See dedicated UA-CH section below |
| Insufficient Feedback | Feedback from the ecosystem about the UA-CH change may not be sufficient, leading to concerns about a lack of awareness from the ecosystem. | We've been proactively sharing our plans to ensure a careful rollout that minimizes disruption. The plans for User-Agent Reduction and the UA-CH API were presented to the W3C Anti-Fraud Community Group on March 18th, 2022 and to both the Web Payments Working Group and the Web Payments Security Interest Group on January 20th, 2022. No significant concerns were raised during or after the presentations. Google has proactively engaged with more than 100 site operators to obtain feedback. Furthermore, Google has also used Blink-Dev channels to communicate the roll-out of the user-agent reduction publicly based on feedback from ecosystem stakeholders. |
| টাইমিং | Concerns raised regarding timing of rollout and industry preparedness | See dedicated UA-CH section below |
| Chrome Platform Status | Requested that the chromestatus page for UA-CH be updated | The chromestatus entry was updated on December 19 to "Mixed signals". |
IP Protection (formerly Gnatcatcher)
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Opt in or Opt Out | Is IP Address Privacy Opt In or Opt Out? | Our goal is to provide IP Protection to all users. With that goal in mind, we are currently evaluating user choice options for IP Protection. |
| IP Address use case for first-party data | Is it possible to use IP addresses to stitch together user journeys across first-party domains post IP Protection? | As previously published , IP Protection will initially focus on tracking in the third-party context, which means first-party domains will not be impacted. |
| Ad Tech use cases | How can companies set up anti-fraud measures with IP Protection? | We recognize the importance of IP address as a signal for anti-fraud efforts in today's web. As part of our Commitments to the CMA (paragraph 20), we have said that we will not implement IP Protection without making reasonable efforts to support websites' ability to conduct anti-spam and anti-fraud efforts. One of our top priorities is to understand how IP Protection impacts anti-fraud use cases and detection capabilities, so that we can further invest in privacy preserving technologies that help companies preserve web safety. We encourage feedback and input on new proposals aimed at supporting the needs of security and anti-fraud companies, even as signals change over time. |
| Fraud and Abuse | Does IP protection include Denial of Service (DoS) Protection? | We are committed to improving privacy while keeping the web safe, and protecting against denial-of-service attacks is an important anti-abuse use case to design for. We hope to minimize impact to DoS protections through both the design of IP Protection itself and through new anti-abuse solutions. Because IP Protection is initially focused on third-party embedded services, some stakeholders have indicated that it should have limited impact on DoS protection for first-party sites. However we continue to ask for public feedback to assess risk to DoS use cases, particularly to third-party embedded services. In parallel, we are exploring abuse-feedback and client-blocking mechanisms that would enable a site or service to block a spammy user, without identifying the user. |
| বিষয়বস্তু ফিল্টারিং | Content filtering with IP Protection | Different companies have different needs with respect to filtering content and customizing user experience. Many such use cases do not currently rely on IP addresses and therefore should be unaffected by IP Protection. For example, a publisher looking to tailor its content and drive more engagement might use first-party cookies or third-party partitioned cookies (CHIPs) to understand a user's interests and previous interactions with the publisher. Or an ad tech partner focused on delivering the right ad to the right user can incorporate FLEDGE and Topics, for example, to deliver similar ad outcomes as they do today with third-party cookies or other cross-site tracking technologies. We are also exploring building new privacy-preserving capabilities into IP Protection, such as coarse geolocation, to further support content filtering where existing mechanisms may be insufficient. We welcome additional feedback on content filtering use cases that may be impacted by IP Protection. |
| (Also reported in Q3) Geolocation use cases | IP Protection may prevent legitimate geolocation use cases from working in the future, such as content personalisation based on geolocation. | Q4 Update: We are working with stakeholders to ensure that Chrome continues to support legitimate use-cases for IP addresses. We are seeking ecosystem feedback on IP Geolocation granularity here . |
গোপনীয়তা বাজেট
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Clearer documentation | More examples so stakeholders can anticipate how things may be limited once Privacy Budget is implemented | The Privacy Budget proposal is still under active discussion and has not been implemented by any browsers. The earliest date of scaled availability represents the earliest date when Privacy Budget could be enforced. This will not happen before the removal of third-party cookies in 2024. We do not have any additional documentation to share at the moment. We will share additional details on the proposal when it becomes more finalized. In the meantime, we welcome stakeholders to share any feedback that would help in the development of the proposal. |
ক্রস-সাইট গোপনীয়তা সীমানা শক্তিশালী করুন
First-Party Sets
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| (Also reported in Q3) Domain limit | Request to expand the number of associated domains | Q4 Update: We have released FPS for local testing, including a mock set submission process on GitHub and a flag to test rSA and rSAFor locally. We have also hosted two open meetings for developers on FPS to continue to address questions around use cases for the associated subset. We encourage developers to test out FPS functionality to provide feedback on how the domain limit for the associated subset would impact the usability of FPS for their use cases. We have clarified in WICG calls that Chrome is committed to providing a usable solution that considers users' privacy interests as well. In that vein, we would appreciate feedback from the community on specific use cases that may be impacted by the domain limit, so that the team can consider ways to address these use cases while continuing to protect user privacy. |
| Request for more details about the abuse mitigation measures | What happens if a domain is added to a set they did not consent to? | We have published submission guidelines for First-Party Sets here on December 2, 2022. As explained in the submission guidelines, any set change management will be following and respecting a validation process on GitHub, including validation on ownership, which should mitigate this risk. |
| Abuse mitigation | Concern that First-Party Set formations can be exploited | We are looking at ways to expand technical checks for subset types and are actively seeking additional input from the community here . |
| Ads use cases | Questions on whether First-Party Sets should be used to support Ad targeting | We're not trying to support Ads targeting use cases for First-Party Sets, and we recommend using the Ads APIs available for such use cases. |
| (Also reported in Q3) Policy | Concern that FPS is not consistent with the CMA Commitments regarding "Applicable Data Protection Legislation," on the basis that GDPR does not impose a limit on the number of sites in a set while FPS envisages a limit of 3 | Our response is unchanged from Q3: "Google is continuing to commit to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising, publishers and advertisers as well as impact on privacy outcomes and compliance with data protection principles as set out in the Applicable Data Protection Legislation. The concern expressed does not disclose any incompatibility with GDPR. We continue to work closely with the CMA to ensure that our work complies with these commitments." |
| Alternative proposal | GDPR Validated Sets | In addition to the feedback provided by the ecosystem on the proposal to adopt "GDPR Validated Sets," Chrome has concerns about the following limitations of this alternative proposal:
Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets. |
বেড়া ফ্রেম API
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Fenced Frames restrictions during OT | What are the current restrictions around Fenced Frames for the Origin Trial period? | We are working on documentation on the restrictions and implementation status and plan to share it during Q1 2023. |
| Multiple ads in a single Fenced Frame | Request to display multiple advertisers in one Fenced Frame in one auction | Currently, this request is not being actively developed, but we welcome additional feedback if ecosystem players consider the feature important. |
| Web Bundles | What are the requirements and support planned for Web Bundles with Fenced Frames? | We currently do not have an update on whether this will be the requirement in the future. Any changes would be announced in advance and would not be enforced before third-party cookie deprecation. Please see this explainer for the current status. |
শেয়ার্ড স্টোরেজ API
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Shared Storage for Ad Tech | Uncertainty surrounding the use of shared storage for Ad Tech use cases | Shared Storage and Private Aggregation API can be used for different kinds of measurement purposes that need cross-site storage measurement. Some examples are listed here . We are foreseeing DSP and Measurement solution providers to be the main integrator for ads use cases. |
CHIPs
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| (Also reported in Q3) Partitioned requirement | Add explicit behavior requirement for "Partitioned" attribute on first-party cookies. | Q4 Update: After discussions on GitHub and PrivacyCG calls, the behavior that we have aligned on is that Partitioned cookies set on first-party cookies will use a partition key of (A,A) where "A" is the top-level site. We will document this behavior on the explainer and specification. |
| কুকি ব্যবস্থাপনা | Are there tools for managing/governing first-party or third-party cookies? | Chrome DevTools and NetLog can be used to test sites with third-party cookie blocking enabled. Both tools report when cookies are blocked due to user configuration. We welcome feedback on what sort of additional auditing websites would like to see. |
FedCM
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| IdP requires knowledge of RP to allow a session | Issue when a user is trying to log into the Feide IdP from two different RPs | We are discussing potential solutions to this issue. |
| ইন্টারঅপারেবিলিটি | Concerns regarding the impact of FedCM on the relationship between users and the websites they log into using FedCM, and "interoperability" among websites | FedCM aims to continue supporting federated-identity services that currently rely on third-party cookies once third-party cookies are removed from Chrome. We expect that FedCM will be just one option available to such services; identity providers (IdPs) and relying parties (RPs) are free to use other technologies that may better suit their needs. It appears that concerns regarding the user-RP relationship and "interoperability" owe to a misunderstanding of the FedCM proposal. FedCM leaves it to IdPs to decide what information to share with an RP, and in what form, once the user has chosen to sign in to that RP's site. FedCM does not require IdPs to "create a unique pseudonymous identifier for each [RP] with whom the user authenticates." Rather, FedCM is open for each IdP to choose whether to share the user's actual identifier, a per-site version of that identifier, or some other version of this information. (The FedCM specification does identify cross-site correlation as a privacy risk associated with the API and discusses directed (per-site) identifiers as a possible mitigation. However, the decision whether to use directed identifiers is left to IdPs, not imposed by the browser.) FedCM also already provides for user choice with respect to identity. For example, if a user has multiple identities with the same IdP (eg, a work profile and a personal profile), FedCM provides a way for the user to select which one they want to use to log in to the RP's site. Beyond that, each RP decides for itself which IdPs to support on its site. One aspect of that decision is considering the mechanism that an IdP relies on, whether that's FedCM or a different technology. Again, the browser does not dictate these choices for RPs or IdPs. |
Fight spam and fraud
Private State Token API
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Handling Bots | What happens if the issuer discovers that Private State Tokens have been issued to bots? | To avoid tokens issued to bots from remaining in the ecosystem for a long time, issuers should rotate the keys they use to sign tokens regularly so that old tokens issued under potentially broken issuance logic expire and sites redeem newer tokens with updated issuance logic. |
| Same-site form submissions | Could Private State Tokens be used for same-site form submissions that involve full-page navigation (ie Content-Type: application/x-www-form-urlencoded) rather than a request from the fetch/XMLHttpRequest APIs? | This isn't currently supported in the first version of Private State Tokens. We welcome feedback from the ecosystem if there is a strong demand for this use case. |
| Server-side verification | Questions on whether Private State Tokens can be verified server side | Tokens are redeemed against the issuer, and then the issuer creates a redemption record that could contain the token itself or some signed value derived from the token, servers can use that redemption record to verify the authenticity of the token, and we expect different issuer ecosystems will come up with different standards for how to interpret their redemption records. |
Quarterly report for 2022 Q4 summarizing the ecosystem feedback received on Privacy Sandbox proposals and Chrome's response.
As part of its commitments to the CMA, Google has agreed to publicly provide quarterly reports on the stakeholder engagement process for its Privacy Sandbox proposals (see paragraphs 12 and 17(c)(ii) of the Commitments ). These Privacy Sandbox feedback summary reports are generated by aggregating feedback received by Chrome from the various sources as listed in the feedback overview , including but not limited to: GitHub Issues, the feedback form made available on privacysandbox.com , meetings with industry stakeholders, and web standards forums. Chrome welcomes the feedback received from the ecosystem and is actively exploring ways to integrate learnings into design decisions.
Feedback themes are ranked by prevalence per API. This is done by taking an aggregation of the amount of feedback that the Chrome team has received around a given theme and organizing in descending order of quantity. The common feedback themes were identified by reviewing topics of discussion from public meetings (W3C, PatCG, IETF), direct feedback, GitHub, and commonly asked questions surfacing through Google's internal teams and public forms.
More specifically, meeting minutes for web standard bodies meetings were reviewed and, for direct feedback, Google's records of 1:1 stakeholder meetings, emails received by individual engineers, the API mailing list, and the public feedback form were considered. Google then coordinated between the teams involved in these various outreach activities to determine the relative prevalence of the themes emerging in relation to each API.
The explanations of Chrome's responses to feedback were developed from published FAQs, actual responses made to issues raised by stakeholders, and determining a position specifically for the purposes of this public reporting exercise. Reflecting the current focus of development and testing, questions and feedback were received in particular with respect to Topics, Fledge and Attribution Reporting APIs.
Feedback received after the end of the current reporting period may not yet have a considered Chrome response.
Glossary of acronyms
- চিপস
- Cookies Having Independent Partitioned State
- ডিএসপি
- ডিমান্ড-সাইড প্ল্যাটফর্ম
- FedCM
- ফেডারেটেড শংসাপত্র ব্যবস্থাপনা
- FPS
- First Party Sets
- আইএবি
- ইন্টারেক্টিভ বিজ্ঞাপন ব্যুরো
- আইডিপি
- পরিচয় প্রদানকারী
- আইইটিএফ
- ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স
- আইপি
- ইন্টারনেট প্রোটোকল ঠিকানা
- openRTB
- রিয়েল-টাইম বিডিং
- OT
- অরিজিন ট্রায়াল
- PatCG
- Private Advertising Technology Community Group
- আরপি
- ভরসা পার্টি
- এসএসপি
- Supply-side Platform
- TEE
- বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট
- UA
- User Agent string
- UA-CH
- User-Agent Client Hints
- W3C
- ওয়ার্ল্ড ওয়াইড ওয়েব কনসোর্টিয়াম
- ডব্লিউআইপিবি
- Willful IP Blindness
General feedback, no specific API/Technology
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| (Also reported in Q3) Usefulness for different types of stakeholders | Concerns that the Privacy Sandbox technologies favor larger developers and that niche (smaller) sites contribute more than generic (larger) sites | Our response is unchanged from Q3: "Google has committed to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising and on publishers and advertisers, regardless of their size. We continue to work closely with the CMA to ensure that our work complies with these commitments. As testing of the Privacy Sandbox progresses, one of the key questions we will assess is how the new technologies perform for different types of stakeholders. Feedback is critical in this respect, especially specific and actionable feedback that can help us further improve the technical designs. We have worked with the CMA to develop our approach to quantitative testing, and are supportive of the CMA publishing a note on experiment design to provide more information to market participants and an opportunity to comment on the proposed approaches." |
| (Also reported in Q3) Documentation requests | Requests for more resources detailing how to manage testing, analysis, and implementation | Q4 Update: We appreciate that developers have found our current material helpful, and continue to be committed to providing more material so developers can understand how the new technologies can work for them. Over the past quarter, we added a "News & Updates" section to privacysandbox.com and published an extensive review of how the Privacy Sandbox can help drive ad relevance in the future. We've also held public developer office hours sessions to share best practices and demos, along with Q&A sessions with product and engineering leads to allow for live discussion/questions. |
| কোর ওয়েব ভাইটাল | How does Privacy Sandbox API latency impact Core Web Vitals? | Keeping latency to a minimum is a key design goal of the Privacy Sandbox APIs. Our current expectation is that API latency should have minimal impact on a site's Core Web Vitals, as the majority of APIs are called after the initial rendering of the website. We continue to monitor and make improvements to reduce latency further for each of the APIs, and encourage continued testing and feedback. Latency in the real time bidding process is addressed in the FLEDGE section under "Performance of FLEDGE Auctions" |
| ইন্টারঅপারেবিলিটি | Concerns regarding interoperability with other potential solutions | The goal of Privacy Sandbox is to protect users against cross-site tracking while supporting the needs of the web ecosystem. We seek to accomplish this by moving away from legacy browser technologies that enable such cross-site tracking, like third-party cookies, and providing in their place new technologies purpose-built to support specific use cases. The Privacy Sandbox proposals improve privacy by limiting the data that leaves a user's device. The proposals do not place technical restrictions on a website's ability to share or otherwise process data once collected from the browser. The technologies therefore do not prevent companies from entering into "data stewardship" agreements or any other similar contractual relationship. Likewise, they do not restrict the ability of users to consent to sharing their data via other means. For clarity, Google has committed to apply the Privacy Sandbox technologies in the same way to all websites, including Google products and services. After Chrome ends support for third-party cookies, the commitments also make clear that Google will not use other personal data, such as users' synced Chrome browsing history, to track users for the targeting or measurement of digital advertising. |
Show Relevant Content & Ads
বিষয়
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Impact on Google search ranking | Enquiry on whether a website's Topics API support will be used as a potential signal for Google Search results ranking | Some websites may choose to opt-out of the Topics API. The Privacy Sandbox team has not coordinated or requested from the Search organization that they use page ranking as an incentive for websites to adopt the Topics API. Google has confirmed to the CMA that Google Search will not use a site's decision to opt-out from the Topics API as a ranking signal. |
| Topics classifier | Add url and page content in addition to hostname to determine a webpage's Topic in order to improve utility for various stakeholders. | A user's browsing history is currently classified using a website's hostnames. Chrome continues to evaluate options for considering page level metadata (such as all or some components of the page URL and/or content) in Topics classification. Any utility improvements must be weighed against the privacy and abuse risks. For example, with respect to metadata in particular, a few of the risks include: - Sites modifying page-level metadata as a method to encode different (and potentially sensitive) meanings into topics; - Sites modifying page-level metadata to misrepresent their topics for financial gain; - Sites modifying page-level metadata dynamically as a method of cross-site tracking |
| (Also reported in Q3) Impact on first-party signals | Topics signal may be highly valuable and as a result devalues other first-party interest-based signals. | Our response is unchanged from Q3: "We believe interest-based advertising is an important use case for the web, and Topics is designed to support that use case. As described [in our Q3 report], other ecosystem stakeholders have expressed concerns that Topics may not be useful enough to provide value. In all cases, improvements to the taxonomy are an ongoing effort, and we expect the taxonomy to evolve with ecosystem testing and input." |
| Updating Taxonomy | How will the taxonomy list be updated? | We are actively seeking feedback on the taxonomy that would be most useful for the ecosystem. The taxonomy included in the initial Topics API proposal was designed to enable functional testing. Chrome is actively considering multiple approaches for updating the taxonomy. For example, Chrome may utilize a notion of commercial value for each topic to determine which category to include in future iterations. |
| Topics regional classifier performance | Topics classifier performing poorly in regional domains | Improvement to the classifier is an ongoing effort. Based on the feedback we have received, one possibility under consideration is to expand the Topics override list, which our analysis shows will increase global coverage and improve accuracy. To explain, the Topics API classification has two relevant components: (1) An override list containing the top 10k sites and their topics, and (2) an on-device ML model that classifies hostnames into topics. By expanding the override list (1), we can improve performance of classification for those regions in which the classifier may be performing poorly. |
| One week epoch | The one week epoch is too long for users looking to make shorter term decisions. | We are actively looking at what the suitable length of epoch should be and we welcome further feedback on what would be a better epoch for the ecosystem. |
| HTTP header retrieval | Concern that there is not enough information regarding the HTTP header retrieval of topics | Work is in progress for headers and fetch(). We also have information available here . We have also added skipObservation information to the explainer. |
| Topics only aims to help advertisers, not users | Topics/Privacy Sandbox appears to be an industry focused approach. Benefit for users is not as clear as benefit to industry. | We believe the benefit to users is that Topics supports interest-based ads that keep the web free and open, and we also believe it significantly improves privacy compared to third-party cookies. Removing third-party cookies without viable alternatives may negatively impact publishers, and could lead to worse approaches which are less private, are not transparent, and are not realistically resettable or controlled by users. Many companies are actively testing Topics and Sandbox APIs, and we're committed to providing the tools to advance privacy and support the web. The W3C Technical Architecture Group has recently published its initial view about the Topics API, which we will be responding to publicly. At this stage, since Google has received questions from the ecosystem about what this review may imply for the development and launch of the Topics API, we would like to reaffirm our plan to make it available in Chrome Stable this year. While Googles appreciates the input of the W3C Technical Architecture Group, it considers it of paramount importance to continue the efforts to develop and test Topics in consultation with the CMA and the ecosystem. |
| ডেটা ফাঁস | Concern that Topics may be leaked to other sites without permission | The design of the Topics API makes it quite unlikely that data from a single publisher (and even a smaller group of publishers) can be leaked in any way. Publisher websites are also in full control over the Topics API and they can prohibit access to this API via permission policy. |
| Lack of advertisers for testing | Publishers are concerned that they currently are unable to demonstrate the value of Topics to advertisers. | In the second half of 2023, we plan to have all the ads related APIs available for integration testing and enable ecosystem analysis of the value of Topics for advertisers. Testing and publication of the results will be supervised by the CMA, which will review the data, analysis and methodology. The ecosystem is encouraged to share feedback with Google and the CMA. |
| Topics and FLEDGE | Request for more information on how to use Topics within FLEDGE's bidding logic | It is possible to use Topics within FLEDGE's bidding logic. An integration guide is also in progress, and will include additional details on implementation. |
| Custom ranking for topics caller | Allow rankings to be tailored by caller | The challenge with custom topic ranking or values for each ad tech is that this could become a mechanism by which an ad tech can influence the topics that are returned, therefore a fingerprinting vector. |
| Topics caller priority list | Allow callers to provide a ranked priority list of topics that the Topics API will return based on eligibility. | We are currently discussing this idea further and welcome additional inputs. |
FLEDGE
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| গুগল অ্যাড ম্যানেজার | Concern that Google Ad Manager is the end decider for FLEDGE auctions and would favor Google Publisher Tags and Google Ad Manager. | FLEDGE allows each publisher to choose the structure of the auction, including the choice of top-level and component sellers. Each buyer and seller in a component auction knows who the top-level seller is, and can choose whether or not to bid. |
| Not enough participants testing FLEDGE | Request to encourage more companies to test FLEDGE, for example by improving the API's functionality and discouraging privacy-intrusive alternatives like fingerprinting | The Privacy Sandbox is proceeding in stages, in close partnership with the guidance of the CMA and ICO, and functional FLEDGE testing has demonstrated necessary stability and capability. Google continues to encourage the ecosystem to test the Sandbox APIs, recently publishing its " Maximize Ad Relevance " documentation to showcase how FLEDGE and other APIs can help support critical use cases for the ad industry after third-party cookie deprecation. Other parts of the Privacy Sandbox already support mitigations to cover tracking (see UA-CH, IP Protection, and Bounce Tracking Mitigations) and will continue to improve over time. Google's goal is not to make FLEDGE the only viable targeting solution, but instead remains committed to working in partnership with industry and regulators to drive the best privacy-preserving ad technologies in the Chrome browser. |
| মেশিন লার্নিং ব্যবহারের ক্ষেত্রে | More guidance on how machine learning use cases to train auction bidding algorithms will be supported in FLEDGE and Attribution Reporting | We recognize the need to help testers find the most useful ways of applying the Privacy Sandbox technologies. We have begun to publish guidance specifically related to the use of the various aspects of the Privacy Sandbox APIs as inputs to machine learning. The most recent piece, Maximize Ad Relevance , discusses how the ads industry can use these signals for machine learning, and we plan to continue publishing such guidance going forward. |
| Querying FLEDGE Key Value (K/V) Server | Why is the K/V server publicly queryable? | The K/V server aims to provide real time signals to FLEDGE auctions. As such, the K/V server needs to be accessible from where those FLEDGE auctions execute, which is on user devices, requiring that it be publicly available. A value stored in the K/V server can only be retrieved by a party that already has its key — so if an ad tech only gives the keys to browsers that are in the Interest Group, and does not use keys that can be randomly guessed, then only browsers that need the Value to run their auction will be able to retrieve it. |
| How to do date/time targeting? | Support for date objects in the bidding logic function. | এটি করার একাধিক উপায় আছে। Buyers can ask their seller to provide the current date and time, and it should be easy for sellers to provide this information to all buyers. Buyers can also provide the date and time in their real time key-value response. Finally, buyers can provide the date and time as part of their contextual response in the per-buyer-signals , which a seller could pass to the buyer's generateBid script. |
| ব্যবহারকারীর পছন্দ | Ability for users to choose to block creatives by advertiser when served via FLEDGE, or alternative solutions. | Users have the ability to opt out of Ads APIs in Chrome. For specific ads, the relevant ad tech is the party best positioned to offer controls over which creatives are shown or how they are selected. |
| Clearer timelines | Request for more information on availability of privacy protections in FLEDGE, such as requiring Fenced Frames. | We plan to publish more detailed timelines in Q1. |
| Reporting confusion | Request for more clarity on how FLEDGE reporting will work with other APIs such as Fenced Frames and Private Aggregation API. | We plan to publish an explainer on the interaction between Private Aggregation API, FLEDGE, and Fenced Frames in the coming weeks. |
| Real-time bidding and FLEDGE | Guidance on how FLEDGE integrates with standard real-time bidding. | The two main things that complicate an ad-tech's ability to do real-time bidding are access to event level data and easier integration into ARA. We are planning on sending updates and explainers on both of these in Q1. |
| Performance of FLEDGE Auctions | Report from testers that FLEDGE auctions have high latency | We appreciate reports from testers sharing their results and use cases and have shared some suggestions on how to improve the performance of FLEDGE . In parallel, we have added tooling to the browser allowing developers to better diagnose what is making auctions slow , and have been systematically addressing the primary sources of latency observed. Recent improvements include timeouts for slow auctions , a fast bidder filtering technique , a way to reuse FLEDGE worklets to avoid paying startup costs , and ongoing work to allow the contextual ad request to run in parallel with the FLEDGE startup time and network fetches. We expect latency optimization to continue as an ongoing conversation between Chrome developers and FLEDGE testers based on their real-world experience using the API. |
| Interest Group size memory limit | Request to raise the limit on the size of a single interest group from 50kB. | We are actively considering the request and are looking for feedback on what limit value works . |
| Combining the FLEDGE served data with first-party cookie | Will FLEDGE support integration with an advertiser's first-party data? | FLEDGE was built to support advertising using the first-party data an advertiser already has. However, FLEDGE does not intend to support an advertiser learning a person's browsing behavior on any website other than the advertiser's own site. Attaching off-site browsing behavior to first-party data is contrary to the goals of Privacy Sandbox. We are planning to share integration guides with more details on how FLEDGE will support integration with first-party data in the coming weeks. |
| K-anonymity value | How will the value "K" to "k-anon" be decided and will it be published? | The "K" value is still being finalized and we will share more information as our plans develop. We are interested in learning more about how an unknown k value may hinder FLEDGE preparedness and scoping ML model training and we welcome additional feedback on this subject. |
| Supporting multiple SSPs | How will multiple SSPs be supported in FLEDGE? | FLEDGE supports multi-seller auctions as noted in this proposal . |
| Visibility of bidding logic | Concern that DSP bidding logic will be exposed in JavaScript | With the current design bidding logic JavaScript can be accessed by others, but we welcome more feedback as to why this could be a source of concern for DSPs. |
| prebid.js | What is the timeline in supporting prebid.js in FLEDGE? | Only versions 7.14 and later of Prebid.js support the FLEDGE module. Any publishers interested in testing must add the FLEDGE module and upgrade their Prebid instance. |
| User defined functions in FLEDGE | How will user defined functions (UDF) be supported in FLEDGE? These are functions that can be programmed by end users to extend the functionality of the API. | Explainer available here . This is still being fleshed out so we welcome additional feedback on use cases. |
| Relaxing same-origin constraint on Interest Group resources | Request to relax same-origin constraint on Interest Group resources to enable certain ad tech use cases | In the current implementation of FLEDGE, biddingLogicUrl , biddingWasmHelperUrl , dailyUpdateUrl and trustedBiddingSignalsUrl must have the same origin as the interest group owner.The constraint exists to prevent certain exploits by attackers, as explained here . |
| interestGroup Ownership | Request to limit whether an ad tech can use joinInterestGroup for the same Interest Groups across sites | Our focus is on how audiences are used, not how they are built. We are discussing potential approaches and welcome additional input. |
| Key Value Server Key Expiration | Discussion on removing server keys once the corresponding interest groups have expired | We are exploring ways to handle key expiration and are looking for feedback . |
Measuring Digital Ads
Attribution Reporting (and other APIs)
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Origin Trial traffic | Current Origin Trial traffic is not enough to conduct utility testing. | The current Origin Trials are meant for ecosystem players to conduct functional testing in order to ensure the API is working as intended. We understand that larger amounts of traffic will be required to perform utility testing once the development of the various Privacy Sandbox API is more mature. The current testing timeline envisages that this will occur by General Availability (ie when the technologies for the use cases will be launched and available for 100% of Chrome traffic) at Q3 2023 (see our up-to-date timeline on privacysandbox.com ).We welcome any additional feedback on use case testing that requires additional traffic. |
| Overlap in functionality of different Privacy Sandbox measurement APIs | Concerns in having multiple measurement approaches overlap through Privacy Sandbox will increase complexity, for example, Attribution Reporting API and Private Aggregation API. | We are working on better documentation to clarify the different use cases for the APIs, and welcome additional feedback on what areas are lacking explanation. For example, Attribution Reporting API is intended specifically to support conversion measurement, whereas Private Aggregation API and Shared Storage are general-purpose APIs intended to support a broader range of cross-site measurement use-cases. |
| Retry failed report request | Clarification on how many times a report request is attempted if it fails. | We have published guidance on this . To summarize, reports are only sent when the browser is running/online. After the first failure to send, the report is retried after 5 minutes. After the second failure, the report is retried after 15 minutes. After that the report is not sent. |
| Reporting Delay | What is the expected reporting delay? | We are looking to hear more feedback from the ecosystem on any reporting delays they are experiencing as we collect data to further assess these delays in parallel. |
| Prerender pages | Will ARA attribution work on prerender pages? | Attribution registration is deferred on prerender pages until activation (actual click or view takes place). This means we will defer the `attributionsrc` request ping. |
| রূপান্তর লিফট পরিমাপ | How to measure conversion lift with AB testing on the same domain | Websites can measure conversion lift with A/B testing on the same domain through attribution reporting. They can encode their A/B parameters as keys using the aggregate API and then receive summary reports for the conversion values by those key buckets. |
| (Also reported in Q3) Cross-domain conversions | How to track the conversions that are cross domain, such as with 2 or more destinations | Q4 Update: We have published a proposal to remove the landing page destination restriction which enables cross domain conversations to be tracked. This proposal has been implemented. |
| (Also reported in Q3) Expiry setting in conversion report | Request to support report filter / expiry for less than 24 hours | Q4 Update: We have shared this pull request which will decouple expiry and reporting windows to mitigate the trade off of reporting delay vs conversion expiry. This is now launched in M110. |
| Fraud and Abuse | Requests from advertisers and marketers to be able to slice and aggregate data based on publisher sites where their ads are served, which would also give more insight into potential fraudulent ad practices | This feedback is actively being discussed here and we welcome additional inputs. |
| (Also reported in Q3) Event level reporting delay | The delay of 2-30 days in event level reporting may be too long for certain use cases. | Event level reporting has default reporting windows of 2, 7, and 30 days. This can be modified by using the "expiry" parameter. Ad-techs could configure the expiry, with a minimum of 1 day, to get potential reports in less than 2 days. We limit the granularity of expiries to 1 day as a privacy protection mechanism, as more fine-grained reporting could result in timing attacks. Additionally, we allow setting independent "expiry" parameters for event level and aggregate reports. এখানে দেখুন. Additionally, Google Ads will not get any special reporting windows that other ad-techs do not get via the Attribution Reporting API. |
| Same reporting origin requirement | Request to remove requirement for source registration origin to be the same as the conversion registration origin | We propose using HTTP redirects to delegate registration to solve this use-case. We welcome any additional feedback on the new guidance. |
| রূপান্তর ট্র্যাকিং | Need to differentiate whether the conversion happened before/after certain hours set by the advertiser | Attribution Reporting API supports setting an expiry window and priority for source attribution. By using both, it will technically be possible to attribute a conversion that happened within X days window separately from a conversion that happened after X. |
| Noise simulation | Request to be able to simulate the different volume of conversions per bucket, to understand the impact on advertisers with less conversions | We are looking to add ways to simulate this in future versions of Noise Lab . We welcome any additional feedback. |
| Reporting on mobile | Will the report still be sent when Chrome is running in the background on mobile? | At the moment, even on mobile, the report will not be sent when Chrome is in the background. This is likely to change when the API integrates with Android Privacy Sandbox. এখানে দেখুন. Note that Android Privacy Sandbox is not part of the Commitments accepted by the CMA. |
| ডেটা প্রাপ্যতা | Concerns that Google will have additional access to data via Privacy Sandbox APIs | First, Google Ads does not receive any preferential access to data from the Attribution Reporting API or other Privacy Sandbox APIs. This issue is also addressed in the General Feedback section under "Interoperability" which includes more detail on Google's Commitments. Second, on the difference between larger and smaller sites, Google recognizes that noise-based privacy protections may have a greater impact on smaller data slices. However, there are some possible mitigations: for instance, methods like aggregating over longer periods of time would solve this problem. That said, it remains unclear if conclusions based on very small data slices (like one or two purchases) are meaningful at all to advertisers. During the origin trial, Google has encouraged testers to take advantage of the ability to experiment with a wide range of privacy and noise parameters so they can provide more specific feedback on this issue. |
Limit Covert Tracking
ব্যবহারকারী-এজেন্ট হ্রাস
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Delay User-Agent Reduction until web ecosystem is more ready | There is not sufficient time to adapt to the coming User-Agent Reduction changes. | We address this feedback in the full report under "Stakeholder Concerns" in the section titled "Google's interaction with the CMA". |
| Delay User-Agent Reduction until web ecosystem is more ready | Request to delay User-Agent Reduction rollout until Structured User Agents (SUA) is deployed | The Google Ads team proposed the Structured User-Agent addition (see specification ) to OpenRTB in October 2021 and it was incorporated in the 2.6 spec update released in April 2022. We have some evidence that SUA is deployed and available today, as demonstrated by the Scientia Mobile blog post demonstrating how to use UA-CH and the WURFL API to create a SUA. |
###
User-Agent Client Hints
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Test UA-CH with other anti-covert tracking techniques | Guidance on how to test all Privacy Sandbox APIs and fingerprinting techniques proposed together in a holistic approach | Our testing plan was designed in order to reflect the asynchronous timelines for developing some of the anti-fingerprinting measures as opposed to the rest of the Sandbox Proposals. It addresses the reality that some anti-fingerprinting measures (ie Privacy Budget, IP Protection and Bounce Tracking Mitigations) will be fully-developed and ready for launch to General Availability only after third-party cookie deprecation. While those anti-fingerprinting measures will not be included in quantitative tests, they will be subject to qualitative assessment based on the facts available at the time of Standstill. |
| (Also reported in Q2) কর্মক্ষমতা | Concerns about the latency of getting hints via Critical-CH (on the first page load) | See dedicated UA-CH section below |
| Insufficient Feedback | Feedback from the ecosystem about the UA-CH change may not be sufficient, leading to concerns about a lack of awareness from the ecosystem. | We've been proactively sharing our plans to ensure a careful rollout that minimizes disruption. The plans for User-Agent Reduction and the UA-CH API were presented to the W3C Anti-Fraud Community Group on March 18th, 2022 and to both the Web Payments Working Group and the Web Payments Security Interest Group on January 20th, 2022. No significant concerns were raised during or after the presentations. Google has proactively engaged with more than 100 site operators to obtain feedback. Furthermore, Google has also used Blink-Dev channels to communicate the roll-out of the user-agent reduction publicly based on feedback from ecosystem stakeholders. |
| টাইমিং | Concerns raised regarding timing of rollout and industry preparedness | See dedicated UA-CH section below |
| Chrome Platform Status | Requested that the chromestatus page for UA-CH be updated | The chromestatus entry was updated on December 19 to "Mixed signals". |
IP Protection (formerly Gnatcatcher)
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Opt in or Opt Out | Is IP Address Privacy Opt In or Opt Out? | Our goal is to provide IP Protection to all users. With that goal in mind, we are currently evaluating user choice options for IP Protection. |
| IP Address use case for first-party data | Is it possible to use IP addresses to stitch together user journeys across first-party domains post IP Protection? | As previously published , IP Protection will initially focus on tracking in the third-party context, which means first-party domains will not be impacted. |
| Ad Tech use cases | How can companies set up anti-fraud measures with IP Protection? | We recognize the importance of IP address as a signal for anti-fraud efforts in today's web. As part of our Commitments to the CMA (paragraph 20), we have said that we will not implement IP Protection without making reasonable efforts to support websites' ability to conduct anti-spam and anti-fraud efforts. One of our top priorities is to understand how IP Protection impacts anti-fraud use cases and detection capabilities, so that we can further invest in privacy preserving technologies that help companies preserve web safety. We encourage feedback and input on new proposals aimed at supporting the needs of security and anti-fraud companies, even as signals change over time. |
| Fraud and Abuse | Does IP protection include Denial of Service (DoS) Protection? | We are committed to improving privacy while keeping the web safe, and protecting against denial-of-service attacks is an important anti-abuse use case to design for. We hope to minimize impact to DoS protections through both the design of IP Protection itself and through new anti-abuse solutions. Because IP Protection is initially focused on third-party embedded services, some stakeholders have indicated that it should have limited impact on DoS protection for first-party sites. However we continue to ask for public feedback to assess risk to DoS use cases, particularly to third-party embedded services. In parallel, we are exploring abuse-feedback and client-blocking mechanisms that would enable a site or service to block a spammy user, without identifying the user. |
| বিষয়বস্তু ফিল্টারিং | Content filtering with IP Protection | Different companies have different needs with respect to filtering content and customizing user experience. Many such use cases do not currently rely on IP addresses and therefore should be unaffected by IP Protection. For example, a publisher looking to tailor its content and drive more engagement might use first-party cookies or third-party partitioned cookies (CHIPs) to understand a user's interests and previous interactions with the publisher. Or an ad tech partner focused on delivering the right ad to the right user can incorporate FLEDGE and Topics, for example, to deliver similar ad outcomes as they do today with third-party cookies or other cross-site tracking technologies. We are also exploring building new privacy-preserving capabilities into IP Protection, such as coarse geolocation, to further support content filtering where existing mechanisms may be insufficient. We welcome additional feedback on content filtering use cases that may be impacted by IP Protection. |
| (Also reported in Q3) Geolocation use cases | IP Protection may prevent legitimate geolocation use cases from working in the future, such as content personalisation based on geolocation. | Q4 Update: We are working with stakeholders to ensure that Chrome continues to support legitimate use-cases for IP addresses. We are seeking ecosystem feedback on IP Geolocation granularity here . |
গোপনীয়তা বাজেট
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Clearer documentation | More examples so stakeholders can anticipate how things may be limited once Privacy Budget is implemented | The Privacy Budget proposal is still under active discussion and has not been implemented by any browsers. The earliest date of scaled availability represents the earliest date when Privacy Budget could be enforced. This will not happen before the removal of third-party cookies in 2024. We do not have any additional documentation to share at the moment. We will share additional details on the proposal when it becomes more finalized. In the meantime, we welcome stakeholders to share any feedback that would help in the development of the proposal. |
ক্রস-সাইট গোপনীয়তা সীমানা শক্তিশালী করুন
First-Party Sets
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| (Also reported in Q3) Domain limit | Request to expand the number of associated domains | Q4 Update: We have released FPS for local testing, including a mock set submission process on GitHub and a flag to test rSA and rSAFor locally. We have also hosted two open meetings for developers on FPS to continue to address questions around use cases for the associated subset. We encourage developers to test out FPS functionality to provide feedback on how the domain limit for the associated subset would impact the usability of FPS for their use cases. We have clarified in WICG calls that Chrome is committed to providing a usable solution that considers users' privacy interests as well. In that vein, we would appreciate feedback from the community on specific use cases that may be impacted by the domain limit, so that the team can consider ways to address these use cases while continuing to protect user privacy. |
| Request for more details about the abuse mitigation measures | What happens if a domain is added to a set they did not consent to? | We have published submission guidelines for First-Party Sets here on December 2, 2022. As explained in the submission guidelines, any set change management will be following and respecting a validation process on GitHub, including validation on ownership, which should mitigate this risk. |
| Abuse mitigation | Concern that First-Party Set formations can be exploited | We are looking at ways to expand technical checks for subset types and are actively seeking additional input from the community here . |
| Ads use cases | Questions on whether First-Party Sets should be used to support Ad targeting | We're not trying to support Ads targeting use cases for First-Party Sets, and we recommend using the Ads APIs available for such use cases. |
| (Also reported in Q3) Policy | Concern that FPS is not consistent with the CMA Commitments regarding "Applicable Data Protection Legislation," on the basis that GDPR does not impose a limit on the number of sites in a set while FPS envisages a limit of 3 | Our response is unchanged from Q3: "Google is continuing to commit to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising, publishers and advertisers as well as impact on privacy outcomes and compliance with data protection principles as set out in the Applicable Data Protection Legislation. The concern expressed does not disclose any incompatibility with GDPR. We continue to work closely with the CMA to ensure that our work complies with these commitments." |
| Alternative proposal | GDPR Validated Sets | In addition to the feedback provided by the ecosystem on the proposal to adopt "GDPR Validated Sets," Chrome has concerns about the following limitations of this alternative proposal:
Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets. |
বেড়া ফ্রেম API
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Fenced Frames restrictions during OT | What are the current restrictions around Fenced Frames for the Origin Trial period? | We are working on documentation on the restrictions and implementation status and plan to share it during Q1 2023. |
| Multiple ads in a single Fenced Frame | Request to display multiple advertisers in one Fenced Frame in one auction | Currently, this request is not being actively developed, but we welcome additional feedback if ecosystem players consider the feature important. |
| Web Bundles | What are the requirements and support planned for Web Bundles with Fenced Frames? | We currently do not have an update on whether this will be the requirement in the future. Any changes would be announced in advance and would not be enforced before third-party cookie deprecation. Please see this explainer for the current status. |
শেয়ার্ড স্টোরেজ API
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Shared Storage for Ad Tech | Uncertainty surrounding the use of shared storage for Ad Tech use cases | Shared Storage and Private Aggregation API can be used for different kinds of measurement purposes that need cross-site storage measurement. Some examples are listed here . We are foreseeing DSP and Measurement solution providers to be the main integrator for ads use cases. |
CHIPs
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| (Also reported in Q3) Partitioned requirement | Add explicit behavior requirement for "Partitioned" attribute on first-party cookies. | Q4 Update: After discussions on GitHub and PrivacyCG calls, the behavior that we have aligned on is that Partitioned cookies set on first-party cookies will use a partition key of (A,A) where "A" is the top-level site. We will document this behavior on the explainer and specification. |
| কুকি ব্যবস্থাপনা | Are there tools for managing/governing first-party or third-party cookies? | Chrome DevTools and NetLog can be used to test sites with third-party cookie blocking enabled. Both tools report when cookies are blocked due to user configuration. We welcome feedback on what sort of additional auditing websites would like to see. |
FedCM
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| IdP requires knowledge of RP to allow a session | Issue when a user is trying to log into the Feide IdP from two different RPs | We are discussing potential solutions to this issue. |
| ইন্টারঅপারেবিলিটি | Concerns regarding the impact of FedCM on the relationship between users and the websites they log into using FedCM, and "interoperability" among websites | FedCM aims to continue supporting federated-identity services that currently rely on third-party cookies once third-party cookies are removed from Chrome. We expect that FedCM will be just one option available to such services; identity providers (IdPs) and relying parties (RPs) are free to use other technologies that may better suit their needs. It appears that concerns regarding the user-RP relationship and "interoperability" owe to a misunderstanding of the FedCM proposal. FedCM leaves it to IdPs to decide what information to share with an RP, and in what form, once the user has chosen to sign in to that RP's site. FedCM does not require IdPs to "create a unique pseudonymous identifier for each [RP] with whom the user authenticates." Rather, FedCM is open for each IdP to choose whether to share the user's actual identifier, a per-site version of that identifier, or some other version of this information. (The FedCM specification does identify cross-site correlation as a privacy risk associated with the API and discusses directed (per-site) identifiers as a possible mitigation. However, the decision whether to use directed identifiers is left to IdPs, not imposed by the browser.) FedCM also already provides for user choice with respect to identity. For example, if a user has multiple identities with the same IdP (eg, a work profile and a personal profile), FedCM provides a way for the user to select which one they want to use to log in to the RP's site. Beyond that, each RP decides for itself which IdPs to support on its site. One aspect of that decision is considering the mechanism that an IdP relies on, whether that's FedCM or a different technology. Again, the browser does not dictate these choices for RPs or IdPs. |
Fight spam and fraud
Private State Token API
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Handling Bots | What happens if the issuer discovers that Private State Tokens have been issued to bots? | To avoid tokens issued to bots from remaining in the ecosystem for a long time, issuers should rotate the keys they use to sign tokens regularly so that old tokens issued under potentially broken issuance logic expire and sites redeem newer tokens with updated issuance logic. |
| Same-site form submissions | Could Private State Tokens be used for same-site form submissions that involve full-page navigation (ie Content-Type: application/x-www-form-urlencoded) rather than a request from the fetch/XMLHttpRequest APIs? | This isn't currently supported in the first version of Private State Tokens. We welcome feedback from the ecosystem if there is a strong demand for this use case. |
| Server-side verification | Questions on whether Private State Tokens can be verified server side | Tokens are redeemed against the issuer, and then the issuer creates a redemption record that could contain the token itself or some signed value derived from the token, servers can use that redemption record to verify the authenticity of the token, and we expect different issuer ecosystems will come up with different standards for how to interpret their redemption records. |
Quarterly report for 2022 Q4 summarizing the ecosystem feedback received on Privacy Sandbox proposals and Chrome's response.
As part of its commitments to the CMA, Google has agreed to publicly provide quarterly reports on the stakeholder engagement process for its Privacy Sandbox proposals (see paragraphs 12 and 17(c)(ii) of the Commitments ). These Privacy Sandbox feedback summary reports are generated by aggregating feedback received by Chrome from the various sources as listed in the feedback overview , including but not limited to: GitHub Issues, the feedback form made available on privacysandbox.com , meetings with industry stakeholders, and web standards forums. Chrome welcomes the feedback received from the ecosystem and is actively exploring ways to integrate learnings into design decisions.
Feedback themes are ranked by prevalence per API. This is done by taking an aggregation of the amount of feedback that the Chrome team has received around a given theme and organizing in descending order of quantity. The common feedback themes were identified by reviewing topics of discussion from public meetings (W3C, PatCG, IETF), direct feedback, GitHub, and commonly asked questions surfacing through Google's internal teams and public forms.
More specifically, meeting minutes for web standard bodies meetings were reviewed and, for direct feedback, Google's records of 1:1 stakeholder meetings, emails received by individual engineers, the API mailing list, and the public feedback form were considered. Google then coordinated between the teams involved in these various outreach activities to determine the relative prevalence of the themes emerging in relation to each API.
The explanations of Chrome's responses to feedback were developed from published FAQs, actual responses made to issues raised by stakeholders, and determining a position specifically for the purposes of this public reporting exercise. Reflecting the current focus of development and testing, questions and feedback were received in particular with respect to Topics, Fledge and Attribution Reporting APIs.
Feedback received after the end of the current reporting period may not yet have a considered Chrome response.
Glossary of acronyms
- চিপস
- Cookies Having Independent Partitioned State
- ডিএসপি
- ডিমান্ড-সাইড প্ল্যাটফর্ম
- FedCM
- ফেডারেটেড শংসাপত্র ব্যবস্থাপনা
- FPS
- First Party Sets
- আইএবি
- ইন্টারেক্টিভ বিজ্ঞাপন ব্যুরো
- আইডিপি
- পরিচয় প্রদানকারী
- আইইটিএফ
- ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স
- আইপি
- ইন্টারনেট প্রোটোকল ঠিকানা
- openRTB
- রিয়েল-টাইম বিডিং
- OT
- অরিজিন ট্রায়াল
- PatCG
- Private Advertising Technology Community Group
- আরপি
- ভরসা পার্টি
- এসএসপি
- Supply-side Platform
- TEE
- বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট
- UA
- User Agent string
- UA-CH
- User-Agent Client Hints
- W3C
- ওয়ার্ল্ড ওয়াইড ওয়েব কনসোর্টিয়াম
- ডব্লিউআইপিবি
- Willful IP Blindness
General feedback, no specific API/Technology
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| (Also reported in Q3) Usefulness for different types of stakeholders | Concerns that the Privacy Sandbox technologies favor larger developers and that niche (smaller) sites contribute more than generic (larger) sites | Our response is unchanged from Q3: "Google has committed to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising and on publishers and advertisers, regardless of their size. We continue to work closely with the CMA to ensure that our work complies with these commitments. As testing of the Privacy Sandbox progresses, one of the key questions we will assess is how the new technologies perform for different types of stakeholders. Feedback is critical in this respect, especially specific and actionable feedback that can help us further improve the technical designs. We have worked with the CMA to develop our approach to quantitative testing, and are supportive of the CMA publishing a note on experiment design to provide more information to market participants and an opportunity to comment on the proposed approaches." |
| (Also reported in Q3) Documentation requests | Requests for more resources detailing how to manage testing, analysis, and implementation | Q4 Update: We appreciate that developers have found our current material helpful, and continue to be committed to providing more material so developers can understand how the new technologies can work for them. Over the past quarter, we added a "News & Updates" section to privacysandbox.com and published an extensive review of how the Privacy Sandbox can help drive ad relevance in the future. We've also held public developer office hours sessions to share best practices and demos, along with Q&A sessions with product and engineering leads to allow for live discussion/questions. |
| কোর ওয়েব ভাইটাল | How does Privacy Sandbox API latency impact Core Web Vitals? | Keeping latency to a minimum is a key design goal of the Privacy Sandbox APIs. Our current expectation is that API latency should have minimal impact on a site's Core Web Vitals, as the majority of APIs are called after the initial rendering of the website. We continue to monitor and make improvements to reduce latency further for each of the APIs, and encourage continued testing and feedback. Latency in the real time bidding process is addressed in the FLEDGE section under "Performance of FLEDGE Auctions" |
| ইন্টারঅপারেবিলিটি | Concerns regarding interoperability with other potential solutions | The goal of Privacy Sandbox is to protect users against cross-site tracking while supporting the needs of the web ecosystem. We seek to accomplish this by moving away from legacy browser technologies that enable such cross-site tracking, like third-party cookies, and providing in their place new technologies purpose-built to support specific use cases. The Privacy Sandbox proposals improve privacy by limiting the data that leaves a user's device. The proposals do not place technical restrictions on a website's ability to share or otherwise process data once collected from the browser. The technologies therefore do not prevent companies from entering into "data stewardship" agreements or any other similar contractual relationship. Likewise, they do not restrict the ability of users to consent to sharing their data via other means. For clarity, Google has committed to apply the Privacy Sandbox technologies in the same way to all websites, including Google products and services. After Chrome ends support for third-party cookies, the commitments also make clear that Google will not use other personal data, such as users' synced Chrome browsing history, to track users for the targeting or measurement of digital advertising. |
Show Relevant Content & Ads
বিষয়
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Impact on Google search ranking | Enquiry on whether a website's Topics API support will be used as a potential signal for Google Search results ranking | Some websites may choose to opt-out of the Topics API. The Privacy Sandbox team has not coordinated or requested from the Search organization that they use page ranking as an incentive for websites to adopt the Topics API. Google has confirmed to the CMA that Google Search will not use a site's decision to opt-out from the Topics API as a ranking signal. |
| Topics classifier | Add url and page content in addition to hostname to determine a webpage's Topic in order to improve utility for various stakeholders. | A user's browsing history is currently classified using a website's hostnames. Chrome continues to evaluate options for considering page level metadata (such as all or some components of the page URL and/or content) in Topics classification. Any utility improvements must be weighed against the privacy and abuse risks. For example, with respect to metadata in particular, a few of the risks include: - Sites modifying page-level metadata as a method to encode different (and potentially sensitive) meanings into topics; - Sites modifying page-level metadata to misrepresent their topics for financial gain; - Sites modifying page-level metadata dynamically as a method of cross-site tracking |
| (Also reported in Q3) Impact on first-party signals | Topics signal may be highly valuable and as a result devalues other first-party interest-based signals. | Our response is unchanged from Q3: "We believe interest-based advertising is an important use case for the web, and Topics is designed to support that use case. As described [in our Q3 report], other ecosystem stakeholders have expressed concerns that Topics may not be useful enough to provide value. In all cases, improvements to the taxonomy are an ongoing effort, and we expect the taxonomy to evolve with ecosystem testing and input." |
| Updating Taxonomy | How will the taxonomy list be updated? | We are actively seeking feedback on the taxonomy that would be most useful for the ecosystem. The taxonomy included in the initial Topics API proposal was designed to enable functional testing. Chrome is actively considering multiple approaches for updating the taxonomy. For example, Chrome may utilize a notion of commercial value for each topic to determine which category to include in future iterations. |
| Topics regional classifier performance | Topics classifier performing poorly in regional domains | Improvement to the classifier is an ongoing effort. Based on the feedback we have received, one possibility under consideration is to expand the Topics override list, which our analysis shows will increase global coverage and improve accuracy. To explain, the Topics API classification has two relevant components: (1) An override list containing the top 10k sites and their topics, and (2) an on-device ML model that classifies hostnames into topics. By expanding the override list (1), we can improve performance of classification for those regions in which the classifier may be performing poorly. |
| One week epoch | The one week epoch is too long for users looking to make shorter term decisions. | We are actively looking at what the suitable length of epoch should be and we welcome further feedback on what would be a better epoch for the ecosystem. |
| HTTP header retrieval | Concern that there is not enough information regarding the HTTP header retrieval of topics | Work is in progress for headers and fetch(). We also have information available here . We have also added skipObservation information to the explainer. |
| Topics only aims to help advertisers, not users | Topics/Privacy Sandbox appears to be an industry focused approach. Benefit for users is not as clear as benefit to industry. | We believe the benefit to users is that Topics supports interest-based ads that keep the web free and open, and we also believe it significantly improves privacy compared to third-party cookies. Removing third-party cookies without viable alternatives may negatively impact publishers, and could lead to worse approaches which are less private, are not transparent, and are not realistically resettable or controlled by users. Many companies are actively testing Topics and Sandbox APIs, and we're committed to providing the tools to advance privacy and support the web. The W3C Technical Architecture Group has recently published its initial view about the Topics API, which we will be responding to publicly. At this stage, since Google has received questions from the ecosystem about what this review may imply for the development and launch of the Topics API, we would like to reaffirm our plan to make it available in Chrome Stable this year. While Googles appreciates the input of the W3C Technical Architecture Group, it considers it of paramount importance to continue the efforts to develop and test Topics in consultation with the CMA and the ecosystem. |
| ডেটা ফাঁস | Concern that Topics may be leaked to other sites without permission | The design of the Topics API makes it quite unlikely that data from a single publisher (and even a smaller group of publishers) can be leaked in any way. Publisher websites are also in full control over the Topics API and they can prohibit access to this API via permission policy. |
| Lack of advertisers for testing | Publishers are concerned that they currently are unable to demonstrate the value of Topics to advertisers. | In the second half of 2023, we plan to have all the ads related APIs available for integration testing and enable ecosystem analysis of the value of Topics for advertisers. Testing and publication of the results will be supervised by the CMA, which will review the data, analysis and methodology. The ecosystem is encouraged to share feedback with Google and the CMA. |
| Topics and FLEDGE | Request for more information on how to use Topics within FLEDGE's bidding logic | It is possible to use Topics within FLEDGE's bidding logic. An integration guide is also in progress, and will include additional details on implementation. |
| Custom ranking for topics caller | Allow rankings to be tailored by caller | The challenge with custom topic ranking or values for each ad tech is that this could become a mechanism by which an ad tech can influence the topics that are returned, therefore a fingerprinting vector. |
| Topics caller priority list | Allow callers to provide a ranked priority list of topics that the Topics API will return based on eligibility. | We are currently discussing this idea further and welcome additional inputs. |
FLEDGE
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| গুগল অ্যাড ম্যানেজার | Concern that Google Ad Manager is the end decider for FLEDGE auctions and would favor Google Publisher Tags and Google Ad Manager. | FLEDGE allows each publisher to choose the structure of the auction, including the choice of top-level and component sellers. Each buyer and seller in a component auction knows who the top-level seller is, and can choose whether or not to bid. |
| Not enough participants testing FLEDGE | Request to encourage more companies to test FLEDGE, for example by improving the API's functionality and discouraging privacy-intrusive alternatives like fingerprinting | The Privacy Sandbox is proceeding in stages, in close partnership with the guidance of the CMA and ICO, and functional FLEDGE testing has demonstrated necessary stability and capability. Google continues to encourage the ecosystem to test the Sandbox APIs, recently publishing its " Maximize Ad Relevance " documentation to showcase how FLEDGE and other APIs can help support critical use cases for the ad industry after third-party cookie deprecation. Other parts of the Privacy Sandbox already support mitigations to cover tracking (see UA-CH, IP Protection, and Bounce Tracking Mitigations) and will continue to improve over time. Google's goal is not to make FLEDGE the only viable targeting solution, but instead remains committed to working in partnership with industry and regulators to drive the best privacy-preserving ad technologies in the Chrome browser. |
| মেশিন লার্নিং ব্যবহারের ক্ষেত্রে | More guidance on how machine learning use cases to train auction bidding algorithms will be supported in FLEDGE and Attribution Reporting | We recognize the need to help testers find the most useful ways of applying the Privacy Sandbox technologies. We have begun to publish guidance specifically related to the use of the various aspects of the Privacy Sandbox APIs as inputs to machine learning. The most recent piece, Maximize Ad Relevance , discusses how the ads industry can use these signals for machine learning, and we plan to continue publishing such guidance going forward. |
| Querying FLEDGE Key Value (K/V) Server | Why is the K/V server publicly queryable? | The K/V server aims to provide real time signals to FLEDGE auctions. As such, the K/V server needs to be accessible from where those FLEDGE auctions execute, which is on user devices, requiring that it be publicly available. A value stored in the K/V server can only be retrieved by a party that already has its key — so if an ad tech only gives the keys to browsers that are in the Interest Group, and does not use keys that can be randomly guessed, then only browsers that need the Value to run their auction will be able to retrieve it. |
| How to do date/time targeting? | Support for date objects in the bidding logic function. | এটি করার একাধিক উপায় আছে। Buyers can ask their seller to provide the current date and time, and it should be easy for sellers to provide this information to all buyers. Buyers can also provide the date and time in their real time key-value response. Finally, buyers can provide the date and time as part of their contextual response in the per-buyer-signals , which a seller could pass to the buyer's generateBid script. |
| ব্যবহারকারীর পছন্দ | Ability for users to choose to block creatives by advertiser when served via FLEDGE, or alternative solutions. | Users have the ability to opt out of Ads APIs in Chrome. For specific ads, the relevant ad tech is the party best positioned to offer controls over which creatives are shown or how they are selected. |
| Clearer timelines | Request for more information on availability of privacy protections in FLEDGE, such as requiring Fenced Frames. | We plan to publish more detailed timelines in Q1. |
| Reporting confusion | Request for more clarity on how FLEDGE reporting will work with other APIs such as Fenced Frames and Private Aggregation API. | We plan to publish an explainer on the interaction between Private Aggregation API, FLEDGE, and Fenced Frames in the coming weeks. |
| Real-time bidding and FLEDGE | Guidance on how FLEDGE integrates with standard real-time bidding. | The two main things that complicate an ad-tech's ability to do real-time bidding are access to event level data and easier integration into ARA. We are planning on sending updates and explainers on both of these in Q1. |
| Performance of FLEDGE Auctions | Report from testers that FLEDGE auctions have high latency | We appreciate reports from testers sharing their results and use cases and have shared some suggestions on how to improve the performance of FLEDGE . In parallel, we have added tooling to the browser allowing developers to better diagnose what is making auctions slow , and have been systematically addressing the primary sources of latency observed. Recent improvements include timeouts for slow auctions , a fast bidder filtering technique , a way to reuse FLEDGE worklets to avoid paying startup costs , and ongoing work to allow the contextual ad request to run in parallel with the FLEDGE startup time and network fetches. We expect latency optimization to continue as an ongoing conversation between Chrome developers and FLEDGE testers based on their real-world experience using the API. |
| Interest Group size memory limit | Request to raise the limit on the size of a single interest group from 50kB. | We are actively considering the request and are looking for feedback on what limit value works . |
| Combining the FLEDGE served data with first-party cookie | Will FLEDGE support integration with an advertiser's first-party data? | FLEDGE was built to support advertising using the first-party data an advertiser already has. However, FLEDGE does not intend to support an advertiser learning a person's browsing behavior on any website other than the advertiser's own site. Attaching off-site browsing behavior to first-party data is contrary to the goals of Privacy Sandbox. We are planning to share integration guides with more details on how FLEDGE will support integration with first-party data in the coming weeks. |
| K-anonymity value | How will the value "K" to "k-anon" be decided and will it be published? | The "K" value is still being finalized and we will share more information as our plans develop. We are interested in learning more about how an unknown k value may hinder FLEDGE preparedness and scoping ML model training and we welcome additional feedback on this subject. |
| Supporting multiple SSPs | How will multiple SSPs be supported in FLEDGE? | FLEDGE supports multi-seller auctions as noted in this proposal . |
| Visibility of bidding logic | Concern that DSP bidding logic will be exposed in JavaScript | With the current design bidding logic JavaScript can be accessed by others, but we welcome more feedback as to why this could be a source of concern for DSPs. |
| prebid.js | What is the timeline in supporting prebid.js in FLEDGE? | Only versions 7.14 and later of Prebid.js support the FLEDGE module. Any publishers interested in testing must add the FLEDGE module and upgrade their Prebid instance. |
| User defined functions in FLEDGE | How will user defined functions (UDF) be supported in FLEDGE? These are functions that can be programmed by end users to extend the functionality of the API. | Explainer available here . This is still being fleshed out so we welcome additional feedback on use cases. |
| Relaxing same-origin constraint on Interest Group resources | Request to relax same-origin constraint on Interest Group resources to enable certain ad tech use cases | In the current implementation of FLEDGE, biddingLogicUrl , biddingWasmHelperUrl , dailyUpdateUrl and trustedBiddingSignalsUrl must have the same origin as the interest group owner.The constraint exists to prevent certain exploits by attackers, as explained here . |
| interestGroup Ownership | Request to limit whether an ad tech can use joinInterestGroup for the same Interest Groups across sites | Our focus is on how audiences are used, not how they are built. We are discussing potential approaches and welcome additional input. |
| Key Value Server Key Expiration | Discussion on removing server keys once the corresponding interest groups have expired | We are exploring ways to handle key expiration and are looking for feedback . |
Measuring Digital Ads
Attribution Reporting (and other APIs)
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Origin Trial traffic | Current Origin Trial traffic is not enough to conduct utility testing. | The current Origin Trials are meant for ecosystem players to conduct functional testing in order to ensure the API is working as intended. We understand that larger amounts of traffic will be required to perform utility testing once the development of the various Privacy Sandbox API is more mature. The current testing timeline envisages that this will occur by General Availability (ie when the technologies for the use cases will be launched and available for 100% of Chrome traffic) at Q3 2023 (see our up-to-date timeline on privacysandbox.com ).We welcome any additional feedback on use case testing that requires additional traffic. |
| Overlap in functionality of different Privacy Sandbox measurement APIs | Concerns in having multiple measurement approaches overlap through Privacy Sandbox will increase complexity, for example, Attribution Reporting API and Private Aggregation API. | We are working on better documentation to clarify the different use cases for the APIs, and welcome additional feedback on what areas are lacking explanation. For example, Attribution Reporting API is intended specifically to support conversion measurement, whereas Private Aggregation API and Shared Storage are general-purpose APIs intended to support a broader range of cross-site measurement use-cases. |
| Retry failed report request | Clarification on how many times a report request is attempted if it fails. | We have published guidance on this . To summarize, reports are only sent when the browser is running/online. After the first failure to send, the report is retried after 5 minutes. After the second failure, the report is retried after 15 minutes. After that the report is not sent. |
| Reporting Delay | What is the expected reporting delay? | We are looking to hear more feedback from the ecosystem on any reporting delays they are experiencing as we collect data to further assess these delays in parallel. |
| Prerender pages | Will ARA attribution work on prerender pages? | Attribution registration is deferred on prerender pages until activation (actual click or view takes place). This means we will defer the `attributionsrc` request ping. |
| রূপান্তর লিফট পরিমাপ | How to measure conversion lift with AB testing on the same domain | Websites can measure conversion lift with A/B testing on the same domain through attribution reporting. They can encode their A/B parameters as keys using the aggregate API and then receive summary reports for the conversion values by those key buckets. |
| (Also reported in Q3) Cross-domain conversions | How to track the conversions that are cross domain, such as with 2 or more destinations | Q4 Update: We have published a proposal to remove the landing page destination restriction which enables cross domain conversations to be tracked. This proposal has been implemented. |
| (Also reported in Q3) Expiry setting in conversion report | Request to support report filter / expiry for less than 24 hours | Q4 Update: We have shared this pull request which will decouple expiry and reporting windows to mitigate the trade off of reporting delay vs conversion expiry. This is now launched in M110. |
| Fraud and Abuse | Requests from advertisers and marketers to be able to slice and aggregate data based on publisher sites where their ads are served, which would also give more insight into potential fraudulent ad practices | This feedback is actively being discussed here and we welcome additional inputs. |
| (Also reported in Q3) Event level reporting delay | The delay of 2-30 days in event level reporting may be too long for certain use cases. | Event level reporting has default reporting windows of 2, 7, and 30 days. This can be modified by using the "expiry" parameter. Ad-techs could configure the expiry, with a minimum of 1 day, to get potential reports in less than 2 days. We limit the granularity of expiries to 1 day as a privacy protection mechanism, as more fine-grained reporting could result in timing attacks. Additionally, we allow setting independent "expiry" parameters for event level and aggregate reports. এখানে দেখুন. Additionally, Google Ads will not get any special reporting windows that other ad-techs do not get via the Attribution Reporting API. |
| Same reporting origin requirement | Request to remove requirement for source registration origin to be the same as the conversion registration origin | We propose using HTTP redirects to delegate registration to solve this use-case. We welcome any additional feedback on the new guidance. |
| রূপান্তর ট্র্যাকিং | Need to differentiate whether the conversion happened before/after certain hours set by the advertiser | Attribution Reporting API supports setting an expiry window and priority for source attribution. By using both, it will technically be possible to attribute a conversion that happened within X days window separately from a conversion that happened after X. |
| Noise simulation | Request to be able to simulate the different volume of conversions per bucket, to understand the impact on advertisers with less conversions | We are looking to add ways to simulate this in future versions of Noise Lab . We welcome any additional feedback. |
| Reporting on mobile | Will the report still be sent when Chrome is running in the background on mobile? | At the moment, even on mobile, the report will not be sent when Chrome is in the background. This is likely to change when the API integrates with Android Privacy Sandbox. এখানে দেখুন. Note that Android Privacy Sandbox is not part of the Commitments accepted by the CMA. |
| ডেটা প্রাপ্যতা | Concerns that Google will have additional access to data via Privacy Sandbox APIs | First, Google Ads does not receive any preferential access to data from the Attribution Reporting API or other Privacy Sandbox APIs. This issue is also addressed in the General Feedback section under "Interoperability" which includes more detail on Google's Commitments. Second, on the difference between larger and smaller sites, Google recognizes that noise-based privacy protections may have a greater impact on smaller data slices. However, there are some possible mitigations: for instance, methods like aggregating over longer periods of time would solve this problem. That said, it remains unclear if conclusions based on very small data slices (like one or two purchases) are meaningful at all to advertisers. During the origin trial, Google has encouraged testers to take advantage of the ability to experiment with a wide range of privacy and noise parameters so they can provide more specific feedback on this issue. |
Limit Covert Tracking
ব্যবহারকারী-এজেন্ট হ্রাস
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Delay User-Agent Reduction until web ecosystem is more ready | There is not sufficient time to adapt to the coming User-Agent Reduction changes. | We address this feedback in the full report under "Stakeholder Concerns" in the section titled "Google's interaction with the CMA". |
| Delay User-Agent Reduction until web ecosystem is more ready | Request to delay User-Agent Reduction rollout until Structured User Agents (SUA) is deployed | The Google Ads team proposed the Structured User-Agent addition (see specification ) to OpenRTB in October 2021 and it was incorporated in the 2.6 spec update released in April 2022. We have some evidence that SUA is deployed and available today, as demonstrated by the Scientia Mobile blog post demonstrating how to use UA-CH and the WURFL API to create a SUA. |
###
User-Agent Client Hints
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Test UA-CH with other anti-covert tracking techniques | Guidance on how to test all Privacy Sandbox APIs and fingerprinting techniques proposed together in a holistic approach | Our testing plan was designed in order to reflect the asynchronous timelines for developing some of the anti-fingerprinting measures as opposed to the rest of the Sandbox Proposals. It addresses the reality that some anti-fingerprinting measures (ie Privacy Budget, IP Protection and Bounce Tracking Mitigations) will be fully-developed and ready for launch to General Availability only after third-party cookie deprecation. While those anti-fingerprinting measures will not be included in quantitative tests, they will be subject to qualitative assessment based on the facts available at the time of Standstill. |
| (Also reported in Q2) কর্মক্ষমতা | Concerns about the latency of getting hints via Critical-CH (on the first page load) | See dedicated UA-CH section below |
| Insufficient Feedback | Feedback from the ecosystem about the UA-CH change may not be sufficient, leading to concerns about a lack of awareness from the ecosystem. | We've been proactively sharing our plans to ensure a careful rollout that minimizes disruption. The plans for User-Agent Reduction and the UA-CH API were presented to the W3C Anti-Fraud Community Group on March 18th, 2022 and to both the Web Payments Working Group and the Web Payments Security Interest Group on January 20th, 2022. No significant concerns were raised during or after the presentations. Google has proactively engaged with more than 100 site operators to obtain feedback. Furthermore, Google has also used Blink-Dev channels to communicate the roll-out of the user-agent reduction publicly based on feedback from ecosystem stakeholders. |
| টাইমিং | Concerns raised regarding timing of rollout and industry preparedness | See dedicated UA-CH section below |
| Chrome Platform Status | Requested that the chromestatus page for UA-CH be updated | The chromestatus entry was updated on December 19 to "Mixed signals". |
IP Protection (formerly Gnatcatcher)
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Opt in or Opt Out | Is IP Address Privacy Opt In or Opt Out? | Our goal is to provide IP Protection to all users. With that goal in mind, we are currently evaluating user choice options for IP Protection. |
| IP Address use case for first-party data | Is it possible to use IP addresses to stitch together user journeys across first-party domains post IP Protection? | As previously published , IP Protection will initially focus on tracking in the third-party context, which means first-party domains will not be impacted. |
| Ad Tech use cases | How can companies set up anti-fraud measures with IP Protection? | We recognize the importance of IP address as a signal for anti-fraud efforts in today's web. As part of our Commitments to the CMA (paragraph 20), we have said that we will not implement IP Protection without making reasonable efforts to support websites' ability to conduct anti-spam and anti-fraud efforts. One of our top priorities is to understand how IP Protection impacts anti-fraud use cases and detection capabilities, so that we can further invest in privacy preserving technologies that help companies preserve web safety. We encourage feedback and input on new proposals aimed at supporting the needs of security and anti-fraud companies, even as signals change over time. |
| Fraud and Abuse | Does IP protection include Denial of Service (DoS) Protection? | We are committed to improving privacy while keeping the web safe, and protecting against denial-of-service attacks is an important anti-abuse use case to design for. We hope to minimize impact to DoS protections through both the design of IP Protection itself and through new anti-abuse solutions. Because IP Protection is initially focused on third-party embedded services, some stakeholders have indicated that it should have limited impact on DoS protection for first-party sites. However we continue to ask for public feedback to assess risk to DoS use cases, particularly to third-party embedded services. In parallel, we are exploring abuse-feedback and client-blocking mechanisms that would enable a site or service to block a spammy user, without identifying the user. |
| বিষয়বস্তু ফিল্টারিং | Content filtering with IP Protection | Different companies have different needs with respect to filtering content and customizing user experience. Many such use cases do not currently rely on IP addresses and therefore should be unaffected by IP Protection. For example, a publisher looking to tailor its content and drive more engagement might use first-party cookies or third-party partitioned cookies (CHIPs) to understand a user's interests and previous interactions with the publisher. Or an ad tech partner focused on delivering the right ad to the right user can incorporate FLEDGE and Topics, for example, to deliver similar ad outcomes as they do today with third-party cookies or other cross-site tracking technologies. We are also exploring building new privacy-preserving capabilities into IP Protection, such as coarse geolocation, to further support content filtering where existing mechanisms may be insufficient. We welcome additional feedback on content filtering use cases that may be impacted by IP Protection. |
| (Also reported in Q3) Geolocation use cases | IP Protection may prevent legitimate geolocation use cases from working in the future, such as content personalisation based on geolocation. | Q4 Update: We are working with stakeholders to ensure that Chrome continues to support legitimate use-cases for IP addresses. We are seeking ecosystem feedback on IP Geolocation granularity here . |
গোপনীয়তা বাজেট
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Clearer documentation | More examples so stakeholders can anticipate how things may be limited once Privacy Budget is implemented | The Privacy Budget proposal is still under active discussion and has not been implemented by any browsers. The earliest date of scaled availability represents the earliest date when Privacy Budget could be enforced. This will not happen before the removal of third-party cookies in 2024. We do not have any additional documentation to share at the moment. We will share additional details on the proposal when it becomes more finalized. In the meantime, we welcome stakeholders to share any feedback that would help in the development of the proposal. |
ক্রস-সাইট গোপনীয়তা সীমানা শক্তিশালী করুন
First-Party Sets
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| (Also reported in Q3) Domain limit | Request to expand the number of associated domains | Q4 Update: We have released FPS for local testing, including a mock set submission process on GitHub and a flag to test rSA and rSAFor locally. We have also hosted two open meetings for developers on FPS to continue to address questions around use cases for the associated subset. We encourage developers to test out FPS functionality to provide feedback on how the domain limit for the associated subset would impact the usability of FPS for their use cases. We have clarified in WICG calls that Chrome is committed to providing a usable solution that considers users' privacy interests as well. In that vein, we would appreciate feedback from the community on specific use cases that may be impacted by the domain limit, so that the team can consider ways to address these use cases while continuing to protect user privacy. |
| Request for more details about the abuse mitigation measures | What happens if a domain is added to a set they did not consent to? | We have published submission guidelines for First-Party Sets here on December 2, 2022. As explained in the submission guidelines, any set change management will be following and respecting a validation process on GitHub, including validation on ownership, which should mitigate this risk. |
| Abuse mitigation | Concern that First-Party Set formations can be exploited | We are looking at ways to expand technical checks for subset types and are actively seeking additional input from the community here . |
| Ads use cases | Questions on whether First-Party Sets should be used to support Ad targeting | We're not trying to support Ads targeting use cases for First-Party Sets, and we recommend using the Ads APIs available for such use cases. |
| (Also reported in Q3) Policy | Concern that FPS is not consistent with the CMA Commitments regarding "Applicable Data Protection Legislation," on the basis that GDPR does not impose a limit on the number of sites in a set while FPS envisages a limit of 3 | Our response is unchanged from Q3: "Google is continuing to commit to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising, publishers and advertisers as well as impact on privacy outcomes and compliance with data protection principles as set out in the Applicable Data Protection Legislation. The concern expressed does not disclose any incompatibility with GDPR. We continue to work closely with the CMA to ensure that our work complies with these commitments." |
| Alternative proposal | GDPR Validated Sets | In addition to the feedback provided by the ecosystem on the proposal to adopt "GDPR Validated Sets," Chrome has concerns about the following limitations of this alternative proposal:
Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets. |
বেড়া ফ্রেম API
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Fenced Frames restrictions during OT | What are the current restrictions around Fenced Frames for the Origin Trial period? | We are working on documentation on the restrictions and implementation status and plan to share it during Q1 2023. |
| Multiple ads in a single Fenced Frame | Request to display multiple advertisers in one Fenced Frame in one auction | Currently, this request is not being actively developed, but we welcome additional feedback if ecosystem players consider the feature important. |
| Web Bundles | What are the requirements and support planned for Web Bundles with Fenced Frames? | We currently do not have an update on whether this will be the requirement in the future. Any changes would be announced in advance and would not be enforced before third-party cookie deprecation. Please see this explainer for the current status. |
শেয়ার্ড স্টোরেজ API
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Shared Storage for Ad Tech | Uncertainty surrounding the use of shared storage for Ad Tech use cases | Shared Storage and Private Aggregation API can be used for different kinds of measurement purposes that need cross-site storage measurement. Some examples are listed here . We are foreseeing DSP and Measurement solution providers to be the main integrator for ads use cases. |
CHIPs
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| (Also reported in Q3) Partitioned requirement | Add explicit behavior requirement for "Partitioned" attribute on first-party cookies. | Q4 Update: After discussions on GitHub and PrivacyCG calls, the behavior that we have aligned on is that Partitioned cookies set on first-party cookies will use a partition key of (A,A) where "A" is the top-level site. We will document this behavior on the explainer and specification. |
| কুকি ব্যবস্থাপনা | Are there tools for managing/governing first-party or third-party cookies? | Chrome DevTools and NetLog can be used to test sites with third-party cookie blocking enabled. Both tools report when cookies are blocked due to user configuration. We welcome feedback on what sort of additional auditing websites would like to see. |
FedCM
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| IdP requires knowledge of RP to allow a session | Issue when a user is trying to log into the Feide IdP from two different RPs | We are discussing potential solutions to this issue. |
| ইন্টারঅপারেবিলিটি | Concerns regarding the impact of FedCM on the relationship between users and the websites they log into using FedCM, and "interoperability" among websites | FedCM aims to continue supporting federated-identity services that currently rely on third-party cookies once third-party cookies are removed from Chrome. We expect that FedCM will be just one option available to such services; identity providers (IdPs) and relying parties (RPs) are free to use other technologies that may better suit their needs. It appears that concerns regarding the user-RP relationship and "interoperability" owe to a misunderstanding of the FedCM proposal. FedCM leaves it to IdPs to decide what information to share with an RP, and in what form, once the user has chosen to sign in to that RP's site. FedCM does not require IdPs to "create a unique pseudonymous identifier for each [RP] with whom the user authenticates." Rather, FedCM is open for each IdP to choose whether to share the user's actual identifier, a per-site version of that identifier, or some other version of this information. (The FedCM specification does identify cross-site correlation as a privacy risk associated with the API and discusses directed (per-site) identifiers as a possible mitigation. However, the decision whether to use directed identifiers is left to IdPs, not imposed by the browser.) FedCM also already provides for user choice with respect to identity. For example, if a user has multiple identities with the same IdP (eg, a work profile and a personal profile), FedCM provides a way for the user to select which one they want to use to log in to the RP's site. Beyond that, each RP decides for itself which IdPs to support on its site. One aspect of that decision is considering the mechanism that an IdP relies on, whether that's FedCM or a different technology. Again, the browser does not dictate these choices for RPs or IdPs. |
Fight spam and fraud
Private State Token API
| Feedback Theme | সারাংশ | Chrome Response |
|---|---|---|
| Handling Bots | What happens if the issuer discovers that Private State Tokens have been issued to bots? | To avoid tokens issued to bots from remaining in the ecosystem for a long time, issuers should rotate the keys they use to sign tokens regularly so that old tokens issued under potentially broken issuance logic expire and sites redeem newer tokens with updated issuance logic. |
| Same-site form submissions | Could Private State Tokens be used for same-site form submissions that involve full-page navigation (ie Content-Type: application/x-www-form-urlencoded) rather than a request from the fetch/XMLHttpRequest APIs? | This isn't currently supported in the first version of Private State Tokens. We welcome feedback from the ecosystem if there is a strong demand for this use case. |
| Server-side verification | Questions on whether Private State Tokens can be verified server side | Tokens are redeemed against the issuer, and then the issuer creates a redemption record that could contain the token itself or some signed value derived from the token, servers can use that redemption record to verify the authenticity of the token, and we expect different issuer ecosystems will come up with different standards for how to interpret their redemption records. |