این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

گزارش بازخورد - 2022 Q4
bookmark_border با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

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

به عنوان بخشی از تعهدات خود به CMA، Google موافقت کرده است که گزارش‌های سه ماهه در مورد فرآیند تعامل با ذینفعان را برای پیشنهادات جعبه ایمنی حریم خصوصی خود به صورت عمومی ارائه کند (به پاراگراف‌های 12 و 17(c)(ii) تعهدات مراجعه کنید). این گزارش‌های خلاصه بازخورد Sandbox حریم خصوصی با جمع‌آوری بازخوردهای دریافتی توسط Chrome از منابع مختلف که در نمای کلی بازخورد فهرست شده است، ایجاد می‌شوند، از جمله اما نه محدود به: مشکلات GitHub، فرم بازخورد موجود در privacysandbox.com ، جلسات با سهامداران صنعت، و انجمن‌های استانداردهای وب. Chrome از بازخوردهای دریافتی از اکوسیستم استقبال می کند و به طور فعال در حال بررسی راه هایی برای ادغام آموخته ها در تصمیمات طراحی است.

مضامین بازخورد بر اساس شیوع در هر API رتبه‌بندی می‌شوند. این کار با جمع‌آوری مقدار بازخوردی که تیم Chrome در مورد یک موضوع خاص دریافت کرده و به ترتیب نزولی از نظر سازماندهی انجام می‌شود. مضامین رایج بازخورد با بررسی موضوعات بحث از جلسات عمومی (W3C، PatCG، IETF)، بازخورد مستقیم، GitHub و سوالات متداول مطرح شده از طریق تیم‌های داخلی Google و فرم‌های عمومی شناسایی شدند.

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

توضیحات پاسخ‌های Chrome به بازخورد از پرسش‌های متداول منتشر شده، پاسخ‌های واقعی به مسائل مطرح‌شده توسط ذینفعان و تعیین موقعیت به‌ویژه برای اهداف این گزارش گزارش عمومی ایجاد شده است. با توجه به تمرکز فعلی توسعه و آزمایش، سؤالات و بازخوردها به ویژه در رابطه با موضوعات، Fledge و APIهای گزارش انتساب دریافت شد.

بازخورد دریافت شده پس از پایان دوره گزارش فعلی ممکن است هنوز پاسخی در نظر گرفته شده برای Chrome نداشته باشد.

واژه نامه کلمات اختصاری

چیپس: کوکی هایی که دارای حالت تقسیم شده مستقل هستند
DSP: پلتفرم سمت تقاضا
FedCM: مدیریت اعتبار فدرال
FPS: مجموعه های مهمانی اول
IAB: دفتر تبلیغات تعاملی
بیجاشدگان داخلی: ارائه دهنده هویت
IETF: کارگروه مهندسی اینترنت
IP: آدرس پروتکل اینترنت
openRTB: مناقصه در زمان واقعی
OT: آزمایش مبدا
PatCG: گروه اجتماعی فناوری تبلیغات خصوصی
RP: حزب اتکا
SSP: پلت فرم سمت عرضه
TEE: محیط اجرای مورد اعتماد
UA: رشته عامل کاربر
UA-CH: نکات مشتری عامل کاربر
W3C: کنسرسیوم وب جهانی
WIPB: کوری IP ارادی

بازخورد عمومی، بدون API/فناوری خاصی

موضوع بازخورد	خلاصه	پاسخ کروم
(همچنین در سه ماهه سوم گزارش شده است) سودمندی برای انواع مختلف ذینفعان	نگرانی از این که فناوری‌های جعبه ایمنی حریم خصوصی به نفع توسعه‌دهندگان بزرگ‌تر هستند و سایت‌های خاص (کوچک‌تر) بیشتر از سایت‌های عمومی (بزرگ‌تر) مشارکت می‌کنند.	پاسخ ما نسبت به Q3 بدون تغییر است: "Google به CMA متعهد شده است که پیشنهادات جعبه ایمنی حریم خصوصی را به گونه‌ای طراحی و اجرا کند که رقابت را با ترجیح دادن خود به کسب‌وکار Google مخدوش نکند، و تاثیر آن را بر رقابت در تبلیغات دیجیتال و بر ناشران و تبلیغ‌کنندگان، صرف نظر از اندازه آنها، در نظر بگیرد. ما به همکاری نزدیک با CMA ادامه می‌دهیم تا اطمینان حاصل کنیم که کارمان با این تعهدات مطابقت دارد. با پیشرفت تست Privacy Sandbox، یکی از سوالات کلیدی که ما ارزیابی خواهیم کرد این است که فناوری های جدید چگونه برای انواع مختلف ذینفعان عمل می کنند. بازخورد از این نظر بسیار مهم است، به ویژه بازخوردهای خاص و عملی که می تواند به ما در بهبود بیشتر طرح های فنی کمک کند. ما با CMA کار کرده‌ایم تا رویکرد خود را برای آزمایش‌های کمی توسعه دهیم و از انتشار یادداشتی در مورد طراحی آزمایش توسط CMA حمایت می‌کنیم تا اطلاعات بیشتری را به شرکت‌کنندگان بازار و فرصتی برای اظهار نظر در مورد رویکردهای پیشنهادی ارائه کنیم."
(همچنین در سه ماهه سوم گزارش شده است) درخواست های اسناد و مدارک	درخواست برای منابع بیشتر در مورد نحوه مدیریت تست، تجزیه و تحلیل و پیاده سازی	به روز رسانی Q4: ما قدردانی می‌کنیم که توسعه‌دهندگان مطالب فعلی ما را مفید دانسته‌اند و همچنان متعهد به ارائه مطالب بیشتر هستند تا توسعه‌دهندگان بتوانند بفهمند فناوری‌های جدید چگونه می‌توانند برای آنها کار کنند. در سه ماهه گذشته، بخش «اخبار و به‌روزرسانی‌ها» را به privacysandbox.com اضافه کرده‌ایم و بررسی گسترده‌ای درباره اینکه چگونه جعبه ایمنی حریم خصوصی می‌تواند به افزایش ارتباط آگهی در آینده کمک کند، منتشر کردیم. ما همچنین جلسات ساعات اداری برنامه‌نویس عمومی را برای به اشتراک گذاشتن بهترین شیوه‌ها و نمایش‌های نمایشی، همراه با جلسات پرسش و پاسخ با محصولات و سرنخ‌های مهندسی برگزار کرده‌ایم تا امکان بحث/سوالات زنده را فراهم کنیم.
Core Web Vitals	چگونه تأخیر Privacy Sandbox API بر Core Web Vitals تأثیر می گذارد؟	حفظ تأخیر به حداقل یک هدف کلیدی طراحی APIهای Privacy Sandbox است. انتظارات فعلی ما این است که تأخیر API حداقل تأثیری بر Core Web Vitals یک سایت داشته باشد، زیرا اکثر API ها پس از رندر اولیه وب سایت فراخوانی می شوند. ما همچنان به نظارت و بهبودهایی برای کاهش بیشتر تأخیر برای هر یک از APIها ادامه می‌دهیم و آزمایش‌ها و بازخوردهای مداوم را تشویق می‌کنیم. تأخیر در فرآیند مناقصه زمان واقعی در بخش FLEDGE در بخش "عملکرد مزایده های FLEDGE" بررسی می شود.
قابلیت همکاری	نگرانی در مورد قابلیت همکاری با سایر راه حل های بالقوه	هدف Privacy Sandbox محافظت از کاربران در برابر ردیابی بین سایتی و در عین حال پشتیبانی از نیازهای اکوسیستم وب است. ما به دنبال این هستیم که با دور شدن از فناوری‌های مرورگر قدیمی که چنین ردیابی بین‌سایتی مانند کوکی‌های شخص ثالث را امکان‌پذیر می‌کنند، به انجام برسانیم و در جای خود فناوری‌های جدیدی را که برای پشتیبانی از موارد استفاده خاص ساخته شده‌اند، انجام دهیم. پیشنهادات جعبه ایمنی حریم خصوصی با محدود کردن داده‌هایی که از دستگاه کاربر خارج می‌شود، حریم خصوصی را بهبود می‌بخشد. این پیشنهادها محدودیت‌های فنی برای توانایی وب‌سایت برای اشتراک‌گذاری یا پردازش داده‌های جمع‌آوری‌شده از مرورگر ایجاد نمی‌کنند. بنابراین، فناوری‌ها مانع از ورود شرکت‌ها به قراردادهای «مدیریت داده» یا هر رابطه قراردادی مشابه دیگری نمی‌شوند. به همین ترتیب، آنها توانایی کاربران را برای رضایت به اشتراک گذاری داده های خود از طریق روش های دیگر محدود نمی کنند. برای وضوح، Google متعهد شده است که فناوری‌های جعبه ایمنی حریم خصوصی را به یک روش برای همه وب‌سایت‌ها، از جمله محصولات و خدمات Google، اعمال کند. پس از پایان پشتیبانی Chrome از کوکی‌های شخص ثالث، تعهدات همچنین مشخص می‌کند که Google از سایر داده‌های شخصی، مانند سابقه همگام‌سازی مرور کروم کاربران، برای ردیابی کاربران برای هدف‌یابی یا اندازه‌گیری تبلیغات دیجیتال استفاده نخواهد کرد.

نمایش محتوا و تبلیغات مرتبط

موضوعات

