گزارش بازخورد - 2024 Q2 و Q3

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

به‌عنوان بخشی از تعهدات خود به CMA، Google موافقت کرده است که گزارش‌های فصلی فرآیند تعامل با ذینفعان را برای پیشنهادات جعبه ایمنی حریم خصوصی خود به صورت عمومی ارائه کند (به پاراگراف‌های 12 و 17(c)(ii) تعهدات مراجعه کنید). در 22 ژوئیه 2024 گوگل اعلام کرد که کوکی های شخص ثالث (3PC) را در کروم منسوخ نخواهد کرد و در عوض پیشنهاد ارائه یک رویکرد به روز برای افزایش انتخاب کاربر را ارائه کرد. بنابراین، با موافقت CMA، Google گزارش عمومی سه ماهه دوم 2024 را به CMA ارسال نکرد تا زمان کافی برای Google و CMA در نظر گرفته شود تا پیامدهای اعلامیه Google را در نظر بگیرند.

این گزارش‌های خلاصه بازخورد جعبه ایمنی حریم خصوصی با جمع‌آوری بازخوردهای دریافتی توسط Chrome از منابع مختلف که در نمای کلی بازخورد فهرست شده است، ایجاد می‌شوند، از جمله اما نه محدود به: مشکلات GitHub، فرم بازخورد موجود در privacysandbox.com ، جلسات با سهامداران صنعت، و انجمن استانداردهای وب Chrome از بازخوردهای دریافتی از اکوسیستم استقبال می کند و به طور فعال در حال بررسی راه هایی برای ادغام آموخته ها در تصمیمات طراحی است.

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

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

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

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

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

آرا

Attribution Reporting API

چیپس

کوکی هایی که دارای حالت تقسیم شده مستقل هستند

DSP

پلتفرم سمت تقاضا

FedCM

مدیریت اعتبار فدرال

FPS

مجموعه های مهمانی اول

IAB

دفتر تبلیغات تعاملی

بیجاشدگان داخلی

ارائه دهنده هویت

IETF

کارگروه مهندسی اینترنت

IP

آدرس پروتکل اینترنت

openRTB

مناقصه در زمان واقعی

OT

آزمایش مبدا

PAT API

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

PatCG

گروه اجتماعی فناوری تبلیغات خصوصی

RP

حزب اتکا

RWS

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

SSP

پلت فرم سمت عرضه

TEE

محیط اجرای مورد اعتماد

UA

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

UA-CH

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

W3C

کنسرسیوم وب جهانی

WIPB

کوری IP ارادی

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

موضوع بازخورد	خلاصه	پاسخ کروم
منسوخ شدن کوکی های شخص ثالث (3PCD)	برنامه های گوگل برای 3PCD چیست و اثرات بلندمدت آن بر صنعت تبلیغات دیجیتال ارزیابی شده است؟	ما یک رویکرد به روز شده را پیشنهاد می کنیم که انتخاب کاربر را افزایش می دهد. همانطور که در اینجا ذکر شد، به جای منسوخ کردن 3PC، تجربه جدیدی را در Chrome معرفی می کنیم که به افراد امکان می دهد انتخاب آگاهانه ای داشته باشند که در سراسر مرور وب آنها اعمال می شود و آنها می توانند هر زمان که بخواهند این انتخاب را تنظیم کنند. ما در حال بحث در مورد این مسیر جدید با تنظیم‌کننده‌ها هستیم و قبل از اجرای این مسیر با صنعت درگیر خواهیم شد.
انتخاب کاربر	اعلام انتخاب کاربر بر علاقه اکوسیستم به اتخاذ راه حل های جعبه ایمنی حریم خصوصی تأثیر گذاشته است. بازخورد متفاوتی در مورد اعلام انتخاب کاربر وجود دارد، از جمله درخواست‌هایی برای ویژگی‌هایی مانند قابلیت‌های نظارت.	با رویکرد به روز شده که انتخاب کاربر را افزایش می دهد، برای توسعه دهندگان مهم است که جایگزین هایی برای افزایش حریم خصوصی برای شناسه های متقابل سایت داشته باشند. در حالی که ما هنوز جزئیاتی برای به اشتراک گذاشتن در مورد ظاهر تجربه جدید نداریم، انتظار داریم ترافیک بدون کوکی در Chrome افزایش قابل توجهی داشته باشد. این بدان معنی است که Privacy Sandbox API برای مشاغل حیاتی است. ما به سرمایه گذاری در فن آوری های Privacy Sandbox برای بهبود بیشتر حریم خصوصی و ابزار ادامه خواهیم داد.
رابط کاربری انتخاب کاربر	سؤالاتی در مورد جدول زمانی ویژگی‌های انصراف/رضایت، نوع گزینه کاربر در نظر گرفته شده، و اینکه چگونه رابط کاربری بر محیط‌های آزمایش خودکار تأثیر می‌گذارد.	در حال حاضر به‌روزرسانی‌های جدول زمانی برای اشتراک‌گذاری نداریم. وقتی تصمیم گرفتیم 3PCD را دنبال نکنیم، می‌خواستیم در اسرع وقت یک به‌روزرسانی برای اکوسیستم ارائه کنیم. به محض اینکه یک به‌روزرسانی در جدول زمانی برای انتخاب کاربر به اشتراک بگذاریم.
تست کروم	درخواست برای ادامه در دسترس بودن برچسب‌های آزمایش کروم برای سنجش پذیرش بازار و تأثیر اقتصادی 3PCD پس از نیمه اول 2024.	ما می‌دانیم که آزمایش‌کنندگان می‌خواهند به استفاده از گروه‌های مرورگر برچسب‌دار برای آزمایش و هماهنگی ادامه دهند، حتی با پایان یافتن آزمایش 1H 2024 با تسهیل کروم. ما در حال ارزیابی مراحل بعدی برای برچسب ها با توجه به اعلام انتخاب کاربر هستیم. در همین حال، تیم کروم قصدی برای گسترش پشتیبانی از گروه‌های مرورگر برچسب‌دار از طریق Chrome Milestone 132 منتشر کرده است که تا ژانویه 2025 اجرا می‌شود.
جعبه ایمنی حریم خصوصی در اندروید	Privacy Sandbox در Android و Privacy Sandbox در Chrome به طور جدایی ناپذیری به هم مرتبط هستند و ما نمی‌توانیم Privacy Sandbox را بدون Android به درستی ارزیابی کنیم. سفر معمولی مشتری، که شامل جنبه‌های بین دستگاهی و چند لمسی است، هم برای Privacy Sandbox در Chrome و هم برای Privacy Sandbox در Android بسیار مهم است.	لطفاً توجه داشته باشید که جعبه ایمنی حریم خصوصی در Android در محدوده تعهدات Google به CMA نیست. اگر بازخورد مختص جدول‌های زمانی Android و عرضه است، ما در حال حاضر هیچ به‌روزرسانی دیگری برای اشتراک‌گذاری نداریم، مگر اینکه همچنان به پیشرفت در Android ادامه دهیم، که آن را به عنوان یک جریان کاری مستقل برای بهبود حریم خصوصی در نظر می‌گیریم. همانطور که قبلاً اشاره کردیم، در دسترس بودن Privacy Sandbox API در اندروید نیز بر اساس نرخی که کاربران دستگاه‌های خود را به‌روزرسانی می‌کنند، تعیین می‌شود که در کنترل Google نیست.
حالت B ترافیک محدود است	ترافیک حراج آگهی موجود از حالت B کمتر از حد انتظار بوده است.	دلایل متعددی وجود دارد که چرا حجم حراج برای API مخاطب محافظت شده (PA API) ممکن است کمتر از حد انتظار باشد، به عنوان مثال: - شرکت‌هایی که می‌دانیم چه کسانی PA API را یکپارچه کرده‌اند، فقط قالب‌های بنر را شامل می‌شوند. - پلتفرم های سمت فروش ممکن است همیشه حراج را راه اندازی نکنند. - ممکن است یک مرورگر دارای گروه های علاقه (IG) نباشد. - ممکن است هیچ پیشنهادی وجود نداشته باشد. با این حال، ما از کسی که تلاش کرده است PA API را آزمایش کند و هیچ ترافیکی دریافت نکرده است، بی اطلاع هستیم.
دید قطعی	مشاهده قطعی ها و مشکلاتی که بر روی APIهای Privacy Sandbox تاثیر می گذارد.	یک صفحه وضعیت عمومی برای APIهای Privacy Sandbox وجود دارد که خدماتی خارج از مرورگر دارند. تیم Chrome بالاترین اولویت را بر قابلیت اطمینان پلتفرم ما و همه APIهای مهمی که توسط سایت‌ها و سرویس‌های اصلی در سراسر وب استفاده می‌شوند، از جمله فناوری‌های جعبه ایمنی حریم خصوصی می‌دهد. تاکنون تنها یک مورد قطعی وجود داشته است. این مربوط به یک پیکربندی موقت برای آزمایش در 1٪ بود. به زودی پیکربندی آزمایشی مربوط به این قطعی دیگر مورد نیاز نخواهد بود، بنابراین ما مطمئن هستیم که پس از فعال شدن APIها به روش عادی در Chrome، این مشکل رخ نخواهد داد.
مطالعه نمودار کوکی	دیدگاه کروم در مورد روش CookieGraph همانطور که در این مقاله در چارچوب Privacy Sandbox توضیح داده شده است چیست؟	این مقاله نکات جالبی را در مورد تشخیص و شیوع کوکی‌های شخص اول (1P) که توسط دامنه‌هایی متفاوت از دامنه‌های بازدید شده توسط کاربر تنظیم شده است، بیان می‌کند. همانطور که مقاله اشاره می کند، این کوکی ها برای جمع آوری تجزیه و تحلیل و اطلاعات نحوه تعامل کاربران با یک وب سایت بسیار مفید هستند. این داده ها برای توسعه دهندگان بسیار مهم است تا تجربه مرور بهتری را در اختیار کاربران قرار دهند. استدلال اصلی مقاله ناقص است زیرا کوکی‌های 1P را یک بردار ردیابی متقابل سایت می‌داند. با این حال، این تنها تحت مفروضات بسیار تهاجمی که در مقاله ذکر شده است صادق است: کاربران مایلند PII خود را با سایت به اشتراک بگذارند. دستگاه ها دارای اثر انگشت پایداری هستند که می توان از آن برای ردیابی کاربر در سراسر سایت ها استفاده کرد. توجه داشته باشید که اینها بردارهای شناسایی مجدد هستند که می‌توانند بدون استفاده از کوکی‌های 1P (مثلاً از طریق اشتراک‌گذاری داده‌های سمت سرور) مورد سوء استفاده قرار گیرند و باید جدا از تلاش فعلی ما که بر مکانیسم‌های ردیابی مبتنی بر حالت متمرکز است، مقابله کرد. مثل 3 عدد در نهایت، می‌خواهیم به این نکته اشاره کنیم که این مقاله، کوکی‌های تحلیلی و تبلیغاتی را با کوکی‌های ردیابی و کوکی‌های کاملاً ضروری معادل کوکی‌های غیر ردیابی می‌داند که ممکن است لزوماً چنین نباشد. در واقع، تجزیه و تحلیل 1P یا سرویس‌های فروشنده تقسیم‌بندی شده به سایت مانند ویجت‌های مکان یاب فروشگاه، ویجت‌های چت یا کوکی‌های متعادل کننده بار اغلب ممکن است فقط به یک دامنه محدود شوند و برعکس، برخی از کوکی‌های کاملا ضروری ممکن است ردیابی بین سایتی برای مبارزه با تقلب باشند. اهداف
تغییرات UX	تغییرات UX در Chrome 112 که کنترل‌های کوکی 1P را در بخش «داده‌های سایت روی دستگاه» تنظیمات Chrome قرار می‌دهد، می‌تواند مسدود کردن همه کوکی‌ها را برای کاربران دشوارتر کند.	این تغییر به عنوان بخشی از تلاش برای جداسازی و ارتقاء کنترل‌های 3PC (یا ذخیره‌سازی پارتیشن نشده) از انواع دیگر داده‌های سایت انجام شد. کنترل‌های 3PC تحت پانل حریم خصوصی و امنیت بالا می‌روند. در حالی که کنترل‌های کوکی‌های 1P و سایر انواع داده‌های سایت - که عملکرد حیاتی سایت معمولاً به آن بستگی دارد - در "داده‌های سایت روی دستگاه" دسته‌بندی می‌شوند. ما به نظارت برای بازخورد در مورد این موضوع ادامه خواهیم داد، اما معتقدیم که جداسازی فعلی تعادل خوبی بین قابلیت کشف کنترل‌های حریم خصوصی معنادار و حفظ یک تجربه مرور کاربردی ایجاد می‌کند.
صورتحساب و پرداخت	صورت‌حساب‌ها و پرداخت‌ها به‌طور کامل مورد آزمایش قرار نمی‌گیرند، زیرا آزمایش‌کنندگان بیشتر روی آزمایش سایر حوزه‌های APIهای Privacy Sandbox سرمایه‌گذاری می‌کنند.	زمان و آنچه که توسعه دهندگان و شرکت ها برای آزمایش انتخاب می کنند، انتخاب آنهاست. APIها عموماً برای آزمایش در دسترس هستند و از سپتامبر 2023 وجود دارند.
تست کردن	تمام ترافیک آزمایشی که DSP ها از SSP دریافت می کنند برچسب گذاری نمی شوند. برخی از DSPها ارائه کرده‌اند که سهم برداشت‌های تجربی بدون برچسب ممکن است در گروه‌های درمان و کنترل متفاوت باشد.	Chrome نمی‌تواند کنترل کند که آیا شرکت‌ها برچسب‌ها را در درخواست‌های پیشنهادی ارسال می‌کنند یا خیر. ما روشی برای دریافت برچسب از مرورگر ارائه می دهیم. سپس این به اکوسیستم بستگی دارد که اگر شرکای آنها نمی توانند مستقیماً آن برچسب ها را بخوانند، برچسب ها را به شرکا منتقل کند.
3PCD در Android WebView	درخواست راهنمایی در مورد فعال کردن پرچم "Test Third Party Cookie Phaseout" در Android WebView برای آزمایش منسوخ شدن.	3 رایانه شخصی به طور پیش فرض در WebView Android مسدود شده اند.
حریم خصوصی متفاوت برای کاهش خطرات در آموزش مدل	چرا از Privacy Differential در آموزش مدل استفاده می شود؟	حریم خصوصی دیفرانسیل، همراه با محیط های اجرایی مورد اعتماد (TEEs)، در آموزش مدل برای جلوگیری از نشت داده ها و ایمن سازی اطلاعات حساس در برابر تهدیدات ضروری است. این رویکرد تضمین می‌کند که وزن مدل نمی‌تواند داده‌های فردی کاربر را آشکار کند.

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

