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

گزارش بازخورد - 2023 Q3

گزارش فصلی برای سه ماهه سوم سال 2023، خلاصه بازخورد اکوسیستم دریافت شده در مورد پیشنهادات جعبه ایمنی حریم خصوصی و پاسخ 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 به بازخورد از پرسش‌های متداول منتشر شده، پاسخ‌های واقعی به مسائل مطرح‌شده توسط ذینفعان و تعیین موقعیت به‌ویژه برای اهداف این گزارش گزارش عمومی ایجاد شده است. با توجه به تمرکز فعلی توسعه و آزمایش، سؤالات و بازخوردها به ویژه در رابطه با موضوعات، مخاطبین محافظت شده و APIهای گزارش اسناد دریافت شد.

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

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

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

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

موضوع بازخورد	خلاصه	پاسخ کروم
آمادگی اکوسیستم	SSP ها نگرانی از آماده نبودن ناشران و انجام ندادن کار استقرار مورد نیاز را برجسته کردند.	Privacy Sandbox به طور خاص بر آموزش ناشران متمرکز شده است، که شامل وبینارها و جلسات اختصاصی با ناشران و SSPهای حاضر برای پیشبرد کار استقرار است.
منسوخ شدن کوکی های شخص ثالث	نگرانی ها در مورد از بین رفتن کوکی های شخص ثالث (3PCD) در سه ماهه چهارم 2023 به دلیل خاموشی فناوری صنعت افزایش یافت.	جدول زمانی برای Sandbox حریم خصوصی با CMA مورد بحث قرار گرفته است و توالی به نیمه دوم سال 2024 آماده می شود. Privacy Sandbox اطلاعات دقیق تری در مورد توالی افزایش 3PCD منتشر خواهد کرد. بر اساس تعهدات، 3PCD منوط به رسیدگی به نگرانی های رقابتی CMA است.
Google Ad Manager	Google Ad Manager از افشای سطح API که آزمایش را دشوار می کند خودداری می کند.	پاسخ ارائه شده توسط Google Ad Manager: به دلایلی که در این پاسخ توسط Google Ad Manager توضیح داده شده است، برنامه‌های Google Ad Manager برای یکپارچه‌سازی API مخاطبان محافظت شده آن شامل پشتیبانی از سرور تبلیغات ناشر Google بدون کنترل حراج سطح بالا نمی‌شود.
Google Ad Manager	Google Ad Manager یک قیمت طبقه مخفی دارد که فقط در معرض AdX یا Open Bidding SSPs قرار دارد.	اسناد عمومی Google Ad Manager می‌گوید که برنده حراج متنی به منطق امتیازدهی سطح بالا منتقل می‌شود و نه به حراجی جزء، از جمله AdX یا Open Bidding. علاوه بر این، این مستندات در مورد منطق امتیازدهی سطح بالا می‌گوید: «Ad Manager پیشنهاد برنده هر حراج مؤلفه، از جمله حراج مؤلفه خود Ad Manager را برای پیشنهادهای گروهی علاقه‌مند خریدارانش، و همچنین بهترین آگهی متنی (که عبارت است از از طریق تخصیص پویا انتخاب شده است)، و آگهی را با بالاترین پیشنهاد ارائه می دهد."
Google Ad Manager	محصولات Google Ads باید مشمول قوانین مشابه محصولات تبلیغاتی شخص ثالث باشند.	محصولات Google Ads در حال حاضر تحت قوانینی مشابه اشخاص ثالث قرار دارند.
آزمایش با استفاده از کروم	برای مرورگرهایی که در A یا B نیستند برچسب اضافه کنید.	ما در حال حاضر به انجام این کار فکر نمی کنیم، زیرا تحقیقات ما نشان داده است که افزودن برچسب های غیر آزمایشی ممکن است نگرانی های مربوط به حریم خصوصی در مورد ترافیک در حالت ناشناس را پیچیده کند.
آژانس تبلیغاتی	آیا آژانس‌ها یا شرکت‌های بدون جاوا اسکریپت در وب‌سایت‌ها می‌توانند از Privacy Sandbox API استفاده کنند؟	هر کسی می‌تواند با APIهای Privacy Sandbox تماس بگیرد. اگر یک آژانس یا هر شخص دیگری بخواهد فناوری‌هایی را مستقیماً روی APIها ایجاد کند، می‌تواند. APIهای سمت کلاینت به ادغام با مشتری نیاز دارند، درست مانند کوکی ها. بسیاری از APIها، مانند کوکی ها، دارای یک رابط هدر HTTP نیز هستند. ما قبلاً یک چارچوب صنعت تبلیغات، Prebid را دیده‌ایم که ادغام سمت مشتری با APIها ایجاد می‌کند. سازمان های دیگر نیز می توانند همین کار را انجام دهند.
راه حل های سمت مشتری	چرا Google راه‌حل‌های سمت مشتری را برای Privacy Sandbox اتخاذ می‌کند در حالی که یک مهندس قبلاً در سال 2012 نسبت به مقیاس‌پذیری چنین راه‌حل‌هایی ابراز نگرانی کرده بود؟	فناوری افزایش حریم خصوصی (PET) به عنوان یک رشته تحصیلی از سال 2012 به طور قابل توجهی تکامل یافته است و همراه با آن، برنامه های کاربردی تجاری قابل دوام است. در هسته Sandbox حریم خصوصی ترکیبی از PET وجود دارد که بیش از یک دهه پیش امکان پذیر نبود. علاوه بر این، قدرت محاسبات شخصی افزایش یافته است، همانطور که انتظارات مصرف کنندگان از مرورگرها و انتظارات نظارتی از حریم خصوصی افزایش یافته است.
فراگیری ماشین	استفاده برنامه ریزی شده Google از جعبه ایمنی حریم خصوصی برای اهداف یادگیری ماشینی چیست؟	امروزه بیشتر اکوسیستم فناوری تبلیغات از یادگیری ماشینی استفاده می کند و ما انتظار نداریم که تغییر کند. جعبه ایمنی حریم خصوصی مانع از ادامه استفاده شرکت‌های فناوری تبلیغات یا هر شخص دیگری از یادگیری ماشینی نمی‌شود. همچنین Privacy Sandbox ایجاب نمی کند که شرکت هایی که با API های آن ادغام می شوند از یادگیری ماشینی استفاده کنند. منطقی است انتظار داشته باشیم که شرکت ها به ساخت محصولات و خدمات به روشی ادامه دهند که نیازهای مشتریان خود را برآورده کند، خواه این شامل یادگیری ماشین باشد یا خیر. هر گونه یادگیری ماشینی که ادغام‌کننده‌های Privacy Sandbox ایجاد می‌کنند، بدیهی است که برای آن‌ها شناخته شده است و بنابراین برای آنها پنهان نمی‌ماند.
تایید داده ها	چگونه شرکت‌ها می‌توانند تأیید کنند که داده‌هایی که از استفاده از جعبه ایمنی حریم خصوصی دریافت می‌کنند دقیق است و آیا Google مایل است از طریق نهادی مانند شورای رتبه‌بندی رسانه (MRC) بررسی شود؟	APIهای Sandbox Privacy در پلتفرم منبع باز ساخته شده‌اند که Chrome را تقویت می‌کند. بخش‌هایی از APIهایی که قرار است در محیط‌های اجرایی مورد اعتماد اجرا شوند نیز منبع باز و قابل ممیزی هستند. هر کسی که بخواهد کد را بازرسی کند می تواند، از جمله MRC.
(همچنین در سه ماهه قبلی گزارش شده است) پشتیبانی تولید	فرآیند Chrome برای پشتیبانی از مشکلات فنی و تشدیدهایی که اکوسیستم را تحت تأثیر قرار می‌دهند Privacy Sandbox چیست؟	Google مجموعه‌ای از کانال‌ها را فراهم می‌کند تا به فن‌آوران تبلیغات اجازه دهد مشکلات فنی را گزارش کنند و هرگونه تشدید لازم را برای حل چنین مشکلاتی فعال کنند. علاوه بر این، کروم انتظار دارد فرآیندی را برای حل مشکلات فنی و تشدیدهایی که بر سلامت اکوسیستم تأثیر می‌گذارند، بسازد و مقیاس‌بندی کند. Chrome متعهد است که منابع لازم برای این تلاش را تضمین کند. لطفاً برای اطلاعات بیشتر در مورد تالارهای گفتمان عمومی و خصوصی برای بازخورد و تشدید، پست توسعه دهنده ما را ببینید.
حالت‌های آزمایش با تسهیل کروم	اطلاعات بیشتر در مورد جدول زمانی و اجرای دقیق حالت‌های آزمایشی با تسهیل Chrome.	ما یک پست وبلاگ در مورد حالت های آزمایشی به اشتراک گذاشته ایم و در تلاش هستیم تا اطلاعات بیشتری را به زودی به اشتراک بگذاریم. ما از پیشنهادهایی برای اندازه برچسب های حالت تست استقبال می کنیم.
ادغام با سایر استانداردهای صنعتی	آیا APIهای Privacy Sandbox به یکی یا هر دو نسخه TCF v2.* و Consent Mode متصل خواهند شد؟	ما برنامه‌ای برای ادغام APIهای Privacy Sandbox به طور مستقیم با TCF v2 یا Consent Mode نداریم. با این حال، شرکت‌ها و گروه‌های تجاری صنعتی می‌توانند محصولات و چارچوب‌های خود را برای کار در ارتباط با APIهای Privacy Sandbox تطبیق دهند. به عنوان مثال، با چارچوب هایی مانند TCF، هر شرکت کننده باید رویکرد انطباق خود را بر اساس سیگنال TCF که دریافت می کند و خط مشی های TCF مرتبط تعیین کند. ما از شرکت‌ها انتظار داریم زمان و نحوه استفاده از عملکردهای مختلف بلوک‌های ساختمانی جعبه ایمنی حریم خصوصی را تعیین کنند.

ثبت نام و تاییدیه

موضوع بازخورد	خلاصه	پاسخ کروم
محدودیت	فرآیند ثبت‌نام به این معناست که Google می‌تواند تصمیم بگیرد که کدام شرکت در اکوسیستم مجاز به استفاده از APIهای Privacy Sandbox است.	فرآیند ثبت نام و تأیید اساساً مستلزم تأیید نهاد است (به عنوان مثال، نهاد دارای شماره DUNs است، می تواند پیوندی به خط مشی حفظ حریم خصوصی ارائه دهد، و غیره) و تأیید عمومی را برای فراخوانی APIها الزامی می کند. نهادهایی که می توانند با موفقیت شرایط ثبت نام را برآورده کنند، اعتبارسنجی خواهند شد. برای شرکت‌هایی که DUN ندارند، ما یک فرآیند تسریع‌شده و رایگان را با Dun & Bradstreet برای به دست آوردن آن ارائه می‌کنیم. هدف افزایش حفاظت از حریم خصوصی APIها (با اقداماتی که قبلا ذکر شد) و همچنین افزودن یک لایه شفافیت به APIهای Privacy Sandbox است، بنابراین افراد علاقه مند بتوانند بهتر بفهمند چه کسی از کدام API استفاده می کند و چه گواهی هایی را ارائه می کند. ما آماده بازخورد بیشتر صنعت در مورد این موضوع هستیم، که قبلاً برای شکل دادن به فرآیند استفاده شده است.
سربار ثبت نام مجدد	پرونده گواهینامه هر 12 ماه یکبار منقضی می شود و وب سایت ها را ملزم به ثبت نام مجدد می کند.	ما بازخوردهای اکوسیستم را شنیده ایم و رویکرد خود را بر این اساس اصلاح کرده ایم. این بدان معناست که فایل‌ها پس از 12 ماه یا هر دوره زمانی مشخصی منقضی نمی‌شوند. ما در حال به روز رسانی راهنمای برنامه نویس ثبت نام خود با زمینه های اضافی هستیم.
فایل تصدیق	چگونه از فایل تصدیق استفاده می شود؟	همه شرکت‌هایی که APIهای مرتبط و اندازه‌گیری را فراخوانی می‌کنند، در مهلت اجرایی ملزم خواهند بود تا فایل گواهی را در سایت خود آپلود کنند و تا زمانی که شما قصد دارید به فراخوانی APIها ادامه دهید، آن را برای عموم نگه دارند. وب‌سایت‌ها می‌توانند تقریباً یک درخواست در ساعت از Privacy Sandbox انتظار داشته باشند و سایر نهادهای بالقوه نیز ممکن است درخواست کنند. این کار از طریق مکانیسم خود سیستم ثبت نام برای پرس و جو از سرورهای نهادهای ثبت شده و اطمینان از معتبر بودن فایل گواهی انجام می شود. گواهینامه ها در گزارش های شفافیت گنجانده شده و برای عموم قابل مشاهده خواهد بود. ما از شرکت ها انتظار داریم که مطابق با گواهینامه های اعلام شده خود عمل کنند، همانطور که سایر اکوسیستم ها و نهادهای نظارتی مربوطه این کار را انجام می دهند.
ثبت نام	ثبت نام در هر سایت است یا هر مبدا؟	ثبت نام در سطح سایت می باشد.

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

موضوعات