موضوع بازخورد	خلاصه	پاسخ کروم
تاثیر بر رتبه بندی جستجوی گوگل	پرس و جو در مورد اینکه آیا پشتیبانی از Topics API یک وب سایت به عنوان یک سیگنال بالقوه برای رتبه بندی نتایج جستجوی Google استفاده می شود یا خیر	برخی از وب‌سایت‌ها ممکن است انتخاب کنند که از موضوعات API انصراف دهند. تیم Privacy Sandbox هماهنگی نکرده یا از سازمان جستجو درخواست نکرده است که از رتبه بندی صفحه به عنوان انگیزه ای برای وب سایت ها برای استفاده از Topics API استفاده کند. Google به CMA تأیید کرده است که جستجوی Google از تصمیم سایت برای انصراف از Topics API به عنوان سیگنال رتبه بندی استفاده نمی کند.
طبقه بندی موضوعات	URL و محتوای صفحه را علاوه بر نام میزبان برای تعیین موضوع صفحه وب به منظور بهبود سودمندی برای سهامداران مختلف اضافه کنید.	تاریخچه مرور کاربر در حال حاضر با استفاده از نام میزبان وب سایت طبقه بندی می شود. Chrome به ارزیابی گزینه‌ها برای در نظر گرفتن فراداده سطح صفحه (مانند همه یا برخی از اجزای URL صفحه و/یا محتوا) در طبقه‌بندی موضوعات ادامه می‌دهد. هر گونه بهبود ابزار باید با خطرات حریم خصوصی و سوء استفاده سنجیده شود. به عنوان مثال، با توجه به فراداده به طور خاص، تعدادی از خطرات عبارتند از: - سایت هایی که ابرداده های سطح صفحه را به عنوان روشی برای رمزگذاری معانی مختلف (و بالقوه حساس) در موضوعات تغییر می دهند. - سایت‌هایی که ابرداده‌های سطح صفحه را تغییر می‌دهند تا موضوعات خود را برای سود مالی نادرست معرفی کنند. - سایت هایی که ابرداده های سطح صفحه را به صورت پویا به عنوان روشی برای ردیابی بین سایتی تغییر می دهند
(همچنین در سه ماهه سوم گزارش شده است) تاثیر بر سیگنال های شخص اول	سیگنال موضوعات ممکن است بسیار ارزشمند باشد و در نتیجه سایر سیگنال‌های مبتنی بر علاقه شخص اول را کاهش دهد.	پاسخ ما نسبت به Q3 بدون تغییر است: "ما معتقدیم تبلیغات مبتنی بر علاقه یک مورد استفاده مهم برای وب است و Topics برای پشتیبانی از این مورد طراحی شده است. همانطور که [در گزارش سه ماهه سوم ما] توضیح داده شد، سایر ذینفعان اکوسیستم ابراز نگرانی کرده اند مبنی بر اینکه موضوعات ممکن است به اندازه کافی برای ارائه ارزش مفید نباشند. در همه موارد، بهبود طبقه بندی یک تلاش مداوم است و ما انتظار داریم که طبقه بندی با آزمایش و ecosy تکامل یابد."
به روز رسانی طبقه بندی	لیست طبقه بندی چگونه به روز می شود؟	ما فعالانه به دنبال بازخورد در مورد طبقه بندی هستیم که برای اکوسیستم مفیدتر است. طبقه بندی موجود در پیشنهاد اولیه Topics API برای فعال کردن تست عملکردی طراحی شده است. کروم به طور فعال چندین رویکرد را برای به روز رسانی طبقه بندی در نظر می گیرد. به عنوان مثال، Chrome ممکن است از مفهوم ارزش تجاری برای هر موضوع استفاده کند تا مشخص کند کدام دسته را در تکرارهای بعدی قرار دهد.
موضوعات عملکرد طبقه بندی کننده منطقه ای	طبقه‌بندی‌کننده موضوعات در حوزه‌های منطقه‌ای ضعیف عمل می‌کند	بهبود طبقه بندی کننده یک تلاش مداوم است. بر اساس بازخوردی که دریافت کرده‌ایم، یکی از امکان‌های مورد بررسی گسترش فهرست لغو موضوعات است، که تحلیل ما نشان می‌دهد که پوشش جهانی را افزایش می‌دهد و دقت را بهبود می‌بخشد. برای توضیح، طبقه‌بندی Topics API دارای دو مؤلفه مرتبط است: (1) فهرست لغو شامل 10 هزار سایت برتر و موضوعات آنها، و (2) یک مدل ML روی دستگاه که نام‌های میزبان را به موضوعات طبقه‌بندی می‌کند. با گسترش فهرست لغو (1)، می‌توانیم عملکرد طبقه‌بندی را برای مناطقی که طبقه‌بندی‌کننده در آنها ضعیف عمل می‌کند، بهبود بخشیم.
دوره یک هفته ای	دوره یک هفته ای برای کاربرانی که به دنبال تصمیم گیری کوتاه مدت هستند بسیار طولانی است.	ما فعالانه به دنبال این هستیم که طول دوره مناسب چقدر باید باشد و از بازخورد بیشتر در مورد اینکه چه دوره ای برای اکوسیستم بهتر است استقبال می کنیم.
بازیابی هدر HTTP	نگرانی از اینکه اطلاعات کافی در مورد بازیابی هدر HTTP موضوعات وجود ندارد	کار برای هدرها و fetch() در حال انجام است. ما همچنین اطلاعاتی را در اینجا در دسترس داریم. ما همچنین اطلاعات skipObservation را به توضیح دهنده اضافه کرده ایم.
هدف موضوعات فقط کمک به تبلیغ‌کنندگان است، نه کاربران	به نظر می رسد جعبه ایمنی موضوعات/حریم خصوصی یک رویکرد متمرکز بر صنعت باشد. سود برای کاربران به اندازه سود برای صنعت روشن نیست.	ما معتقدیم که مزیت برای کاربران این است که Topics از تبلیغات مبتنی بر علاقه پشتیبانی می کند که وب را آزاد و باز نگه می دارد، و همچنین معتقدیم که حریم خصوصی را به طور قابل توجهی در مقایسه با کوکی های شخص ثالث بهبود می بخشد . حذف کوکی‌های شخص ثالث بدون جایگزین‌های مناسب ممکن است بر ناشران تأثیر منفی بگذارد و به رویکردهای بدتر منجر شود. که کمتر خصوصی هستند، شفاف نیستند و به طور واقعی توسط کاربران قابل تنظیم مجدد یا کنترل نیستند. بسیاری از شرکت‌ها به‌طور فعال موضوعات و APIهای Sandbox را آزمایش می‌کنند، و ما متعهد به ارائه ابزارهایی برای ارتقای حریم خصوصی و پشتیبانی از وب هستیم. گروه معماری فنی W3C اخیراً دیدگاه اولیه خود را در مورد Topics API منتشر کرده است که ما به صورت عمومی به آن پاسخ خواهیم داد. در این مرحله، از آنجایی که گوگل از اکوسیستم سؤالاتی در مورد آنچه که این بررسی ممکن است برای توسعه و راه‌اندازی Topics API داشته باشد، دریافت کرده است، مایلیم برنامه خود را برای در دسترس قرار دادن آن در Chrome Stable در سال جاری مجدداً تأیید کنیم. در حالی که Googles از ورودی گروه معماری فنی W3C قدردانی می کند، ادامه تلاش ها برای توسعه و آزمایش موضوعات را با مشورت CMA و اکوسیستم بسیار مهم می داند.
نشت داده ها	نگرانی از اینکه موضوعات ممکن است بدون اجازه به سایت های دیگر درز کند	طراحی Topics API باعث می‌شود که اطلاعات یک ناشر (و حتی گروه کوچک‌تری از ناشران) به هیچ وجه به بیرون درز نکند. وب‌سایت‌های ناشر نیز بر روی Topics API کنترل کامل دارند و می‌توانند از طریق خط‌مشی مجوز، دسترسی به این API را ممنوع کنند.
عدم وجود تبلیغ کننده برای آزمایش	ناشران نگران هستند که در حال حاضر نمی توانند ارزش موضوعات را به تبلیغ کنندگان نشان دهند.	در نیمه دوم سال 2023، ما قصد داریم تمام API های مرتبط با تبلیغات را برای آزمایش یکپارچه سازی در دسترس داشته باشیم و تجزیه و تحلیل اکوسیستم ارزش موضوعات را برای تبلیغ کنندگان فعال کنیم. آزمایش و انتشار نتایج توسط CMA نظارت خواهد شد که داده ها، تجزیه و تحلیل و روش شناسی را بررسی خواهد کرد. اکوسیستم تشویق می شود تا بازخورد خود را با Google و CMA به اشتراک بگذارد.
موضوعات و FLEDGE	برای اطلاعات بیشتر در مورد نحوه استفاده از موضوعات در منطق مناقصه FLEDGE درخواست کنید	امکان استفاده از موضوعات در منطق مناقصه FLEDGE وجود دارد. راهنمای ادغام نیز در حال انجام است و شامل جزئیات بیشتری در مورد پیاده سازی خواهد بود.
رتبه بندی سفارشی برای موضوعات تماس گیرنده	اجازه دهید رتبه بندی توسط تماس گیرنده تنظیم شود	چالش با رتبه بندی موضوع یا مقادیر سفارشی برای هر فناوری تبلیغاتی این است که این می تواند به مکانیزمی تبدیل شود که از طریق آن یک فناوری تبلیغاتی می تواند بر موضوعاتی که برگردانده می شوند تأثیر بگذارد، بنابراین بردار اثر انگشت.
موضوعات لیست اولویت تماس گیرنده	به تماس‌گیرندگان اجازه دهید فهرست اولویت‌بندی‌شده‌ای از موضوعاتی که Topics API بر اساس واجد شرایط بودن آنها را برمی‌گرداند، ارائه دهند.	ما در حال حاضر در حال بحث بیشتر درباره این ایده هستیم و از ورودی های اضافی استقبال می کنیم.

FLEDGE