موضوع بازخورد	خلاصه	پاسخ کروم
ثبت نام	درخواست توضیح در مورد نحوه عملکرد ثبت‌نام گواهی بین مبدأ ثبت‌شده در مقابل مبدأ فناوری تبلیغات با زیردامنه www.	فناوری تبلیغات فقط باید در https://example.com نصب شود. وقتی آنها گواهینامه خود را در https://example.com/.well-known/privacy-sandbox-attestations.json قرار می دهند، https://www.example.com تحت پوشش قرار می گیرد زیرا یک زیر دامنه است.
مشخصات API	پیشنهاد برای افزودن یک طرح JSON برای فایل گواهی به مخزن.	ما در حال ارزیابی این پیشنهاد هستیم و از بازخورد اضافی در اینجا استقبال می کنیم.

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

موضوعات

موضوع بازخورد	خلاصه	پاسخ کروم
موضوعات وزن	مهمترین چیزی که در Topics باید فهمید، نادر بودن یک سیگنال مشخص است. طراحی فعلی باید به گونه ای تکامل یابد که امکان افزودن یک مقدار وزن در کنار هر موضوع مشاهده شده را فراهم کند. وزن، وزن نسبی یک موضوع معین برای یک مرورگر در مقایسه با تمام مرورگرهایی است که از آن موضوع استفاده می کنند.	ما می خواهیم بیشتر بدانیم که چرا نادر بودن یک سیگنال مهم ترین سیگنال است. ما از بازخورد اضافی از اکوسیستم در مورد کاربرد این مورد استفاده در اینجا استقبال می کنیم.
موضوع ها قابلیت اطمینان	گوگل باید تضمین های قوی تری در مورد قابلیت اطمینان موضوعات در طول زمان ارائه دهد.	تغییرات در API های ما همچنان بر اساس بازخورد اکوسیستم انجام می شود و قبل از تغییرات به طور عمومی مورد بحث قرار می گیرد. پیشنهاد ما برای ساختار حکمرانی تجدیدنظر شده تضمین های بیشتری را ارائه می دهد.
طبقه بندی کننده	سایت‌های ناشران معمولاً به اشتباه طبقه‌بندی می‌شوند یا موضوعات بسیار سطح بالایی به آنها اختصاص داده می‌شود که نمی‌توانند اهداف معنی‌داری داشته باشند.	همانطور که در توضیح ما در مورد طبقه‌بندی موضوعات ذکر شد، سایت‌ها از طریق ترکیبی از فهرست نادیده گرفته شده توسط انسان، شامل محبوب‌ترین سایت‌ها، و یک مدل یادگیری ماشینی روی دستگاه، طبقه‌بندی می‌شوند. Chrome به ارزیابی گزینه‌های سایت‌ها برای مشارکت در طبقه‌بندی موضوعات ادامه می‌دهد. هر گونه بهبود ابزار باید با خطرات حریم خصوصی و سوء استفاده سنجیده شود. به عنوان مثال، چند مورد از خطرات عبارتند از: - سایت هایی که از خود برچسب گذاری به عنوان روشی برای رمزگذاری معانی مختلف (و بالقوه حساس) در موضوعات استفاده می کنند. و - سایت هایی که به موضوعات حمله می کنند تا مفید بودن آن را برای دیگران کم رنگ کنند (به عنوان مثال، ارسال هرزنامه به موضوعات کاربر با نویز بی معنی). عموم می توانند این اجزا را با ابزار موجود از طریق chrome://topics-internals یا این colab بازرسی کنند. از طریق آزمایش، ما انتظار داریم که طبقه بندی در طول زمان بهبود یابد و از بازخورد نمونه هایی از سایت هایی که ممکن است به اشتباه طبقه بندی شوند استقبال می کنیم.
سوال API	نگرانی از اینکه Topics API مزایای مداوم و ضدرقابتی به SSPهایی که از محتوای بد کسب درآمد می کنند، می دهد.	مانند 3PCها، مرورگر تا زمانی که آن موجودیت ثبت شده و تأیید شده باشد، به کسانی که موضوعات را به آنها برمی گرداند، ناشناس است.
(در فصل های گذشته نیز گزارش شده است) مفید بودن برای انواع مختلف ذینفعان	از آنجایی که طبقه‌بندی‌کننده Topics در حال حاضر فقط از نام میزبان صفحه برای تعریف موضوعات مربوطه استفاده می‌کند، سایت‌های بزرگ با محتوای متنوع موضوعات عمومی را ارائه می‌کنند در حالی که سایت‌های کوچک موضوعات خاص با ارزش تبلیغاتی بیشتری را ارائه می‌کنند.	پاسخ ما مشابه فصل های قبل است: همانند 3PCها، تفاوتی در ارزش اطلاعات ارائه شده توسط سایت های مختلف وجود دارد. سایت‌های با علاقه در ارزش خود متناقض هستند: همه سایت‌های با علاقه دارای زمینه تجاری با ارزش نیستند و بنابراین ارزش کمتری دارند. اینها سایت هایی هستند که از Topics API بهره مند می شوند. ما امکان طبقه‌بندی در سطح صفحه را به جای طبقه‌بندی در سطح سایت در نظر گرفته‌ایم، با این حال، تعدادی از نگرانی‌های مهم حریم خصوصی و امنیتی با چنین طبقه‌بندی وجود دارد.
طبقه بندی کننده	به سایت‌های کوچک‌تر اغلب طبقه‌بندی نادرست یا بدون طبقه‌بندی اختصاص داده می‌شود، بنابراین نمی‌توانند در تبادل ارزش شرکت کنند.	با توجه به آسیب‌های احتمالی، سایت‌های خاصی که به طور بالقوه به اشتباه طبقه‌بندی شده‌اند، بیشتر از سایت‌های دیگر آسیب نمی‌بینند، با توجه به اینکه اطلاعات متنی یک سایت همیشه برای مزایده‌ها در سایت آن‌ها در دسترس خواهد بود، که حتی در این مورد، اطلاعات قابل مقایسه با موضوع صحیح را ارائه می‌کند. از طبقه بندی اشتباه موضوعات معمولاً برای جمع‌آوری اطلاعات تبلیغاتی مفید بالقوه از وب‌سایت‌های خارجی، به جای سایت‌های خودشان استفاده می‌شوند.
نسخه تاکسونومی	چگونه می توانیم به نسخه طبقه بندی دسترسی داشته باشیم تا از سازگاری با عقب اطمینان حاصل کنیم؟	نسخه تاکسونومی بخشی از هدر درخواست است که با یک درخواست واکشی با قابلیت موضوع ارسال می شود. برای مثال، اگر سرصفحه "(1 2);v=chrome.1:2:5, ();p=P000000000" باشد، نسخه chrome.1:1:2 است. جایی که chrome.1 نسخه پیکربندی، 2 نسخه طبقه بندی و 5 نسخه مدل است. این در مشخصات توضیح داده شده است و همچنین به توضیح اضافه شده است.
داده های موضوعات	درخواست توضیح درباره نحوه به‌روزرسانی داده‌های Topics.	به روز رسانی طبقه بندی مشخص نشده است. این به فروشندگان مرورگر انعطاف پذیری در پیاده سازی می دهد. با این اوصاف، در اینجا اکتشافی به‌روزرسانی طبقه‌بندی کروم از V1 به V2 آمده است: - یک درخت طبقه بندی واحد برای موضوعات V1 و V2 حفظ می شود. - شناسه موضوع یکسان نشان دهنده همان معنی است. - درخت فقط رشد می کند - اضافه کردن موضوعات یا اتصالات جدید، هرگز کوچک نمی شود. - با این حال، برخی از موضوعات یا پیوندها ممکن است در یک نسخه "غیرفعال" باشند که می تواند تصور حذف یا سازماندهی مجدد را ایجاد کند. مثال ها: - "Pickup Trucks" اکنون "Trucks, Vans & SUVs" را به عنوان والدین واسطه دارد. - «مطالعه زبان خارجی» اکنون «آموزش» را به عنوان والدین دوم دارد و «مرجع» مادر اصلی آن غیرفعال می شود. تأثیر موضوعات "غیر فعال": از این موضوعات برای طبقه بندی جدید استفاده نمی شود. با این حال، هنوز هم هنگام اجرای بلوک‌های کاربر در نظر گرفته می‌شوند: اگر کاربری موضوعی را در V1 مسدود کند، فرزندانش در V2 مسدود می‌مانند (حتی اگر موضوع فرزند تحت والد دیگری در V2 ظاهر شود).
طبقه بندی کننده	به دنبال درک علل و هر گونه گزینه اصلاحی موجود در مورد طبقه بندی های اشتباه است.	ابتدا، مایلیم به این نکته اشاره کنیم که تعیین موضوعات یک سایت توسط کروم صرفاً به عنوان ورودی الگوریتم موضوعات آن برای تعیین علایق کاربر برای اهداف تبلیغاتی است. برای مقاصد طبقه بندی کلی تر توسعه داده نشده است. ما به دقت کلی مدل طبقه‌بندی خود علاقه‌مندیم و سعی می‌کنیم تا جایی که ممکن است دقت/یادآوری آن‌ها را بهبود ببخشیم، اما در سطح جهانی برخلاف سطح طبقه‌بندی سایت فردی. این به این دلیل است که طبقه‌بندی اشتباه، زمانی که اتفاق می‌افتد، به سایت فردی که به اشتباه طبقه‌بندی شده است آسیبی نمی‌رساند، بلکه کیفیت سیگنال موضوعات را هنگام انتخاب یک آگهی در سایت‌های دیگر کاهش می‌دهد. هنگام انتخاب تبلیغات در سایتی که به اشتباه طبقه بندی شده است، موضوعات واقعی سایت از قبل برای آن سایت شناخته شده است و می تواند به عنوان ورودی برای جستجوهای تبلیغاتی استفاده شود. ما از بازخورد اضافی در اینجا استقبال می کنیم.
تست API	آیا موضوعات و به طور کلی Privacy Sandbox API با Chromium قابل آزمایش است؟	Topics API با Chromium ارسال نمی‌شود، بلکه با Chrome ارسال می‌شود.
موضوع تماس گیرنده	درخواست بهبود ارزش افزوده موضوعات با استفاده از خدمات TEE برای فناوری های تبلیغاتی برای پشتیبانی از هزینه تجزیه و تحلیل پیشرفته به روش های منطبق با حریم خصوصی.	ما در اینجا به بازخوردهای مشابه پاسخ داده ایم. ما فرکانس معکوس را در نظر گرفتیم و در نهایت پس از مدل‌سازی فرکانس معکوس متوجه شدیم که با ارزش موضوع مطابق با ارزش ارائه شده توسط خریداران و فروشندگان، همبستگی خوبی ندارد. ما از بازخورد اضافی در اینجا استقبال می کنیم.
مشخصات API	آیا تنظیمات همگروهی علاقه مرورگر می‌تواند موضوعات API را مسدود کند؟	ما در اینجا به این بازخورد پاسخ داده ایم. Topics API تکامل یافته FLoC است و خط مشی مجوزهای FLoC را رعایت می کند. همانطور که در توضیح توضیح داده شده است: "توجه: Permissions-Policy قدیمی: interest-cohort=() از FLoC نیز محاسبه موضوع را ممنوع می کند."
رتبه بندی موضوعات	آیا هنگام دریافت «5 موضوع برتر»، تعداد بازدیدهای وب‌سایت را بر اساس هر تماس‌گیرنده واجد شرایط محاسبه می‌کنیم یا همیشه بر اساس کل تاریخچه بازدید مرورگر محاسبه می‌شود؟ علاوه بر این، آیا موضوعات برای هر تماس‌گیرنده جداگانه رتبه‌بندی می‌شوند؟	این بر اساس فراوانی زیرمجموعه‌ای از تاریخچه‌های مرور است. ورودی تاریخچه مرور (یک صفحه) فقط در صورتی واجد شرایط شرکت است که صفحه حداقل یک تماس گیرنده موضوعات داشته باشد. جزئیات بیشتر در مورد ذخیره تاریخچه موضوعات در اینجا موجود است. همانطور که در اطلاعیه ما در مورد پیشرفت‌های Topics API آمده است، رتبه‌بندی به فرکانس و همچنین به سطح اولویت باینری بستگی دارد (برای جزئیات بیشتر اینجا و اینجا را ببینید). با این حال، به فرکانس تماس گیرندگان بستگی ندارد. لطفاً توجه داشته باشید که این بدان معنا نیست که همه تماس‌گیرندگان می‌توانند همه 5 موضوع برتر را در دوره بعدی دریافت کنند. همانطور که در توضیح آمده است "تنها تماس گیرندگانی که کاربر را مشاهده کرده اند که در سه هفته گذشته از سایتی در مورد موضوع مورد نظر بازدید کرده اند می توانند موضوع را دریافت کنند." مرورگر باید ردیابی کند که کدام تماس گیرنده کدام 5 موضوع برتر را مشاهده کرده است (مطابق با 5 موضوع برتر با دامنه تماس گیرنده در مشخصات). ما از بازخورد اضافی در مورد این موضوع در اینجا استقبال می کنیم.

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