موضوع بازخورد	خلاصه	پاسخ کروم
کارایی	نگرانی‌های عملکرد در مورد تأثیر نرخ انتخاب موضوعات در منطقه اقتصادی اروپا.	ما به ذینفعان مربوطه پیشنهاد می کنیم که در مورد این موضوع با مرجع حفاظت از داده های مربوطه خود تماس بگیرند. آنها بهترین موقعیت را برای رسیدگی به چنین نگرانی‌هایی دارند و تأثیر می‌گذارند که آیا برنامه‌های فن‌آوری‌های تقویت‌کننده حریم خصوصی توسط قوانین تشویق می‌شوند یا در عوض مانند ردیابی رفتار می‌شوند که نیازمند رویکردهای مشابه برای رضایت است. مورد دوم ممکن است باعث شود APIهایی مانند آنهایی که در Privacy Sandbox وجود دارد، اغلب در دسترس نباشند.
ثبت نام	آیا پیشنهاد دهندگان پایین دستی برای استفاده از سیگنال های Topics از SSP های بالادستی باید در Topics API ثبت نام کنند؟	گیرنده های پایین دستی موضوعاتی فراتر از تماس گیرنده اولیه Topics API نیازی به ثبت نام ندارند، اگرچه بسیاری از آنها احتمالاً برای استفاده های دیگر API ثبت نام می کنند. فهرستی از ثبت‌نام‌شدگان Privacy Sandbox به‌عنوان بخشی از تلاش‌های شفاف‌سازی برنامه، به‌صورت برنامه‌ریزی ارائه می‌شود، که به تماس‌گیرنده علاقه‌مند به Topics API اجازه می‌دهد بررسی کند که آیا گیرنده‌ای که موضوعی را برایش ارسال می‌کند، ثبت نام کرده است یا خیر.
فیلتر کردن موضوعات	درخواست اعمال فیلتر تماس گیرنده دیگر برای موضوعاتی که آنها در صفحه بازیابی می کنند، به منظور به اشتراک گذاشتن تنها مواردی که خریداران واجد شرایط بازیابی هستند.	ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.
حذف سایت	وب سایت ها را از مشارکت در موضوعات کاربر مستثنی کنید.	موضوعات به طور پیش فرض فراخوانی نمی شوند. توجه به این نکته مهم است که هنگام انتخاب موضوعات هیچ محتوای صفحه در نظر گرفته نمی شود و همه موضوعات برای اطمینان از حساس نبودن آنها تنظیم شده است. یک وب سایت همچنین می تواند سایت خود را از لحاظ کردن موضوع در محاسبه موضوع از طریق سربرگ خط مشی مجوز زیر محدود کند: `Permissions-Policy: browsing-topics=()`
مشاهده موضوعات	به ناشران اجازه دهید تا به Chrome اجازه دهند تا موضوعات را بر اساس محتوای صفحه (مثلاً سر یا بدن) طبقه بندی کند.	ما قبلاً ارائه عملکردی برای طبقه‌بندی سایت‌ها به موضوعات بر اساس محتوای صفحه در نظر گرفتیم و تصمیم گرفتیم بر اساس نگرانی‌های مربوط به حفظ حریم خصوصی و امنیتی به جلو حرکت نکنیم. این پیشنهاد ممکن است برخی از این نگرانی ها را کاهش دهد، اما مشخص نیست که تا چه حد. با توجه به دوره آزمایشی CMA آتی، انتظار نداریم این تغییر قبل از 3PCD رخ دهد. ما از بازخورد اضافی در اینجا استقبال می کنیم .
مشاهده موضوعات	خط‌مشی‌های مجوز دقیق‌تری برای ناشران ارائه دهید.	ارائه خط‌مشی‌های مجوز دقیق‌تر برای ناشران، سایت‌های ناشر را قادر می‌سازد تا بر کاربرد Topics API برای کل اکوسیستم تأثیر منفی بگذارند، بدون اینکه تأثیر منفی بر کاربرد Topics API برای خود سایت بگذارد. برای پشتیبانی از مجوزهای جداگانه برای بازیابی و مشاهده مشکل GitHub برای بحث دقیق تر در مورد موضوع، به خط مشی مجوزهای به روز رسانی مراجعه کنید.
موضوعات پزشکی و بهداشتی	چرا طبقه بندی موضوعات موضوعاتی را در دسته بندی های پزشکی یا بهداشت پوشش نمی دهد؟	مقوله های پزشکی و بهداشتی موضوعات حساسی در نظر گرفته می شوند و بنابراین از طبقه بندی موضوعات حذف می شوند.
بازیابی موضوعات	روشی سریعتر برای DSPها برای دریافت موضوعات بدون واکشی با استفاده از سرصفحه.	متدهای هدر نسبت به ایجاد یک iframe متقاطع و برقراری فراخوانی `document.browsingTopics()` از آن کارایی بیشتری دارند و هزینه کمتری دارند. (یک iframe متقاطع باید برای تماس استفاده شود، زیرا زمینه سطح بالا برای مشاهده یک موضوع باید با زمینه ای که از آن به موضوعات دسترسی پیدا می شود مطابقت داشته باشد.) این در اینجا به تفصیل مورد بحث قرار گرفت.
بازیابی موضوعات	درخواست‌هایی برای پشتیبانی از ارسال موضوعات از طریق هدر در درخواست‌های برچسب اسکریپت متقابل.	از منظر امنیتی، این امکان پذیر نیست. هر سند و محیط اجرای آن با یک مبدأ واحد مرتبط است - منبع سند. منابع فرعی شخص ثالث بارگیری و اجرا شده در همان محیط، متعلق به مبدأ سند در نظر گرفته می شود. این برای جلوگیری از نشت داده های بدون رضایت از یک منبع به منبع دیگر است. یک جایگزین، ارائه ویژگی `browsingTopics` در تگ‌های `<script>` است. این باید از منظر امنیتی تمیز باشد و تاخیر اضافی اضافه نکند. ما آماده بازخورد از طرف های علاقه مند هستیم.
اطلاع	آگاهی عمومی از Topics API و نحوه استفاده از API را بهبود بخشید.	ما با ذینفعی که این بازخورد را ارائه کرده بود درگیر شدیم و این مشکل در GitHub حل شد. در آینده، ما به حمایت از درک اکوسیستم از API ادامه خواهیم داد و مشتاقانه منتظر شنیدن نظرات ذینفعان هستیم. در عین حال، به سهامدارانی که می‌خواهند درباره موضوعات API بیشتر بدانند، پیشنهاد می‌کنیم که با مستندات راهنمای برنامه‌نویس Chrome آشنا شوند.
اطلاع	اعلان برای هشدار به کاربر هنگامی که موضوعات آنها توسط یک وب سایت مشاهده می شود.	ما به این بازخورد در GitHub پرداختیم . کاربران می‌توانند درباره کنترل‌های موضوعات در مرکز راهنمای Chrome اطلاعات بیشتری کسب کنند.
فراگیری ماشین	چگونه می توان از ML برای استنباط موضوعات کاربر استفاده کرد؟	ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی استقبال می کنیم .
سودمندی برای انواع مختلف ذینفعان	شرکت‌های فناوری تبلیغاتی کوچک‌تر ممکن است نتوانند موضوعات را به دلیل نحوه محاسبه مرورگرها مشاهده کنند.	فقط فناوری های تبلیغاتی که مشاهده کرده اند کاربر از صفحه ای در مورد موضوع مورد نظر در سه هفته گذشته بازدید کرده است، موضوعی را دریافت می کنند. اگر فناوری تبلیغات در سه هفته گذشته برای آن کاربر در سایتی در مورد آن موضوع، API را فراخوانی نکرده باشد، مقدار برگشتی خالی خواهد بود. این ویژگی به این معنی است که فناوری‌های تبلیغاتی که خدمات آن‌ها توسط تعداد بیشتری از صاحبان سایت استفاده می‌شود و بنابراین فرصت‌های بیشتری برای مشاهده بازدید از سایت توسط یک کاربر خاص دارند، ممکن است موضوعات بیشتری نسبت به سایر فناوری‌های تبلیغاتی دریافت کنند. این ویژگی برای حفاظت از حریم خصوصی API ضروری است زیرا در دسترس بودن اطلاعات مربوط به یک کاربر را فقط به طرف هایی محدود می کند که قبلاً می توانند همان اطلاعات اساسی را مشاهده کنند (در حال حاضر از طریق کوکی های شخص ثالث).
درخواست XHR	چه زمانی گنجاندن موضوعات در درخواست‌های `XMLHttpRequest` (XHR) منسوخ می‌شود؟	همانطور که کروم در آگوست 2023 اعلام کرد ، کروم هنگام انتقال از Origin Trial به General Availability، پشتیبانی از XHR را منسوخ کرد. با پیشرفت افزایش موضوعات، پشتیبانی XHR فقط برای کاربرانی که ویژگی‌های OT برایشان فعال شده بود، در نظر گرفته شد و با ادغام گروه‌های آزمایشی OT به طور کامل منسوخ شد. اگر از Topics با XHR استفاده می کردید، سایت های شما خراب نمی شوند. موضوعات به عنوان درخواست XHR شما اضافه نمی شوند. توصیه می‌کنیم یا به `fetch` برای درخواست خود انتقال دهید، از ویژگی iframe استفاده کنید یا از JavaScript API برای بازیابی موضوعات استفاده کنید. Fetch توسط همه مرورگرهای مدرن پشتیبانی می شود، اما اینترنت اکسپلورر یا اپرا مینی پشتیبانی نمی شود.
فرآیند به روز رسانی طبقه بندی و طبقه بندی	اطلاعات بیشتر در مورد تاکسونومی موضوعات و سرعت انتشار طبقه‌بندی‌کننده و نحوه آماده شدن شرکت‌ها برای چنین به‌روزرسانی‌هایی.	پاسخ ما نسبت به Q2 بدون تغییر باقی می ماند: همانطور که در پست وبلاگ اخیر به اشتراک گذاشته شده است، ما انتظار داریم که طبقه بندی در طول زمان تکامل یابد، و حکومت طبقه بندی در نهایت به یک حزب خارجی که نماینده سهامداران از سراسر صنعت است تبدیل شود. ما همچنین طرح رمپ آپ را در گروه اعلام موضوعات به اشتراک گذاشتیم.
سو استفاده کردن	حمله بالقوه از طریق زنجیره تغییر مسیر.	ما در حال بررسی این موضوع هستیم و از بازخورد اضافی استقبال می کنیم.
انواع موجودی ناشر	آزمایش مخاطبین و موضوعات محافظت شده از چه نوع موجودی ناشر پشتیبانی می کند؟	نه مخاطب محافظت شده و نه موضوعات ذاتاً از نظر انواع موجودی که می‌توانند در آن استفاده شوند محدودکننده نیستند.
زمان افزایش سرعت	برای رسیدن به 100% طبقه بندی های جدید، زمان افزایش را توصیه نکنید.	به دنبال این درخواست بازخورد از اکوسیستم و بحث در طول جلسات PATCG، ما برنامه خود را برای عرضه طبقه بندی جدید اعلام کرده ایم.

API مخاطب محافظت شده (FLEDGE سابق)