موضوع بازخورد	خلاصه	پاسخ کروم
Google Ad Manager	نگرانی از اینکه Google Ad Manager تصمیم‌گیرنده نهایی حراج‌های FLEDGE است و به نفع Google Publisher Tags و Google Ad Manager است.	FLEDGE به هر ناشر اجازه می دهد تا ساختار حراج را انتخاب کند، از جمله انتخاب فروشندگان سطح بالا و قطعات. هر خریدار و فروشنده در حراج قطعات می‌داند فروشنده سطح بالا کیست و می‌تواند انتخاب کند که پیشنهاد دهد یا نه.
شرکت کنندگان کافی در حال آزمایش FLEDGE نیستند	درخواست تشویق شرکت‌های بیشتری برای آزمایش FLEDGE، برای مثال با بهبود عملکرد API و ممانعت از جایگزین‌های مزاحم حریم خصوصی مانند اثر انگشت	جعبه ایمنی حریم خصوصی در مراحلی با همکاری نزدیک با راهنمایی CMA و ICO پیش می رود و آزمایش عملکردی FLEDGE پایداری و قابلیت لازم را نشان داده است. Google همچنان به تشویق اکوسیستم برای آزمایش Sandbox API ها ادامه می‌دهد و اخیراً اسناد « به حداکثر رساندن ارتباط آگهی » خود را منتشر کرده است تا نشان دهد چگونه FLEDGE و سایر APIها می‌توانند به پشتیبانی از موارد استفاده حیاتی برای صنعت تبلیغات پس از منسوخ شدن کوکی‌های شخص ثالث کمک کنند. سایر بخش‌های جعبه ایمنی حریم خصوصی در حال حاضر از اقدامات کاهشی برای پوشش ردیابی پشتیبانی می‌کنند (به UA-CH، حفاظت IP، و کاهش‌های ردیابی جهشی مراجعه کنید) و در طول زمان بهبود خواهند یافت. هدف Google این نیست که FLEDGE را به تنها راه‌حل هدف‌یابی بادوام تبدیل کند، بلکه در عوض متعهد به همکاری با صنعت و قانون‌گذاران برای هدایت بهترین فناوری‌های تبلیغاتی حفظ حریم خصوصی در مرورگر کروم است.
موارد استفاده از یادگیری ماشین	راهنمایی بیشتر در مورد نحوه استفاده از موارد یادگیری ماشین برای آموزش الگوریتم‌های پیشنهاد مزایده در FLEDGE و Attribution Reporting پشتیبانی می‌شود.	ما نیاز به کمک به آزمایش‌کنندگان را می‌دانیم تا مفیدترین روش‌ها را برای استفاده از فناوری‌های جعبه ایمنی حریم خصوصی پیدا کنند. ما شروع به انتشار راهنمایی‌هایی کرده‌ایم که به‌طور خاص مربوط به استفاده از جنبه‌های مختلف APIهای جعبه ایمنی حریم خصوصی به‌عنوان ورودی‌های یادگیری ماشینی است. جدیدترین مقاله، به حداکثر رساندن ارتباط آگهی ، به این موضوع می‌پردازد که چگونه صنعت تبلیغات می‌تواند از این سیگنال‌ها برای یادگیری ماشینی استفاده کند، و ما قصد داریم به انتشار چنین راهنمایی‌هایی در آینده ادامه دهیم.
پرس و جو FLEDGE ارزش کلید (K/V) سرور	چرا سرور K/V به صورت عمومی قابل استعلام است؟	هدف سرور K/V ارائه سیگنال‌های بلادرنگ به حراج‌های FLEDGE است. به این ترتیب، سرور K/V باید از جایی که مزایده‌های FLEDGE اجرا می‌شوند، که در دستگاه‌های کاربر است، قابل دسترسی باشد و نیاز است که در دسترس عموم قرار گیرد. یک مقدار ذخیره شده در سرور K/V را تنها می توان توسط طرفی که از قبل کلید خود را دارد بازیابی کرد - بنابراین اگر یک فناوری تبلیغاتی کلیدها را فقط به مرورگرهایی که در گروه Interest هستند می دهد و از کلیدهایی استفاده نمی کند که می توان به طور تصادفی حدس زد، آنگاه فقط مرورگرهایی که برای اجرای حراج خود به مقدار نیاز دارند می توانند آن را بازیابی کنند.
چگونه هدف گذاری تاریخ/زمان را انجام دهیم؟	پشتیبانی از اشیاء تاریخ در تابع منطق مناقصه.	راه های متعددی برای این کار وجود دارد. خریداران می توانند از فروشنده خود بخواهند که تاریخ و زمان فعلی را ارائه کند و ارائه این اطلاعات به همه خریداران برای فروشندگان باید آسان باشد. خریداران همچنین می‌توانند تاریخ و زمان را در پاسخ ارزش کلیدی خود در زمان واقعی ارائه دهند. در نهایت، خریداران می‌توانند تاریخ و زمان را به‌عنوان بخشی از پاسخ متنی خود در سیگنال‌های هر خریدار ارائه کنند، که فروشنده می‌تواند آن را به اسکریپت GenerBid خریدار منتقل کند.
تنظیمات برگزیده کاربر	امکان انتخاب کاربران برای مسدود کردن خلاقیت‌ها توسط تبلیغ‌کننده هنگام ارائه از طریق FLEDGE یا راه‌حل‌های جایگزین.	کاربران می‌توانند از APIهای تبلیغاتی در کروم انصراف دهند. برای تبلیغات خاص، فناوری تبلیغات مربوطه، طرفی است که بهترین موقعیت را دارد تا کنترل‌هایی را در مورد اینکه کدام خلاقیت‌ها نشان داده می‌شوند یا نحوه انتخاب آنها ارائه می‌کند.
جدول زمانی واضح تر	برای اطلاعات بیشتر در مورد در دسترس بودن حفاظت های حریم خصوصی در FLEDGE، مانند نیاز به قاب های حصاردار، درخواست کنید.	ما قصد داریم تا جدول زمانی دقیق تری را در سه ماهه اول منتشر کنیم.
گزارش سردرگمی	برای وضوح بیشتر در مورد نحوه کار گزارش FLEDGE با سایر APIها مانند Fenced Frames و Private Aggregation API درخواست کنید.	ما قصد داریم توضیحی در مورد تعامل بین API جمع‌آوری خصوصی، FLEDGE و فریم‌های حصاردار در هفته‌های آینده منتشر کنیم.
مناقصه در زمان واقعی و FLEDGE	راهنمایی در مورد نحوه ادغام FLEDGE با مناقصه بلادرنگ استاندارد.	دو مورد اصلی که توانایی یک فناوری تبلیغاتی را برای انجام مناقصه بلادرنگ پیچیده می‌کند، دسترسی به داده‌های سطح رویداد و ادغام آسان‌تر در ARA است. ما در حال برنامه ریزی برای ارسال به روز رسانی و توضیح در مورد هر دوی این موارد در Q1 هستیم.
اجرای حراج های FLEDGE	گزارش از آزمایش کنندگان مبنی بر اینکه حراج های FLEDGE تاخیر بالایی دارند	ما از گزارش‌های آزمایش‌کنندگان که نتایج و موارد استفاده خود را به اشتراک می‌گذارند قدردانی می‌کنیم و پیشنهاداتی را در مورد چگونگی بهبود عملکرد FLEDGE به اشتراک گذاشته‌ایم. به موازات آن، ما ابزارهایی را به مرورگر اضافه کرده‌ایم که به توسعه‌دهندگان اجازه می‌دهد بهتر تشخیص دهند که چه چیزی باعث کندی حراج‌ها می‌شود ، و به طور سیستماتیک به منابع اولیه تأخیر مشاهده‌شده پرداخته‌ایم. پیشرفت‌های اخیر شامل مهلت زمانی برای حراج‌های آهسته ، تکنیک فیلتر سریع پیشنهاددهنده ، روشی برای استفاده مجدد از Worklet‌های FLEDGE برای جلوگیری از پرداخت هزینه‌های راه‌اندازی ، و کار مداوم برای اجازه دادن به درخواست آگهی متنی برای اجرا موازی با زمان راه‌اندازی FLEDGE و واکشی‌های شبکه است. ما انتظار داریم که بهینه‌سازی تأخیر به‌عنوان یک مکالمه مداوم بین توسعه‌دهندگان Chrome و آزمایش‌کنندگان FLEDGE بر اساس تجربه دنیای واقعی آن‌ها با استفاده از API ادامه یابد.
محدودیت حافظه اندازه گروه علاقه	درخواست افزایش محدودیت اندازه یک گروه ذینفع از 50 کیلوبایت.	ما فعالانه درخواست را بررسی می کنیم و به دنبال بازخوردی در مورد اینکه چه مقدار محدودی کار می کند هستیم.
ترکیب داده های ارائه شده FLEDGE با کوکی شخص اول	آیا FLEDGE از ادغام با داده های شخص اول تبلیغ کننده پشتیبانی می کند؟	FLEDGE برای پشتیبانی از تبلیغات با استفاده از داده‌های شخص اولی که یک تبلیغ‌کننده از قبل دارد ساخته شده است. با این حال، FLEDGE قصد ندارد از تبلیغ کننده ای پشتیبانی کند که رفتار مرور یک شخص را در هیچ وب سایتی غیر از سایت خود تبلیغ کننده یاد می گیرد. ضمیمه کردن رفتار مرور خارج از سایت به داده های شخص اول مغایر با اهداف Privacy Sandbox است. ما در حال برنامه ریزی برای به اشتراک گذاشتن راهنماهای یکپارچه سازی با جزئیات بیشتر در مورد نحوه پشتیبانی FLEDGE از ادغام با داده های شخص اول در هفته های آینده هستیم.
ارزش ناشناس بودن K	مقدار "K" به "k-anon" چگونه تعیین می شود و آیا منتشر می شود؟	مقدار "K" هنوز در حال نهایی شدن است و با توسعه برنامه هایمان اطلاعات بیشتری را به اشتراک خواهیم گذاشت. ما علاقه مندیم در مورد اینکه چگونه یک مقدار k ناشناخته ممکن است مانع آمادگی FLEDGE و آموزش مدل ML شود، بیشتر بیاموزیم و از بازخورد اضافی در مورد این موضوع استقبال می کنیم.
پشتیبانی از چندین SSP	چگونه چندین SSP در FLEDGE پشتیبانی خواهند شد؟	همانطور که در این پیشنهاد ذکر شده است، FLEDGE از حراج های چند فروشنده پشتیبانی می کند.
قابل مشاهده بودن منطق مناقصه	نگرانی از اینکه منطق مناقصه DSP در جاوا اسکریپت نمایش داده شود	با منطق مناقصه طراحی فعلی، جاوا اسکریپت می تواند توسط دیگران قابل دسترسی باشد، اما ما از بازخورد بیشتری در مورد اینکه چرا این می تواند منبع نگرانی برای DSP ها باشد استقبال می کنیم.
prebid.js	جدول زمانی پشتیبانی از prebid.js در FLEDGE چیست؟	فقط نسخه‌های 7.14 و جدیدتر Prebid.js از ماژول FLEDGE پشتیبانی می‌کنند. هر ناشر علاقه مند به آزمایش باید ماژول FLEDGE را اضافه کند و نمونه Prebid خود را ارتقا دهد.
توابع تعریف شده توسط کاربر در FLEDGE	چگونه توابع تعریف شده کاربر (UDF) در FLEDGE پشتیبانی می شوند؟ اینها توابعی هستند که می توانند توسط کاربران نهایی برای گسترش عملکرد API برنامه ریزی شوند.	توضیح دهنده در اینجا موجود است. این هنوز در حال تکمیل است، بنابراین ما از بازخورد اضافی در مورد موارد استفاده استقبال می کنیم.
کاهش محدودیت منبع مشابه در منابع گروه بهره	برای فعال کردن موارد استفاده از فناوری تبلیغاتی خاص، درخواست کاهش محدودیت‌های همان مبدأ در منابع گروه علاقه‌مندی کنید	در اجرای فعلی FLEDGE، `biddingLogicUrl` ، `biddingWasmHelperUrl` ، `dailyUpdateUrl` و `trustedBiddingSignalsUrl` باید منشأ یکسانی با مالک گروه ذینفع داشته باشند. محدودیت برای جلوگیری از سوء استفاده های خاص توسط مهاجمان وجود دارد، همانطور که در اینجا توضیح داده شده است.
مالکیت interestGroup	درخواست برای محدود کردن اینکه آیا یک فناوری تبلیغات می‌تواند از joinInterestGroup برای گروه‌های علاقه یکسان در سراسر سایت‌ها استفاده کند یا خیر.	تمرکز ما بر نحوه استفاده از مخاطبان است نه نحوه ساخت آنها. ما در حال بحث در مورد رویکردهای بالقوه هستیم و از ورودی های اضافی استقبال می کنیم.
ارزش کلید انقضای کلید سرور	بحث در مورد حذف کلیدهای سرور پس از انقضای گروه های ذینفع مربوطه	ما در حال بررسی راه هایی برای رسیدگی به انقضای کلید هستیم و به دنبال بازخورد هستیم.

اندازه گیری تبلیغات دیجیتال

گزارش انتساب (و سایر APIها)