موضوع بازخورد	خلاصه	پاسخ کروم
(در فصل های گذشته نیز گزارش شده است) هزینه ها	اجرای TEE ها در ابرهای عمومی در مقایسه با مراکز داده فناوری تبلیغات داخلی گران تر است؟	مدل امنیتی TEE فعلی ما از شیوه‌های پیاده‌سازی ابر عمومی بهره می‌برد (جزئیات بیشتر را در توضیح الزامات TEE ابر عمومی ببینید). به عنوان مثال، TEE های مبتنی بر سخت افزار فعلی در برابر همه حملات فیزیکی دفاع نمی کنند. ارائه دهندگان ابر عمومی پشتیبانی شده فعلی ما، AWS و GCP، اقدامات کاهشی را برای خطرات دسترسی فیزیکی، از جمله کارمندان، طراحی و اجرا کردند. در حالی که برخی از فناوری‌های تبلیغاتی به ما اشاره کرده‌اند که اجرای سرویس‌های ابری گران‌تر از مراکز داده فناوری تبلیغات داخلی است، سایر فناوری‌های تبلیغاتی روی ابرهای عمومی اجرا می‌شوند، خواه به دلیل هزینه یا مزایای دیگر. ما همچنان به ارزیابی گزینه‌ها برای گسترش پشتیبانی TEE، از جمله خارج از ابرهای عمومی، ادامه می‌دهیم. به عنوان بخشی از آن، ما در حال تحقیق در مورد مراکز داده داخلی هستیم و با اکوسیستم درگیر هستیم تا راه حل های بالقوه برای ارائه چنین پشتیبانی را بررسی کنیم. در این مرحله کنونی از تحقیقات، نمی‌توانیم تضمین کنیم که این امر منجر به راه‌حلی قابل اجرا برای اکوسیستم خواهد شد.
PA API و Google Ad Manager (GAM)	GAM قادر به دستیابی به یک نتیجه بازار منصفانه نیست. GAM نمی تواند تبلیغات را به موقع ارائه کند، گزارش می دهد که چند تبلیغ با استفاده از PA API ارائه شده است، و قابلیت پیکربندی در مورد اینکه کدام روش را برای ارائه یک تبلیغ انتخاب می کند، به عنوان مثال با خاموش کردن PA API برای اسلات های خاص، ارائه نمی دهد.	پاسخ مدیر تبلیغات گوگل: GAM روی بهینه‌سازی تأخیر هنگام ارائه تبلیغات از طریق API PA کار می‌کند و به کار خود ادامه می‌دهد تا درآمد اضافی ناشر از تقاضای PA API بیشتر از هزینه‌های متحمل شده به دلیل تأخیر اضافی حراج PA API باشد. آزمایش اولیه ما نشان می‌دهد که ناشران سود خالص درآمدی از PA API در ترافیک بدون 3PC می‌بینند، که نشان می‌دهد تقاضای اضافی از PA API بیشتر از هزینه‌های ناشی از تأخیر است. جزئیات بیشتر در مورد رویکرد ما را می توان در سؤالات متداول ما یافت. به‌علاوه، GAM به ناشران گزارش‌هایی درباره تبلیغات ارائه‌شده از طریق API PA ارائه می‌دهد. این شامل آگهی‌هایی می‌شود که وقتی GAM یک فروشنده مؤلفه است، و آگهی‌هایی که از طریق سایر فروشندگان مؤلفه ارائه می‌شوند وقتی GAM یک فروشنده سطح بالا است. جزئیات بیشتر در مورد گزارش را می توانید در مرکز راهنمایی ما بیابید. در نهایت، GAM به ناشران اجازه می دهد تا از طریق یک کنترل درون UI، استفاده از PA API را در ترافیک خود فعال یا غیرفعال کنند (برای جزئیات به مرکز راهنمای ما مراجعه کنید). ما آماده در نظر گرفتن بازخورد در مورد کنترل‌های بیشتری هستیم که ممکن است ناشران بخواهند و هر گونه درخواست ویژگی را مطابق با فرآیند اولویت‌بندی ویژگی استاندارد خود اولویت بندی می‌کنیم.
PA API & GAM/AdX	به نظر می‌رسد Google موضعی اتخاذ کرده است که به سادگی هیچ گونه برداشت API PA را که GAM تصمیم نهایی را برای فروش نمی‌گیرد، خریداری نمی‌کند، دقیقاً مانند AdWords که فقط از خانه خرید می‌کند. به نظر می‌رسد که این صرفاً سوءاستفاده از موقعیت بازار است، زیرا GAM/AdX می‌تواند یک پیکربندی حراج مؤلفه را مانند هر صرافی دیگری به یک فروشنده سطح بالای جایگزین ارائه دهد.	پاسخ مدیر پلتفرم تبلیغات گوگل: این موضع گوگل نیست. پلتفرم‌های خرید Google (Google Ads و DV360) از صرافی‌های غیر Google بازدید می‌کنند. این هم برای نمایش‌های API PA و هم برای نمایش‌های API غیر PA صادق است.
واکنش بازار	نگرانی های موزیلا: مخاطبان محافظت شده Google بیش از اینکه از شما محافظت کند از تبلیغ کنندگان (و Google) محافظت می کند .	ما از ارزیابی موزیلا قدردانی می کنیم و به تعامل با بازخورد موزیلا در انجمن های استانداردهای عمومی ادامه خواهیم داد. موضوع ارزیابی آنها این است که اجرای فعلی PA API هنوز همه حفاظت های برنامه ریزی شده را اعمال نمی کند . رویکرد ما به بازار با PA API به دنبال ایجاد تعادل مناسب بین تشویق پذیرش و اجرای حفاظت از حریم خصوصی در اسرع وقت است. به عنوان بخشی از این، ما یک نقشه راه برای اعمال محدودیت‌های حریم خصوصی در طول زمان ایجاد کرده‌ایم تا ادغام با APIها را بهتر تسهیل کنیم و همچنین به ما فرصت دهیم تا بازخورد بیشتری را جمع‌آوری کنیم که می‌توانیم آن را در حفاظت‌های آینده بگنجانیم (مانند ویژگی‌های VAST در قاب های حصاردار). ما همچنین از ارتباطات اخیر موزیلا در مورد رویکرد خود به حریم خصوصی و تبلیغات دیجیتال استقبال می کنیم: " یک اینترنت رایگان و باز نباید به قیمت حریم خصوصی تمام شود " و " بهبود تبلیغات آنلاین از طریق محصول و زیرساخت ".
(در فصل های گذشته نیز گزارش شده است) نتایج حراج	درخواست برای یک حراجی برای بازگرداندن چندین URL رندر با امتیاز مربوط به آنها، کپی برداری از تبلیغات بومی و جلوگیری از مشکلات UX و تأخیر را آسان تر می کند.	پاسخ ما مشابه فصل های قبل است: به اشتراک گذاشتن چندین رندرURL، و امتیاز مربوط به آنها، از یک حراج PA API، چیزی است که ما در نظر گرفتیم، اما به دلیل نگرانی های حفظ حریم خصوصی اجرا نکردیم. ما تمایل به اجتناب از نمایش چندباره یک تبلیغ به یک کاربر در یک صفحه را درک می کنیم و در حال ارزیابی این درخواست هستیم. ما در اینجا از بازخورد اضافی اکوسیستم در مورد پشتیبانی اضافی مورد نیاز در PA API برای پشتیبانی بهینه از موارد استفاده از تبلیغات بومی استقبال می کنیم.
عملکرد	نگرانی در مورد تأخیر تأثیرگذار بر PA API.	ما نگرانی‌هایی در مورد تأخیر شنیده‌ایم و این بخشی از دلیلی است که ما تعدادی ویژگی را به عنوان بخشی از API PA توسعه داده‌ایم که این امکان را برای SSPها فراهم می‌کند تا هم محدودیت‌هایی را برای تأخیر DSP تعیین کنند و هم بهبودهایی را ایجاد کنند که می‌تواند تأخیر را کاهش دهد. . ما اخیراً راهنمای بهترین شیوه‌های تأخیر خود را به‌روزرسانی کرده‌ایم که حاوی اطلاعات بیشتری در مورد نحوه استفاده از این ویژگی‌ها است. ما همچنین به توسعه بهبودهای تأخیر جدید ادامه می دهیم که برخی از آنها را می توان در اینجا مشاهده کرد.
فروشندگان سطح بالا	Google باید به ناشران اجازه دهد تا فروشندگان حراج PA API سطح بالا را انتخاب کنند.	PA API نسبت به کسانی که حراج را در طرح‌های تک‌فروشنده و چند فروشنده آغاز می‌کنند، ناشناس است. انتخاب‌های شرکت‌های منفرد در مورد اینکه آیا و چگونه از حراج‌های PA API پشتیبانی می‌کنند، با خود آنهاست.
(در فصل های گذشته نیز گزارش شده است) هدف گذاری منفی	درخواست راه‌حلی برای موارد استفاده که در آن تبلیغ‌کننده نمی‌خواهد تبلیغات را برای مخاطب خاصی نمایش دهد.	ما از هدف‌یابی IG منفی از طریق پیشنهادات اضافی (متنی) پشتیبانی می‌کنیم، که نیازهایی را که تبلیغ‌کننده نمی‌خواهد تبلیغات را برای مخاطب خاصی نمایش دهد برطرف می‌کند. جزئیات را می توان در این توضیح دهنده و این شماره GitHub یافت. ما همچنین در حال بررسی راه‌حل‌هایی برای حمایت از هدف‌گذاری منفی IG برای پیشنهادات PA API هستیم و از بازخورد اضافی در اینجا استقبال می‌کنیم.
(در فصل های گذشته نیز گزارش شده است) تبلیغات بومی	درخواست پشتیبانی Fenced Frame برای تبلیغات بومی.	ما در حال بررسی حمایت از این مورد استفاده هستیم و در اینجا راه‌حل‌ها و راه‌حل‌های احتمالی را مورد بحث قرار می‌دهیم.
WebView	جستجوی توضیح در مورد سناریویی که IG در Chrome ملحق شده است برای حراج اجرا شده در WebView در دسترس نبود.	زمانی که زیرساخت حفظ حریم خصوصی کافی در دسترس است، ما می خواهیم از این موارد استفاده پشتیبانی کنیم. ما در حال حاضر هیچ اعلامیه دیگری برای ارائه نداریم، اما از بازخورد اضافی در اینجا استقبال می کنیم.
IGهای منفی	درخواست به‌روزرسانی پردازش URL برای پشتیبانی از IGهای منفی از طریق ویژگی هدر نوپا.	ما در حال ارزیابی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم.
فیلتر تنوع	درخواست راهنمایی در مورد نحوه اجرای فیلتر تنوع هنگام اجرای تبلیغات بومی در PA API با چند فروشنده و چند حراج.	ما در حال بحث در مورد این درخواست در اینجا هستیم و از بازخورد اضافی استقبال می کنیم.
(در فصل های گذشته نیز گزارش شده است) مسدود کردن فیلترها	درخواست راهنمایی در مورد نحوه اجرای قوانین «انسداد ناشر» (فیلترها) هنگام اجرای تبلیغات بومی در PA API با چند فروشنده.	ما راهنمایی را در اینجا به اشتراک گذاشته ایم و از بازخورد اضافی استقبال می کنیم.
محدودیت ها	درخواست اجازه دادن به محدودیت در سطح دامنه به جای در سطح زیر دامنه.	محدودیت‌ها در سطح زیر دامنه یا مبدا از مدل امنیتی پایه وب پیروی می‌کنند، بنابراین این طراحی پیش‌فرض ما است. ما در اینجا و اینجا با جزئیات بیشتر در مورد این بحث صحبت کرده ایم.
مناقصه مورد اعتماد	درخواست برای عامل کاربر و نکات مشتری مرتبط در درخواست‌های سیگنال مناقصه قابل اعتماد.	ما در حال پیگیری این درخواست ویژگی هستیم و از بازخورد اضافی در اینجا استقبال می کنیم .
(در فصل های گذشته نیز گزارش شده است) IG های متعدد	از چندین IG در یک پیشنهاد استفاده کنید.	این مورد امروزه در PA API پشتیبانی نمی‌شود، زیرا منجر به تغییر در مدل اصلی حریم خصوصی می‌شود. ما از بحث بیشتر در اینجا استقبال می کنیم.
(در فصل های گذشته نیز گزارش شده است) عملکرد	انتقال منطق بیشتر به مشتری می تواند به عملکرد صفحه و UX آسیب برساند و به طور بالقوه به نمرات SEO وب سایت آسیب برساند.	ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم.
دینامیک حراج	PA API اطلاعات مربوط به پویایی حراج را کاهش می دهد (مثلاً چه کسی شرکت می کند، چه کسی برنده هر مؤلفه حراج شده و غیره) است که ناشران قابلیت ردیابی را کاهش می دهد و تشخیص اینکه آیا معاملات حفظ می شوند یا خیر.	ما در اینجا راه حلی برای ردیابی معاملات پیشنهاد کردیم. ما قصد داریم برخی از فیلدهای موجود را اصلاح کنیم و برخی فیلدهای جدید را در شی IG ایجاد کنیم تا DealID و SeatID را ذخیره کنیم و به آنها اجازه انتشار از generateBid به scoreAd یا خروج از طریق گزارش در سطح رویداد را بدهیم. این باید پشتیبانی کافی برای مورد استفاده معامله را فراهم کند. ما از بازخورد در مورد سایر ابرداده‌هایی که فناوری‌های تبلیغاتی آن را برای پویایی حراج و حفظ این قابلیت ردیابی برای ناشران حیاتی می‌دانند، استقبال می‌کنیم. ما فن‌آوران تبلیغات را تشویق می‌کنیم که نمونه‌های خاصی از ابرداده‌هایی را که به آن ارجاع می‌دهند و از کدام طرف به کدام طرف نیاز دارد ارائه کنند.
GAM	نگرانی در مورد الزام استفاده از GAM به عنوان سرور تبلیغات ناشر برای دسترسی به تقاضای AdX.	پاسخ ارائه شده توسط Google Ad Manager: GAM نیازی ندارد که ناشران از عملکرد سرور تبلیغاتی آن برای دسترسی به عملکرد تبادل آن استفاده کنند.
(در فصل های گذشته نیز گزارش شده است) حراج قطعات	برندگان حراج مؤلفه PA API برای GAM قابل مشاهده خواهند بود و نگرانی‌هایی را در مورد دسترسی نابرابر به اطلاعات ایجاد می‌کنند.	پاسخ ما نسبت به فصل های قبلی بدون تغییر باقی می ماند: پاسخ ارائه شده توسط Google Ad Manager: ما برای سال‌ها تمرکز زیادی بر عادلانه بودن حراج داشته‌ایم، از جمله قول داده‌ایم که هیچ قیمتی از هیچ یک از منابع تبلیغاتی تضمین‌نشده ناشر، از جمله قیمت کالاهای خطی غیرتضمین‌شده، با خریدار دیگری قبل از پیشنهاد در حراج به اشتراک گذاشته نمی‌شود. ، که بعداً در تعهدات خود به سازمان رقابت فرانسه مجدداً تأیید کردیم. برای حراج‌های PA API، ما قصد داریم به قول خود عمل کنیم و قبل از اتمام حراج در حراج‌های چند فروشنده، پیشنهاد هیچ شرکت‌کننده در حراج را با هیچ شرکت‌کننده دیگری در حراج به اشتراک نگذاریم. برای روشن بودن، همانطور که در این به‌روزرسانی توضیح داده شد، قیمت حراج متنی را با هیچ حراجی جزء، از جمله حراج خودمان، به اشتراک نمی‌گذاریم. علاوه بر این، ما از اطلاعات مربوط به تنظیمات حراج اجزا، از جمله سیگنال‌های ارائه شده توسط خریداران به SSPها، به عنوان بخشی از حراج خود استفاده نمی‌کنیم. در واقع، ما از تغییراتی در API PA استقبال می‌کنیم که به فروشندگان مؤلفه اجازه می‌دهد پیکربندی‌های حراج مؤلفه خود را به گونه‌ای مشخص کنند که از فروشنده سطح بالا مبهم باشد."
GAM	اگر GAM در ایجاد مزایده مؤلفه های IG یا PA API شرکت نکرده باشد، آیا GAM برای اجرا/گزارش حراج های سطح بالا درخواست سهم درآمد خواهد کرد؟	پاسخ ارائه شده توسط Google Ad Manager: وقتی ناشران استفاده از GAM را به‌عنوان سرور تبلیغاتی خود انتخاب می‌کنند، GAM حراج سطح بالا را اجرا می‌کند و برای عملکرد سرور تبلیغاتی خود، هزینه ارائه آگهی دریافت می‌کند (همان هزینه ارائه آگهی که خارج از حراج‌های PA API اعمال می‌شود). با این حال ، اگر آگهی برنده از یک فروشنده مؤلفه غیر GAM باشد - به این معنی که GAM در ایجاد حراج مؤلفه IG یا PA API شرکت نکرده است - GAM صورتحساب را اداره نمی کند و هزینه رسانه ای را نیز دریافت نمی کند.
کلیک	آیا ثبت نام رویدادهای کلیک در معرض همان حریم خصوصی دیفرانسیل است؟	این ویژگی در حال حاضر برنامه ریزی نشده است که مشمول محدودیت های "K-Anon" باشد ، زیرا "تعداد کلیک ها" فقط به عنوان یک مرورگری در داخل عملکرد generateBid() در دسترس خواهد بود. این به عنوان یک ویژگی جدید در گزارش سطح رویداد در دسترس نیست.
عملکرد	هزینه های بالایی به دلیل پاسخ بی قید و شرط به درخواست های پیشنهادات متنی.	ما نمی توانیم به طور مستقیم اطلاعاتی را ارائه دهیم که DSP ها به دلیل نگرانی از حریم خصوصی دارای IGS هستند. با این حال ، ما در حال بررسی راه حل های جایگزین هستیم که می توانند ضمن حفظ حریم خصوصی ، بینش هایی را ارائه دهند.
تبلیغات بومی و خارج از کشور	درخواست به روزرسانی در مورد دیدگاه Chrome در مورد تبلیغات بومی و خارج از کشور.	موقعیت کروم به مورد استفاده مورد نظر بستگی دارد. در فیلم ، موقعیت Chrome این است که وظیفه ما تشویق اکوسیستم برای همگرایی در راه حل های ویدیویی با استفاده از API های ما است. تاکنون تنها پیشنهاد مشخصی که ما از آن آگاه هستیم ، پیشنهاد GAM است. در مورد بومی ، ما به طور فعال در اینجا بازخورد را جمع می کنیم و قصد داریم به زودی تکنیک های تبلیغاتی را با مراحل کشف بیشتر درگیر کنیم.
نظارت بر زمان واقعی (RTM)	ترافیک دارای برچسب گزارش های RTM را ارسال نمی کند.	ما از این شکاف آگاه هستیم و در تلاش هستیم تا یک راه حل ارائه دهیم. ما در صورت وجود در اینجا به روزرسانی را به اشتراک خواهیم گذاشت.
حمایت از افزایش مخاطبان	درخواست به روزرسانی در مورد پشتیبانی از برنامه افزودنی مخاطبان/مخاطبان با فروشنده در PA API.	ما در حال تلاش برای ارائه راه حلی برای این مورد استفاده هستیم. ما در حال جمع آوری بازخورد از اکوسیستم در مورد آنچه باید بسازیم و پشتیبانی می کنیم. ما در صورت وجود به روزرسانی را به اشتراک خواهیم گذاشت و از بازخورد اضافی در اینجا استقبال می کنیم.
اشکال زدایی	در ابزار توسعه دهنده Chrome ، هیچ پانلی برای نظارت بر عملکرد دقیق PA API وجود ندارد. به عنوان مثال ، عملکرد کلی ممکن است تحت تأثیر تعداد IGS یا تعداد خریداران باشد.	در حالی که این بازخورد خاص مربوط به قابلیت های UI ابزار توسعه دهنده Chrome برای کمک به نظارت است ، در 7 اکتبر ما توانایی فناوری های تبلیغاتی را برای پیکربندی رویدادهای سفارشی که می تواند به عنوان پایه ای برای نظارت و هشدار استفاده شود ، معرفی کردیم. جزئیات بیشتر در اینجا موجود است و امیدواریم که این به روزرسانی به بخش ماده ای از این بازخورد بپردازد. ما از هرگونه بازخورد بیشتر در مورد این ویژگی استقبال می کنیم ، خواه مربوط به نقاط داده های پشتیبانی شده یا تجربه توسعه دهنده در بحث مربوط به GitHub در اینجا باشد .
سیگنال ها	نگرانی در مورد اینکه آیا DSP ها می توانند اطمینان حاصل کنند که Perbuyersignals به SSP مستقل از نتایج حراج متنی ارسال می شود.	حراج متنی فرض می شود که فقط یک پیشنهاد برنده از یک DSP داشته باشد ، یا بهتر گفته می شود که یک پیشنهاد برای تلاش برای ضرب و شتم با حراج API بعدی PA است. برای جریان API PA ، SSP تصمیم می گیرد هر DSP را که می خواهند ببینند آیا تقاضا (به شکل IG در دستگاه) را برای ارائه دعوت می کنند ، دعوت کند. این کاملاً ممکن است و در واقع بسیار محتمل است که DSP که حراج متنی را از دست داده است "مجدداً" برای شرکت در حراج PA API "مجدداً مورد استفاده قرار گیرد". در این "دعوت مجدد" زمانی است که DSP ، اگر تصمیم به پذیرش بگیرد ، به SSP هر سیگنالهایی را که تأیید کننده تبلیغ می خواهد اطمینان حاصل کند ، می خواهد اطمینان حاصل کند که DSP در صورت وجود برای آن کمپین وجود دارد. به عبارت دیگر ، در حراج PA API همیشه راهی وجود دارد که DSP بدون توجه به آنچه در حراج متنی رخ داده است ، به SSP ارسال کند.
سیگنال ها	درخواست اضافه کردن PREVCLICKS به شیء مرورگرهای منتقل شده به generatedBid() .	این درخواست را می توان با پیشنهاد ما برای پشتیبانی از سیگنال های کلیک حل کرد. ما این ویژگی را در پست وبلاگ اخیر و توضیح دهنده مربوطه اعلام کردیم. ما در اینجا از بازخورد اضافی در مورد این پیشنهاد استقبال می کنیم.
(همچنین در سه ماهه قبلی گزارش شده است) سیگنال های مدل سازی	درخواست افزایش تعداد بیت سیگنال های مدل سازی از 12 بیت به 30 بیت.	ما در اینجا با یک پیشنهاد پیشخوان به این بازخورد پاسخ داده ایم. ما به طور جدی با صنعت درگیر هستیم تا نظرات آنها را در مورد پیشنهاد خود درک کنیم و در حال حاضر مزایای این صنعت را در برابر تأثیر کاربران Chrome و سایر ذینفعان در نظر می گیریم.
مستندات	درخواست راهنمایی در مورد نحوه استفاده از سرورهای کلید/مقدار (K/V) و Tees.	راهنمایی در مورد استفاده از Tees در زمینه K/V در جزئیات طراحی مدل اعتماد K/V در اینجا موجود است.
طول عمر IG های منفی	درخواست افزایش طول عمر IG های منفی تا 365 روز.	از IG های منفی برای جلوگیری از نمایش تبلیغات استفاده می شود ، اما بازیگران بد هنوز هم می توانند از آن برای آشکار کردن اطلاعات در مورد کاربران استفاده کنند ، در نتیجه خطرات شناسایی مجدد (به عنوان مثال یکی از راه های حمله بازیگران بد فقط قرار دادن پیشنهادات بالا با IG های منفی در آنها به طور مکرر است بیاموزید که آیا یک کاربر از سایت های خاصی بازدید کرده یا بازدید نکرده است). اگر TTL 365 روزه را حفظ کنیم ، بازیگران بد داده های بیشتری در مورد IG های منفی خواهند داشت که منجر به خطرات حریم خصوصی قابل توجهی بیشتر می شود. بنابراین ، ما نمی توانیم از این درخواست پشتیبانی کنیم تا از حریم شخصی کاربر محافظت کنیم.
مشخصات API	چه چیزی را می توان به عنوان مقادیر منتقل شده به عنوان بخشی از perbuyersignals درج کرد؟ آیا می توان این را به طور دلخواه توسط فروشنده تعریف کرد؟	Perbuyersignals مکانی برای فروشندگان است تا بتوانند اطلاعاتی را که می خواهند در داخل حراج در دسترس قرار دهند ، به خریداران ارائه دهند. این است که اکوسیستم تصمیم بگیرد که چه چیزی را می خواهند در آنجا وارد کنند ، اما ما در اینجا از بحث های اضافی استقبال می کنیم.
جایگزین های کلان اندازه تبلیغات	به دنبال راهنمایی در اطراف اندازه تبلیغات جایگزین های کلان نیست.	ما به زودی جزئیات بیشتری را به اشتراک خواهیم گذاشت.
ارسال پیشنهاد SSP MACRO تعویض: جعل URL سطح بالا	کروم چه مکانیسم هایی را می تواند معرفی کند تا فروشندگان تأیید بتوانند URL سطح بالا را در چارچوب ماسهبازی حریم خصوصی تأیید کنند؟ آیا نقاط داده جایگزین یا سیگنال هایی وجود دارد که می توانند در قاب های حصارکشی استفاده شوند تا از صحت URL سطح بالا در سطح SSP اطمینان حاصل شود؟	ما در حال حاضر در مورد این بازخورد خوش آمدید در اینجا بحث می کنیم.
درخواست ویژگی	درخواست ارائه UACH کم آنتروپی در UpdateURL و در مورد گزارش های گزارش در زمان واقعی.	این درخواست ها در اینجا مورد بحث قرار می گیرند ، و ما از بازخورد اضافی در اینجا و اینجا استقبال می کنیم.
درخواست ویژگی	درخواست سرور قابل اعتماد رضایت از طرح اشکال زدایی را برای فعال شدن هنگامی که یک مشتری داده شده باعث شده است گزارش های سطح رویداد Fordebuggingonly را از طریق forDebuggingOnly.reportAdAuctionWin() و forDebuggingOnly.reportAdAuctionLoss() ارسال کند.	این یک درخواست فعال است که ما در حال حاضر در حال ردیابی هستیم و در صورت وجود به روزرسانی اکوسیستم را ارائه می دهیم. ما در اینجا از بازخورد اضافی استقبال می کنیم.
استفاده API	درخواست راهنمایی در مورد چگونگی شمارش دسترسی منحصر به فرد کاربر و دسترسی به تصور.	ما در حال بحث در مورد پیشنهادی برای پرداختن به نحوه خواندن IG از درون یک کار ذخیره سازی مشترک هستیم ، که می توانید گزارش های کل خصوصی را در مورد آن ارسال کنید. جزئیات بیشتر در اینجا موجود است و ما از بازخورد در مورد پیشنهاد و سودمندی آن در اکوسیستم استقبال می کنیم.
استفاده API	عدم وضوح در مورد آنچه ناشران باید آزمایش کنند ، کدام API مهم هستند ، کدام یک باید روشن شود و چه چیزی در آینده قرار دارد.	تلاش هایی برای پشتیبانی بهتر ناشران و نقش آنها در اکوسیستم انجام می شود.
استفاده API	آیا می توان شنوندگان رویداد را به رویدادهای کار حراج تبلیغاتی اضافه کرد؟	این از طریق رویدادهای عادی امکان پذیر نیست اما رویدادهای پروتکل Chrome Devtools تا حدی به این مورد استفاده می کنند. توجه داشته باشید که احتمالاً رویدادهای منظم بر ویژگی های انزوا/حریم خصوصی تأثیر می گذارد ، اما جزئیات در اینجا موجود است.
K-ناشناس بودن	به دنبال شفاف سازی در مورد الزامات ارائه تبلیغات (به عنوان مثال حداقل 50 نفر می توانستند تبلیغ را مشاهده کنند ، در صورت اجازه نمایش).	مستندات توسعه دهنده مروری بر انتظارات ما از تحولات آینده ارائه می دهد. به ویژه توضیح می دهد که آستانه اولیه ناشناس بودن K K = 10 نفر است. لیست پستی Blink-Dev به روزرسانی هایی را در مورد آنچه اتفاق می افتد به صورت زنده در Chrome ارائه می دهد. همانطور که در موضوع لیست پستی K-Anmonymity آمده است ، ما در حال حاضر به طور تجربی نیاز به ناشناس بودن K را در حدود 1 ٪ از ترافیک پایدار Chrome اجرا می کنیم و هرگز آن را بر روی برچسب صریح ("حالت A" و "حالت B" اجرا نمی کنیم) برش ها
چف کردن	آیا می توان Tee K/V Chaffing را به طور موقت از تماس با تمام قسمتهای N ، به مقداری که باعث محافظت از حریم خصوصی در برابر ابزار (یعنی عملکرد/هزینه K/V) می شود ، حذف یا کاهش داد؟	این نوع درخواست ها فقط برای موارد غیر تولیدی که در آن قابل کنترل است ، انجام می شود. برای موارد تولید هنوز هم مورد نیاز است. ما می توانیم پس از دریافت بازخورد از استفاده غیر تولیدی ، وضعیت را ارزیابی کنیم.
چف کردن	درخواست اضافه کردن پرچم برای غیرفعال کردن Chaffing از Debug/Prod K/V باینری.	این پرچم با نسخه 1.0.0 تهیه شده است.
اشکال API	API پس از به روزرسانی به Chrome 126 ، کار خود را متوقف کرد ، حتی اگر API در تنظیمات فعال شود.	مشخص شد که این مسئله مربوط به پرچم Chrome "Enable-Frames" است که توسط کاربران برای اهداف توسعه فعال شده است. تنظیم مجدد این پرچم به طور پیش فرض مسئله را برطرف می کند.
گزارش	درخواست برای ایجاد گزارش در زمان واقعی ، API را برای خریداران وابسته به فروشنده نیست.	این درخواست در اینجا در نظر گرفته شده است. راه حل RTM به تازگی منتشر شد و ما به ویژه از آن فناوری های تبلیغاتی که قبلاً به این ویژگی وارد شده اند ، از بازخورد استقبال می کنیم.
گزارش	درخواست گزارش 3P ؛ در حالی که DSP ها و SSP ها اعلان های تصور از Chrome را دریافت می کنند ، ارائه دهندگان فنی با لایه میانی به طور پیش فرض انجام نمی دهند.	ما در مورد این درخواست بحث می کنیم و از بازخورد اضافی در اینجا استقبال می کنیم.