موضوع بازخورد	خلاصه	پاسخ کروم
مزایده های سطح بالا	امکان استفاده از سرور تبلیغات ناشر Google بدون اینکه به Google Ad Manager کنترل حراج سطح بالای Protected Audience API را بدهد.	پاسخ ارائه شده توسط Google Ad Manager: برنامه‌های Google Ad Manager برای API مخاطبان محافظت‌شده شامل پشتیبانی از سرور تبلیغات ناشر Google بدون کنترل حراج مخاطب محافظت‌شده سطح بالا، به دلایل زیر نیست. برای ارائه خدمات مناسب به مشتریان خود در بازار ارائه تبلیغات ناشر، سرور تبلیغات ناشر Google باید کنترل حراج مخاطب محافظت شده سطح بالا را حفظ کند. به عنوان یک سرور تبلیغات ناشر، نقش ما این است که پیش‌بینی ناشران را ارائه دهیم تا بتوانند در مورد کمپین‌های فروش مستقیم بدون رزرو بیش از حد مذاکره کنند و رزروهای مستقیم خود را به‌طور بهینه انجام دهند. انجام این کار مستلزم اجرای حراج نهایی برای مقایسه تمام تقاضاهای واجد شرایط مستقیم و غیرمستقیم است. پیش بینی و سرعت عملکردهای اصلی هستند که ناشران از یک سرور تبلیغات انتظار دارند. بدون پیش بینی دقیق، ناشران ممکن است در نهایت موجودی خود را بیش از حد بفروشند، که شهرت تجاری آنها را به خطر می اندازد. سرعت‌گیری نیز بسیار مهم است، زیرا ناتوانی در انجام قراردادهای رزرو با تبلیغ‌کنندگان نیز به رابطه مستقیم ناشر-آگهی‌دهنده آسیب وارد می‌کند، که می‌تواند تأثیر قابل‌توجهی بر تجارت ناشران داشته باشد. بنابراین، به طور خلاصه، فعالیت سرور تبلیغات ناشر در اجرای حراج مخاطب محافظت شده سطح بالا را متمایز از سایر فعالیت های سرور تبلیغات ناشر نمی دانیم.
`directFrom SellerSignals`	`directFrom SellerSignals` به Google Ad Manager اجازه می دهد تا ناشر را از دیدن قیمت حراج متنی خود جلوگیری کند.	پاسخ کروم: اطلاعات ارسال شده به `runAdAuction()` معلوم نیست که از فروشنده می آید مگر اینکه فروشنده `runAdAuction()` را از iframe خودش فراخوانی کند. در یک حراج چند فروشنده، غیر ممکن است که همه فروشندگان فریمی را ایجاد کنند که `runAdAuction()` را فراخوانی می کند. `directFromSellerSignals` با بارگیری محتوا از یک بسته منبع فرعی که از مبدا فروشنده بارگیری شده بود به این مشکل پرداخت. این تضمین می کند که صحت و یکپارچگی اطلاعات ارسال شده به حراجی از پیکربندی های فروشنده-حراج قابل دستکاری نیست. اگر ناشران بخواهند از API مخاطبان محافظت‌شده برای درک هر یک از اطلاعاتی که ارائه‌دهندگان فناوری آن‌ها به حراج‌های مخاطب محافظت‌شده منتقل می‌کنند استفاده کنند، می‌توانند این قابلیت را از آن ارائه‌دهندگان فناوری بخواهند. پاسخ ارائه شده توسط Google Ad Manager: ما سال‌ها تمرکز زیادی بر عادلانه بودن حراج داشته‌ایم، از جمله قول داده‌ایم که هیچ قیمتی از منابع تبلیغاتی تضمین‌نشده ناشر، از جمله قیمت کالاهای خطی غیرتضمین‌شده، با خریدار دیگری قبل از پیشنهاد در حراج به اشتراک گذاشته نخواهد شد. که ما بعداً در تعهدات خود به سازمان رقابت فرانسه مجدداً تأیید کردیم. برای حراج‌های مخاطب محافظت‌شده، ما قصد داریم با استفاده از `directFromSellerSignals` به قول خود عمل کنیم و قبل از تکمیل حراج در حراج‌های چند فروشنده، پیشنهاد هیچ شرکت‌کننده حراج را با هیچ شرکت‌کننده دیگری در حراج به اشتراک نگذاریم. برای روشن بودن، همانطور که در به‌روزرسانی دینامیک حراج سطح بالا توضیح داده شد، قیمت حراج متنی را با حراج اجزای خودمان نیز به اشتراک نمی‌گذاریم.
قرار گرفتن در معرض اطلاعات	منطق تجاری حساس و جزئیات قرارداد ممکن است توسط مرورگر افشا شود.	شخصی که از یک مرورگر وب استفاده می کند می تواند همه چیزهایی که در مرورگر اتفاق می افتد را ببیند. وقتی یک مزایده تبلیغاتی در داخل مرورگر اتفاق می‌افتد، این درست است که شخصی که مرورگرش است می‌تواند برگزاری آن حراج را تماشا کند، از جمله اینکه ببیند طرف‌های مختلف چقدر برای پیشنهاد پیشنهاد می‌کنند. از آنجایی که یک مرورگر نماینده کاربر است، فکر نمی‌کنیم که امکان یا مطلوبی برای تغییر آن وجود داشته باشد. با این حال، فقط شخصی که از مرورگر استفاده می کند، امکان مشاهده این عملیات را دارد. حراج روی دستگاهی که با استفاده از Protected Audience API اجرا می‌شود، برای هیچ سروری از جمله سرور Google قابل مشاهده نیست.
`PerBuyerExperiment GroupId`	محدوده ارزش فعلی از `PerBuyerExperiment GroupId` می تواند به خریداران اجازه دهد که داده های متنی را با درخواست سرور مورد اعتماد مرتبط کنند.	استفاده از API مخاطب محافظت شده به این روش با تأیید اجباری Privacy Sandbox که کاربران API سعی در دور زدن محافظت‌های Privacy Sandbox ندارند، مطابقت ندارد. در آینده، این الزام که سرورهای کلید-مقدار در محیط‌های اجرایی قابل اعتماد (TEE) اجرا شوند، حفاظت فنی در برابر این حمله را فراهم می‌کند.
خط مشی همان مبدا	برای اجازه دادن به زیر دامنه‌ها، سیاست همان مبدأ را کاهش دهید.	ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.
نسخه API	درخواست نسخه‌سازی و انتشار یادداشت‌ها برای تغییرات در Protected Audience API.	ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.
مزایده های چند SSP	به سیگنال‌های حراج سطح بالا اجازه دهید ادغام‌های JSON را با `auctionSignals` سیگنال مؤلفه انجام دهند.	ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.
حد پیشنهاد	محدودیت تعداد مؤلفه‌های تبلیغاتی را که وارد پیشنهاد قیمت می‌شوند از 20 به 40 افزایش دهید.	ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم در مورد اینکه چرا این مفید است استقبال می کنیم.
(در فصل های گذشته نیز گزارش شده است) اجرای حراج مخاطبان حفاظت شده	گزارش از آزمایش‌کنندگان مبنی بر اینکه حراج‌های مخاطب محافظت‌شده تأخیر بالایی دارند.	در مورد سؤالات تأخیر، API مخاطب محافظت شده عموماً از الگوی استاندارد موجود در کنترل‌های ساختمان پیروی می‌کند که به فروشندگان اجازه می‌دهد تصمیم بگیرند که مناقصه‌دهندگان چقدر زمان و منابع می‌توانند مصرف کنند، و ابزارهایی ایجاد می‌کند که به خریداران اجازه می‌دهد تصمیم بگیرند چگونه از منابع در دسترس خود به بهترین شکل استفاده کنند. این کنترل ها و ابزارها به طور کلی امروزه در دسترس هستند، اما سود کامل آنها تنها پس از پذیرش توسط خریداران و فروشندگان محقق می شود. علاوه بر این، Chrome به کار بر روی انواع بهبودهای زیرساختی برای سرعت حراج ( crrev.com/1190815 , crrev.com/1199839 , crrev.com/1201837 , crrev.com/1198339 , crrev.com/1197323 ) ادامه می دهد. ما از هر دو نیمه این تلاش تأخیر بازخورد می‌خواهیم: ابزارهای جدیدی که خریداران و فروشندگان مفید می‌دانند، و گزارش‌هایی از تنگناهای مشاهده‌شده که مهندسان Chrome باید بررسی کنند.
فیلتر سمت خرید	بر اساس گروه‌های علاقه، پشتیبانی از فیلتر سمت خرید را اضافه کنید.	ما چندین روش را پیشنهاد کرده‌ایم که SSPها و DSPها می‌توانند طرح‌های خود را برای مدیریت این موضوع تغییر دهند: انتقال برخی از کارها به سرور کلید/مقدار DSP. SSP ها برخی سیگنال های متنی را ایجاد می کنند و آن ها را به DSP ها می دهند. SSP ها سیگنال های متنی را برای DSP ها ذخیره می کنند.
کنترل گروه علاقه ناشر	پشتیبانی از ناشرانی که به دنبال واگذاری استفاده از گروه‌های علاقه ایجاد شده توسط ناشر هستند.	ما با بسیاری از طرف ها در مورد این درخواست مذاکره کرده ایم. ما بر این باوریم که همه موارد استفاده از این دست که در «تفویض» گروه‌های ذینفع ایجاد شده توسط ناشر دخیل هستند، اکنون قابل پذیرش هستند، و علاوه بر این، باید پشتیبانی بیشتری ایجاد کنیم تا برخی از موارد استفاده در آینده روان‌تر شوند.
(همچنین در Q2 گزارش شده است) محیط های اجرایی مورد اعتماد	پشتیبانی از Trusted Execution Environments (TEE) در محیط های ابری غیر عمومی.	پاسخ ما مشابه فصل های قبل است: در حالی که ما به بررسی پشتیبانی از گزینه‌های فراتر از راه‌حل‌های مبتنی بر ابر عمومی ادامه می‌دهیم، هیچ برنامه‌ای برای پشتیبانی از TEE‌های داخلی نداریم. در این مرحله، با توجه به الزامات امنیتی Privacy Sandbox و چالش‌های قابل توجهی که توسط استقرارهای داخلی ارائه می‌شود، ما معتقدیم که ادامه گسترش و بهبود استقرار مبتنی بر ابر (به عنوان مثال، پشتیبانی از Google Cloud علاوه بر AWS) بیشترین سود را برای زیست بوم. با این حال، ما از بازخورد اضافی در مورد اینکه چرا چنین الزامی با توجه به محدودیت‌های حریم خصوصی و امنیتی ضروری و امکان‌پذیر است، استقبال می‌کنیم.
محیط اجرای مورد اعتماد	اجزای موجود در مسیر سرویس دهی TEE، مانند متعادل کننده بار، می توانند تمام ترافیک را مشاهده کنند و اطلاعات آدرس IP هر درخواست را داشته باشند.	در حال حاضر آدرس IP به عنوان یک فراداده در سرصفحه‌های درخواست به سرویس تبلیغاتی فروشنده نامعتبر در مورد مزایده‌های مزایده و مزایده و حراج مخاطب محافظت شده روی دستگاه ارسال می‌شود. برای اطلاعات بیشتر به ارسال ابرداده مراجعه کنید. در درازمدت، ما قصد داریم ترافیک فناوری تبلیغات و ردیابی را از طریق یک IP Proxy ردیابی کنیم، که از مشاهده تمام ترافیک در مسیر سرویس توسط اجزا جلوگیری می‌کند.
زمان برای زندگی (TTL)	آیا زمان حیات (TTL) قبل از اینکه سرویس ها باید کلیدهای جدید را درخواست کنند تنظیم می شود یا قرار است انعطاف پذیر (یا پویا) باشد؟	TTL به طور کلی ثابت است. در حال حاضر، TTL برای عموم 8 روز است، و چرخش هر 7 روز اتفاق می افتد. TTL همچنین برای کلیدهای خصوصی در مورد سرویس تجمع یکسان است. در مورد خدمات مناقصه و مزایده، کلیدهای خصوصی و عمومی هر N ساعت در مسیر بدون درخواست واکشی می شوند و در حافظه پنهان ذخیره می شوند، به طوری که بین چرخش کلیدها و دریافت این کلیدها از سوی سرورها بیش از یک ساعت تاخیر وجود نداشته باشد. . بافر 1 روزه بین چرخش کلید و انقضا برای اطمینان از این است که حتی اگر تولید کلید شکست بخورد، خدمات می توانند به کار خود ادامه دهند. ما در حال بررسی گسترش TTL برای انعطاف پذیری بیشتر در برابر قطع هستیم. در صورت نشت کلید، ما قصد داریم به صورت دستی تولید کلید را اجباری کنیم و کلیدها را زودتر باطل کنیم. توجه داشته باشید که کلیدهای عمومی در حال حاضر به مدت 24 ساعت دوباره روی مشتریان ذخیره می شوند تا اطمینان حاصل شود که در صورت قطع هماهنگ کننده، سرویس ها همچنان می توانند کار کنند.
شکل دهی ترافیک	پشتیبانی از شکل دهی ترافیک برای خدمات مناقصه و مزایده.	خریداران می‌توانند بر اساس داده‌های شخص اول ناشر یا داده‌های متنی، تقاضا برای حراج‌های مخاطب محافظت شده را نشان دهند. فروشندگان می‌توانند تصمیمات مشابهی را در سرور تبلیغات فروشنده یا سرور Ad Exchange نیز انجام دهند. این مدل‌ها را می‌توان بر روی داده‌های 1P و هرگونه گزارش انبوه از حراج‌های مخاطب محافظت‌شده آموزش داد. فروشندگان می توانند از این اطلاعات برای جلوگیری از ارسال درخواست به سرورهای Bidding و Auction در زمانی که هیچ تقاضایی برای حراج مخاطب محافظت شده وجود ندارد استفاده کنند. ما معتقدیم که این می تواند راهی موثر برای شکل دادن به ترافیک باشد.
حراج قطعات	کدام سیگنال‌های حراج سطح بالا با فروشندگان کامپوننت به اشتراک گذاشته می‌شوند؟	خریداران در حراج قطعات فقط سیگنال هایی را از فروشنده قطعات دریافت می کنند. ما به دنبال به اشتراک گذاشتن اسناد در مورد توالی کلی یک حراج ترکیبی با پیشنهاد سرصفحه و حراج مخاطب محافظت شده هستیم.
رندر ویدیو	پشتیبانی از رندر ویدیو با استفاده از مخاطبان محافظت شده و فریم های حصاردار.	Protected Audience API از رندر ویدیو با استفاده از مکانیزمی که به iframe متکی است پشتیبانی می کند. با این حال، ما هنوز راه‌حلی طراحی نکرده‌ایم که با قاب‌های حصاردار سازگار باشد، و این یکی از دلایلی است که تصمیم گرفتیم اجرای فریم‌های حصاردار را تا سال 2026 به عقب برگردانیم. این بدان معناست که اگر شریکی تصمیم به اجرای قاب‌های حصاردار در حال حاضر داشته باشد، پشتیبانی از ویدیو برای آن شریک وجود ندارد.
محدودیت فرکانس	(در فصل های گذشته نیز گزارش شده است) کنترل فرکانس برای هر کاربر در یک کمپین و گروه تبلیغاتی.	پاسخ ما نسبت به گزارش های قبلی تغییری نکرده است: مخاطب محافظت‌شده از محدودیت فرکانس برای حراج‌های روی دستگاه و کمپین‌های متنی و نام تجاری نیز پشتیبانی می‌کند. ذخیره‌سازی مشترک و سرپوش‌های مخصوص سایت نیز می‌توانند برای کنترل‌های درپوش فرکانس اضافی استفاده شوند.
تنظیمات برگزیده تبلیغات	آیا مخاطب محافظت شده راهی برای انصراف یا مسدود کردن فهرست توسط سایت‌های تبلیغ‌کننده یا راهی برای خروج از همه گروه‌های ذینفع از یک مالک ارائه می‌کند؟	راه‌های مختلفی برای کاربران وجود دارد که می‌توانند دسترسی به API مخاطب محافظت شده و سایر ویژگی‌های Privacy Sandbox را مسدود کنند .
خط مشی مبدأ یکسان برای URL منبع اسکریپت های مناقصه و حراج	این الزام را کاهش دهید که همه فیلدهایی که نشانی‌های اینترنتی را برای بارگیری اسکریپت‌ها یا JSON مشخص می‌کنند، باید با مالک یک منبع باشند.	ما در حال حاضر در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم .
`forDebuggingOnly`	پتانسیل برای `forDebuggingOnly .reportAdAuctionWin` که در صورت باقی ماندن در پست 3PCD مورد سوء استفاده قرار گیرد.	در طول سال‌های گذشته، پس از منسوخ شدن کوکی‌های شخص ثالث، بازخوردی از اکوسیستم در رابطه با شکاف‌های عملکردی در مخاطبین محافظت‌شده دریافت کرده‌ایم، و ما در تلاش هستیم تا طرحی را برای پشتیبانی از آنها در پست 3PCD بدون به خطر انداختن اهداف صندوق ایمنی حریم خصوصی، تدوین کنیم. ما از هرگونه پیشنهاد و بازخورد اضافی در مورد عملکردی که اکوسیستم مایل به مشاهده آن است استقبال می کنیم.
گروه های علاقه مند متعدد	از چند گروه ذینفع در یک پیشنهاد استفاده کنید.	این مورد امروزه در Protected Audience API پشتیبانی نمی‌شود، زیرا منجر به تغییر مدل حریم خصوصی اساسی می‌شود. ما از بحث بیشتر در اینجا استقبال می کنیم.
حراج های روی دستگاه	آیا Chrome در Android از حراج‌های مخاطب محافظت شده روی دستگاه پشتیبانی می‌کند؟	بله، حراج‌های روی دستگاه در Chrome در Android پشتیبانی می‌شوند .
(گزارش شده در سه ماهه دوم 2023) داده های مربوط به کلیک	داده های مربوط به کلیک را به browserSignals اضافه کنید.	ما همچنان به ارزیابی این درخواست ویژگی ادامه می‌دهیم و از بازخورد اضافی در مورد اینکه چرا باید این درخواست اولویت‌بندی شود، استقبال می‌کنیم.
ارائه دهندگان محیط اجرایی مورد اعتماد	آیا تفاوت های مادی در ارائه خدمات قابل اعتماد برای ارائه دهندگان ابر مختلف وجود دارد؟	ما از تفاوت های عمده ای آگاه نیستیم ، اما ما توصیه می کنیم که اکوسیستم راهنماهای استقرار عمومی را بررسی کنیم تا ببینیم کدام راه حل متناسب با نیازهای آنها است. Google Cloud . AWS
(گزارش شده در سه ماهه های قبلی) پشتیبانی از هدف قرار دادن گروه علاقه منفی	API برای پشتیبانی از هدف قرار دادن گروه علاقه منفی: نشان دادن تبلیغات فقط در صورتی که کاربر به یک گروه علاقه تعلق نداشته باشد.	ما به دنبال اجرای این ویژگی هستیم و در مورد درخواست بحث می کنیم.
تخلف	ویژگی های پشتیبانی که به کاربران امکان می دهد تبلیغات بدی را که توسط API مخاطبان محافظت شده در قاب های حصارکشی ارائه می شود ، گزارش دهند.	ما معتقدیم که مکانیسم گزارش تبلیغات قاب موجود در حصار ، گزینه های خوبی را برای تکنیک های تبلیغاتی که می خواهند یک جریان گزارش "تبلیغات بد" تولید شده توسط کاربر ارائه دهند ، ارائه می دهد. این امر باعث می شود گزارش های تبلیغاتی بد به روشی که اساساً از استاندارد صنعت تغییر نکرده است. ما در صورت باقی ماندن شکاف ، از درخواست های ویژگی های اضافی استقبال می کنیم ، از جمله در طول زمان پس از برداشتن کوکی شخص ثالث اما قبل از اینکه قاب حصیری گسترده شود.
گزارش API جمع آوری خصوصی	چگونه می توانیم زمانی را که کاربر در آن گروه علاقه صرف کرده است محاسبه کنیم؟	در Chrome M116+ باید بتوانید از recency به عنوان تعریف شده Pull/639 استفاده کنید.
سرور ناشناس	اطلاعات بیشتر در مورد سرور ناشناس بودن K.	ما اطلاعات بیشتری در مورد سرورهای ناشناس بودن K در اینجا به اشتراک گذاشتیم و از بازخورد اضافی استقبال کردیم.
URL های خلاق پویا	پشتیبانی از URL های خلاق بدون پیش دبستانی در حالی که هنوز هم ناشناس بودن K را احترام می گذارد.	ما در مورد این درخواست ویژگی بحث می کنیم و از بازخورد اضافی در مورد اینکه چرا باید این امر در اولویت قرار گیرد استقبال می کنیم.
الزام ناشناس بودن k	آیا الزام ناشناس بودن K در به روزرسانی های گروه علاقه دوباره معرفی می شود؟	ما پیش بینی تغییر در موقعیت بیان شده در این پست GitHub را پیش بینی نمی کنیم. همانطور که در آن پست اعلام شد ، ما تصمیم گرفتیم الزام ناشناس بودن K را در به روزرسانی های گروه مورد علاقه مخاطبان محافظت شده حذف کنیم ، که تأثیر قابل توجهی در حمایت های کلی حریم خصوصی API ندارد ، و ما قصد داریم سایر محافظت های مستقیم بیشتر را در نظر بگیریم (مانند IP حریم خصوصی آدرس یا یک سرور بروزرسانی قابل اعتماد) در تاریخ بعدی که فن آوری های مرتبط تر توسعه یافته ، مستقر و پذیرفته شده اند.
خدمات مناقصه و حراج تست بتا	چه زمانی آزمایش بتا خدمات مناقصه و حراج آغاز می شود؟	همانطور که در جدول زمانی و نقشه راه گفته شد ، مرحله اول آزمایش خدمات مناقصه و حراج در نوامبر 2023 آغاز می شود.
سد سازی جاده	درخواست برای پشتیبانی از هماهنگی خلاق برای شبکه های تبلیغاتی (SSP و DSP در یک شرکت یا خصوصیات مشابه هستند).	ما از بازخورد این مورد استفاده قدردانی می کنیم و به دنبال این هستیم که بدانیم آیا فناوری های تبلیغاتی بیشتری علاقه مند به دیدن این پشتیبانی هستند یا خیر. ما از بازخورد اضافی استقبال می کنیم .
تبلیغات بومی	پشتیبانی قاب حصارکشی برای تبلیغات بومی.	ما در حال بررسی حمایت از پرونده استفاده هستیم و در مورد راه حل ها و راه حل های احتمالی بحث می کنیم.
ناشناس بودن k	چگونه می توانم تبلیغات گروه علاقه ای را که آستانه K-Anon را برآورده می کنند ، به حداکثر برسانم؟	ما راهنمایی های تاکتیکی در مورد این موضوع به اشتراک گذاشته ایم.
پشتیبانی پست	پشتیبانی از ارسال داده های حراج از طریق درخواست های پست.	ما در حال ارزیابی این درخواست ویژگی هستیم و از ارسال های اضافی شماره GitHub در مورد اینکه چرا این امر باید در اولویت قرار گیرد استقبال می کنیم.
دانه بندی گزارش	دانه بندی گزارش دهنده گزارش تبلیغات قاب حصارکشی با تبلیغات متشکل از چند قطعه چیست؟	طراحی فعلی اجازه ضبط شناسه یا موقعیت محصول را نمی دهد زیرا این ممکن است حریم شخصی کاربر را به خطر بیاندازد. فقط قابل استفاده است `reserved.top_navigation` قابل استفاده است ، که در صورت فعال سازی کاربر (مانند کلیک) در قاب حصیری مؤلفه تبلیغاتی ارسال می شود ، که منجر به یک ناوبری سطح بالا می شود.
حراج تبلیغات	آیا یک SSP که در یک حراج مؤلفه شرکت می کند ، می تواند حراج مؤلفه دیگری را ایجاد کند؟	یک `componentSeller` هم نمی تواند شامل `componentAuctions` باشد. حراج چند فروش فقط دو سطح دارد: 1. حراج های مؤلفه به طور موازی. 2. حراج سطح بالا (جایی که آگهی برنده از هر `componentAuction` رقابت می کند).
در دسترس بودن خدمات مناقصه و حراج	آیا مناقصه و حراج در مرحله آزمایش تسهیل شده Chrome در دسترس خواهد بود؟	سرور مناقصه و حراج در مرحله آزمایش تسهیل شده Chrome در دسترس نخواهد بود.
سیگنال های مناقصه	به مرورگرها اجازه دهید سیگنال های مناقصه را درخواست و حذف کنند.	ما در مورد این درخواست بحث می کنیم و از بازخورد اضافی در مورد اینکه چرا باید این امر در اولویت قرار گیرد استقبال می کنیم .
`generateBid()`	امکان به روزرسانی `userBiddingSignals` Usergroup از طریق `updateURL` .	ما این پیشنهاد را در نظر می گیریم و از بازخورد و بحث اضافی استقبال می کنیم .
انواع موجودی ناشر	چه نوع موجودی ناشر توسط مخاطبان محافظت شده و آزمایش مباحث پشتیبانی می شود؟	نه مخاطبان محافظت شده و نه مباحث از نظر انواع موجودی که می توان از آنها استفاده کرد ، ذاتاً محدود کننده نیستند.
ادغام سرور به سرور	آیا ادغام مستقیم بین SSP و DSP برای مخاطبان محافظت شده لازم است؟	اگر DSP نیازی به پردازش سیگنال های متنی در سرور خود نباشد ، ادغام مستقیم بین SSP و DSP لازم نیست تا بتواند اطلاعات پردازش شده را به عملکرد مناقصه در دستگاه خود منتقل کند.
یک قسمت `bid_currency` در B&A	پشتیبانی از قسمت `bid_currency` در سرویس مناقصه و حراج.	B&A هنوز از `bid_currency` پشتیبانی نمی کند ، اگرچه ما قصد داریم تا پایان ژانویه 2024 از آن پشتیبانی کنیم. به جدول زمانی مراجعه کنید.
`perBuyerSignals`	آیا محدودیت اندازه برای `perBuyerSignals` وجود دارد؟	هیچ محدودیتی در تعداد سیگنال های هر خریدار وجود ندارد ، اما ارسال داده های بیش از حد ممکن است اثرات مضر بر عملکرد مرورگر داشته باشد.
موارد استفاده متقاطع	آیا می توانیم از گروه های علاقه مند API مخاطبان محافظت شده در چندین وب سایت استفاده کنیم؟	مخاطبان محافظت شده برای چنین مواردی طراحی نشده اند ، همانطور که در Turtledove/شماره ها/282 توضیح داده شده است.
درخواست های گروه علاقه HTTP	شامل حباب گروه علاقه در هدرهای HTTP شوید.	ما در حال بررسی این درخواست هستیم و از این درخواست بازخورد بیشتری استقبال می کنیم .
کنترل کیفیت تبلیغات	از دست دادن کنترل کیفیت آگهی مربوط به اطلاعات متقابل.	ما در حال بررسی این بازخورد هستیم و از بازخورد اضافی استقبال می کنیم .
chrome devtools	درخواست های شبکه محافظت شده مخاطبان در حال خروج باید در برگه شبکه Tools Developer Crome قابل مشاهده باشد.	ما در حال کار بر روی فعال کردن این قابلیت در برگه شبکه هستیم و از بازخورد اضافی در مورد اینکه چرا باید این امر در اولویت قرار گیرد استقبال می کنیم .
محیط اعدام قابل اعتماد	چه موقع جزئیات مربوط به معیارها تأثیر حریم خصوصی (و مدرک آنها) به توضیح دهنده در مورد نظارت بر محیط زیست قابل اعتماد اضافه می شود؟	ما در حال به روزرسانی توضیح دهنده با این اطلاعات هستیم. توضیح دهنده به روز شده تا نوامبر 2023 در دسترس خواهد بود.
`directFrom SellerSignals`	چرا `directFrom SellerSignals` است `directFrom SellerSignals` به عنوان یک بسته وب بسته بندی نشده اند؟	ما در اینجا دلیل این تصمیم را برای این تصمیم به اشتراک گذاشتیم.
نمایندگی	آیا روش قابل دوام برای انجام نمایندگی در جایی که نتیجه یک گروه علاقه در حال انتخاب است ، یک اقدام هدفمند دیگر وجود دارد؟	حراج های متعدد تو در تو به دو دلیل با اهداف حریم خصوصی ما سازگار نیستند. اول ، هنگامی که برنده حراج در داخل یک قاب حصارکشی قرار می گیرد ، اهداف حریم خصوصی ما برای مخاطبان محافظت شده شامل ارائه خلاقانه حاصل بدون اطلاع از متن است: URL صفحه یا کوکی شخص اول یک نقض حریم خصوصی است. در آن محیط ، حراج تو در تو قابل استفاده نیست. دوم ، مدل مخاطبان محافظت شده می گوید که برنده هر حراج باید فقط براساس داده های یک سایت اضافی باشد. حراج های تو در تو راهی برای ترکیب این امر خواهد بود که در نتیجه امکان انتخاب تبلیغات بر اساس مشخصات سایت های مختلف ایجاد می شود.
داده ها در معیار استراحت	داده های موجود در معیار REST را در مدل اعتماد Key/Value Service توضیح دهید.	داده های موجود در سرویس ارزش کلیدی در حافظه بارگذاری می شوند و به جای انجام هرگونه ذخیره سازی خوانده شده ، از آنجا سرو می شوند.
سیگنال داده خریدار	آیا برای سیگنال های `buyer_data` که از DSP دریافت می شود ، محدودیت اندازه مشخصی وجود دارد؟	در حال حاضر هیچ محدودیت تحمیل شده مرورگر برای سیگنال های `buyer_data` دریافت شده از DSP ها وجود ندارد.

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

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