موضوع بازخورد	خلاصه	پاسخ کروم
ترافیک آزمایشی مبدا	ترافیک فعلی Origin Trial برای انجام آزمایش ابزار کافی نیست.	Origin Trials کنونی برای بازیکنان اکوسیستم طراحی شده است تا آزمایشات عملکردی را انجام دهند تا اطمینان حاصل شود که API همانطور که در نظر گرفته شده است کار می کند. ما می‌دانیم که وقتی توسعه API مختلف Privacy Sandbox بالغ‌تر شد، برای انجام تست ابزار به حجم بیشتری از ترافیک نیاز است. جدول زمانی آزمایش فعلی پیش‌بینی می‌کند که این امر در دسترس‌پذیری عمومی (یعنی زمانی که فناوری‌های موارد استفاده راه‌اندازی می‌شوند و برای 100٪ ترافیک Chrome در دسترس هستند) در سه ماهه سوم 2023 (به جدول زمانی به‌روز ما در privacysandbox.com مراجعه کنید) رخ می‌دهد. ما از هرگونه بازخورد اضافی در مورد آزمایش مورد استفاده که نیاز به ترافیک بیشتری دارد استقبال می‌کنیم.
همپوشانی در عملکرد API های مختلف اندازه گیری Privacy Sandbox	نگرانی در مورد همپوشانی چندین رویکرد اندازه‌گیری از طریق Privacy Sandbox، پیچیدگی را افزایش می‌دهد، به‌عنوان مثال، Attribution Reporting API و Private Aggregation API.	ما در حال کار بر روی اسناد بهتر برای روشن کردن موارد استفاده مختلف برای APIها هستیم و از بازخوردهای اضافی در مورد مواردی که توضیحی ندارند استقبال می کنیم . به عنوان مثال، Attribution Reporting API به طور خاص برای پشتیبانی از اندازه‌گیری تبدیل در نظر گرفته شده است، در حالی که API جمع‌آوری خصوصی و ذخیره‌سازی مشترک APIهای همه منظوره هستند که برای پشتیبانی از طیف وسیع‌تری از موارد استفاده اندازه‌گیری بین سایتی در نظر گرفته شده‌اند.
درخواست گزارش ناموفق را دوباره امتحان کنید	توضیح در مورد اینکه چند بار درخواست گزارش در صورت عدم موفقیت درخواست شده است.	ما راهنمایی در این مورد منتشر کرده ایم . به طور خلاصه، گزارش‌ها فقط زمانی ارسال می‌شوند که مرورگر در حال اجرا/آنلاین باشد. پس از اولین عدم ارسال، گزارش پس از 5 دقیقه دوباره امتحان می شود. پس از شکست دوم، گزارش پس از 15 دقیقه دوباره امتحان می شود. پس از آن گزارش ارسال نمی شود.
تاخیر گزارش	تاخیر گزارش مورد انتظار چقدر است؟	ما به دنبال شنیدن بازخورد بیشتری از اکوسیستم در مورد تأخیرهای گزارش دهی آنها هستیم زیرا داده هایی را برای ارزیابی بیشتر این تاخیرها به صورت موازی جمع آوری می کنیم.
صفحات پیش اجرا	آیا ارجاع ARA در صفحات پیش اجرا کار خواهد کرد؟	ثبت نام در صفحات پیش اجرا تا زمان فعال سازی (کلیک یا مشاهده واقعی) به تعویق می افتد. این بدان معناست که پینگ درخواست «attributionsrc» را به تعویق می اندازیم.
اندازه گیری بالابر تبدیل	نحوه اندازه گیری افزایش تبدیل با آزمایش AB در همان دامنه	وب‌سایت‌ها می‌توانند افزایش تبدیل را با آزمایش A/B در همان دامنه از طریق گزارش اسناد اندازه‌گیری کنند. آن‌ها می‌توانند پارامترهای A/B خود را به‌عنوان کلید با استفاده از API کل رمزگذاری کنند و سپس گزارش‌های خلاصه‌ای را برای مقادیر تبدیل توسط آن سطل‌های کلید دریافت کنند.
(همچنین در Q3 گزارش شده است) تبدیل های بین دامنه ای	نحوه ردیابی تبدیل هایی که متقاطع دامنه هستند، مانند 2 یا چند مقصد	به روز رسانی Q4: ما پیشنهادی برای حذف محدودیت مقصد صفحه فرود منتشر کرده‌ایم که امکان ردیابی مکالمات بین دامنه‌ای را فراهم می‌کند. این پیشنهاد اجرایی شده است.
(همچنین در سه ماهه سوم گزارش شده است) تنظیم انقضا در گزارش تبدیل	درخواست برای پشتیبانی از فیلتر گزارش / انقضا برای کمتر از 24 ساعت	به روز رسانی Q4: ما این درخواست کشش را به اشتراک گذاشته‌ایم که پنجره‌های انقضا و گزارش را از هم جدا می‌کند تا مبادله تاخیر گزارش در مقابل انقضای تبدیل را کاهش دهد. این در حال حاضر در M110 راه اندازی شده است.
تقلب و سوء استفاده	درخواست‌هایی از تبلیغ‌کنندگان و بازاریاب‌ها برای اینکه بتوانند داده‌ها را بر اساس سایت‌های ناشری که در آن آگهی‌هایشان ارائه می‌شود، برش داده و جمع‌آوری کنند، که همچنین بینش بیشتری در مورد شیوه‌های تبلیغات تقلبی احتمالی می‌دهد.	این بازخورد به طور فعال در اینجا مورد بحث قرار می گیرد و ما از ورودی های اضافی استقبال می کنیم.
(همچنین در Q3 گزارش شد) تاخیر گزارش سطح رویداد	تاخیر 2 تا 30 روزه در گزارش سطح رویداد ممکن است برای موارد استفاده خاص بسیار طولانی باشد.	گزارش سطح رویداد دارای پنجره های گزارش پیش فرض 2، 7 و 30 روزه است. این را می توان با استفاده از پارامتر "expiry" تغییر داد. Ad-tech ها می توانند انقضا را با حداقل 1 روز پیکربندی کنند تا گزارش های احتمالی را در کمتر از 2 روز دریافت کنند. به‌عنوان مکانیزم حفاظت از حریم خصوصی، جزئیات انقضاها را به ۱ روز محدود می‌کنیم، زیرا گزارش‌های دقیق‌تر می‌تواند منجر به حملات زمان‌بندی شود. علاوه بر این، ما اجازه می دهیم پارامترهای مستقل "انقضا" را برای سطح رویداد و گزارش های انبوه تنظیم کنیم. اینجا را ببینید. به‌علاوه، Google Ads پنجره‌های گزارش‌گیری خاصی را که سایر فناوری‌های تبلیغاتی از طریق Attribution Reporting API دریافت نمی‌کنند، دریافت نخواهد کرد.
همان نیاز مبدا گزارش دهی	درخواست حذف الزام برای یکسان بودن مبدا ثبت منبع با مبدا ثبت تبدیل	ما پیشنهاد می کنیم از تغییر مسیرهای HTTP برای واگذاری ثبت نام برای حل این مورد استفاده استفاده کنیم. از هرگونه بازخورد اضافی در مورد راهنمایی جدید استقبال می کنیم.
ردیابی تبدیل	باید متمایز شود که آیا تبدیل قبل یا بعد از ساعات مشخصی که توسط تبلیغ‌کننده تعیین می‌شود اتفاق افتاده است یا خیر	Attribution Reporting API از تنظیم یک پنجره انقضا و اولویت برای انتساب منبع پشتیبانی می کند. با استفاده از هر دو، از نظر فنی می‌توان تبدیلی را که در پنجره X روز اتفاق افتاد جدا از تبدیلی که بعد از X اتفاق افتاد نسبت داد.
شبیه سازی نویز	درخواست برای شبیه‌سازی حجم مختلف تبدیل‌ها در هر سطل، برای درک تأثیر بر تبلیغ‌کنندگان با تبدیل کمتر	ما به دنبال اضافه کردن راه هایی برای شبیه سازی این موضوع در نسخه های بعدی Noise Lab هستیم. ما از هرگونه بازخورد اضافی استقبال می کنیم.
گزارش در موبایل	آیا وقتی Chrome در پس‌زمینه در تلفن همراه اجرا می‌شود، گزارش همچنان ارسال می‌شود؟	در حال حاضر، حتی در تلفن همراه، وقتی کروم در پس‌زمینه است، گزارش ارسال نمی‌شود. زمانی که API با Android Privacy Sandbox ادغام می‌شود، این احتمالاً تغییر می‌کند. اینجا را ببینید. توجه داشته باشید که Android Privacy Sandbox بخشی از تعهدات پذیرفته شده توسط CMA نیست.
در دسترس بودن داده ها	نگرانی‌هایی که Google از طریق APIهای Privacy Sandbox به داده‌ها دسترسی بیشتری خواهد داشت	اول، Google Ads هیچ گونه دسترسی ترجیحی به داده‌ها از API گزارش Attribution یا سایر APIهای Privacy Sandbox دریافت نمی‌کند. این موضوع همچنین در بخش بازخورد عمومی در بخش "تعامل پذیری" که شامل جزئیات بیشتری در مورد تعهدات Google است، پرداخته شده است. دوم، در مورد تفاوت بین سایت های بزرگتر و کوچکتر، گوگل تشخیص می دهد که حفاظت از حریم خصوصی مبتنی بر نویز ممکن است تأثیر بیشتری بر بخش های داده کوچکتر داشته باشد. با این حال، برخی کاهش‌های احتمالی وجود دارد: برای مثال، روش‌هایی مانند تجمیع در دوره‌های زمانی طولانی‌تر این مشکل را حل می‌کند. با این حال، مشخص نیست که آیا نتیجه‌گیری بر اساس برش‌های داده بسیار کوچک (مانند یک یا دو خرید) اصلاً برای تبلیغ‌کنندگان معنادار است یا خیر. در طول آزمایش اولیه، Google آزمایش‌کنندگان را تشویق کرده است تا از توانایی آزمایش طیف گسترده‌ای از پارامترهای حریم خصوصی و نویز استفاده کنند تا بتوانند بازخورد خاص‌تری درباره این موضوع ارائه دهند.

ردیابی پنهان را محدود کنید

کاهش عامل کاربر

موضوع بازخورد	خلاصه	پاسخ کروم
تا زمانی که اکوسیستم وب آماده تر شود، کاهش عامل کاربر را به تاخیر بیندازید	زمان کافی برای انطباق با تغییرات آتی کاهش عامل کاربر وجود ندارد.	ما این بازخورد را در گزارش کامل در زیر "نگرانی های ذینفعان" در بخش با عنوان "تعامل Google با CMA" بررسی می کنیم.
تا زمانی که اکوسیستم وب آماده تر شود، کاهش عامل کاربر را به تاخیر بیندازید	درخواست به تأخیر انداختن عرضه کاهش عامل کاربر تا زمانی که SUA مستقر شود	تیم Google Ads افزودن ساختار یافته کاربر-عامل ( به مشخصات را ببینید) در اکتبر 2021 به OpenRTB پیشنهاد کرد و در به‌روزرسانی مشخصات 2.6 که در آوریل 2022 منتشر شد، گنجانده شد. ما شواهدی داریم که نشان می‌دهد SUA امروزه مستقر و در دسترس است، همانطور که در پست وبلاگ Scientia Mobile نشان داده شده است که نحوه استفاده از UA-CH و WURFL API برای ایجاد یک SUA را نشان می‌دهد.

###

نکات مشتری عامل کاربر

موضوع بازخورد	خلاصه	پاسخ کروم
UA-CH را با سایر تکنیک های ردیابی ضد پنهان آزمایش کنید	راهنمایی در مورد نحوه آزمایش همه APIهای Sandbox Privacy و تکنیک‌های اثرانگشت ارائه شده با هم در یک رویکرد جامع	طرح آزمایشی ما به‌منظور منعکس‌کردن جدول‌های زمانی ناهمزمان برای توسعه برخی از اقدامات ضد اثرانگشت بر خلاف بقیه پیشنهادات Sandbox طراحی شده است. به این واقعیت می پردازد که برخی از اقدامات ضد اثرانگشت (به عنوان مثال بودجه حریم خصوصی، حفاظت از IP و کاهش ردیابی پرش) به طور کامل توسعه یافته و تنها پس از منسوخ شدن کوکی های شخص ثالث برای دسترسی عمومی آماده می شوند. در حالی که این اقدامات ضد اثرانگشت در آزمایش‌های کمی گنجانده نمی‌شوند، اما بر اساس حقایق موجود در زمان Standstill، مشمول ارزیابی کیفی خواهند بود.
(همچنین در سه ماهه دوم گزارش شده است) عملکرد	نگرانی در مورد تأخیر دریافت راهنمایی از طریق Critical-CH (در بارگذاری صفحه اول)	بخش اختصاصی UA-CH را در زیر ببینید
بازخورد ناکافی	بازخورد اکوسیستم در مورد تغییر UA-CH ممکن است کافی نباشد، که منجر به نگرانی در مورد عدم آگاهی از اکوسیستم می شود.	ما به طور فعال برنامه‌های خود را به اشتراک گذاشته‌ایم تا از عرضه دقیقی که اختلال را به حداقل می‌رساند اطمینان حاصل کنیم. طرح‌های کاهش عامل کاربر و UA-CH API در 18 مارس 2022 به گروه جامعه ضد کلاهبرداری W3C و در 20 ژانویه 2022 به گروه پرداخت وب و گروه سود امنیت پرداخت وب ارائه شد. هیچ نگرانی قابل توجهی در طول یا بعد از ارائه‌ها مطرح نشد. گوگل به طور فعال با بیش از 100 اپراتور سایت برای دریافت بازخورد درگیر شده است. علاوه بر این، گوگل همچنین از کانال‌های Blink-Dev برای برقراری ارتباط عمومی کاهش عامل کاربر بر اساس بازخورد سهامداران اکوسیستم استفاده کرده است.
زمان بندی	نگرانی های مطرح شده در مورد زمان عرضه و آمادگی صنعت	بخش اختصاصی UA-CH را در زیر ببینید
وضعیت پلتفرم Chrome	درخواست کرد که صفحه chromestatus برای UA-CH به روز شود	ورودی chromestatus در 19 دسامبر به "سیگنال های مختلط" به روز شد.

حفاظت IP (Gnatcatcher سابق)

موضوع بازخورد	خلاصه	پاسخ کروم
شرکت کردن یا انصراف	آیا حریم خصوصی آدرس IP را انتخاب کنید یا انصراف دهید؟	هدف ما ارائه حفاظت IP برای همه کاربران است. با در نظر گرفتن این هدف، در حال حاضر در حال ارزیابی گزینه های انتخاب کاربر برای حفاظت از IP هستیم.
مورد استفاده آدرس IP برای داده های شخص اول	آیا می توان از آدرس های IP برای دوخت سفرهای کاربر در دامنه های شخص اول حمایت از IP استفاده کرد؟	همانطور که قبلاً منتشر شد ، محافظت IP در ابتدا روی ردیابی در متن شخص ثالث متمرکز خواهد شد ، این بدان معنی است که دامنه های شخص اول تحت تأثیر قرار نمی گیرند.
موارد استفاده از فناوری	چگونه شرکت ها می توانند اقدامات ضد کلاهبرداری را با محافظت از IP تنظیم کنند؟	ما اهمیت آدرس IP را به عنوان سیگنالی برای تلاش های ضد کلاهبرداری در وب امروز تشخیص می دهیم. به عنوان بخشی از تعهدات ما به CMA (بند 20) ، ما گفتیم که ما محافظت از IP را بدون تلاش های معقول برای پشتیبانی از توانایی وب سایت ها در انجام اقدامات ضد اسپم و ضد کلاهبرداری انجام نخواهیم داد. یکی از اولویت های اصلی ما این است که درک کنیم که چگونه محافظت از IP بر موارد استفاده ضد کلاهبرداری و قابلیت های تشخیص تأثیر می گذارد ، به طوری که ما می توانیم بیشتر در فن آوری های حفظ حریم خصوصی سرمایه گذاری کنیم که به شرکت ها کمک می کند تا ایمنی وب را حفظ کنند. ما بازخورد و ورودی را در مورد پیشنهادات جدید با هدف حمایت از نیازهای شرکتهای امنیتی و ضد کلاهبرداری تشویق می کنیم ، حتی اگر سیگنال ها با گذشت زمان تغییر کنند.
تقلب و سوء استفاده	آیا محافظت از IP شامل انکار سرویس (DOS) است؟	ما متعهد هستیم ضمن حفظ ایمن بودن وب ، حریم خصوصی را بهبود بخشیم و محافظت در برابر حملات انکار سرویس ، یک مورد مهم استفاده از ضد سوء استفاده برای طراحی است. ما امیدواریم که از طریق طراحی محافظت از IP و از طریق راه حل های جدید ضد سوء استفاده ، تأثیر را در حفاظت از DOS به حداقل برسانیم. از آنجا که در ابتدا محافظت از IP بر روی خدمات تعبیه شده شخص ثالث متمرکز شده است ، برخی از ذینفعان اعلام کرده اند که باید تأثیر محدودی در محافظت DOS برای سایت های شخص اول داشته باشد. با این حال ، ما همچنان از بازخورد عمومی برای ارزیابی ریسک برای موارد استفاده DOS ، به ویژه برای خدمات جاسوسی شخص ثالث استفاده می کنیم . به موازات ، ما در حال بررسی مکانیسم های سوءاستفاده و مسدود کردن مشتری هستیم که یک سایت یا سرویس را قادر می سازد بدون شناسایی کاربر ، یک کاربر اسپم را مسدود کند.
فیلتر محتوا	فیلتر محتوا با محافظت از IP	شرکت های مختلف با توجه به فیلتر کردن محتوا و شخصی سازی تجربه کاربر نیازهای متفاوتی دارند. بسیاری از موارد استفاده در حال حاضر به آدرس های IP متکی نیستند و بنابراین باید تحت تأثیر محافظت IP قرار بگیرند. به عنوان مثال ، ناشر که به دنبال تنظیم محتوای خود و رانندگی بیشتر درگیری است ، ممکن است از کوکی های شخص اول یا کوکی های پارتیشن شخص ثالث (تراشه) برای درک علایق کاربر و تعامل قبلی با ناشر استفاده کند. یا یک شریک AD Tech با تمرکز بر ارائه تبلیغ مناسب به کاربر مناسب ، می تواند Fledge و موضوعات را در بر بگیرد ، به عنوان مثال ، برای ارائه نتایج AD مشابه همانطور که امروز با کوکی های شخص ثالث یا سایر فن آوری های ردیابی متقابل انجام می شود. ما همچنین در حال بررسی ایجاد قابلیت های جدید برای حفظ حریم خصوصی در محافظت از IP ، مانند جغرافیایی درشت ، برای پشتیبانی بیشتر از فیلتر محتوا در جایی که مکانیسم های موجود ممکن است کافی نباشد. ما از بازخورد اضافی در مورد موارد استفاده از فیلتر محتوا که ممکن است تحت تأثیر محافظت IP باشد استقبال می کنیم.
(همچنین در Q3 گزارش شده است) موارد استفاده از جغرافیا	محافظت از IP ممکن است مانع از کار با استفاده از جغرافیایی قانونی در آینده شود ، مانند شخصی سازی محتوا بر اساس جغرافیایی.	به روزرسانی Q4: ما با ذینفعان همکاری می کنیم تا اطمینان حاصل کنیم که Chrome همچنان به پشتیبانی از موارد قانونی برای آدرس های IP ادامه می دهد. ما در اینجا به دنبال بازخورد اکوسیستم در مورد دانه جغرافیایی IP هستیم.