خدمات حراج محافظت شده

موضوع بازخورد	خلاصه	پاسخ کروم
تازیانه	نیاز Google برای ورود به سیستم دستی تحت استانداردهای فنی ، محدودیت قوی در انتخاب فروشنده ابر است. استانداردهای فنی اعمال شده را می توان بدون بازدید از دفتر ارائه دهندگان ابر دنبال کرد ، همانطور که به نظر می رسد گوگل در ذهن دارد. تأخیر دیرهنگام ارائه دهندگان جایگزین در سال 2025 (زودتر) قابل قبول نیست زیرا اثرات شبکه را تشویق می کند تا به راه حل های Google تشویق شود.	سرویس جمع آوری تنها سرویس مورد نیاز برای اجرای در یک سرویس TEE برای رسیدگی به برخی موارد استفاده از فناوری تبلیغاتی است. سرویس جمع آوری از هر دو سرویس وب آمازون (AWS) و Google Cloud Platform (GCP) پشتیبانی می کند. بر اساس بازخورد از فناوری های تبلیغاتی ، ما معتقدیم که چنین پشتیبانی در این مرحله کافی است. در مورد ارائه دهندگان ابر اضافی - Google معیارهای مفصلی را برای TEES در مورد ارائه دهندگان ابر عمومی منتشر کرد. اینها با هدف اطمینان از اینكه راه حل TEE از اهداف حریم خصوصی و امنیتی ماسهبازی حریم خصوصی برخوردار است . به طور خاص ، سرورهای Tee با جعبه ماسه ای حریم خصوصی داده های کاربر را رمزگذاری نشده پردازش می کنند (به عنوان مثال داده های ناشر و سایت های تبلیغ کننده برای خدمات جمع آوری). برای رسیدن به اهداف حریم خصوصی کاربر API ، اینها باید ایمن باشند. یک محیط امن نیز به همین ترتیب برای اطمینان از ادامه حمایت از اطلاعات محرمانه شرکت ها (به عنوان مثال ، جلوگیری از سایر شرکت کنندگان در حراج PA API از دسترسی به داده های تجاری اختصاصی خریدار) ضروری است. به بهترین دانش ما ، در حال حاضر هیچ فناوری TEE وجود ندارد که از داده های کاربر از یک اپراتور بالقوه متناقض محافظت کند. بنابراین ، ما چندین الزامات را برای اعتبارسنجی اعتماد به نفس ارائه دهنده ابر درج می کنیم. ما مطمئن نیستیم که "دفتر ارائه دهندگان ابر" به چه چیزی اشاره دارد و بخشی از الزامات نیست. ما از هرگونه بازخورد در مورد الزامات استقبال می کنیم. ما همچنین به ارزیابی پشتیبانی از ارائه دهندگان جدید ، از جمله بر اساس درخواست های ارسال شده با استفاده از فرآیند تعریف شده در توضیحات ، ما ادامه می دهیم. تاکنون ، ما فقط درخواستی برای حمایت از لاجورد دریافت کرده ایم ، که ما ارزیابی می کنیم.
B&A	ارزیابی پیچیدگی فنی و امکان سنجی سرویس B&A دشوار است زیرا این طرح در حال تحول است.	برای پرداختن به این نگرانی ها ، ما توضیح دهنده های مفصلی را در مورد GitHub توضیح داده ایم که در مورد طراحی B&A ، زمان بندی در دسترس بودن و نقشه راه از ویژگی های پشتیبانی از API PA منتشر شده است. ما از فناوری های تبلیغاتی که به دنبال استقرار B&A و جمع آوری بازخورد از اکوسیستم در GitHub هستیم ، پشتیبانی می کنیم.
B&A	به دنبال راهنمایی و راه بهتر برای محاسبه هزینه استفاده از TEE برای B&A برای شروع استفاده از آن یا مهاجرت به استفاده از آن از روی دستگاه است.	ما به تازگی راهنمای اندازه سرور K/V را منتشر کرده ایم ، که شامل ابزار برای اندازه گیری دقیق تر هزینه ها است.
سرور K/V	Ad-Reverifer درخواست می کند از URL صفحه کامل به سرور K/V برای انجام تأیید تبلیغ استفاده کند.	ما در حال حاضر امکان ارائه URL صفحه کامل به سرور K/V را که در یک TEE برای اهداف تأیید آگهی اجرا می شود ، ارزیابی می کنیم. URL صفحه کامل در K/V BYOS در دسترس نخواهد بود.
امنیت حراج	به دنبال ویژگی های امنیتی حراج برای اطمینان از اینکه بازیگران بد به داده های حساس دسترسی پیدا نمی کنند یا به عنوان جعل کننده عمل نمی کنند - کدام ویژگی ها از حراج در برابر حملات پخش مجدد محافظت می کنند و چگونه می توان حفاظت های امنیتی را اجرا کرد؟	مدل امنیتی فعلی B&A می تواند از یکپارچگی حراج محافظت کند. B&A در یک TEE اجرا می شود که از محرمانه بودن سیگنال های Ad Techs و کد از بازیگران مخرب محافظت می کند. در معماری B&E ، یک بارگذاری درخواست B&A رمزگذاری شده (درخواست رمزگذاری متن) از طریق یک سرور تبلیغاتی غیرقابل اعتماد به سرویس SaleserFrontend (SFE ، توسط SSPS در TEE) از مشتری جریان می یابد. متن رمزگذاری درخواست حاوی شناسه نسل مبتنی بر Timestamp است. SFE جدول زمانی درخواست را بررسی می کند و هرگونه درخواست پخش مجدد را که در چند ثانیه از زمان سرور نیست ، رد می کند. علاوه بر آن ، B&A می تواند یک بار پاسخ پاسخ اندازه ثابت را برای سرور به ارتباط سرور برگرداند. این راه حل ها می توانند به کاهش حملات پخش مجدد از طریق سیستم کمک کنند وقتی که یک بازیگر مخرب سعی می کند همان درخواست بار را برای کسب اطلاعات بیشتر در مورد محتوای خود دوباره پخش کند. B&A در حال مستند سازی و به روزرسانی مدل های امنیتی در توضیحات است.
سیگنال ها از طریق سرور K/V	درخواست شامل Perbuyersignals ارسال شده از طریق سرویس K/V به عنوان بخشی از درخواست سیگنال های پیشنهادی قابل اعتماد از Chrome.	ما در حال ارزیابی امکان سنجی اطلاعات از Perbuyersignals هستیم که به سرور K/V منتقل شده در یک TEE از جمله URL صفحه کامل منتقل می شود.
سرور K/V	درخواست یک جدول زمانی اتخاذ فاز تر برای محدودیت های حریم خصوصی در K/V و B&A.	ما تمایل به یک رویکرد فاز تر برای پذیرش TKV را درک می کنیم و از درخواست های خاص شما در مورد K/V و B&A قدردانی می کنیم. با این حال ، پس از ارزیابی دقیق ، ما تصمیم گرفتیم که در حال حاضر محافظت از حریم خصوصی در این API ها را آرام نکنیم. ما معتقدیم که این اقدامات ، مانند Chaffing ، برای حفظ حریم خصوصی کاربر و حفظ اعتماد به ماسهبازی حریم خصوصی بسیار مهم است.
سرور K/V	به دنبال راهنمایی در مورد نحوه مقیاس فروشگاه K/V از طریق یک پیکربندی سازگار است.	راهنمای اندازه سرور K/V به تازگی منتشر شده می تواند در اینجا کمک کند. این ابزار در هر ترکیبی از پارامترها ، QPS (که به عنوان "RPS" در توضیح دهنده ذکر شده است) ارائه می دهد.
سرور K/V	اطلاعات فروشنده را در درخواست سرور K/V اضافه کنید.	ما در مورد این موضوع بحث می کنیم و از بازخورد اضافی در اینجا استقبال می کنیم.
خدمات K/V + B & A	درخواست برای روشن کردن جدول زمانی یا نقشه راه انتشار برای K/V و B&A.	برای هر دو K/V و B&A ، ما مراحل و جدول زمانی داریم: برای سرور K/V در رابطه با حراج های API PA در دستگاه (VS B&A) جدول زمانی عمومی در اینجا موجود است. از نظر چگونگی تعریف "در دسترس بودن عمومی" برای K/V ، به بخش نقشه راه مراجعه کنید که ویژگی تعیین شده برای بتا و GA را مشخص می کند. برای B&A ، جدول زمانی عمومی را در اینجا و نقشه راه در اینجا مشاهده کنید. ما تست مقیاس را "تست مقیاس کامل پایدار و تولید" تعریف می کنیم - در اینجا ویژگی خاصی را که در این مرحله تنظیم شده است ، ببینید. B&A همچنین دارای مراحل آلفا و بتا است ، بنابراین آزمایش مقیاس شامل مجموعه فوق العاده ای از ویژگی های مراحل قبلی خواهد بود. برای هر دو K/V و B&A ، به ما اطلاع دهید که آیا این تعاریف مرحله به ارائه وضوح در مورد آنچه در دسترس خواهد بود کمک می کند. اگر هنوز شکاف وجود دارد ، لطفاً به ما اطلاع دهید. ما خوشحالیم که این موارد خاص را برای کمک به اطلاع رسانی به برنامه ریزی انجام می دهیم.

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

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