موضوع بازخورد	خلاصه	پاسخ کروم
دستگاه	برنامه ای برای پشتیبانی متقابل از دستگاه برای API گزارش انتساب.	دستگاه متقابل چالش های جدید حریم خصوصی را در بالای 3 قطعه ارائه می دهد و همچنین با توجه به طیف وسیعی از دستگاه ها و سیستم عامل هایی که کاربر ممکن است از آن استفاده کند ، چالش های توزیع فناوری را اضافه می کند. ما در حال بررسی راه حل های بالقوه هستیم ، اما ما بر روی موارد مهم استفاده شده که در حال حاضر توسط گزارش انتساب پشتیبانی می شوند متمرکز شده ایم و برنامه ای برای معرفی پشتیبانی متقابل قبل از حذف کوکی های شخص ثالث نداریم.
(همچنین در سه ماهه قبلی گزارش شده است) اندازه داده های ماشه	چرا اندازه داده ماشه به 3 بیت محدود می شود؟	اندازه آن به 3 بیت و 8 مقدار مجزا محدود می شود تا اطمینان حاصل شود که میزان اطلاعات متقابل و اطلاعات متقاطع در مورد کاربر محدود است. ما از بازیکنان اکوسیستم استقبال می کنیم تا در مورد اینکه آیا پارامتر شدن فعلی برای گزارش در سطح رویداد کافی است ، بازخورد ارائه دهند .
قیف تبدیل	چندین دامنه را که در تبدیل استفاده شده اند گزارش دهید.	این مورد استفاده از زمان افزودن مقصد متعدد امکان پذیر است. ما از بازخورد اضافی استقبال می کنیم.
همان دامنه در حمایت از کشور مختلف	آیا گزارش انتساب با وب سایتهایی که دارای یک دامنه یکسان هستند اما TLD های مختلف کشور هستند ، کار می کند؟	این موضوع با ذینفعان که این سؤال را مطرح کرده است مورد بحث و حل و فصل شده است. اگر یک فناوری تبلیغی نیاز به استفاده از TLD های مختلف کشور داشته باشد ، آنها نیاز به ثبت نام های متعدد دارند ، با یکی برای هر کشور TLD.
مخاطبان محافظت شده و گزارش انتساب	آیا فناوری های تبلیغاتی می توانند به هر دو تبدیل از طریق نمایشگاه برای حراجی های محافظت شده مخاطبان و همچنین تبدیل های کلیک برای گزارش انتساب دسترسی پیدا کنند؟	بله ، Sandbox حریم خصوصی باید از VTC و CTC در مخاطبان محافظت شده پشتیبانی کند.
تأخیر در گزارش AgageGregatable	تأخیر در گزارش قابل جمع کردن بیشتر را کاهش دهید.	ما بازخورد اخیر در مورد این را شنیده ایم و ایده های مشترک را در اینجا به اشتراک گذاشته ایم. ما از بازخورد اضافی از اکوسیستم استقبال می کنیم.
تأخیر در گزارش AgageGregatable	کاهش تأخیرها از طریق معرفی واسطه سرور.	ما در حال بررسی این پیشنهاد هستیم و از بازخورد اضافی استقبال می کنیم .
تأخیر در گزارش سطح رویداد	تأخیرهای گزارش سطح رویداد را کاهش دهید.	پیشنهاد کامل در سطح رویداد ، که در تنظیمات انعطاف پذیر در سطح رویداد شرح داده شده است ، می تواند تاخیر گزارش در سطح رویداد را با یک تجارت سر و صدا کاهش دهد.
منشأ گزارش منبع در هر منبع	محدودیت منشأ گزارش منبع حداکثر در هر سایت گزارش منبع ، مانع از ثبت نام منابع از منشأ گزارش های مختلف برای منشأ ناشر واحد می شود.	این مورد با ذینفعان مورد بحث قرار گرفته است که این مسئله را مطرح کرده است و یک راه حل بالقوه استفاده از 1 گزارش گزارش در هر سایت گزارش منبع قبل از تلاش دیگر راه حل های بالقوه مربوط به تغییر مسیر مورد آزمایش قرار می گیرد. ما در مورد هر بازخورد اکوسیستم اضافی نیز در مورد این حد باز هستیم.
گزارش انتشار	چگونه می توانیم خطاها یا مسائل مربوط به API گزارش انتساب را به Chrome گزارش دهیم؟	در حال حاضر ما توصیه می کنیم که Techs Ad هرگونه خطای API گزارش دهنده را که ممکن است به عنوان موضوعی در GitHub با آنها روبرو شوند ، گزارش دهند. اگر آنها با یک مسئله مرتبط با کروم روبرو هستند ، توصیه می کنیم یک اشکال کروم ایجاد کنید. پیوندهایی برای چگونگی و از کجا پرچم گذاری هر مشکلی را می توان در زمینه بازخورد درگیر و به اشتراک گذاشت .
تکذیب	چگونه می توانیم تبدیل ها را در خطوط لوله و دستگاه های مختلف اختصاص دهیم؟	Dedupplic در بین دستگاه ها و خطوط لوله اندازه گیری یک چالش شناخته شده و فعلی است که امروزه فناوری های تبلیغاتی نیز با 3 قطعه با آن روبرو هستند. با استفاده از API گزارش انتساب ، فناوری های تبلیغاتی می توانند تصمیم بگیرند که چه زمانی تبدیل های خاص را ثبت کنند و ابرداده خاصی را اضافه کنند تا نشان دهند کدام خط لوله های اندازه گیری از آنها برای ردیابی تبدیل ها استفاده کرده اند (به عبارت دیگر ، بخشی از کلید جمع آوری) ، که می تواند در برابر اندازه گیری دیگر مقایسه شود خطوط لوله ما در مورد این بازخورد اکوسیستم اضافی باز هستیم.
فداکاری و اولویت	درخواست اولویت اول قبل از deduplication.	ما در حال بررسی این درخواست هستیم و از بازخورد اضافی استقبال می کنیم .
ضد تقلب	خطر استفاده از کاربر مخرب داده های سطح رویداد.	تأیید گزارش به دلایلی که در مورد این گزارش های سطح رویداد پشتیبانی نمی کند ، برای گزارش در سطح رویداد کار نمی کند؟ .
نوع تبدیل	چگونه می توانیم بین نمای از طریق و ناوبری در گزارش انتساب تمایز قائل شویم؟	ما گزینه فیلتر داخلی زیر را داریم: `source_type` . جزئیات اضافی در اینجا موجود است .

سرویس تجمیع