بودجه حریم خصوصی

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

مرزهای حفظ حریم خصوصی سایت را تقویت کنید

ست های شخص اول

موضوع بازخورد	خلاصه	پاسخ کروم
(همچنین در Q3 گزارش شده است) حد دامنه	درخواست گسترش تعداد حوزه های مرتبط	به روزرسانی Q4: ما FPS را برای آزمایش های محلی منتشر کرده ایم ، از جمله یک فرآیند ارسال مجموعه مسخره در GitHub و یک پرچم برای آزمایش RSA و RSAFOR به صورت محلی. ما همچنین دو جلسه باز برای توسعه دهندگان در FPS برگزار کرده ایم تا همچنان به سؤالات مربوط به موارد استفاده برای زیر مجموعه های مرتبط بپردازیم. ما توسعه دهندگان را ترغیب می کنیم تا عملکرد FPS را آزمایش کنند تا بازخوردی در مورد چگونگی تأثیر دامنه برای زیر مجموعه مرتبط بر قابلیت استفاده از FPS برای موارد استفاده آنها تأثیر بگذارند. ما در تماس های WICG توضیح داده ایم که Chrome متعهد به ارائه یک راه حل قابل استفاده است که منافع حریم خصوصی کاربران را نیز در نظر می گیرد. در این راستا ، ما از بازخورد جامعه در مورد موارد استفاده خاص که ممکن است تحت تأثیر محدودیت دامنه باشد ، قدردانی می کنیم ، به طوری که این تیم می تواند راه های پرداختن به این موارد استفاده را در حالی که همچنان به حفظ حریم خصوصی کاربر است ، در نظر بگیرد.
درخواست اطلاعات بیشتر در مورد اقدامات کاهش سوءاستفاده	چه اتفاقی می افتد اگر دامنه ای به مجموعه ای اضافه شود که آنها رضایت نداشته باشند؟	ما دستورالعمل های ارسال برای مجموعه های شخص اول را در 2 دسامبر 2022 منتشر کرده ایم. همانطور که در دستورالعمل های ارسال توضیح داده شده است ، هر مدیریت تغییر مجموعه ای پیروی می کند و یک فرآیند اعتبار سنجی در مورد GitHub ، از جمله اعتبار در مالکیت ، که باید این خطر را کاهش دهد ، احترام می گذارد.
کاهش	نگرانی از این که از سازندهای تعیین شده شخص اول قابل بهره برداری باشد	ما به دنبال راه هایی برای گسترش چک های فنی برای انواع زیر مجموعه هستیم و به طور فعال به دنبال ورودی اضافی از جامعه در اینجا هستیم.
تبلیغات از موارد استفاده می کند	سؤالاتی در مورد اینکه آیا از مجموعه های شخص اول برای پشتیبانی از هدف گذاری تبلیغ استفاده می شود	ما در تلاش نیستیم تا از تبلیغات هدفمند استفاده از موارد استفاده برای مجموعه های شخص اول پشتیبانی کنیم و توصیه می کنیم از API های ADS موجود برای چنین مواردی استفاده کنید.
(همچنین در Q3 گزارش شده است) سیاست	این نگرانی که FPS با تعهدات CMA در مورد "قانون حمایت از داده های قابل اجرا" سازگار نیست ، بر این اساس که GDPR محدودیتی را برای تعداد سایت ها در یک مجموعه تحمیل نمی کند در حالی که FPS محدودیت 3 را پیش بینی می کند	پاسخ ما از Q3 بدون تغییر است: "Google در حال تعهد به CMA برای طراحی و اجرای پیشنهادات Sandbox Privacy است که به شکلی که رقابت را با پیشگیری از تجارت خود Google تحریف نمی کند ، و تأثیرگذاری بر رقابت در تبلیغات دیجیتال ، ناشران و تبلیغ کنندگان و همچنین تأثیرگذاری بر پیامدهای حفاظت از داده ها ، همانطور که در قانون کاربردی ارائه شده است ، در نظر می گیرد. ناسازگاری با GDPR ما همچنان با CMA همکاری می کنیم تا اطمینان حاصل شود که کار ما با این تعهدات مطابقت دارد. "
پیشنهاد جایگزین	مجموعه های معتبر GDPR	علاوه بر بازخورد ارائه شده توسط اکوسیستم در مورد پیشنهاد اتخاذ "مجموعه های معتبر GDPR" ، Chrome نگرانی در مورد محدودیت های زیر این پیشنهاد جایگزین دارد: "GDPR مجموعه های معتبر" ادعا می کند که "با" GDPR "تراز شده است (اگرچه واقعاً مشخص نیست که منظور از آن چیست). در مقابل ، تعهدات Google نیاز به در نظر گرفتن "تأثیر بر نتایج حریم خصوصی" به طور کلی دارد. CMA در تصمیم خود در مورد پذیرش تعهدات ، خاطرنشان می کند که این از تعهد گوگل برای در نظر گرفتن "پیروی از اصول حفاظت از داده ها همانطور که در قانون حفاظت از داده های قابل اجرا آمده است" متمایز است ، که همانطور که CMA توضیح می دهد ، این واقعیت را نشان می دهد که Google به قانون حفاظت از داده های قابل اجرا محدود می شود ، هم به طور کلی به تعهدات مربوط می شود. ما نگرانی های مربوط به حریم خصوصی در مورد این پیشنهاد برای اجازه دادن دامنه ها در مجموعه های مختلف داریم. مجموعه های شخص اول برای پشتیبانی از موارد استفاده خاص که در حال حاضر به کوکی های شخص ثالث بستگی دارد بدون اینکه ردیابی فراگیر در سایت را فعال کند ، در نظر گرفته شده است. اجازه دادن به دامنه ها برای پیوستن به چندین مجموعه ، می تواند یک محافظت از حریم خصوصی کلیدی را که در پیشنهاد مجموعه های شخص اول ایجاد شده است ، بدون معرفی محدودیت های معنی دار دیگر حذف کند. مجموعه های معتبر GDPR همچنین پیشنهاد می کنند "مجموعه ای را به عنوان گروهی از کنترل کننده های داده و پردازنده هایی که یک خط مشی استفاده مشترک دارند" تعریف کنند. این شبیه به الزام در پیشنهاد اصلی مجموعه های شخص اول ما است که همه طرفین در یک مجموعه باید یک سیاست حفظ حریم خصوصی مشترک را به اشتراک بگذارند. ما از آن زمان این شرط را بر اساس بازخورد شدید از اکوسیستم نگرانی در مورد الزامات مبتنی بر سیاست حفظ حریم خصوصی حذف کرده ایم. به عنوان مثال ، ما از ناشران سایت شنیدیم که حفظ یک سیاست حفظ حریم خصوصی مشترک به دلیل تغییرات محصول و جغرافیایی ، از جمله سایر چالش های ایجاد شده توسط اعضای جامعه W3C ( 1 ، 2 ، 3 ) غیرقابل نفوذ است. ما معتقدیم که همین چالش ها در مورد این پیشنهاد اعمال می شود. از آنجا که این گزینه جایگزین شد ، Chrome پیشنهاد مجموعه های شخص اول را به روز کرده و دستورالعمل های ارسال را برای ایجاد مجموعه های جدید منتشر کرده است.

Fenced Frames API

موضوع بازخورد	خلاصه	پاسخ کروم
محدودیت های قاب های حصارکشی در طول OT	محدودیت های فعلی در مورد فریم های حصارکشی برای دوره آزمایشی مبدا چیست؟	ما در حال کار بر روی مستندات در مورد محدودیت ها و وضعیت اجرای هستیم و قصد داریم آن را در طول Q1 2023 به اشتراک بگذاریم.
چندین تبلیغ در یک قاب حصار	درخواست نمایش چندین تبلیغ در یک قاب حصار در یک حراج	در حال حاضر ، این درخواست به طور فعال توسعه نمی یابد ، اما اگر بازیکنان اکوسیستم ویژگی را مهم بدانند ، از بازخورد اضافی استقبال می کنیم.
بسته های وب	الزامات و پشتیبانی برنامه ریزی شده برای بسته های وب با قاب های حصارکشی چیست؟	ما در حال حاضر به روزرسانی در مورد اینکه آیا این الزام در آینده خواهد بود ، نداریم. هرگونه تغییر از قبل اعلام می شود و قبل از استهلاک کوکی شخص ثالث اجرا نمی شود. لطفاً برای وضعیت فعلی این توضیح دهنده را ببینید.

API ذخیره سازی مشترک

موضوع بازخورد	خلاصه	پاسخ کروم
ذخیره سازی مشترک برای فناوری تبلیغاتی	عدم اطمینان پیرامون استفاده از ذخیره مشترک برای موارد استفاده از فناوری تبلیغاتی	ذخیره سازی مشترک و API جمع آوری خصوصی می تواند برای انواع مختلفی از اهداف اندازه گیری که نیاز به اندازه گیری ذخیره سازی در سایت دارند استفاده شود. برخی از نمونه ها در اینجا ذکر شده است. ما در حال پیش بینی DSP و ارائه دهندگان راه حل اندازه گیری هستیم تا یکپارچه ساز اصلی موارد استفاده از تبلیغات باشد.

تراشه ها

موضوع بازخورد	خلاصه	پاسخ کروم
(همچنین در Q3 گزارش شده است) نیاز تقسیم شده	نیاز به رفتار صریح را برای ویژگی "تقسیم بندی شده" در کوکی های شخص اول اضافه کنید.	به روزرسانی Q4: پس از بحث و گفتگو در مورد تماس های GitHub و PrivacyCG ، رفتاری که ما روی آن تراز کرده ایم این است که کوکی های تقسیم شده روی کوکی های شخص اول که از یک کلید پارتیشن (A ، A) استفاده می کنند ، در جایی که "A" سایت سطح بالا است. ما این رفتار را در مورد توضیحات و مشخصات مستند خواهیم کرد.
مدیریت کوکی ها	آیا ابزاری برای مدیریت/حاکمیت کوکی های شخص اول یا شخص ثالث وجود دارد؟	Devtools Chrome و NetLog می توانند برای آزمایش سایت هایی با مسدود کردن کوکی شخص ثالث فعال شوند. هر دو ابزار گزارش می دهند که کوکی ها به دلیل پیکربندی کاربر مسدود می شوند. ما از بازخورد در مورد نوع وب سایت های حسابرسی اضافی که دوست دارند ببینند استقبال می کنیم.