موضوع بازخورد	خلاصه	پاسخ کروم
پاسخ بازار	الزام سیستم های انتساب رقیب فقط از گزارش های سطح رویداد و گزارش خلاصه/کل در مرزهای تنگ ، محدودیت دلخواه در رقابت است. این امر از بازپرداخت و انتساب خاص دستگاه در زمان واقعی در سطح رویداد جلوگیری می کند ، حتی اگر حفاظت از آنها برای اطمینان از انطباق محافظت از داده ها (به عنوان مثال شناسایی DE) وجود داشته باشد.	طرح ذکر شده بر اساس اهداف حریم خصوصی API است - به عنوان مثال محافظت از اطلاعات متقابل سایت که از یک سایت به سایت دیگر منتقل می شود. به عنوان مثال ، ARA از طریق گزارش های رویداد از انتساب سطح رویداد پشتیبانی می کند. گزارش های رویداد در حداقل یک ساعت به تأخیر می افتد ، که لازم است تا گزارش سطح رویداد با هویت کاربر در سایت تبلیغ کننده ، با استفاده از حملات کانال جانبی ، همانطور که در اینجا ثبت شده است ، دشوار شود. علاوه بر این ، روش های دیگری برای انجام انتساب ، فراتر از ARA وجود دارد ، مانند جمع آوری مستقیم اطلاعات از کاربرانی که آگاهانه داده های شناسایی را ارائه می دهند. ما در مورد موارد استفاده که نمی توان با مرزهای حریم خصوصی فعلی API های ماسه ای حریم خصوصی به دست آورد ، بازخورد بازخورد داریم.
چند سطحی	درخواست تأیید در مورد اینکه آیا ARA و API های ذخیره سازی مشترک از موارد استفاده از چند سطحی پشتیبانی می کنند و در آن مشهود است.	در حال حاضر ARA و ذخیره سازی مشترک از انتساب چند سطحی (دستگاه متقاطع) پشتیبانی نمی کنند. Cross App و Attribution وب در همان دستگاه (از طریق ARA) پشتیبانی می شود.
(همچنین در سه ماهه قبلی گزارش شده است) Cross-Device	آیا ARA از تبدیل بین دستگاه پشتیبانی می کند؟	پاسخ ما شبیه به محله های قبلی است: دستگاه متقابل چالش های جدید حریم خصوصی را در بالای 3 قطعه ارائه می دهد و همچنین با توجه به طیف وسیعی از دستگاه ها و سیستم عامل هایی که کاربر ممکن است از آن استفاده کند ، چالش های توزیع فناوری را اضافه می کند. ما در حال بررسی راه حل های بالقوه هستیم ، اما ما بر روی موارد مهم استفاده که در حال حاضر توسط ARA پشتیبانی می شود متمرکز شده ایم و در حال حاضر جدول زمانی برای پشتیبانی از دستگاه های متقابل نداریم.
مقیاس بندی	نگرانی در مورد اینکه آیا گزارش انتساب API (ARA) در حال حاضر پیکربندی شده است و می توان با اطمینان از آن استفاده کرد و به همه کاربران Chrome خدمات داد.	ARA در حال حاضر در دسترس همه کاربران Chrome است و همانطور که انتظار می رفت در حال اجرا است. علاوه بر این ، ما همچنان به آزمایش و نظارت بر قابلیت اطمینان و مقیاس پذیری آن ادامه می دهیم ، زیرا تعداد شرکت های فناوری تبلیغاتی که ARA را آزمایش می کنند ، همچنان افزایش می یابد. ما از بازخورد اکوسیستم اضافی در مورد این در اینجا استقبال می کنیم.
(همچنین در سه ماهه قبلی گزارش شده است) کپی برداری	نگرانی در مورد چگونگی پیشنهاد ARA برای محدود کردن مکانیسم انتساب در دستگاه ها به گونه ای که ناشران قادر به انجام منطق پس از اتمام برای گزارش های خلاصه نیستند ، از جمله اختصاص دادن چندین تبدیل از نوع مشابه برای همان کلیک تبلیغاتی.	پاسخ ما از محله های قبلی بدون تغییر باقی می ماند: Dedupplic در بین دستگاه ها و خطوط لوله اندازه گیری یک چالش شناخته شده و فعلی است که امروزه فناوری های تبلیغاتی نیز با 3 قطعه با آن روبرو هستند. با استفاده از ARA ، فناوری های تبلیغاتی می توانند تصمیم بگیرند که چه زمانی تبدیل های خاص را ثبت کنند و ابرداده خاصی را اضافه کنند تا نشان دهند کدام خطوط لوله اندازه گیری از آنها برای ردیابی تبدیل ها استفاده کرده اند (یعنی بخشی از کلید جمع آوری) ، که می تواند در برابر سایر خطوط لوله اندازه گیری مقایسه شود. ما از بازخورد اکوسیستم اضافی در مورد این در اینجا استقبال می کنیم.
ردیابی تبدیل	درخواست توانایی کار با تبدیل از چندین حوزه.	ما در اینجا در مورد این درخواست بحث می کنیم و از بازخورد اکوسیستم اضافی استقبال می کنیم.
گزارش	این مرورگر حداقل دو روز منتظر می ماند اما تا 30 روز برای ارسال تبدیل به این امر می تواند باعث نگرانی شود زیرا اکثر تبلیغ کنندگان ذینفعان تبلیغ کننده های عملکرد هستند که در زمان واقعی کار می کنند.	تنظیمات پیش فرض برای گزارش های سطح رویداد دارای ویندوزهای گزارش پیش فرض زیر است: 2 روز ، 7 روز و 30 روز. با گزارش های انعطاف پذیر در سطح رویداد ، می توانید تعداد و طول گزارش ویندوز را از مقادیر پیش فرض تغییر دهید. گزارش ویندوز می تواند به حداقل 1 ساعت تغییر یابد که ممکن است در موارد استفاده از تبلیغ کننده عملکرد کمک کند. ما از بازخورد اکوسیستم اضافی در مورد این در اینجا استقبال می کنیم.
انتساب آنلاین به افول	آیا گزینه های پیاده سازی برای تبلیغات آنلاین به خارج از خانه در ARA وجود خواهد داشت ، یا پیشنهاد دیگری برای اندازه گیری انتساب آفلاین به خط وجود دارد؟	در حال حاضر هیچ برنامه ای برای پشتیبانی از موارد استفاده از اندازه گیری آنلاین به صورت آنلاین در ARA وجود ندارد. چالش های حریم خصوصی و امنیتی قابل توجهی وجود دارد که برای این نوع پشتیبانی باید در نظر گرفته شود. ما از بازخورد اکوسیستم اضافی در مورد موارد استفاده برای این پشتیبانی در اینجا استقبال می کنیم.
گزارش دهی اشکال	چگونه می توان ADID را ذخیره و یا بازیابی کرد به گونه ای که برای ثبت نام های Chrome (منبع/ماشه) برای انتساب برنامه به WEB در دسترس باشد؟	برای فعال کردن گزارش های اشکال زدایی ، فناوری تبلیغی باید به ما ثابت کند که آنها می توانند از قبل به کاربر در برنامه و وب بپیوندند ، و این کار برای اطمینان از عدم اطلاعات جدید توسط گزارش های اشکال زدایی انجام نمی شود. AD Tech می تواند با تهیه یک کلید پیوست که برای هر کاربر منحصر به فرد است ، پیوستن را اثبات کند. این کلید پیوستن می تواند adid باشد یا می تواند یک کلید پیوستن به 1p باشد. اگر AD Tech از Adid استفاده کند ، Chrome به طور بومی از دسترسی به ADID از مرورگر پشتیبانی نمی کند و API انتظار دارد که هر فناوری تبلیغاتی روش خود را برای عبور از ADID در طول ثبت وب داشته باشد.
گرانوری سطل	آیا استفاده از استراتژی های مختلف سطل در هر تبلیغ کننده امکان پذیر است؟	ما توصیه می کنیم با رویکردهای مختلف مقیاس بندی بودجه کمک کنید تا مواردی را پیدا کنید که برای موارد استفاده شما بهترین کار را داشته باشد. ARA با هدف انعطاف پذیر و قابل تنظیم برای برآورده کردن انواع موارد استفاده از فناوری تبلیغاتی ساخته شده است. بنابراین ما توصیه می کنیم با استراتژی های مختلف چاشنی در هر تبلیغ کننده یا در هر عمودی آزمایش کنید. استفاده از استراتژی های مختلف سطل می تواند مفید باشد که تبلیغ کنندگان در مقادیر اندازه گیری مورد علاقه خود در ردیابی و حجم مقادیر اندازه گیری تفاوت داشته باشند.
مستندات	درخواست مستندات اضافی برای اجرای برنامه <> وب برای ARA.	ما مستندات را در برنامه <> وب برای ARA در اینجا منتشر کرده ایم.
عملکرد	تعداد درخواست های مربوط به ARA به طور بالقوه می تواند بار سنگین در سرور (های) ناشر نسبت به تعداد درخواست های نگهدارنده که برای برق گفتند ، باشد. رویدادهای منبع جمع در یک درخواست واحد می تواند به کاهش بار در سرور کمک کند. یک ایده بالقوه اجازه دادن به مجموعه ای از اشیاء رمزگذاری شده JSON است	رویدادهای منبع جمع بر اساس منطق خاص تا حدی با استفاده از منطق JavaScript در ترکیب با API امکان پذیر است. ما در حال حاضر این درخواست را ارزیابی می کنیم و از بازخورد اضافی از اکوسیستم در اینجا استقبال می کنیم.
درخواست ویژگی	پیشنهادی برای یک پیشنهاد راه حل به دلیل عدم پشتیبانی ادغام سرور به سرور.	در حال حاضر ما قصد اجرای پشتیبانی از ادغام سرور به سرور در ARA را نداریم. بسیاری از چالش های حریم خصوصی زیادی وجود دارد که باید بیشتر مورد توجه قرار گیرد تا بتواند از ادغام سرور به سرور پشتیبانی کند. ما از بازخورد اکوسیستم در مورد موارد استفاده اضافی برای پشتیبانی سرور به سرور در اینجا استقبال می کنیم.
مستندات	درخواست یک راهنمای "شروع سریع" که بخش های اصلی ARA/نحوه بلند شدن و دویدن با چند مورد استفاده ساده را توضیح می دهد.	یک راهنمای شروع سریع برای ARA در اینجا موجود است. ما امسال در حال بهبود این اسناد هستیم و از بازخورد اضافی در مورد موارد استفاده خاص یا سناریوهایی که به اسناد اضافی در اینجا نیاز دارند ، استقبال می کنیم.
استفاده API	درخواست توصیه های مربوط به مقیاس بندی مشارکت برای بسیاری از مقادیر کوچک.	ما توصیه می کنیم با رویکردهای مختلف مقیاس بندی بودجه کمک کنید تا مواردی را پیدا کنید که برای موارد استفاده شما بهترین کار را داشته باشد. برای سناریوی بسیاری از مقادیر کوچک ، توصیه می کنیم با مقادیر مختلف Epsilon آزمایش کنید تا نقاط تورم را شناسایی کنید که در آن ممکن است نویز از اپسیلون برای مورد استفاده شما قابل قبول باشد. جزئیات بیشتر در مقاله تحقیقاتی ما در مورد بهینه سازی گزارش خلاصه در ARA موجود است.
سطح انعطاف پذیر در سطح	چه زمانی سطح رویداد انعطاف پذیر (مشخصات ماشه چندگانه) اجرا می شود؟	در حال حاضر در سطح رویداد انعطاف پذیر از شخصی سازی جنبه های پیکربندی ثبت نام زیر پشتیبانی می کند: تعداد گزارش هایی که می توانند در هر منبع ، تعداد و طول گزارش ویندوز و کاردینال بودن داده های ماشه تولید شوند. ما در حال حاضر در حال جمع آوری بازخورد اکوسیستم اضافی در مورد پیشرفتهای اضافی در سطح رویداد هستیم ، اما قصد داریم در حال حاضر اجرا شود. ما از بازخوردهای اضافی در مورد موارد استفاده که ممکن است از برخی از پیشرفتهای انعطاف پذیر در سطح رویداد ذکر شده در اینجا بهره مند شود استقبال می کنیم.
پردازش سطل	درخواست برای در نظر گرفتن مشارکت های جمع شده برای سطل ها و همچنین قابلیت گسترش آینده و سازگاری به عقب.	ما در مورد این درخواست بحث می کنیم و از بازخورد اضافی در اینجا استقبال می کنیم.
اپسیلون	هنگامی که ARA در دسترس بودن عمومی تغییر می کند ، در محدوده Epsilon چه اتفاقی می افتد؟	ARA در Q3 2023 در دسترس بودن کلی در Chrome قرار گرفت. در این زمان ، هیچ برنامه ای برای اصلاح پنجره ارزش Epsilon وجود ندارد. پیشنهاد ما برای یک ساختار حاکمیتی اصلاح شده ، تضمین های اضافی را در صورت پیش بینی هرگونه اصلاح ارائه می دهد.
گزارش	گزارش های Trigger-Nunnown-Eror حاوی ویژگی های منبع در بدنه گزارش نیستند.	همانطور که در مشخصات مشخص شده است ، نیازی به حضور سایر زمینه ها در بدنه گزارش برای خطای ناشناخته ماشه نیست. ما می دانیم که جدول توصیف زمینه های موجود در بدنه گزارش به طور بالقوه گمراه کننده است ، زیرا زمینه های مرتبط با منبع ممکن است بسته به علت اصلی خطا وجود داشته باشد یا نباشد. به عنوان مثال ، قبل از وقوع منطق تطبیق منبع ، یک خطای داخلی ممکن است رخ دهد ، این بدان معنی است که هیچ منبع منبع برای جمع آوری گزارش اشکال زدایی در دسترس نیست. اسناد اکنون برای روشن شدن این موضوع به روز شده است.
استفاده API	آیا هنگام کار با دو هدف اندازه گیری ، شمارش و ارزش ، نشانه تقسیم بودجه مشارکت و اپسیلون است؟	هنگام کار با دو هدف اندازه گیری ، توصیه می کنیم بودجه مشارکت بین آنها را تقسیم کنید.
گزارش	آیا ARA از گزارش های چند لمسی یا گزارش های کمک (گزارش مشارکت AKA) پشتیبانی می کند؟	ARA در حال حاضر از گزارش های چند لمسی یا گزارش های کمک پشتیبانی نمی کند. در حال حاضر ما هیچ برنامه ای برای اجرای این کار نداریم. ما از بازخورد اضافی در مورد موارد استفاده و اولویت آنها در اینجا استقبال می کنیم.
اشکال API	برای ARA ، مستندات بیان می کند که از XOR برای ترکیب منبع و محرک های کلیدی جمع آوری شده استفاده می شود ، اما در عمل یا استفاده می شود. این اختلاف منجر به سردرگمی و خطاهای احتمالی در اجرای آن می شود.	اسناد به روز شده است تا منعکس شود که این یک خطا است.