موضوع بازخورد	خلاصه	پاسخ کروم
بهبود بودجه	برخی از تکنیک های تبلیغاتی در مواردی که خرابی ، خطاها یا حذف گزارش های آنها وجود دارد ، می توانند گزارش ها را دوباره پردازش کنند.	این تیم در حال بررسی راه های پرداختن به این موضوع به روشی برای حفظ حریم خصوصی است.
ثبت نام در سایت	چندین فن آوری تبلیغاتی درخواست پشتیبانی برای پردازش چندین منشاء در همان حساب را برای موارد استفاده مانند تقسیم داده های GEO ، تبلیغ کننده درخواست کرده اند. این رفتار همچنین با توجه به اینکه ثبت نام API مشتری اکنون مبتنی بر سایت است (و نه مبتنی بر مبدا) انتظار می رود. مهاجرت از مبدا به ثبت نام سایت ، روند تبلیغات را از طریق سازگاری با فرآیند ثبت نام مشتری ، ساده تر می کند.	ما به زودی مهاجرت را از ثبت نام Origin به ثبت نام در سایت برای ثبت نام در سایت آغاز خواهیم کرد و از بازخورد اکوسیستم استقبال می کنیم.
برنامه آزادی و استهلاک	برنامه انتشار و استهلاک برای ویژگی های خدمات جمع آوری و تکه های منتشر شده. هدف از این طرح این است که به تکنیک های تبلیغاتی در سیاست های انتشار ما مراجعه کنیم تا بتوانند آنها را برای انتشار نسخه های آینده و استهلاک آماده کنند و اطمینان حاصل کنند که آنها نسخه های پایدار و ایمن خدمات را اجرا می کنند.	ما اخیراً پیشنهادی را برای برنامه انتشار و برنامه استهلاک خدمات جمع آوری منتشر کرده ایم و از بازخورد اضافی استقبال می کنیم.
هماهنگ کننده	چه اتفاقی می افتد اگر هماهنگ کنندگان در خدمات جمع آوری پایین بیایند؟	هر دو هماهنگ کننده برای عملکرد صحیح سیستم باید کاملاً در دسترس باشند. عدم دسترسی کوتاه با ترمیم ها در کتابخانه های مشتری ما جای می گیرد. عدم دسترسی طولانی تر هر یک از این دو هماهنگ ، مشاغل جمع آوری شکست خواهد خورد. در صورت عدم مصرف بودجه حریم خصوصی ، می توان مشاغل را مجدداً مورد استفاده قرار داد. در صورتی که هرگونه عدم موفقیت خدمات منجر به مصرف بودجه بدون گزارش خلاصه ای برای ذخیره سازی فناوری تبلیغاتی شود ، در حال حاضر توصیه می کنیم آنها از گزارش های اشکال زدایی برای بازیابی نتایج با استفاده از ابزار تست محلی استفاده کنند. ما همچنین در حال کار بر روی ویژگی هایی هستیم تا در صورت بروز خرابی امکان بهبودی بودجه را فراهم کنیم تا تکنیک های تبلیغاتی بتوانند شغل خود را دوباره انجام دهند.

API تجمع خصوصی

موضوع بازخورد	خلاصه	پاسخ کروم
پرچم	درخواست پشتیبانی از URL حباب در ذخیره سازی مشترک.	پشتیبانی از URL حباب در Chrome M116 اضافه شده است.

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

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

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

محافظت از IP (قبلاً Gnatcatcher)

موضوع بازخورد	خلاصه	پاسخ کروم
ترافیک شخص ثالث واجد شرایط	"ترافیک واجد شرایط شخص ثالث" در توضیح دهنده چیست؟	ما اهمیت این سؤال را درک می کنیم و به طور جدی در تلاش هستیم تا مشخص شود که ترافیک شخص ثالث واجد شرایط خواهد بود و کدام یک نخواهد بود. ما از بازخورد در مورد این موضوع استقبال می کنیم.
حسابرسی ترافیک شبکه	پشتیبانی از شرکت ها برای انجام ممیزی ترافیک شبکه برای شبکه های خود.	فقط ترافیک شخص ثالث تعبیه شده در سایت های شخص اول تحت تأثیر قرار می گیرد که باید میزان ترافیکی که نیاز به فیلتر دارد را محدود کند. علاوه بر این ، ما قصد داریم به کاربران این گزینه را بدهیم که آیا از محافظت از IP استفاده می کنند یا نه ، و برای Chrome تحت کنترل شرکت ، سیاست های سازمانی برای غیرفعال کردن محافظت از IP وجود خواهد داشت. سرانجام ، ما در حال بررسی اینکه کنترل ها (در صورت وجود) برای غیرفعال کردن محافظت از IP به اپراتورهای شبکه ارائه می شود. ما از بازخورد در مورد این موضوع استقبال می کنیم.
کنترل دسترسی	محافظت از IP ممکن است بر خدمات وب که از آدرس های IP برای کنترل دسترسی استفاده می کنند ، تأثیر بگذارد.	ما اهمیت موارد استفاده ضد کلاهبرداری و تأثیر احتمالی آن موارد استفاده را درک می کنیم. ما به دنبال بازخورد اکوسیستم هستیم که چگونه می توانیم از مواردی که به طور معمول به آدرس های IP اعتماد کرده اند ، از موارد استفاده ضد کلاهبرداری بهتر پشتیبانی کنیم.
ارتباط بین پروکسی های 2-HOP	چگونه می توان اطمینان حاصل کرد که هیچ اطلاعاتی بین پروکسی ها وجود ندارد.	ما در حال طراحی تعامل پروکسی هستیم. هدف ما به حداقل رساندن شانس برای به اشتراک گذاری اطلاعات از طریق تجارت ، فرآیند و وسایل فنی است.
احراز هویت غیر Google	پشتیبانی از احراز هویت غیر Google.	ما قصد داریم در آینده جزئیات بیشتری درباره تأیید اعتبار حساب منتشر کنیم ، اگرچه برخی ملاحظات اولیه را به اشتراک گذاشته ایم.
طبقه بندی ردیاب	چگونه محافظت از IP تعیین می کند که چه چیزی یک ردیاب و انواع آن را تشکیل می دهد؟	ما اهمیت این سؤال را درک می کنیم و به طور جدی در تلاش هستیم تا مشخص شود که ترافیک شخص ثالث واجد شرایط خواهد بود و کدام یک نخواهد بود. ما از بازخورد در مورد این موضوع استقبال می کنیم.
تجزیه و تحلیل	محافظت از IP ممکن است بر صحت خدمات تحلیلی تأثیر بگذارد.	ما به دنبال درک تأثیر محافظت از IP هستیم و از بازخورد و نمونه های اضافی از اکوسیستم استقبال می کنیم.
پروکسی	اگر کاربر از پروکسی استفاده می کند یا یک پروکسی را به صورت دستی تعریف کرده است ، ماسک IP در این حالت چگونه کار خواهد کرد؟	ما به دنبال درک تأثیر محافظت از IP در سایر پروکسی ها هستیم. ما در حال حاضر هیچ برنامه ای برای اشتراک گذاری نداریم. ما از بازخورد در مورد این موضوع استقبال می کنیم.
پیشنهاد حق بیمه	آیا محافظت از IP یک ویژگی پولی خواهد بود؟	محافظت IP به عنوان بخشی از تجربه اصلی مرورگر در دسترس کاربران Chrome خواهد بود. این یک ویژگی پولی نخواهد بود.
سرور پروکسی	آیا در جلسات کاربر از همان سرورهای پروکسی استفاده می شود؟	یک اتصال HTTP/S از یک جفت پروکسی واحد استفاده می کند و یک آدرس IP ماسک شده را به مبدا ارائه می دهد. فراتر از آن ، هیچ محدودیت سختی در اتصالات مختلف HTTP/S وجود ندارد که از سرورهای مشابه استفاده کنند.
پشتیبانی سکو	محافظت از IP در کدام پلتفرم پشتیبانی می شود؟	حفاظت IP در ابتدا برای Android و Desktop در Chrome در دسترس خواهد بود. ما همچنان به ارزیابی نحوه گسترش محافظت از سیستم عامل های دیگر می پردازیم.
انصاف	آیا کاربران قادر به محافظت از IP هستند؟	ما قصد داریم انتخاب کنیم که آیا آنها می خواهند از IP محافظت کنند یا خیر.
ناشناس سازی	چه نوع درخواست هایی تحت حمایت IP ناشناس می شوند؟	درخواست های HTTP/S و DNS به دامنه های شخص ثالث واجد شرایط از طریق پروکسی های حریم خصوصی ناشناس می شوند. ما جزئیات بیشتری را در یک توضیح دهنده آینده در مورد چگونگی تعیین اینکه کدام دامنه ها گنجانده شده است ارائه خواهیم داد. بقیه ترافیک (به عنوان مثال ، بقیه درخواست های DNS یا سایر ترافیک HTTP/S) بی تأثیر است.
دید داده	آدرس های شبکه ممکن است در اولین هاپ در محافظت از IP قابل دسترسی باشد.	در مدل پروکسی دو هاپ ، اولین هاپ (کنترل شده توسط Google) فقط IP مشتری منبع و درخواست اتصال به هاپ دوم را می بیند ، در حالی که هاپ دوم (کنترل شده توسط یک CDN خارجی) فقط در حالت اول یک توپ را می بیند هاپ (پورت Proxy IP +) و IP مقصد. برای پاسخ از مبدأ ، هاپ دوم قادر به پاسخ به اولین پورت پروکسی+هاپ مرتبط با درخواست است و نیازی به یادگیری چیزی در مورد IP مشتری اصلی ندارد (و اولین هاپ فقط پاسخ را برمی گرداند به مشتری ، بدون یادگیری چیزی در مورد IP مقصد). به این ترتیب ، هاپ اول فقط IP مشتری و هاپ دوم را می آموزد ، در حالی که هاپ دوم فقط IP مقصد را می آموزد.
نمایشگاه	آیا محافظت IP در آینده در دسترس Android WebView خواهد بود؟	ما در حال حاضر هیچ برنامه ای برای اشتراک گذاری نداریم ، اما چشم انداز ما این است که این محافظت را تا حد امکان ارائه دهیم.

کاهش ردیابی گزاف گویی

موضوع بازخورد	خلاصه	پاسخ کروم
پیگیری تعامل	تعامل کاربر چگونه ردیابی می شود؟	ردیابی ردیابی دو نوع تعامل کاربر را ردیابی می کند: فعال سازی کاربر مطابق مشخصات HTML تعریف شده است. اینها اساساً کلیک ، پرس های کلیدی ، شیرهای صفحه لمسی و غیره است. ادعاهای موفق WebAuth . این مواردی است که کاربر یک کلید امنیتی را برطرف می کند یا از یک کلید عبور به عنوان شکل احراز هویت استفاده می کند این فعل و انفعالات با سایت سطح بالا در صفحاتی که در آن رخ می دهد همراه است. به عنوان مثال ، اگر کاربر در Iframe تعبیه شده کلیک کند ، تعامل با سایت سطح بالا همراه است و نه سایت تعبیه شده. فعل و انفعالات در یک پایگاه داده حاوی ETLD بدون طرح و زمان تعامل ذخیره می شود. فعل و انفعالات از دامنه مرتبط با حذف حالت کاهش ردیابی به مدت 45 روز محافظت می کند.
معافیت های لیست شده	آیا می توان دامنه ها را معاف کرد؟	ما این درخواست را در نظر می گیریم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.

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

هیچ بازخوردی در این سه ماه دریافت نکرد.

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

مجموعه های وب سایت مرتبط (مجموعه های شخص اول)

موضوع بازخورد	خلاصه	پاسخ کروم
رویکرد متمرکز	نگرانی از رویکرد مخزن متمرکز برای مدیریت مجموعه های وب سایت مرتبط.	یک مخزن عمومی و به راحتی در دسترس برای طراحی RWS مهم است زیرا مسئولیت ارسال را برای ارسال ها فراهم می کند. عملکرد کوکی شخص ثالث در نهایت با استفاده از API دسترسی به ذخیره سازی یا API RSAFOR ارائه می شود ، با عضویت RWS دسترسی به اعطای خودکار (بر خلاف اعلان ها با API دسترسی به ذخیره سازی). ما معتقدیم که رویکردی مانند فرآیند ارسال RWS یک نیاز مناسب برای دسترسی به کوکی شخص ثالث با اعطای خودکار است.
تغییر نام پرونده JSON	آیا با تغییر در نام API ، آیا نام پرونده JSON میزبان نیاز به تغییر دارد؟	بله ، دستورالعمل های ارسال تغییر یافته است ، و دامنه اصلی باید یک پرونده JSON را در `/.well-known/related-website-set.json` ارائه دهد. مجموعه های موجود در لیست RWS نیازی به تغییر ندارند ، اما اگر تغییراتی در مجموعه های موجود ارائه شود ، پرونده JSON باید تغییر یابد.
(همچنین در سه ماهه قبلی گزارش شده است) حد دامنه	درخواست گسترش تعداد حوزه های مرتبط	همانطور که در یک وبلاگ در تاریخ 31 آگوست اعلام شد ، ما به دنبال بازخورد اکوسیستم ، محدوده دامنه مرتبط را به پنج حوزه افزایش داده ایم. ما تصمیم گرفتیم که محدوده دامنه مرتبط را به پنج حوزه (به علاوه یک دامنه اصلی) افزایش دهیم که به بهترین وجه با مقایسه ترین اجرای ارائه شده توسط یک مرورگر اصلی دیگر مطابقت دارد.
کوکی های شخص ثالث	آیا مجموعه وب سایت های مرتبط فقط با کوکی های شخص ثالث غیرفعال می شوند؟	مجموعه های وب سایت مرتبط حتی در شرایطی که کاربر کوکی های شخص ثالث را مسدود نکرده باشد کار خواهد کرد. اما هیچ تأثیر قابل توجهی وجود نخواهد داشت زیرا کوکی های مربوطه بدون نیاز به مجموعه های وب سایت مرتبط و API دسترسی به ذخیره سازی در دسترس هستند.
ویرایش های قانونی	چگونه مجموعه وب سایت مربوطه مخزن مانع از تغییر مجموعه های غیر مالکین می شود؟	در مورد راهنماهای ارسال ، هر کسی می تواند PR را در GitHub ارسال کند تا پرونده `first_party_sets.JSON` را ویرایش کند. با این حال ، اگر روابط عمومی تصویب شود (از اعتبار فنی عبور می کند ، و غیره) ، آن را به صورت دستی در دسته ها به لیست FPS متعارف یک بار در هفته (سه شنبه ها در ساعت 12 بعد از ظهر شرقی) توسط Google ادغام می شود. اگر یک بازیگر بد سعی کند مجموعه ای را که متعلق به آنها نیست اصلاح کند ، نباید مشکلی ایجاد کند زیرا آنها قادر به تغییر پرونده های `.well-known` نیستند و بنابراین اعتبارسنجی ها شکست می خورند.
دامنه ربودن	ربودن دامنه ممکن است داده های دامنه مرتبط را در معرض احزاب غیرمجاز قرار دهد.	این امکان پذیر نیست ، همانطور که در این موضوع محافظت شده مخاطبان GitHub بحث شده است.

قاب های حصارکشی API

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

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

موضوع بازخورد	خلاصه	پاسخ کروم
حوزه متقاطع	اجازه ارتباط در حوزه ها را برای ذخیره سازی محلی.	این مورد استفاده در حال حاضر مطابق با دروازه های خروجی حفظ حریم خصوصی ذخیره سازی نیست ، اما ما از متن دیگری استقبال می کنیم زیرا پیشنهادات مربوط به ذخیره سازی غیر مشارکت را تحول می دهیم.
پرچم	درخواست پشتیبانی از URL حباب در ذخیره سازی مشترک.	پشتیبانی از URL حباب در Chrome M116 اضافه شده است.