فدستان

موضوع بازخورد	خلاصه	پاسخ کروم
IDP برای اجازه یک جلسه به دانش RP نیاز دارد	هنگامی که یک کاربر در تلاش است از دو RP های مختلف وارد Feide IDP شود	ما در مورد راه حل های بالقوه برای این موضوع بحث می کنیم.
قابلیت همکاری	نگرانی در مورد تأثیر FEDCM در رابطه بین کاربران و وب سایتهایی که آنها با استفاده از FEDCM و "قابلیت همکاری" بین وب سایت ها وارد می شوند	FEDCM قصد دارد به حمایت از خدمات هویتی فدرال که در حال حاضر به کوکی های شخص ثالث متکی هستند ، پس از حذف کوکی های شخص ثالث از Chrome ، ادامه دهد. ما انتظار داریم که FEDCM فقط یک گزینه در دسترس چنین خدماتی باشد. ارائه دهندگان هویت (IDP) و احزاب با تکیه (RP) برای استفاده از سایر فن آوری هایی که ممکن است متناسب با نیاز آنها باشد ، آزاد هستند. به نظر می رسد که نگرانی های مربوط به رابطه کاربر RP و "قابلیت همکاری" مدیون سوء تفاهم از پیشنهاد FEDCM است. FEDCM آن را به آوارگان واگذار می کند تا تصمیم بگیرد که چه اطلاعاتی را با RP به اشتراک بگذارد ، و به چه شکلی ، هنگامی که کاربر تصمیم به ورود به سایت RP گرفت. FEDCM نیازی به IDP ندارد تا "یک شناسه نامطلوب منحصر به فرد برای هر [RP] ایجاد کند که کاربر با آن تأیید می کند." در عوض ، FEDCM برای هر IDP باز است تا بتواند شناسه واقعی کاربر را به اشتراک بگذارد ، یک نسخه در هر سایت از آن شناسه یا نسخه دیگری از این اطلاعات. . FEDCM همچنین در حال حاضر انتخاب کاربر را با توجه به هویت فراهم می کند. به عنوان مثال ، اگر کاربر دارای چندین هویت با همان IDP باشد (به عنوان مثال ، یک پروفایل کار و یک پروفایل شخصی) ، FEDCM راهی را برای کاربر فراهم می کند تا کدام یک را که می خواهد برای ورود به سایت RP استفاده کند انتخاب کند. فراتر از آن ، هر RP برای خود تصمیم می گیرد که IDP ها از سایت خود پشتیبانی کنند. یکی از جنبه های این تصمیم در نظر گرفتن مکانیسمی است که یک IDP به آن متکی است ، خواه FEDCM باشد یا یک فناوری متفاوت. باز هم ، مرورگر این گزینه ها را برای RPS یا IDP ها دیکته نمی کند.

با هرزنامه و کلاهبرداری مبارزه کنید

API Token State Private

موضوع بازخورد	خلاصه	پاسخ کروم
دست زدن به رباتها	چه اتفاقی می افتد اگر صادرکننده کشف کند که نشانه های دولتی خصوصی به رباتها صادر شده است؟	برای جلوگیری از توکن های صادر شده برای باقیمانده در اکوسیستم برای مدت طولانی ، صادرکنندگان باید کلیدهایی را که استفاده می کنند برای امضای نشانه ها به طور مرتب بچرخانند ، به گونه ای که نشانه های قدیمی صادر شده تحت منطق صدور بالقوه شکسته منقضی می شوند و سایت ها با منطق صدور به روز شده ، نشانه های جدیدتر را بازخرید می کنند.
ارسال فرم همان سایت	آیا می توان از نشانه های ایالتی خصوصی برای ارسال های فرم همان سایت استفاده کرد که شامل ناوبری تمام صفحه (IE محتوا-نوع: Application/X-ww-form-urlencoded) به جای درخواست API های Fetch/XMLHTTPREQUEST است؟	این در حال حاضر در نسخه اول نشانه های دولتی خصوصی پشتیبانی نمی شود. اگر تقاضای شدیدی برای این مورد استفاده شود ، از بازخورد اکوسیستم استقبال می کنیم.
تأیید سمت سرور	سؤالاتی در مورد اینکه آیا نشانه های حالت خصوصی می توانند سمت سرور تأیید شوند	توکن ها در برابر صادرکننده بازخرید می شوند ، و سپس صادرکننده سابقه بازخرید را ایجاد می کند که می تواند شامل خود نشانه یا برخی از ارزش های امضا شده حاصل از نشانه باشد ، سرورها می توانند از آن سوابق رستگاری برای تأیید صحت این نشانه استفاده کنند ، و ما انتظار داریم که اکوسیستم های مختلف صادرکننده با معیارهای مختلفی برای تفسیر سوابق رستگاری خود روبرو شوند.

گزارش سه ماهه برای سال 2022 Q4 خلاصه بازخورد اکوسیستم دریافت شده از پیشنهادات ماسه ای حریم خصوصی و پاسخ کروم.

به عنوان بخشی از تعهدات خود در مورد CMA ، گوگل موافقت کرده است که گزارش های سه ماهه ای را در مورد فرآیند مشارکت ذینفعان برای پیشنهادات Sandbox حریم خصوصی خود ارائه دهد (به بندهای 12 و 17 (ج) (ii) تعهدات مراجعه کنید). این گزارش های خلاصه بازخورد Sandbox با جمع آوری بازخورد دریافت شده توسط Chrome از منابع مختلف که در نمای کلی بازخورد ذکر شده است ، از جمله اما محدود به: مسائل مربوط به GitHub ، فرم بازخورد موجود در privacysandbox.com ، جلسات با ذینفعان صنعت و انجمن های استاندارد وب تولید می شود. Chrome از بازخورد دریافت شده از اکوسیستم استقبال می کند و به طور فعال در حال بررسی راه های ادغام یادگیری در تصمیمات طراحی است.

مضامین بازخورد با شیوع در هر API رتبه بندی می شوند. این کار با جمع آوری میزان بازخوردی که تیم Chrome در اطراف یک موضوع معین دریافت کرده و به ترتیب نزولی کمیت ، سازماندهی می شود ، انجام می شود. مضامین بازخورد مشترک با بررسی مباحث بحث از جلسات عمومی (W3C ، PATCG ، IETF) ، بازخورد مستقیم ، GitHub و سوالات معمولاً پرسیده شده از طریق تیم های داخلی گوگل و فرم های عمومی مشخص شد.

به طور خاص ، دقایقی جلسات جلسات بدنه های استاندارد وب مورد بررسی قرار گرفت و برای بازخورد مستقیم ، سوابق Google از جلسات 1: 1 ذینفعان ، ایمیل های دریافت شده توسط مهندسین انفرادی ، لیست پستی API و فرم بازخورد عمومی در نظر گرفته شد. سپس گوگل بین تیم های درگیر در این فعالیت های مختلف دسترسی هماهنگ شد تا شیوع نسبی مضامین در رابطه با هر API را تعیین کند.

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

بازخورد دریافت شده پس از پایان دوره گزارش فعلی ممکن است هنوز پاسخ Chrome در نظر گرفته نشده باشد.

واژه نامه مخفف

چیپس: کوکی هایی که دارای وضعیت تقسیم شده مستقل هستند
DSP: بستر سمت تقاضا
فدستان: مدیریت اعتبار فدرال
FPS: مجموعه های مهمانی اول
IAB: دفتر تبلیغات تعاملی
بیجاشدگان داخلی: ارائه دهنده هویت
IETF: کارگروه مهندسی اینترنت
IP: آدرس پروتکل اینترنت
OpenRTB: مناقصه در زمان واقعی
OT: آزمایش مبدا
پتک: گروه جامعه فناوری تبلیغات خصوصی
RP: حزب اتکا
SSP: بستر عرضه
TEE: محیط اجرای مورد اعتماد
UA: رشته عامل کاربر
ua-ch: نکات مشتری عامل کاربر
W3C: کنسرسیوم وب جهانی
WIPB: نابینایی IP اراده

بازخورد عمومی ، هیچ API/فناوری خاص

موضوع بازخورد	خلاصه	پاسخ کروم
(همچنین در Q3 گزارش شده است) سودمندی برای انواع مختلف ذینفعان	نگرانی از اینکه فن آوری های ماسهبازی حریم خصوصی از توسعه دهندگان بزرگتر حمایت می کنند و سایت های طاقچه (کوچکتر) بیشتر از سایت های عمومی (بزرگتر) کمک می کنند	پاسخ ما از Q3 بدون تغییر است: "گوگل به CMA متعهد شده است كه پیشنهادات ماسه صندوق حریم خصوصی را به گونه ای طراحی و پیاده سازی كند كه رقابت را با پیشگیری از تجارت خود Google تحریف نمی كند ، و تأثیرگذاری بر رقابت در تبلیغات دیجیتال و ناشران و تبلیغ کنندگان ، صرف نظر از اندازه آنها ، در نظر می گیرد. با پیشرفت آزمایش ماسهبازی حریم خصوصی ، یکی از سؤالات کلیدی که ما ارزیابی خواهیم کرد این است که چگونه فن آوری های جدید برای انواع مختلف ذینفعان انجام می دهند. بازخورد از این نظر بسیار مهم است ، به ویژه بازخورد خاص و عملی که می تواند به ما در بهبود بیشتر طرح های فنی کمک کند. ما با CMA همکاری کرده ایم تا رویکرد خود را برای آزمایش کمی توسعه دهیم و از انتشار CMA یادداشتی در مورد طراحی آزمایش حمایت می کنیم تا اطلاعات بیشتری را برای شرکت کنندگان در بازار ارائه دهیم و فرصتی برای اظهار نظر در مورد رویکردهای پیشنهادی. "
(همچنین در Q3 گزارش شده است) درخواست های مستند سازی	درخواست منابع بیشتر در مورد نحوه مدیریت آزمایش ، تجزیه و تحلیل و اجرای	به روزرسانی Q4: ما قدردانی می کنیم که توسعه دهندگان مواد فعلی ما را مفید دانسته اند و همچنان متعهد به تهیه مطالب بیشتر هستند تا توسعه دهندگان بتوانند درک کنند که چگونه فناوری های جدید می توانند برای آنها کار کنند. در طی سه ماهه گذشته ، ما یک بخش "اخبار و به روزرسانی ها" را به privacysandbox.com اضافه کردیم و بررسی گسترده ای در مورد چگونگی ماسهبازی حریم خصوصی می تواند به پیشبرد تبلیغات در آینده کمک کند. ما همچنین جلسات ساعتهای دفتر توسعه دهنده عمومی را برای به اشتراک گذاشتن بهترین شیوه ها و نسخه های نمایشی برگزار کرده ایم ، به همراه جلسات پرسش و پاسخ با محصول و مهندسی منجر به بحث و گفتگو/سؤالات زنده می شود.
Core Web Vitals	چگونه تأثیر تأخیر API با تأخیر ماسه ای بر روی وب ویتامین های اصلی تأثیر می گذارد؟	نگه داشتن تأخیر در حداقل یک هدف اصلی طراحی API های ماسه ای حریم خصوصی است. انتظار فعلی ما این است که تأخیر API باید تأثیر کمتری در وب سایت اصلی سایت داشته باشد ، زیرا اکثر API ها پس از ارائه اولیه وب سایت فراخوانی می شوند. ما همچنان به نظارت و پیشرفت هایی برای کاهش تأخیر بیشتر برای هر یک از API ها ادامه می دهیم و ادامه آزمایش و بازخورد را ترغیب می کنیم. تأخیر در فرآیند مناقصه در زمان واقعی در بخش Fledge تحت "عملکرد حراج های Fledge" مورد بررسی قرار می گیرد
قابلیت همکاری	نگرانی در مورد قابلیت همکاری با سایر راه حل های بالقوه	هدف از حریم خصوصی Sandbox محافظت از کاربران در برابر ردیابی متقابل سایت ضمن پشتیبانی از نیازهای اکوسیستم وب است. ما به دنبال این هستیم که با دور شدن از فن آوری های مرورگر میراث که امکان ردیابی متقابل سایت مانند کوکی های شخص ثالث را فراهم می کند ، این کار را انجام دهیم و در جای خود فناوری های جدید را برای پشتیبانی از موارد خاص استفاده کنیم. پیشنهادات Sandbox حریم خصوصی با محدود کردن داده هایی که دستگاه کاربر را ترک می کند ، حریم خصوصی را بهبود می بخشد. این پیشنهادات محدودیت های فنی را بر اساس توانایی وب سایت در به اشتراک گذاشتن یا در غیر این صورت پردازش داده های پس از جمع آوری از مرورگر قرار نمی دهد. بنابراین فناوری ها مانع از ورود شرکت ها به توافق نامه های "داده های داده" یا هر رابطه مشابه قراردادی مشابه نمی شوند. به همین ترتیب ، آنها توانایی کاربران در رضایت به اشتراک گذاری داده های خود را از طریق روش های دیگر محدود نمی کنند. برای شفافیت ، گوگل متعهد شده است که فن آوری های Sandbox را به همان روش برای همه وب سایت ها ، از جمله محصولات و خدمات Google ، به کار گیرد. پس از پایان پشتیبانی Chrome از کوکی های شخص ثالث ، تعهدات همچنین روشن می کند که Google از سایر داده های شخصی مانند تاریخچه مرور کروم همگام سازی کاربران استفاده نمی کند تا کاربران را برای هدف قرار دادن یا اندازه گیری تبلیغات دیجیتال ردیابی کند.