سرویس تجمیع

موضوع بازخورد	خلاصه	پاسخ کروم
مشاغل تجمع	درخواست اجازه دادن به پیشوندهای متعدد در مشاغل جمع آوری.	ما در حال بررسی این بازخورد هستیم و پیشنهادی را در اینجا ارسال کرده ایم. ما از بازخورد در مورد پیشنهاد در اینجا استقبال می کنیم.
درخواست ویژگی	درخواست تغییر اسکریپت Terraform به طوری که اگر Service_Account_Token_Creator_List تنظیم نشده باشد (یا خالی باشد) ، پس از آن اصلاح خط مشی IAM حساب می شود.	ما در اینجا در حال بررسی این موضوع هستیم و از بازخورد اکوسیستم اضافی استقبال می کنیم.
استفاده API	شفاف سازی مورد نیاز در مورد طرح Terraform همیشه تغییرات را نشان می دهد.	این مسئله در نسخه AGS 2.8 برطرف شده است.
استفاده API	به دنبال توصیه هایی برای تنظیم تنظیمات برای هر تبلیغ برای فرکانس تجمع با فیلتر سهم انعطاف پذیر است.	دسته بندی توسط تبلیغات در حال حاضر با ARA امکان پذیر است. فیلتر سهم انعطاف پذیر می تواند برای موارد پیشرفته تر مورد استفاده قرار گیرد که یک فناوری تبلیغی می خواهد سهم بیشتر گزارش توسط فرکانس های مختلف را انجام دهد. فناوری های تبلیغاتی می توانند در مورد دسته بندی در اینجا و استفاده از شناسه های فیلتر با ARA در اینجا اطلاعات بیشتری کسب کنند. ما همچنین در حال کار بر روی مستندات بیشتر برای فیلتر شناسه هستیم.
درخواست ویژگی	درخواست پشتیبانی از `log_sum_exp` در خدمات جمع آوری (AGS).	ما برای اطلاعات بیشتر در مورد مورد استفاده به این ذینفعان رسیده ایم. ما پس از جزئیات بیشتر ، به روزرسانی ارائه خواهیم داد.
درخواست ویژگی	درخواست کنید هر زمان که در مورد AG ها و مسائل بالقوه در مورد AG های مستقر وجود داشته باشد ، می توانید سیاهههای مربوط/بینش/سایر معیارها را ببینید.	ما به روزرسانی هایی را در مستندات خود منتشر کرده ایم تا خطاهای بیشتر ، کاهش و توضیحات را در اینجا شامل شود. ما از بازخوردهای اضافی در مورد هرگونه خطا/معیارها/سیاهههای مربوط و غیره که مستند یا در دسترس نیستند استقبال می کنیم و در اینجا چه جزئیات می تواند مفید باشد.
تست API	مقدار نهایی اپسیلون بعد از دوره آزمون چه خواهد بود؟	در این زمان ، هیچ برنامه ای برای اصلاح پنجره Value Epsilon وجود ندارد. ما آزمایش کنندگان را تشویق می کنیم تا با پارامترهای مختلف آزمایش کنند و بازخورد ارائه دهند.
گزارش	گزارش در حال تولید است ، اما هنوز هم در کد بازگشت ، حریم خصوصی_Budget_Authorization_Error را دریافت می کند.	ما در مورد مشخص کردن منشأ صحیح گزارش و گزارش های قابل جمع آوری برای جلوگیری از این خطا راهنمایی هایی را ارائه داده ایم. ما از بازخورد اضافی در مورد این مسئله استقبال می کنیم ، به ویژه در صورت وجود خطاهای مکرر.
کشف کلیدی	برنامه های پیشنهادی برای کشف کلیدی چیست؟	ما هنوز یک جدول زمانی برای بازپرداخت پیشنهاد کلیدی کشف نداریم اما در حال درخواست بازخورد از اکوسیستم در مورد پیشنهاد اینجا هستیم.
سفارشی سازی	به دنبال گزینه های سفارشی سازی در دسترس برای خدمات جمع آوری.	سفارشی سازی سرویس جمع آوری در داخل TEE امکان پذیر نیست اما برای برخی از مؤلفه های خارج از TEE امکان پذیر است. این به دلیل استانداردهای حریم خصوصی و امنیتی است که ما باید در درون TEE حفظ کنیم. ما در حال کار بر روی به روزرسانی اسناد خود هستیم تا به فناوری های تبلیغاتی در درک معماری و مؤلفه های قابل تنظیم کمک کنیم. ما نمی توانیم از شخصی سازی خاصی پشتیبانی کنیم ، بنابراین توصیه می کنیم تکنیک های تبلیغاتی را در صورت امکان از تنظیمات استاندارد خود استفاده کنند.
نقطه در مقابل نمونه های تقاضا	آیا این سیستم با استفاده از نمونه های نقطه ای در مقابل نمونه های مورد تقاضا آزمایش شده است؟ آیا جدا از عدم دسترسی موقت بالقوه آنها ، اشکالاتی خاص برای استفاده از نمونه های نقطه ای وجود دارد؟	ما آزمایش را در موارد نقطه ای در اولویت قرار نداده ایم زیرا توصیه می کنیم تکنیک های تبلیغاتی را برای استفاده از نمونه های مورد تقاضا استفاده کنید. اشکال نمونه های نقطه ای می تواند شغل در هنگام مصرف بودجه قطع شود. اگر بودجه مصرف شده باشد و کار قبل از دریافت فناوری تبلیغی گزارش خلاصه ، قطع شود ، تکنیک های تبلیغاتی به سادگی قادر به آزمایش مجدد کار نخواهند بود بلکه نیاز به درخواست بازیابی بودجه دارند. بازیابی بودجه فقط برای شکست فاجعه بار در حفظ حریم خصوصی توصیه می شود. ما توصیه می کنیم تکنیک های تبلیغاتی برای کمک به به حداقل رساندن هزینه ها ، Autoscaling را پیکربندی کنید. انتخاب 0 برای AutoScaling به این معنی است که تا زمان درخواست شغلی نمونه های در حال اجرا وجود نخواهد داشت (توجه داشته باشید که این ممکن است تأخیر را افزایش دهد زیرا نمونه ها در زمان درخواست می چرخند).
خطاها و راه حل های شناخته شده	شفاف سازی مورد نیاز در مورد کار خدمات جمع آوری "خطای سرویس"	این مسئله در اینجا حل شده است. ما همچنین برخی از پیام های خطای خود را به روز کرده ایم تا آنها را توصیفی تر کنیم. به عنوان مثال ، ما شروع به پرتاب خطاهای مجوز/AUTH خاص تر بر روی AWS کرده ایم ، برخلاف قبلاً وقتی این خطاها به عنوان خطاهای داخلی ظاهر می شدند. ما مستندات را در مورد کدهای خطا و مراحل کاهش در اینجا به روز کرده ایم و از بازخورد اضافی در مورد خطاهایی که مستند یا در دسترس نیستند استقبال کرده ایم و چه جزئیات در اینجا مفید خواهد بود.