چیپس

هیچ بازخوردی در این سه ماه دریافت نکرد.

فدستان

موضوع بازخورد	خلاصه	پاسخ کروم
کوکی های شخص ثالث	آیا FEDCM در حال حاضر غیرفعال است اگر کاربران "بلوک کوکی های شخص ثالث" را در تنظیمات Chrome فعال کنند؟	بله ، FEDCM در حال حاضر غیرفعال است. برای آزمایش ، توصیه می کنیم علاوه بر این `chrome://flags/#fedcm- without-third-party-cookies` . ما در آینده به دنبال پشتیبانی از FEDCM بدون کوکی های شخص ثالث هستیم.

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

API Token State Private (و سایر API)

موضوع بازخورد	خلاصه	پاسخ کروم
انقضاء	پس از حذف Google Chrome ، آیا نشانه از بین می رود یا ذخیره می شود؟	اگر کاربر Google Chrome را حذف کند ، این نشانه از بین می رود.
اطلاعات	چگونه صادرکنندگان می توانند اطلاعات صادر شده را در امور خصوصی خصوصی حفظ کنند؟	اطلاعات همیشه در نشانه ها خصوصی نگه داشته می شوند و توسط احزاب خارجی که کلیدها ندارند ، نمی توانند رمزگذاری شوند.
خطا در نسخه ی نمایشی	خطا هنگام تلاش برای اجرای نسخه ی نمایشی Token State.	ما نسخه ی نمایشی را به روز کرده ایم و اکنون باید به درستی کار کند.

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