نمایش محتوای و تبلیغات مربوطه

موضوعات

موضوع بازخورد	خلاصه	پاسخ کروم
تأثیر در رتبه بندی جستجوی Google	پرس و جو در مورد اینکه آیا پشتیبانی API مباحث وب سایت به عنوان یک سیگنال بالقوه برای رتبه بندی نتایج جستجوی Google استفاده خواهد شد	برخی از وب سایت ها ممکن است از API موضوعات خودداری کنند. تیم Sandbox حریم خصوصی از سازمان جستجو هماهنگ یا درخواست نکرده است که از رتبه بندی صفحه به عنوان انگیزه ای برای وب سایت ها برای اتخاذ API مباحث استفاده می کند. Google به CMA تأیید کرده است که جستجوی Google از تصمیم سایت برای امتناع از API مباحث به عنوان سیگنال رتبه استفاده نمی کند.
طبقه بندی کننده مباحث	علاوه بر نام میزبان برای تعیین موضوع صفحه وب به منظور بهبود ابزار برای ذینفعان مختلف ، محتوای URL و صفحه را علاوه بر نام میزبان اضافه کنید.	سابقه مرور کاربر در حال حاضر با استفاده از نام میزبان وب سایت طبقه بندی می شود. Chrome به ارزیابی گزینه های مربوط به ابرداده سطح صفحه (مانند همه یا برخی از مؤلفه های URL صفحه و/یا محتوا) در طبقه بندی موضوعات ادامه می دهد. هرگونه پیشرفت ابزار باید در برابر خطرات حریم خصوصی و سوءاستفاده وزن شود. به عنوان مثال ، با توجه به ابرداده به ویژه ، برخی از خطرات شامل موارد زیر است: - سایتها که ابرداده در سطح صفحه را به عنوان روشی برای رمزگذاری معانی متفاوت (و بالقوه حساس) در موضوعات اصلاح می کنند. - سایتها برای اصلاح ابرداده در سطح صفحه برای ارائه نادرست مباحث خود برای سود مالی. -سایت ها به صورت پویا به عنوان روشی برای ردیابی متقابل سایت ، به صورت پویا در سطح صفحه تغییر می کنند
(همچنین در Q3 گزارش شده است) تأثیر بر روی سیگنال های شخص اول	سیگنال مباحث ممکن است بسیار با ارزش باشد و در نتیجه سایر سیگنال های مبتنی بر علاقه شخص اول را کاهش می دهد.	پاسخ ما از Q3 بدون تغییر است: "ما معتقدیم که تبلیغات مبتنی بر علاقه یک مورد استفاده مهم برای وب است و مباحث برای پشتیبانی از آن مورد استفاده طراحی شده است. همانطور که در گزارش Q3 ما شرح داده شده است ، سایر ذینفعان اکوسیستم ابراز نگرانی کرده اند که مباحث ممکن است به اندازه کافی مفید نباشد.
به روزرسانی طبقه بندی	لیست طبقه بندی چگونه به روز می شود؟	ما به طور فعال به دنبال بازخورد در مورد طبقه بندی هستیم که برای اکوسیستم مفیدترین است. طبقه بندی موجود در مباحث اولیه API برای فعال کردن آزمایش عملکردی طراحی شده است. Chrome به طور فعال در حال بررسی چندین رویکرد برای به روزرسانی طبقه بندی است. به عنوان مثال ، Chrome ممکن است از مفهوم ارزش تجاری برای هر موضوع استفاده کند تا مشخص کند کدام گروه را در تکرارهای آینده قرار می دهد.
مباحث عملکرد طبقه بندی منطقه ای	مباحث طبقه بندی کننده عملکرد ضعیف در حوزه های منطقه ای	بهبود در طبقه بندی یک تلاش مداوم است. بر اساس بازخوردی که ما دریافت کرده ایم ، یک امکان مورد نظر گسترش لیست مباحث است که تجزیه و تحلیل ما نشان می دهد پوشش جهانی را افزایش داده و دقت را بهبود می بخشد. برای توضیح ، طبقه بندی API مباحث دارای دو مؤلفه مربوطه است: (1) یک لیست نادیده گرفته شده حاوی سایت های 10K برتر و مباحث آنها ، و (2) یک مدل ML در دستگاه که نام میزبان را به موضوعات طبقه بندی می کند. با گسترش لیست Override (1) ، می توانیم عملکرد طبقه بندی را برای مناطقی که در آن طبقه بندی کننده ممکن است عملکرد ضعیفی داشته باشد ، بهبود بخشد.
دوره یک هفته	دوره یک هفته برای کاربرانی که به دنبال تصمیم گیری های کوتاه تر هستند خیلی طولانی است.	ما به طور فعال در حال بررسی این هستیم که طول مناسب دوره باید باشد و از بازخورد بیشتر در مورد آنچه که می تواند یک دوره بهتر برای اکوسیستم باشد ، استقبال می کنیم.
بازیابی هدر HTTP	نگرانی از این که اطلاعات کافی در مورد بازیابی موضوعات HTTP وجود ندارد	کار برای هدرها و واکشی ها در حال انجام است. ما همچنین اطلاعات موجود در اینجا را داریم. ما همچنین اطلاعات SkipObservation را به توضیح دهنده اضافه کرده ایم.
مباحث فقط هدف کمک به تبلیغ کنندگان است ، نه کاربران	مباحث/ماسهبازی حریم خصوصی به نظر می رسد یک رویکرد متمرکز در صنعت است. فایده برای کاربران به اندازه فایده صنعت مشخص نیست.	ما معتقدیم که فایده کاربران این است که مباحث از تبلیغات مبتنی بر علاقه پشتیبانی می کنند که وب را آزاد و آزاد نگه می دارند ، و ما همچنین معتقدیم که این امر به طور قابل توجهی در مقایسه با کوکی های شخص ثالث حریم خصوصی را بهبود می بخشد . از بین بردن کوکی های شخص ثالث بدون گزینه های قابل استفاده ممکن است بر ناشران تأثیر منفی بگذارد و می تواند منجر به رویکردهای بدتر شود که کمتر خصوصی هستند ، شفاف نیستند و از نظر واقع بینانه قابل تنظیم نیستند یا توسط کاربران کنترل می شوند. بسیاری از شرکت ها به طور فعال در حال آزمایش موضوعات و API های ماسهبازی هستند و ما متعهد هستیم که ابزارهایی را برای پیشبرد حریم خصوصی و پشتیبانی از وب فراهم کنیم. گروه معماری فنی W3C اخیراً نمای اولیه خود را در مورد مباحث API منتشر کرده است ، که ما به آن پاسخ خواهیم داد. در این مرحله ، از آنجا که Google سؤالاتی از اکوسیستم دریافت کرده است که این بررسی ممکن است برای توسعه و راه اندازی موضوعات API دلالت کند ، ما می خواهیم برنامه خود را دوباره تأیید کنیم تا امسال آن را در Chrome Patable در دسترس قرار دهیم. در حالی که Googles از ورودی گروه معماری فنی W3C قدردانی می کند ، آن را برای ادامه تلاش برای توسعه و آزمایش موضوعات با مشورت CMA و اکوسیستم از اهمیت ویژه ای می داند.
نشت داده ها	این نگرانی که مباحث ممکن است بدون اجازه به سایت های دیگر نشت شود	طراحی API مباحث بسیار بعید است که داده های یک ناشر واحد (و حتی یک گروه کوچکتر از ناشران) به هر طریقی فاش شوند. وب سایت های ناشر نیز کنترل کامل بر روی موضوعات API دارند و می توانند از طریق خط مشی اجازه ، دسترسی به این API را ممنوع کنند.
کمبود تبلیغ کننده برای آزمایش	ناشران نگران این هستند که در حال حاضر قادر به نشان دادن ارزش موضوعات برای تبلیغ کنندگان نیستند.	در نیمه دوم سال 2023 ، ما قصد داریم تمام API های مربوط به تبلیغات را برای آزمایش ادغام در دسترس داشته باشیم و تجزیه و تحلیل اکوسیستم از ارزش مباحث را برای تبلیغ کنندگان فراهم کنیم. آزمایش و انتشار نتایج توسط CMA نظارت خواهد شد ، که داده ها ، تجزیه و تحلیل و روش شناسی را مرور می کند. اکوسیستم تشویق می شود تا بازخورد را با Google و CMA به اشتراک بگذارد.
مباحث و سرگردانی	درخواست اطلاعات بیشتر در مورد نحوه استفاده از موضوعات در منطق مناقصه Fledge	استفاده از موضوعات در منطق مناقصه Fledge امکان پذیر است. یک راهنمای ادغام نیز در حال انجام است و جزئیات بیشتری در مورد اجرای آن را شامل می شود.
رتبه بندی سفارشی برای مباحث تماس گیرنده	اجازه دهید رتبه بندی توسط تماس گیرنده تنظیم شود	چالش با رتبه بندی موضوع سفارشی یا مقادیر برای هر فناوری تبلیغاتی این است که این می تواند به مکانیسمی تبدیل شود که با استفاده از آن یک فناوری تبلیغی می تواند بر موضوعاتی که بازگردانده می شوند ، تأثیر بگذارد ، بنابراین یک بردار اثر انگشت.
مباحث لیست اولویت تماس گیرنده	به تماس گیرندگان اجازه دهید لیستی از اولویت های رتبه بندی شده از موضوعاتی را ارائه دهند که API مباحث بر اساس واجد شرایط بودن باز می گردند.	ما در حال حاضر در مورد این ایده بیشتر بحث می کنیم و از ورودی های اضافی استقبال می کنیم.

گله