API تجمع خصوصی

موضوع بازخورد	خلاصه	پاسخ کروم
طراحی کلیدی	درخواست راهنمای طراحی کلیدی جمع آوری خصوصی	در حالی که ما یک راهنمای خاص جمع آوری خصوصی نداریم ، هر دو چارچوب تست بار خدمات جمع آوری و راهنمای مدیریت کلید پیشرفته می توانند به عنوان منابع استفاده شوند.
بودجه مشارکت	بودجه مشارکت در چه سطحی محاسبه و محدود است؟	بودجه مشارکت 2^16 در یک پنجره 10 دقیقه ای نورد و 2^20 در یک پنجره 24 ساعته نورد است.

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

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

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

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

موضوع بازخورد	خلاصه	پاسخ کروم
اندروید	برنامه ای برای محافظت از IP به اندروید چیست؟	While we are exploring bringing anti-covert tracking features to Android, including IP Protection, we don't have formal plans to share at this time.
API Usage	Question on if there is or will be an anti-fraud exception for IP Protection?	We strive to strike a balance between protecting users from being tracked across the web based on their IP addresses while minimizing disruption to the normal operations of servers, including the use of IP addresses for anti-abuse. While we cannot provide more details at the moment, we expect to provide them in the near future and look forward to continuing the discussion.
Bad Actor Identification	Concerns regarding the effectiveness of traditional security measures against malicious IP addresses.	IP Protection will not proxy 1P requests, so we expect most Intrusion Detection Systems will not be impacted. We plan to provide additional details in the future that address anti-fraud and site breakage concerns for incognito users.
پوشاندن آدرس IP	If the news publisher site (1P) uses the same domain with the advertising site (3P), will the IP address be masked for both? If not, how does one distinguish the two?	IP Protection currently proposes a list-based approach to identify which third-party traffic goes through the proxies. However, even if an origin is on that list, it won't be proxied if accessed in a 1P context. We are finalizing the details regarding which specific 3P domains will be prioritized initially and how we'll precisely define 1P and 3P contexts for IP Protection.
پوشاندن آدرس IP	Concern about IP protection and its impact on anti-fraud systems.	1Ps are not impacted by our IP Protection plans, so sites such as forums should have access to IP addresses for dispute resolution. We plan to provide additional details in the future that address advertising fraud concerns.
پوشاندن آدرس IP	Is the IP masked in the header for impacted domains?	Users will be assigned to a geographic area based on their pre-proxy IP address representing their current location. شما می توانید جزئیات بیشتر را در اینجا بیابید.