به عنوان بخشی از تعهدات خود در مورد CMA ، گوگل موافقت کرده است که گزارش های سه ماهه ای را در مورد فرآیند مشارکت ذینفعان برای پیشنهادات ماسه صندوق حریم خصوصی خود ارائه دهد (به پاراگراف های 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 یا فناوری خاصی وجود ندارد

موضوع بازخورد	خلاصه	پاسخ کروم
آمادگی اکوسیستم	SSP ها نگرانی از عدم آمادگی ناشران و انجام کار استقرار لازم را نشان داد.	حریم خصوصی Sandbox به طور خاص بر آموزش ناشران متمرکز شده است ، که شامل وبینارهای اختصاصی و جلسات با ناشران و SSP های موجود برای هدایت کار استقرار است.
استهلاک کوکی شخص ثالث	نگرانی های مربوط به استهلاک کوکی شخص ثالث (3pcd) در Q4 2023 به دلیل خاموشی فناوری صنعت افزایش می یابد.	جدول زمانی برای ماسهبازی حریم خصوصی با CMA مورد بحث قرار گرفته است که توالی منجر به نیمه دوم آمادگی 2024 می شود. حریم خصوصی Sandbox اطلاعات دقیق تری در مورد توالی شیب 3pcd منتشر خواهد کرد. براساس این تعهدات ، 3pcd مشمول نگرانی های مربوط به رقابت CMA است.
Google Ad Manager	Google Ad Manager از افشای آزمایش سطح API امتناع می ورزد.	پاسخ ارائه شده توسط Google Ad Manager: به دلایلی که در این پاسخ توسط Google Ad Manager توضیح داده شده است ، برنامه های Google Ad Manager برای ادغام API مخاطبان محافظت شده خود شامل پشتیبانی از سرور تبلیغات ناشر گوگل بدون کنترل حراج سطح بالا نیست.
Google Ad Manager	Google Ad Manager دارای قیمت طبقه مخفی است که فقط در معرض ADX یا SSP های مناقصه باز قرار دارد.	مستندات عمومی Google Ad Manager می گوید که برنده حراج متنی به منطق امتیاز دهی سطح بالا منتقل می شود و به هیچ حراج مؤلفه ای از جمله ADX یا مناقصه باز نیست. علاوه بر این ، این مستندات از منطق امتیاز دهی سطح بالا می گوید: "مدیر تبلیغات پیشنهاد برنده هر حراج مؤلفه ، از جمله حراج مؤلفه خود مدیر تبلیغات را برای پیشنهادات گروه علاقه به خریداران خود و همچنین بهترین تبلیغات متنی مقایسه می کند (یعنی این است. انتخاب شده از طریق تخصیص پویا) ، و با بالاترین پیشنهاد به تبلیغ می پردازد. "
Google Ad Manager	محصولات Google ADS باید مطابق قوانین مشابه محصولات تبلیغاتی شخص ثالث باشد.	محصولات Google Ads قبلاً در معرض قوانین مشابه اشخاص ثالث قرار دارند.
آزمایش با تسهیل کروم	برچسب ها را برای مرورگرهایی که در A یا B نیستند اضافه کنید.	ما در حال حاضر در حال انجام این کار نیستیم ، زیرا تحقیقات ما نشان داده است که اضافه کردن برچسب های غیر آزمایش ممکن است نگرانی های مربوط به حریم خصوصی پیرامون ترافیک را در حالت ناشناس پیچیده کند.
آژانس تبلیغاتی	آیا آژانس ها یا شرکت های بدون JavaScript در وب سایت ها می توانند از API های Sandbox Privacy Privace استفاده کنند؟	هرکسی می تواند با API های Sandbox Privacy تماس بگیرد. اگر یک آژانس یا هر کس دیگری بخواهد فناوری هایی را مستقیماً در API ایجاد کند. API های سمت مشتری ، دقیقاً همانطور که کوکی ها انجام می دهند ، نیاز به ادغام با مشتری دارند. بسیاری از API ها مانند کوکی ها نیز دارای رابط هدر HTTP هستند. ما قبلاً شاهد یک چارچوب صنعت تبلیغاتی ، پیش از آن ، ایجاد ادغام سمت مشتری با API ها بودیم. سازمان های دیگر می توانند همین کار را انجام دهند.
راه حل های سمت مشتری	چرا وقتی یک مهندس قبلاً ابراز نگرانی از مقیاس پذیری چنین راه حل هایی در سال 2012 داشت ، Google راه حل های سمت مشتری را برای حریم خصوصی Sandbox اتخاذ کرده است؟	فناوری تقویت حریم خصوصی (PET) به عنوان یک زمینه مطالعه از سال 2012 به طور قابل توجهی تکامل یافته و با استفاده از آن ، برنامه های قابل استفاده از نظر تجاری. در هسته اصلی حریم خصوصی ماسهبازی ترکیبی از حیوانات خانگی وجود دارد که بیش از یک دهه پیش امکان پذیر نبودند. In addition, personal computing power has increased, as have consumer expectations of browsers and regulatory expectations of privacy.
فراگیری ماشین	What is Google's planned usage of Privacy Sandbox for machine learning purposes?	Much of the ad tech ecosystem uses machine learning today and we do not expect that to change. Privacy Sandbox does not prevent ad tech companies or anyone else from continuing to use machine learning. Nor does Privacy Sandbox require that companies integrating with its APIs use machine learning. It is reasonable to expect that companies will continue building products and services in ways that meet the needs of their customers, whether that includes machine learning or not. Any machine learning that Privacy Sandbox integrators do build will obviously be known to them and thus not be obscured to them.
Data verification	How can companies verify that the data they receive from using the Privacy Sandbox is accurate and is Google willing to be reviewed via an entity such as the Media Ratings Council (MRC)?	Privacy Sandbox APIs are built within the open-source platform that powers Chrome. The portions of the APIs meant to run in Trusted Execution Environments are also open source and auditable. Anyone who wants to inspect the code can, including MRC.
(Also reported in previous quarters) Production Support	What is the process in place for Chrome to support Privacy Sandbox technical issues and escalations affecting the ecosystem?	Google provides a range of channels to allow ad techs to report technical issues and enable any necessary escalations to resolve such issues. In addition, Chrome expects to further build and scale a process to resolve technical issues and escalations affecting the health of the ecosystem. Chrome is committed to ensuring resources for this effort. Please see our developer post for more information on the public and private forums for feedback and escalation.
Chrome-facilitated testing modes	More information about the timelines and exact implementations for the Chrome-facilitated testing modes.	We have shared a blog post about testing modes and are working to share more information soon. We are welcoming suggestions for what size the testing mode labels should be.
Integration with other industry standards	Will the Privacy Sandbox APIs connect to either or both TCF v2.* and Consent Mode?	We do not have plans to integrate Privacy Sandbox APIs directly with TCF v2 or Consent Mode. However, companies and industry trade groups are welcome to adapt their products and frameworks to work in conjunction with Privacy Sandbox APIs. For example, with frameworks like TCF, each participant must determine its own compliance approach based on the TCF signal it receives and the associated TCF policies. We expect companies to determine when and how to use various functionality our Privacy Sandbox building blocks offer.

Enrollment & Attestation

Feedback Theme	خلاصه	Chrome Response
محدودیت	Enrollment process means Google can decide which company in the ecosystem is allowed to use Privacy Sandbox APIs.	The Enrollment and Attestation process essentially entails verification of the entity (for example, the entity has a DUNs number, can provide a link to a privacy policy, and so forth) and makes the public attestation a requirement for calling the APIs. Entities that can successfully fulfill the enrollment requirements will be validated. For companies that do not have a DUNs, we are providing an expedited, complimentary process with Dun & Bradstreet to acquire one. The objective is to enhance privacy protections of the APIs (by the measures just mentioned) and also to add a layer of transparency to the Privacy Sandbox APIs, so interested parties can better understand who is using which API and what attestations they are making. We are open to further industry feedback on this issue, which has already been used to shape the process.
Re-enrollment overhead	Attestation file expires every 12 months and requires websites to re-enroll.	We've heard feedback from the ecosystem and amended our approach accordingly. This means that files will no longer expire after 12 months or any set period of time. We are updating our enrollment developer guide with additional context.
Attestation file	How is the attestation file used?	All companies calling relevance and measurement APIs will be required by the enforcement deadline to upload the attestation file on their site and keep it for public view as long as you are intending to continue calling the APIs. Websites could expect approximately one request per hour from Privacy Sandbox, and other potential entities may query as well. This will be conducted via the enrollment system's own mechanism to query enrolled entities' servers and ensure the attestation file is valid. Attestations will be included in Transparency Reports and viewable by the general public. We expect companies to act in accordance with their stated attestations, as will the rest of the ecosystem and relevant regulatory bodies.
ثبت نام	Is enrollment per site or per origin?	Enrollment is at the site level.

Show Relevant Content & Ads

موضوعات

Feedback Theme	خلاصه	Chrome Response
کارایی	Performance concerns on the impact of Topics opt-in rate in the European Economic Area.	We would suggest to concerned stakeholders to contact your relevant Data Protection Authority about this issue. They are best placed to address such concerns and influence whether applications of privacy-enhancing technologies are incentivized by laws or instead treated like tracking, requiring the same approaches to consent. The latter could result in APIs like those in Privacy Sandbox not being available as often.
ثبت نام	Do downstream bidders need to enroll in Topics API to use Topics signals from upstream SSPs?	The downstream receivers of topics beyond the initial Topics API caller do not need to be enrolled, though many are likely to be enrolled for other API usage. A list of Privacy Sandbox enrollees will be provided programmatically as part of the program's transparency efforts, which would allow an interested caller of the Topics API to check if the recipient they are sending a topic to is enrolled, if the caller should want to.
Topics filtering	Request to apply another caller's filtering to the topics that they retrieve on the page, in order to share only what buyers are eligible to retrieve.	We are considering this request and welcome additional feedback from the ecosystem.
Site exclusion	Exclude websites from contributing to a user's Topics.	Topics are not called by default. It's important to note that no page content is taken into account when topics are selected, and all topics are curated to make sure they are not sensitive. A website can also restrict their site from being included in topic calculation via the following permission policy header: `Permissions-Policy: browsing-topics=()`
Topics observation	Allow publishers to give permissions for Chrome to classify topics based on page content (for example, head or body).	We previously considered offering functionality to classify sites into topics based on page content, and made the decision not to move forward based on privacy and security concerns. This proposal may mitigate some of those concerns, but it's unclear as to what extent. Due to the upcoming CMA experiment period, we don't expect this change to occur before 3PCD. We welcome additional feedback here .
Topics observation	Provide more fine-grained permission policies for publishers.	Providing more fine-grained permission policies for publishers would enable publisher sites to negatively impact the utility of the Topics API for the ecosystem as a whole, without it negatively impacting the utility of the Topics API for the site itself. Refer to the Update permissions policy to support separate permissions for retrieve and observe GitHub issue for a more detailed discussion of the topic.
Medical and Health Topics	Why does the Topics taxonomy not cover topics in Medical or Health categories?	Medical and health categories are considered sensitive topics and thus excluded from the Topics taxonomy.
Topics retrieval	Faster way for DSPs to get Topics without fetching using headers.	The header methods are more performant and less costly than creating a cross-origin iframe and making a `document.browsingTopics()` call from it. (A cross-origin iframe must be used for the call, because the top-level context to observe a topic must match the context from which topics are accessed.) This was discussed in detail here .
Topics retrieval	Requests to support passing Topics via headers on cross-origin script tag requests.	From a security perspective, this isn't possible. Each document and its execution environment are associated with a single origin–that of the document. Third-party subresources loaded and executed within that same environment are considered to be owned by the origin of the document. This is to prevent unconsented data leakage from one origin to another. An alternative is to provide a `browsingTopics` attribute on `<script>` tags. This should be clean from a security perspective, and not add additional latency. We are open to feedback from interested parties.
اطلاع	Improve public awareness of Topics API and how the API will be used.	We've engaged with the stakeholder who provided this feedback and this issue was resolved on GitHub . Going forward, we'll continue supporting ecosystem understanding of the API and we look forward to hearing views from stakeholders. In the meantime, we suggest stakeholders wanting to know more about the Topics API familiarize themselves with the documentation in the Chrome developer guide .
اطلاع	Notification to alert user when their Topics are being observed by a website.	We addressed this feedback on GitHub . Users can learn more about Topics controls in the Chrome help center .
فراگیری ماشین	How ML can be used to infer user Topics?	We are discussing this issue and welcome additional feedback .
Usefulness for different types of stakeholders	Smaller ad tech companies may not be able to observe Topics due to the way browsers calculate them.	Only ad techs that observed the user visit a page about the topic in question within the past three weeks will receive a topic. If the ad tech did not call the API in the previous three weeks for that user on a site about that topic, then the returned value will be empty. This feature means that ad techs whose services are used by a larger number of site owners, and therefore have more opportunities to observe a site visit by a given user, may receive more topics than other ad techs. This feature is essential for the privacy protections of the API as it limits the availability of information about a user to only those parties who are already able to observe the same underlying information (currently via third-party cookies).
XHR Request	When will Topics inclusion in `XMLHttpRequest` (XHR) requests be deprecated?	As Chrome announced in August 2023 , Chrome began deprecating support for XHR when transitioning from Origin Trial to General Availability. As the ramp-up of Topics progressed, XHR support was only included for users for whom the OT features were enabled and was fully deprecated when the individual OT experiment groups were merged. If you were using Topics with XHR, your sites will not break. The topics just won't be added to your XHR request headers. We recommend that you either transition to `fetch` for your request, use the iframe attribute, or use the JavaScript API to retrieve topics. Fetch is supported by all modern browsers, but not Internet Explorer or Opera Mini.
Taxonomy and classifier update process	More information on the Topics taxonomy and classifier release cadence and how companies can prepare for such updates.	Our response remains unchanged from Q2: As shared in the recent blog post , we expect the taxonomy to evolve over time, and for governance of the taxonomy to eventually transition to an external party representing stakeholders from across the industry. We also shared the ramp-up plan in the topics-announce group .
سو استفاده کردن	Potential attack via redirect chain.	We are considering this issue and welcome additional feedback.
Publisher Inventory Types	What types of publisher inventory will Protected Audience and Topics testing support?	Neither Protected Audience nor Topics are inherently restrictive in terms of the types of inventory they can be used on.
Ramp-up time	Recommend no ramp-up time for new taxonomies to get to 100%.	Following this feedback request from the ecosystem and discussion during PATCG meetings, we have announced our plan for the rollout of the new taxonomy .

Protected Audience API (formerly FLEDGE)

Feedback Theme	خلاصه	Chrome Response
Top-Level Auctions	Ability to use Google's publisher ad server without also giving Google Ad Manager control of the top-level Protected Audience API auction.	Response provided by Google Ad Manager: Google Ad Manager's plans for the Protected Audience API do not include supporting Google's publisher ad server without the control of the top-level Protected Audience auction, for the following reasons. In order to properly serve our customers in the publisher ad serving market, Google's publisher ad server needs to retain control of the top-level Protected Audience auction. As a publisher ad server, our role is to provide publishers forecasting so they can negotiate direct sold campaigns without overbooking, and to pace and deliver their direct reservations optimally. Doing this requires running the final auction to compare all eligible direct and indirect demand. Forecasting and pacing are core functionalities that publishers expect from an ad server. Without accurate forecasting, publishers may end up overselling their inventory, which puts their business reputation at risk. Pacing is also critical, as being unable to fulfill reservation contracts with advertisers also risks damage to the publisher-advertiser direct relationship, which could result in significant impact to a publishers business. In short, therefore, we do not view a publisher ad server's activity of running the top-level Protected Audience auction as distinct from the other activities of the publisher ad server.
`directFrom SellerSignals`	`directFrom SellerSignals` allows Google Ad Manager to prevent the publisher from seeing the price of its contextual auction.	Chrome response: Information passed into `runAdAuction()` is not known to come from the seller unless the seller calls `runAdAuction()` from its own iframe. In a multi-seller auction it becomes impossible to have all sellers create the frame calling `runAdAuction()` . `directFromSellerSignals` addressed this issue by loading content from a subresource bundle loaded from a seller's origin. This ensures that the authenticity and integrity of information passed into an auction from the seller-auctions configurations cannot be manipulated. If publishers want to use Protected Audience API to understand any of the information their technology providers are passing into Protected Audience auctions, they can ask those technology providers for this functionality. Response provided by Google Ad Manager: We have maintained a strong focus on auction fairness for years, including our promise that no price from any of a publisher's non-guaranteed advertising sources, including non-guaranteed line item prices, will be shared with another buyer before they bid in the auction, which we then later reaffirmed in our commitments to the French Competition Authority . For Protected Audience auctions, we intend to keep our promise by leveraging `directFromSellerSignals` , and not share the bid of any auction participant with any other auction participant prior to completion of the auction in multi-seller auctions. To be clear, we won't share the price of the contextual auction with our own component auction either, as explained in the Further clarify top-level auction dynamics update.
Information Exposure	Sensitive business logic and contractual details may be exposed by the browser.	The person using a web browser can see everything that is happening in the browser. When an ad auction happens inside the browser, it is true that the person whose browser it is could watch that auction take place, including seeing how much different parties choose to bid. Since a browser is the user's agent, we do not think it is possible or desirable to try to change this. Only the person using the browser has visibility into these operations, however. An on-device auction run using the Protected Audience API is not observable to any servers, including Google's.
`PerBuyerExperiment GroupId`	Current value range of `PerBuyerExperiment GroupId` could allow buyers to correlate the contextual data with the trusted server request.	Using the Protected Audience API in this way is inconsistent with Privacy Sandbox's mandatory attestation that API users will not try to circumvent the Privacy Sandbox protections. In the future, the requirement that key-value servers run in trusted execution environments (TEEs) will provide technical protection against this attack.
Same-origin policy	Relax the same-origin policy to allow for subdomains.	We are considering this request and welcome additional feedback from the ecosystem.
API versioning	Request for versioning and release notes for changes to the Protected Audience API.	We are considering this request and welcome additional feedback from the ecosystem.
Multi-SSP Auctions	Allow top-level auction signals to perform JSON merges with component signal `auctionSignals` .	We are considering this request and welcome additional feedback from the ecosystem.
Bid limit	Increase the limit on the number of ad components entering the bid from 20 to 40.	We are considering this request and welcome additional feedback from the ecosystem on why this would be useful.
(Also reported in previous quarters) Performance of Protected Audience Auctions	Report from testers that Protected Audience auctions have high latency.	On questions of latency, the Protected Audience API has generally followed the existing standard paradigm of building controls that let sellers decide how much time and resources the bidders can consume, and building tools that let buyers decide how to best use the resources available to them. These controls and tools are generally available today, but their full benefit will only be realized after adoption by buyers and sellers. In addition, Chrome continues to work on a variety of infrastructure improvements to auction speed ( crrev.com/1190815 , crrev.com/1199839 , crrev.com/1201837 , crrev.com/1198339 , crrev.com/1197323 ). We invite feedback on both halves of this latency effort: new tools that buyers and sellers would find useful, and reports of observed bottlenecks that Chrome engineers should investigate.
Buy-side filtering	Add support for buy-side filtering based on interest groups.	We have suggested several ways in which SSPs and DSPs could change their designs to handle this: Moving some work into the DSP's Key/Value server. SSPs creating some contextual signals and giving those to DSPs. SSPs caching contextual signals for DSPs.
Publisher Interest Group Control	Support for publishers seeking to delegate the use of publisher-created interest groups.	We have engaged in discussions with many parties about the request. We believe that all such use cases involved in "delegating" the publisher-created interest groups can be accommodated now, and furthermore that we should build additional support to make some use cases flow more smoothly in the future.
(Also reported in Q2) Trusted Execution Environments	Support for Trusted Execution Environments (TEE) in non-public cloud environments.	Our response is similar to previous quarters: While we are continuing to explore support for options beyond public cloud-based solutions, we have no current plans to support on-premise TEEs. At this stage, given Privacy Sandbox security requirements and the significant challenges presented by on-premise deployments, we believe that continuing to expand and improve cloud-based deployments (for example, supporting Google Cloud in addition to AWS) is the most beneficial for the زیست بوم. However, we welcome additional feedback on why such a requirement is necessary and feasible given the privacy and security constraints.
Trusted Execution Environment	Components in the TEE serving path, such as the load balancer, can observe all the traffic and have information of the IP address of each request.	Currently IP address is passed as a metadata in request headers to untrusted seller's ad service in the case of both Bidding and Auction and on-device Protected Audience auctions. Refer to Metadata forwarding for more information. In the long term, we plan to proxy ad tech and tracker traffic through an IP Proxy, which will prevent components from observing all the traffic in the serving path.
Time-to-Live (TTL)	Will the time-to-live (TTL) before services have to request new keys be set or is it intended to be flexible (or dynamic)?	The TTL is generally static. Currently, the TTL for the public is 8 days, and the rotation happens every 7 days; the TTL is also the same for private keys in the case of the Aggregation Service. In case of Bidding and Auction services, private and public keys are fetched every N hours in the non-request path and cached in-memory, so that there is no more than an N-hour delay between keys rotating and servers picking up these keys . The 1-day buffer between key rotation and expiry is to ensure that even if the key generation fails, the services can continue operating. We are considering extending the TTL to be more resilient for outages. In case of a key leak, we plan to manually force key generation and invalidate keys sooner. Note that public keys are cached on the clients, currently for 24 hours, again to ensure that in case of coordinator outage, the services can still operate.
شکل دهی ترافیک	Traffic Shaping support for Bidding and Auction Services.	Buyers can indicate, based on Publisher first party data or contextual data, demand for Protected Audience auctions. Sellers can do similar determinations as well in the seller's ad server or Ad Exchange server. The models can be trained on 1P data and any aggregate reports from Protected Audience auctions. Sellers can use this information to avoid sending requests to Bidding and Auction servers when there is no demand for Protected Audience auctions. We believe this can be an effective way to shape traffic.
Component Auction	What top level auctionSignals are shared with Component sellers?	Buyers in a component auction only receive signals from the component seller. We are looking to share documentation around the overall sequence of a combined auction with header bidding and Protected Audience auction soon.
Video Rendering	Support for video rendering using Protected Audience and Fenced Frames.	Protected Audience API supports video rendering using a mechanism that relies on iframes. However, we haven't yet designed a solution that is compatible with Fenced Frames, and this is one of the reasons we had decided to push back Fenced Frames enforcement to 2026. That means if a partner does decide to enforce Fenced Frames now, the support for video would be lacking for that partner.
Frequency capping	(Also reported in previous quarters) Per-user frequency controls within a campaign and ad group.	Our response is unchanged from the previous reports: Protected Audience will support frequency capping for on-device auctions and contextual and branding campaigns as well. Shared storage and site-specific caps can also be used for additional frequency capping controls.
Ad Preferences	Does Protected Audience provide a way to opt-out or blocklist by advertiser sites or a way to leave all interest groups from the same owner?	There are several ways for users to block access to the Protected Audience API and other Privacy Sandbox features.
Same-origin policy for source URL of bidding and auction scripts	Relax the requirement that all fields that specify URLs for loading scripts or JSON must be same-origin with the owner.	We are currently considering this request and welcome additional feedback from the ecosystem.
`forDebuggingOnly`	Potential for `forDebuggingOnly .reportAdAuctionWin` to be misused if it remains post 3PCD.	Over the past years we have been receiving feedback from the ecosystem regarding functionality gaps in Protected Audience once third-party cookies are deprecated, and we are working to formulate a plan to support them post 3PCD without compromising on the goals of Privacy Sandbox. We welcome any additional suggestions and feedback on missing functionality that the ecosystem would like to see.
Multiple Interest Groups	Use multiple interest groups in the same bid.	This is not supported in Protected Audience API today, as it would result in a change to the underlying privacy model. We welcome additional discussion here .
On-device auctions	Will Chrome on Android support on-device Protected Audience auctions?	Yes, on-device auctions will be supported in Chrome on Android.
(Reported in Q2 2023) Click-related data	Add click-related data to browserSignals.	We continue to evaluate this feature request and welcome additional feedback on why this should be prioritized.
Trusted Execution Environment providers	Are there material differences in the Trusted Execution Environment offerings of different cloud providers?	We are not aware of any major differences, but we recommend the ecosystem review the public deployment guides to see which solution best suits their needs. Google Cloud . AWS .
(Reported in previous quarters ) Support for negative Interest Group targeting	An API to support negative interest group targeting: showing ads only if a user does not belong to an interest group.	We are looking into implementing this feature and are discussing the request .
Content Violation	Support features that allow users to report bad ads served by Protected Audience API in Fenced Frames.	We believe that the existing Fenced Frame Ads Reporting mechanism offers good options for ad techs who want a user-generated "Bad Ads" reporting flow. This would allow bad ads reporting in a way essentially unchanged from the industry standard today. We welcome additional feature requests if any gaps remain, including during the time after third-party cookie removal but before Fenced Frame rendering becomes widespread.
Private Aggregation API Reporting	How can we calculate time the user has spent in that interest group?	In Chrome M116+ you should be able to use recency as defined pull/639 .
K-Anonymity server	More information on K-Anonymity server.	We shared more information on K-Anonymity servers here and welcome additional feedback.
Dynamic Creative URLs	Support for creative URLs without pre-declaration while still respecting k-anonymity.	We are discussing this feature request and welcome additional feedback on why this should be prioritized.
K-anonymity requirement	Will k-anonymity requirement on Interest Group updates be re-introduced?	We don't anticipate changes to the position stated in this GitHub post . As announced in that post, we decided to remove the k-anonymity requirement on Protected Audience interest group updates, which does not have a significant impact on the API's overall privacy protections, and we plan to consider other potential more direct protections (such as IP address privacy or a trusted update server) at a later date when the related technologies are more developed, deployed and adopted.
Bidding & Auction Services Beta Testing	When will Bidding & Auction Services Beta testing begin?	As stated in Timeline and roadmap , the first phase of Bidding and Auction Services testing begins in November 2023.
Roadblocking	Request to support Creative coordination for Ad Networks (SSP and DSP are in the same company or properties).	We appreciate the feedback for this use case and we're looking to understand whether more ad techs are interested in seeing this supported. We welcome additional feedback .
Native Advertising	Fenced Frame support for Native Advertising.	We are considering supporting the use case and are discussing possible workarounds and solutions .
K-anonymity	How can I maximize interest group ads that meet k-anon thresholds?	We have shared some tactical guidance on this topic .
POST support	Support for sending auction data via POST requests.	We are evaluating this feature request and welcome additional GitHub issue submissions on why this should be prioritized.
Reporting granularity	What is the reporting granularity of Fenced Frame ad reporting with Ads Composed of Multiple Pieces?	The current design does not allow capturing product ID or position as this may compromise user privacy. Only the `reserved.top_navigation` can be invoked, which would be sent when there is a user activation (such as a click) on the ad component fenced frame, which results in a top-level navigation.
Ad auction	Can an SSP participating in a component auction trigger another component auction itself?	A `componentSeller` cannot also include `componentAuctions` . The multi-seller auction only has two levels: 1. The component auctions in parallel. 2. The top-level auction (where the winning ad from each `componentAuction` competes).
Bidding & Auction Services availability	Will Bidding & Auction be available during the Chrome facilitated testing phase?	Bidding and Auction Server will not be available during the Chrome facilitated testing phase.
Bidding signals	Allow browsers to request and delete bidding signals.	We are discussing this request and welcome additional feedback on why this should be prioritized.
`generateBid()`	Ability to update interestGroup's `userBiddingSignals` through `updateURL` .	We are considering this proposal and welcome additional feedback and discussion.
Publisher Inventory Types	What types of publisher inventory will be supported by Protected Audience and TOPICS testing?	Neither Protected Audience nor Topics are inherently restrictive in terms of the types of inventory they can be used on.
Server-to-Server integration	Is direct integration between the SSP and DSP required for Protected Audience?	Direct integration between the SSP and DSP is not required if DSP does not need to process contextual signals in its own server in order to pass that processed information into its on-device bidding function.
A `bid_currency` field in B&A	Support for `bid_currency` field in Bidding and Auction Service.	B&A doesn't support a `bid_currency` yet, although we plan to support that by the end of January 2024. Refer to the timeline here .
`perBuyerSignals`	Is there a size limit for `perBuyerSignals` ?	There is no limit on the number of per-buyer signals, but sending too much data may have detrimental effects on the browser's performance.
Cross-site use cases	Can we use Protected Audience API interest groups across multiple websites?	Protected Audience is not designed for such use cases, as explained in turtledove/issues/282 .
Interest Group HTTP Requests	Include Interest Group Blob in the HTTP headers.	We are considering this request and welcome more feedback on this request.
Ad quality control	Loss of ad quality control related on cross-site information.	We are considering this feedback and welcome additional feedback .
Chrome DevTools	Outgoing Protected Audience network requests should be visible in the Chrome Developer Tools Network Tab.	We are working on enabling this functionality in the network tab and welcome additional feedback on why this should be prioritized.
Trusted Execution Environment	When will the details on which metrics are privacy-impacting (and their degree) be added to the explainer on Trusted Execution Environment monitoring?	We are in the process of updating the explainer with this information. The updated explainer will be available by November 2023.
`directFrom SellerSignals`	Why is `directFrom SellerSignals` not packaged as a web bundle?	We shared the rationale for this decision here .
Impression delegation	Is there any viable way to do impression delegation where the outcome of an interest group being selected is yet another targeting action?	Multiple nested auctions are not compatible with our privacy goals for two reasons. First, when the winner of an auction renders inside a Fenced Frame, our privacy goals for Protected Audience include the resulting creative rendering without knowledge of the context: the surrounding page's URL or first-party cookie are a privacy violation. In that environment, a nested auction is not viable. Second, the Protected Audience model says that each auction's winner should be based on data from just one additional site. Nested auctions would be a way to compound that, resulting in the possibility of choosing ads based on a many-site profile.
Data at Rest criterion	Explain further the Data at Rest criterion in the Key/Value service trust model.	Data in the Key Value Service is loaded into memory and served from there rather than doing any read-through caching.
Buyer Data Signal	Is there a defined size limit for the `buyer_data` signals received from the DSPs?	There are currently no browser imposed limits for `buyer_data` signals received from DSPs.

Measure Digital Ads

Attribution Reporting (and other APIs)

Feedback Theme	خلاصه	Chrome Response
Cross-device	Plan for cross-device support for Attribution Reporting API.	Cross-device presents new privacy challenges on top of 3PC and also adds technology distribution challenges given the range of devices and platforms a user might use. We are exploring potential solutions, but we are focused on the critical use cases currently supported by Attribution Reporting and do not have plans to introduce cross-device support before the removal of third-party cookies.
(Also reported in previous quarters) Trigger Data Size	Why is the trigger data size limited to 3 bits?	The size is limited to 3 bits and 8 distinct values to ensure that the amount of cross-site and cross-context information about a user is limited. We welcome ecosystem players to submit feedback on whether the current parametrization for event-level reporting is sufficient.
Conversion funnel	Report multiple domains that were used in conversion.	This use case is possible since the addition of multiple destinations . We welcome additional feedback .
Same domain in different country support	Does Attribution Reporting work with websites that have the same Domain but multiple country TLDs?	This issue has been discussed and resolved with the stakeholder that raised the question. If an ad tech needs to use multiple country TLDs they will need to have multiple enrollments, with one for each country TLD.
Protected Audience and Attribution Reporting	Can ad techs access both view-through conversions for Protected Audience auctions as well as click-through conversions for Attribution Reporting?	Yes, Privacy Sandbox should support both VTCs and CTCs within Protected Audience.
Agaggregatable report delays	Reduce aggregatable report delays further.	We have heard recent feedback regarding this and have shared ideas here . We welcome additional feedback from the ecosystem.
Agaggregatable report delays	Reducing delays via introducing server mediation.	We are considering this proposal and welcome additional feedback .
Event-level report delays	Reduce event-level report delays.	The full flexible event-level proposal, described in Flexible event-level configurations , can reduce event-level reporting delays down to 1 hour with a noise tradeoff.
Source reporting origin per source	Limitation of max source reporting origins per source reporting site prevents ad techs from registering sources from different reporting origins for a single publisher origin.	This has been discussed with the stakeholder that raised the issue and a potential solution of using 1 reporting origin per source-reporting site is being tested before trying other potential solutions involving redirects. We are open to any additional ecosystem feedback regarding this limit as well.
Issue reporting	How can we report errors or issues with the Attribution Reporting API to Chrome?	Currently we recommend ad techs report any Attribution Reporting API errors they may be facing as an Issue on GitHub. If they are facing a Chrome-related issue we recommend creating a Chromium bug. Links for how and where to flag any issues can be found in Engage and share feedback .
Deduplication	How can we deduplicate conversions across different pipelines and devices?	Deduplicating across devices and measurement pipelines is a known and current challenge that ad techs also face today with 3PCs. With the Attribution Reporting API, ad techs can decide when to register specific conversions and add specific metadata to indicate which measurement pipelines they have used to track the conversions (in other words, part of the aggregation key), which can be compared against other measurement pipelines. We are open to any additional ecosystem feedback regarding this.
Deduplication and Priority	Request to have priority first before deduplication.	We are considering this request and welcome additional feedback .
ضد تقلب	Risk of malicious user tampering the event-level data.	Report verification does not work for event-level reporting for the reasons described in Why doesn't this support event-level reports? .
Conversion type	How can we differentiate between view through and navigation in Attribution Reporting?	We have the following built-in filtering option: `source_type` . Additional details are available here .

Aggregation Service

Feedback Theme	خلاصه	Chrome Response
Budget recovery	Some ad techs have requested the ability to reprocess reports in cases where there are failures, errors, or deletions of their reports.	The team is exploring ways to address this in a privacy-preserving way.
Site enrollment	Multiple ad techs have requested support for processing multiple origins in the same account for use cases such as splitting data by Geo, advertiser. This behavior is also expected by ad techs given that the client API enrollment is now site-based (and not origin based). Migration from origin to site enrollment streamlines the ad tech onboarding process via consistency with the client enrollment process.	We will be launching migration from origin enrollment to site enrollment for the Aggregation Service soon and welcome feedback from the ecosystem .
Release & Deprecation Plan	Release and depreciation schedule for Aggregation Service features and patches published. The goal of the plan is to give ad techs visibility into our release policies to enable them to prepare for upcoming releases and deprecations, and ensure they run stable and secure versions of services.	We have recently published a proposal for the Aggregation Service release and deprecation plan and welcome additional feedback .
Coordinators	What happens if the coordinators go down on aggregation service?	Both coordinators need to be fully available for the system to function correctly. Short unavailability is accommodated with retries in our client libraries; longer unavailability of either of the two coordinators will have aggregation jobs fail. Jobs can be rerun if the budget for privacy isn't consumed yet. In the case where any service failure led to budget consumption without a summary report written to ad tech storage, we currently recommend they use debug reports to retrieve results using the local testing tool . We are also working on features to allow for budget recovery in the case of failures so ad techs can rerun their jobs.

Private Aggregation API

Feedback Theme	خلاصه	Chrome Response
Blob Url	Request to support Blob Url in Shared Storage.	Support for Blob Url has been added in Chrome M116.

Limit Covert Tracking

User Agent Reduction and User Agent Client Hints

Feedback Theme	خلاصه	Chrome Response
JavaScript API	Availability of the User Agent Client Hints JavaScript API.	There are no plans to remove this functionality as it is our core solution for partners who want to actively access the high-entropy data beyond what is available by default in the frozen and reduced UA.
Device and Form Factor information	Ability for websites to understand input, output, and other information the device visiting the website can support.	We have added support for this request following feedback from the ecosystem.

IP Protection (formerly Gnatcatcher)

Feedback Theme	خلاصه	Chrome Response
Eligible Third Party Traffic	What is "eligible third-party traffic" referring to in the explainer?	We understand the importance of this question and are actively working to identify which third-party traffic will be eligible and which will not. We welcome feedback on this topic.
Network Traffic Audits	Support for enterprises to perform network traffic audits for their networks.	Only third-party traffic embedded in first-party sites will be affected, which should limit the amount of traffic that requires filtering. Additionally, we plan to give users the option of whether or not to use IP Protection, and for enterprise-controlled Chrome, there will be enterprise policies to disable IP Protection. Finally, we're exploring what controls (if any) will be provided to network operators to disable IP Protection. We welcome feedback on this topic.
Access control	IP Protection may impact web services that use IP addresses for access control.	We understand the importance of anti-fraud use cases and the possible impact to those use cases. We are seeking ecosystem feedback on how we can better support anti-fraud use cases that typically have relied on IP addresses.
Communication between the 2-Hop proxies	How to ensure there is no information between proxies.	We are in the process of designing the proxy interactions. Our goal is to minimize the chances for such information sharing via business, process, and technical means.
Non-Google Authentications	Support for Non-Google Authentications.	We plan to publish more details about account authentication in the future, though we have shared some initial considerations .
Tracker classification	How will IP Protection determine what constitutes a tracker and its variants?	We understand the importance of this question and are actively working to identify which third-party traffic will be eligible and which will not. We welcome feedback on this topic.
تجزیه و تحلیل	IP Protection may impact the accuracy of analytics services.	We are looking to understand the impact of IP Protection further and welcome additional feedback and examples from the ecosystem.
پروکسی	If a user is using proxy or has manually defined a proxy, how will IP Mask work in this case?	We are looking to understand the impact that IP Protection may have on other proxies. We do not have any plans to share at the moment. We welcome feedback on this topic.
Premium offering	Will IP Protection be a paid feature?	IP Protection will be available to Chrome users as part of the core browser experience. It will not be a paid feature.
سرور پروکسی	Will the same proxy servers be used during user sessions?	An HTTP/S connection will use a single pair of proxies and will present a single masked IP address to the origin. Beyond that, there are no hard constraints on different HTTP/S connections having to use the same servers.
Platform support	On which platform will IP Protection be supported?	IP Protection will initially be available on Chrome for Android and Desktop. We continue to evaluate how to expand the protection to other platforms.
Opt-Out	Will users be able to disable IP Protection?	We plan to provide users the choice on whether they want to use IP Protection or not.
ناشناس سازی	What kinds of requests will be anonymized under IP Protection?	HTTP/S and DNS requests to eligible third-party domains are anonymized via the privacy proxies. We will provide additional details in an upcoming explainer on how we will determine which domains will be included. The rest of the traffic (for example, the rest of the DNS requests or other HTTP/S traffic) is unaffected.
Data Visibility	Network addresses may be accessed during the first hop in IP Protection.	In the two-hop proxy model, the first hop (controlled by Google) only sees the source client IP and a request to connect to the second hop, while the second hop (controlled by an external CDN) only sees a tuple on the first hop (proxy IP + port) and the destination IP. For the response back from the origin, the second hop is able to forward the response to the first hop proxy+port associated with the request and doesn't need to learn anything about the original client IP (and the first hop just returns the response to the client, without learning anything about the destination IP). In this way, the first hop only learns the client IP and the second hop, while the second hop only learns the destination IP.
WebView	Will IP Protection be available to Android WebView in the future?	We do not have any plans to share at the moment, but our vision is to provide this protection as broadly as possible.

Bounce Tracking Mitigation

Feedback Theme	خلاصه	Chrome Response
Interaction Tracking	How are user interactions tracked?	Bounce tracking mitigations track two types of user interactions: User activations as defined by the html spec . These are basically clicks, key presses, touch screen taps, etc. Successful webauth assertions. These are cases where a user taps a security key or uses a passkey as form of authentication These interactions are associated with the top-level site on pages where they occur. For example, if a user clicks in an embedded iframe the interaction is associated with the top-level site and not the embedded site. The interactions are stored in a database containing the schemeless etld+1 and the time of the interaction. Interactions protect the associated domain from bounce tracking mitigation state deletion for 45 days.
Allowlisted Exemptions	Can domains be exempted?	We are considering this request and we welcome additional feedback from the ecosystem .

Privacy Budget

No feedback received this quarter.

Strengthen cross-site privacy boundaries

Related Website Sets (formerly First-Party Sets)

Feedback Theme	خلاصه	Chrome Response
Centralized Approach	Concern over the centralized repository approach for managing Related Website Sets.	A public, easily accessible repository is key to the design of RWS as it provides accountability for submissions. Third-party cookie functionality is ultimately provided by the use of the Storage Access API or the rSAFor API, with RWS membership providing auto-granted access (as opposed to through prompts with the Storage Access API). We believe that an approach like the RWS submission process is an appropriate requirement for auto-granted third-party cookie access.
Renaming json file	With the change in API name, does the hosted JSON file name need to be changed?	Yes, the submission guidelines have been changed, and the primary domain must serve a JSON file at `/.well-known/related-website-set.json` . Existing sets in the RWS list do not need to be changed, but if there are modifications submitted to existing sets, the JSON file must be changed.
(Also reported in previous quarters) Domain Limit	Request to expand the number of associated domains	As announced in a blogpost on August 31, we have raised the associated domain limit to five domains following feedback from the ecosystem. We have decided to increase the associated domain limit to five domains (plus one primary domain) which best matches the most comparable implementation offered by another major browser.
Third Party Cookies	Will Related Website Sets only work with third-party cookies disabled?	Related Website Sets will work even when a user has not blocked third-party cookies; but there will be no observable effect since the relevant cookies are available without any need for Related Website Sets and Storage Access API.
Legitimate edits	How does the Related Website Sets repository prevent non-owners from modifying sets?	Per the submission guides , anyone can submit a PR on GitHub to edit the `first_party_sets.JSON` file. However, if the PR is approved (passes technical validations, and so forth), it will be manually merged in batches to the canonical FPS list once per week (Tuesdays at 12pm Eastern Time) by Google. If a bad actor tries to modify a set they don't own, it shouldn't be a problem since they won't be able to modify the `.well-known` files and therefore the validations will fail.
Domain hijacking	Domain hijacking may expose related domain data to unauthorized parties.	This is not possible, as discussed in this Protected Audience GitHub issue .

Fenced Frames API

Feedback Theme	خلاصه	Chrome Response
Content Violation	Allow users to report suspicious ads.	Suspicious ad reporting is not prevented by Fenced Frames. Users can still interact with the ad and report suspicious ads to the ad tech in the usual way.
Interaction with surrounding sites	Allow interaction with the surrounding or top-level website.	We are looking to understand why this request is necessary and welcome additional feedback from the ecosystem.
Native Advertising	Fenced Frame support for Native Advertising.	We are considering supporting the use case and are discussing possible workarounds and solutions .

Shared Storage API

Feedback Theme	خلاصه	Chrome Response
Cross domain	Allow communication across domains for local storage.	This use case is currently not in line with Shared Storage's privacy-preserving output gates but we welcome additional context as we evolve proposals for non-partitioned storage.
Blob Url	Request to support Blob Url in Shared Storage.	Support for Blob Url has been added in Chrome M116.

چیپس

No feedback received this quarter.

FedCM

Feedback Theme	خلاصه	Chrome Response
Third-party cookies	Is FedCM currently disabled if users enable "Block third-party cookies" in the Chrome settings"?	Yes, FedCM is currently disabled. For testing, we recommend that you additionally enable `chrome://flags/#fedcm- without-third-party-cookies` . We are looking to support FedCM without third-party cookies in the future.

Fight spam and fraud

Private State Token API (and other APIs)

Feedback Theme	خلاصه	Chrome Response
Token expiration	Once Google Chrome is uninstalled, will the Token be lost or will it be cached?	The token will be lost if the user uninstalls Google Chrome.
Token Information	How can issuers keep issued information within the Private State Token private?	Information is always kept private in the token and cannot be unencrypted by external parties that do not have the keys.
Error in demo	Error when trying to run the Private State Token demo.	We have updated the demo and it should be working correctly now.