موضوع بازخورد	خلاصه	پاسخ کروم
Google Ad Manager	نگرانی از اینکه Google Ad Manager تصمیم گیرنده نهایی برای حراج های Fledge است و به نفع برچسب های ناشر Google و Google Ad Manager است.	Fledge به هر ناشر اجازه می دهد تا ساختار حراج را انتخاب کند ، از جمله انتخاب فروشندگان سطح بالا و مؤلفه. هر خریدار و فروشنده در یک حراج مؤلفه می داند که فروشنده سطح بالا کیست و می تواند انتخاب کند یا خیر.
شرکت کنندگان در آزمایشات کافی نیست	درخواست تشویق شرکتهای بیشتر برای آزمایش Fledge ، به عنوان مثال با بهبود عملکرد API و دلسرد کردن گزینه های حریم خصوصی حریم خصوصی مانند اثر انگشت	ماسهبازی حریم خصوصی با همکاری نزدیک با راهنمایی CMA و ICO در مراحل انجام می شود و آزمایش عملکردی عملکردی ثبات و توانایی لازم را نشان داده است. Google همچنان به تشویق اکوسیستم برای آزمایش API های Sandbox ، که اخیراً مستندات " حداکثر ارتباط تبلیغات " خود را منتشر می کند تا نشان دهد چگونه Fledge و سایر API ها می توانند به پشتیبانی از موارد مهم استفاده برای صنعت تبلیغ پس از استهلاک کوکی شخص ثالث کمک کنند. سایر قسمت های ماسهبازی حریم خصوصی در حال حاضر از کاهش ردیابی پشتیبانی می کنند (به UA-CH ، IP محافظت کنید و ردیابی ردیابی گزاف گویی) و با گذشت زمان به پیشرفت خود ادامه می دهند. هدف Google این نیست که Fledge تنها راه حل هدفمند مناسب باشد ، بلکه در عوض متعهد به همکاری با صنعت و تنظیم کننده ها برای هدایت بهترین فناوری های تبلیغاتی حفظ حریم خصوصی در مرورگر Chrome است.
موارد استفاده از یادگیری ماشین	راهنمایی بیشتر در مورد نحوه استفاده از یادگیری ماشین برای آموزش الگوریتم های مناقصه حراج در گزارش های مربوط به Fledge و Attribution پشتیبانی می شود	ما نیاز به کمک به آزمایش کنندگان را برای یافتن مفیدترین روش های استفاده از فن آوری های Sandbox Privey Pliction می دانیم. ما شروع به انتشار راهنمایی های مربوط به استفاده از جنبه های مختلف API های ماسه ای حریم خصوصی به عنوان ورودی برای یادگیری ماشین کرده ایم. جدیدترین قطعه ، حداکثر ارتباط تبلیغات ، در مورد چگونگی استفاده از صنعت تبلیغات می تواند از این سیگنال ها برای یادگیری ماشین استفاده کند ، و ما قصد داریم تا انتشار چنین راهنمایی هایی را ادامه دهیم.
سرور کلید Fledge مقدار کلید (k/v)	چرا سرور K/V به طور عمومی پرس و جو می شود؟	سرور K/V قصد دارد سیگنال های زمان واقعی را برای حراج های Fledge ارائه دهد. به این ترتیب ، سرور K/V باید از جایی که حراج های Fledge اجرا می شوند ، که در دستگاه های کاربر قرار دارد ، قابل دسترسی باشد و نیاز به دسترسی عمومی دارد. مقدار ذخیره شده در سرور K/V فقط توسط طرفی که از قبل کلید خود را دارد قابل بازیابی است - بنابراین اگر یک فناوری تبلیغی فقط کلیدهای مرورگرهایی را که در گروه مورد علاقه قرار دارند ، می دهد و از کلیدهایی استفاده نمی کند که به طور تصادفی قابل حدس باشد ، سپس فقط مرورگرهایی که برای اجرای حراج خود نیاز به ارزش دارند ، می توانند آن را بازیابی کنند.
چگونه می توان هدف قرار دادن تاریخ/زمان را انجام داد؟	پشتیبانی از اشیاء تاریخ در عملکرد منطق مناقصه.	راه های متعددی برای این کار وجود دارد. خریداران می توانند از فروشنده خود بخواهند تاریخ و زمان فعلی را ارائه دهند و برای فروشندگان آسان است که این اطلاعات را به همه خریداران ارائه دهند. خریداران همچنین می توانند تاریخ و زمان را در پاسخ ارزش کلیدی زمان واقعی خود ارائه دهند. سرانجام ، خریداران می توانند تاریخ و زمان را به عنوان بخشی از پاسخ متنی خود در سیگنال های هر خریدار ارائه دهند ، که یک فروشنده می تواند به اسکریپت تولید کننده خریدار منتقل شود.
تنظیمات برگزیده کاربر	توانایی کاربران برای انتخاب مسدود کردن خلاقان توسط تبلیغ کننده هنگام ارائه خدمات از طریق Fledge یا راه حل های جایگزین.	کاربران این توانایی را دارند که از API های تبلیغاتی در Chrome خودداری کنند. برای تبلیغات خاص ، فناوری تبلیغاتی مربوطه حزبی است که بهترین موقعیت را برای ارائه کنترل هایی که خلاقین نشان داده شده اند یا نحوه انتخاب آنها ارائه شده است.
جدول زمانی واضح تر	درخواست اطلاعات بیشتر در مورد در دسترس بودن حفاظت از حریم خصوصی در Fledge ، مانند نیاز به قاب های حصارکشی.	ما قصد داریم جدول زمانی دقیق تر را در 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.
Measuring conversion lift	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.
تقلب و سوء استفاده	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.

ردیابی پنهان را محدود کنید

User-Agent Reduction

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	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.
تقلب و سوء استفاده	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.

Strengthen cross-site privacy boundaries

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: "GDPR Validated Sets" claims to "align to" GDPR (although it is not really clear what is meant by that). In contrast, Google's commitments require it to take into account "impact on privacy outcomes" more generally. In its decision accepting the commitments the CMA points out that this is distinct from Google's obligation to take into account "compliance with data protection principles as set out in the Applicable Data Protection Legislation," which, as the CMA explains, reflects the fact that Google is bound by the Applicable Data Protection Legislation, both as it applies to the commitments and more generally. We have privacy concerns about the proposal to allow domains to appear in multiple sets. First-Party Sets are intended to support specific use cases that currently depend on third-party cookies without enabling pervasive cross-site tracking. Allowing domains to join multiple sets would remove a key privacy protection built into the First-Party Sets proposal, without introducing any other meaningful limitations. GDPR Validated Sets also proposes to "define a Set as a group of data controllers and processors that share a common use policy." This is similar to the requirement in our original First-Party Sets proposal that all parties in a set must share a common privacy policy. We have since removed that requirement based on strong feedback from the ecosystem raising concerns about privacy policy-based requirements. For example, we heard from site publishers that maintaining a common privacy policy was infeasible because of product and geographical variations, among other challenges raised by members of the W3C community ( 1 , 2 , 3 ). We believe that the same challenges would apply to this proposal. Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets.

Fenced Frames 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.

تراشه ها

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
DSP: Demand-side Platform
FedCM: مدیریت اعتبار فدرال
FPS: First Party Sets
IAB: دفتر تبلیغات تعاملی
بیجاشدگان داخلی: ارائه دهنده هویت
IETF: کارگروه مهندسی اینترنت
IP: Internet Protocol address
openRTB: مناقصه در زمان واقعی
OT: آزمایش مبدا
PatCG: Private Advertising Technology Community Group
RP: حزب اتکا
SSP: Supply-side Platform
TEE: محیط اجرای مورد اعتماد
UA: User Agent string
UA-CH: User-Agent Client Hints
W3C: کنسرسیوم وب جهانی
WIPB: 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.
Core Web Vitals	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
Google Ad Manager	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.
Measuring conversion lift	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.
تقلب و سوء استفاده	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.

ردیابی پنهان را محدود کنید

User-Agent Reduction

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	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.
تقلب و سوء استفاده	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.

Strengthen cross-site privacy boundaries

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: "GDPR Validated Sets" claims to "align to" GDPR (although it is not really clear what is meant by that). In contrast, Google's commitments require it to take into account "impact on privacy outcomes" more generally. In its decision accepting the commitments the CMA points out that this is distinct from Google's obligation to take into account "compliance with data protection principles as set out in the Applicable Data Protection Legislation," which, as the CMA explains, reflects the fact that Google is bound by the Applicable Data Protection Legislation, both as it applies to the commitments and more generally. We have privacy concerns about the proposal to allow domains to appear in multiple sets. First-Party Sets are intended to support specific use cases that currently depend on third-party cookies without enabling pervasive cross-site tracking. Allowing domains to join multiple sets would remove a key privacy protection built into the First-Party Sets proposal, without introducing any other meaningful limitations. GDPR Validated Sets also proposes to "define a Set as a group of data controllers and processors that share a common use policy." This is similar to the requirement in our original First-Party Sets proposal that all parties in a set must share a common privacy policy. We have since removed that requirement based on strong feedback from the ecosystem raising concerns about privacy policy-based requirements. For example, we heard from site publishers that maintaining a common privacy policy was infeasible because of product and geographical variations, among other challenges raised by members of the W3C community ( 1 , 2 , 3 ). We believe that the same challenges would apply to this proposal. Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets.

Fenced Frames 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.

تراشه ها

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.

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
DSP: Demand-side Platform
FedCM: مدیریت اعتبار فدرال
FPS: First Party Sets
IAB: دفتر تبلیغات تعاملی
بیجاشدگان داخلی: ارائه دهنده هویت
IETF: کارگروه مهندسی اینترنت
IP: Internet Protocol address
openRTB: مناقصه در زمان واقعی
OT: آزمایش مبدا
PatCG: Private Advertising Technology Community Group
RP: حزب اتکا
SSP: Supply-side Platform
TEE: محیط اجرای مورد اعتماد
UA: User Agent string
UA-CH: User-Agent Client Hints
W3C: کنسرسیوم وب جهانی
WIPB: 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.
Core Web Vitals	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
Google Ad Manager	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.
Measuring conversion lift	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.
تقلب و سوء استفاده	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.

ردیابی پنهان را محدود کنید

User-Agent Reduction

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	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.
تقلب و سوء استفاده	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.

Strengthen cross-site privacy boundaries

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: "GDPR Validated Sets" claims to "align to" GDPR (although it is not really clear what is meant by that). In contrast, Google's commitments require it to take into account "impact on privacy outcomes" more generally. In its decision accepting the commitments the CMA points out that this is distinct from Google's obligation to take into account "compliance with data protection principles as set out in the Applicable Data Protection Legislation," which, as the CMA explains, reflects the fact that Google is bound by the Applicable Data Protection Legislation, both as it applies to the commitments and more generally. We have privacy concerns about the proposal to allow domains to appear in multiple sets. First-Party Sets are intended to support specific use cases that currently depend on third-party cookies without enabling pervasive cross-site tracking. Allowing domains to join multiple sets would remove a key privacy protection built into the First-Party Sets proposal, without introducing any other meaningful limitations. GDPR Validated Sets also proposes to "define a Set as a group of data controllers and processors that share a common use policy." This is similar to the requirement in our original First-Party Sets proposal that all parties in a set must share a common privacy policy. We have since removed that requirement based on strong feedback from the ecosystem raising concerns about privacy policy-based requirements. For example, we heard from site publishers that maintaining a common privacy policy was infeasible because of product and geographical variations, among other challenges raised by members of the W3C community ( 1 , 2 , 3 ). We believe that the same challenges would apply to this proposal. Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets.

Fenced Frames 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.

تراشه ها

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.

گزارش بازخورد - 2022 Q4 bookmark_borderbookmark با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

واژه نامه کلمات اختصاری

بازخورد عمومی، بدون API/فناوری خاصی

نمایش محتوا و تبلیغات مرتبط

موضوعات

FLEDGE

اندازه گیری تبلیغات دیجیتال

گزارش انتساب (و سایر APIها)

ردیابی پنهان را محدود کنید

کاهش عامل کاربر

نکات مشتری عامل کاربر

حفاظت IP (Gnatcatcher سابق)

بودجه حریم خصوصی

مرزهای حفظ حریم خصوصی سایت را تقویت کنید

ست های شخص اول

Fenced Frames API

API ذخیره سازی مشترک

تراشه ها

فدستان

با هرزنامه و کلاهبرداری مبارزه کنید

API Token State Private

واژه نامه مخفف

بازخورد عمومی ، هیچ API/فناوری خاص

نمایش محتوای و تبلیغات مربوطه

موضوعات

گله

Measuring Digital Ads

Attribution Reporting (and other APIs)

ردیابی پنهان را محدود کنید

User-Agent Reduction

User-Agent Client Hints

IP Protection (formerly Gnatcatcher)

بودجه حریم خصوصی

Strengthen cross-site privacy boundaries

First-Party Sets

Fenced Frames API

API ذخیره سازی مشترک

تراشه ها

FedCM

Fight spam and fraud

Private State Token API

Glossary of acronyms

General feedback, no specific API/Technology

Show Relevant Content & Ads

موضوعات

FLEDGE

Measuring Digital Ads

Attribution Reporting (and other APIs)

ردیابی پنهان را محدود کنید

User-Agent Reduction

User-Agent Client Hints

IP Protection (formerly Gnatcatcher)

بودجه حریم خصوصی

Strengthen cross-site privacy boundaries

First-Party Sets

Fenced Frames API

API ذخیره سازی مشترک

تراشه ها

FedCM

Fight spam and fraud

Private State Token API

Glossary of acronyms

General feedback, no specific API/Technology

Show Relevant Content & Ads

موضوعات

FLEDGE

Measuring Digital Ads

Attribution Reporting (and other APIs)

ردیابی پنهان را محدود کنید

User-Agent Reduction

User-Agent Client Hints

IP Protection (formerly Gnatcatcher)

بودجه حریم خصوصی

Strengthen cross-site privacy boundaries

First-Party Sets

Fenced Frames API

API ذخیره سازی مشترک

تراشه ها

FedCM

Fight spam and fraud

گزارش بازخورد - 2022 Q4
bookmark_border با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.