Bounce Tracking Mitigation

Feedback Theme	خلاصه	Chrome Response
مشخصات API	Clarification needed on the behavior of Chrome's handling of extended navigation when a tab is closed.	We have resolved this issue here and updated the specification accordingly.
Nav Tracking	Discussion of a tracking mitigation approach involving a finite set of links to reduce entropy in cross-site requests.	We are continuing to discuss this topic with other browser vendors here , and welcome additional feedback and any specific proposals on this issue from the ecosystem.

Privacy Budget

As noted in the GitHub explainer and developer site , Privacy Budget is no longer being actively
considered as part of the Privacy Sandbox proposals.

Strengthen cross-site privacy boundaries

Related Website Sets (formerly First-Party Sets)

Feedback Theme	خلاصه	Chrome Response
(Also reported in previous quarters) Related Website Set (RWS) Domain Limit	Request to increase the limit of Associated domains within RWS	Our response is similar to previous quarters: At present, we do not expect to increase the numeric limit. The limit was established based on user privacy considerations, feedback from ecosystem stakeholders in the W3C, and consideration of comparable implementations in other browsers. For additional information, please see our blog posts ( 1 , 2 ). We recommend examining use cases that require cross-site cookie access beyond the numeric limit, and consider leveraging our guidance for identity use-cases , authenticated embeds , and advertising use cases . If the user sessions are tied to login actions, we would recommend using the Federated Credential Management (FedCM) API to maintain functionality. We welcome feedback on other use cases which may be required here .
Cross-site cookie handling	Cross-site cookies set by a subdomain are not being passed in subsequent requests from the primary domain. The problem persists even with proper CORS and credential configurations.	We provided guidance here regarding correct usage of the requestStorageAccessFor API needing to specify the full origin (ie include subdomains) in order for cross-site cookies to be sent on subsequent fetch requests.
User Choice	Request for further information regarding requestStorageAccessFor used by RWS after the rollout of user choice, in particular how the implicit or explicit user gesture, which currently allows access to 3PCs, will function in the new system.	We expect that the behavior of RWS in either user choice mode, (ie, regardless of whether users have chosen to retain or limit their 3PCs) will be consistent with existing/shipping behavior in Chrome with 3PCs allowed vs. 3PCs blocked with RWS enabled ("Allow related sites to see your activity in the group" setting). We recommend invoking hasStorageAccess first to check whether the embed already has access to unpartitioned cross-site cookies before invoking requestStorageAccess. The hasStorageAccess method will return true if the user chose to allow 3PCs. requestStorageAccessFor currently does not require a user gesture if 3PCs are allowed. We have opened a new GitHub issue to discuss and specify what the right behavior should be in this case, and welcome additional feedback from the ecosystem.
API Usage	Concerns about the lack of clarity regarding the use of RWS for "commercial" purposes, hindering their adoption. The stakeholder indicated interest in grouping publications for targeted advertising.	The intended use of RWS is to support core site functionality and core user journeys. We encourage using our purpose-built advertising APIs for use cases related to targeted advertising.
API Usage	Report of an issue with requestStorageAccess where they could set localStorage data but not cookies.	The issue was caused by a typo in the SameSite attribute. Ensure correct spelling and explicitly set it to None for 3PCs.
مشخصات API	Discrepancies in the JSON schemas across the repository, such as the misplacement of the "contact" field and suggestions for improvements, including the use of the "oneOf" keyword to ensure consistency.	We are investigating this feedback and will look into making these improvements to the schema in the near future. We welcome additional feedback here .
Third-party (3P) access to RWS	With given user consent, allow an outlet to indicate the 3P domains that will also have such access to the RWS API data.	Allowing 3Ps to combine their own unpartitioned data with RWS site data would undermine Privacy Sandbox's cross-site tracking protections. However, we are considering the potential for enabling 3Ps to maintain data partitioned to an RWS and are seeking feedback on the design for such a solution here .

Fenced Frames API

Feedback Theme	خلاصه	Chrome Response
API Question	Concerns on how Fenced Frames with no network access could break brand safety and fraud protection for advertisers.	We are tracking this concern in the context of our plan to enforce Fenced Frames. We will start looking soon into solutions that are compatible with Fenced Frames enforcement and as soon as proposals exist that are material enough we will share them.
API Question	Is Fenced Frames API still scheduled for 2026?	As stated in our public announcement , Fenced Frames will be required no sooner than 2026.
API Bug	When reportEvent() successfully sends click data from a cross-origin subframe, setReportEventDataForAutomaticBeacons() does not overwrite the top frame's data.	We are discussing this issue and welcome additional feedback here .

Shared Storage API

Feedback Theme	خلاصه	Chrome Response
App Advertising	There is no equivalent of the Shared Storage API in Privacy Sandbox on Android.	We are evaluating solutions on Android based on use case needs and platform constraints. We do not have any plans to share at the moment, but we welcome additional feedback from the ecosystem on this issue.
API Usage	Confusion regarding the need for an additional javascript worklet for implementation for Shared Storage API.	We are investigating this feedback and looking into potentially updating our documentation to explain the need for additional worklet scripts for Share Storage API.
غیر قابل اعتماد بودن	Shared Storage API could change significantly or be dropped based on the privacy criticisms, making it an unreliable base to build on.	We do not have plans to significantly change or drop the Shared Storage infrastructure. The main changes that have been announced are to the Select URL output gate where fenced frames will be required and event level reporting will be deprecated. However these changes will not go into effect until at least 2026.

چیپس

Feedback Theme	خلاصه	Chrome Response
Partitioned Cookies	Chrome does not differentiate partition keys based on frame ancestors, unlike Firefox, leading to inconsistencies.	Chrome adopted the "ancestor chain bit" to resolve the security concern and discrepancy with Firefox's behavior. We have set this out in further detail here .
Partitioned Cookies	Embedded iframes with different storage access levels share and overwrite the same partitioned cookie, causing inconsistencies in authentication states.	For this particular configuration, our recommendation is to use unpartitioned cookies with an invocation of Storage Access API. We have discussed this in further detail here .
Partitioned Cookies	Will partitioned cookie jars be cleared when 3PCs are disabled? Is there a way to test this behavior?	We do not have any plans to share at this time. However, developers can test this functionality by manually deleting partitioned cookies via the Chrome DevTools Application>Cookies panel.

FedCM

Feedback Theme	خلاصه	Chrome Response
Identity Provider (IdP) Registration Scope & Organization Chooser	Question on extending IdP registration from the current same-origin policy to a same-site policy. This change would allow broader and more flexible identity management, such as enabling a university's welcome page to register multiple subdomain-based identity providers without needing separate origin-specific registrations. Feedback on improving debuggability, handling approved clients for silent mediation, clarifying cookie behavior, allowing customization of the popup wording, and addressing timeout issues.	We acknowledge this feedback and are considering how an organization chooser could be incorporated into FedCM. We welcome additional feedback from the ecosystem here as we continue to refine this approach.
IdP Cookies	Discussion on the impact of implementing short-lived session cookies as part of the Device Bound Session Credentials (DBSC) proposal. Concerns are raised about user experience in FedCM, where expired IdP cookies require a user-visible modal for renewal.	The proposed DBSC should allow for cookie renewal without user interaction, ensuring continuous user experience. We have discussed this issue in further detail here .
مشخصات API	Question on appropriateness of using "NetworkError" in the FedCM API specification when the size of the "providers" array is not equal to 1.	We agree that "TypeError" would be more appropriate for this situation since it reflects a coding error rather than a network issue. We will consider this change and explore the possibility of removing this restriction in future updates as we progress towards multi-IdP support. We welcome additional feedback here .

Fight spam and fraud

Private State Token API (and other APIs)

Feedback Theme	خلاصه	Chrome Response
Deprecation Trial & Mode B	Concerns about the deprecation trial, Mode B testing, the potential discontinuation of Private State Tokens (PSTs), and the possibility of a new API better suited for their anti-fraud use case.	The deprecation trial and Mode B testing remain unchanged. We will communicate any updates through the dev blog . We have no plans to discontinue PSTs and we are discussing ongoing feature development and updates on GitHub . We have not announced any new APIs, but we welcome feedback on how PSTs can better address anti-fraud use cases.
API Feedback	Request for the capability of revoking tokens to address an anti-fraud use case.	While the issuer could revoke all tokens by changing the keys they use, individual token revocation is infeasible with the API as it would require allowing the issuer to associate token issuance and redemption which breaks the PST privacy model of preventing tracking between the two events.