گزارش بازخورد - 2025 Q2، گزارش بازخورد - 2025 Q2

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

Google این گزارش فصلی را به عنوان بخشی از تعهدات خود به سازمان رقابت و بازار ("CMA") تحت پاراگراف های 12، 17(c)(ii) و 32(a) تهیه کرده است. این گزارش پیشرفت Google در پیشنهادات جعبه ایمنی حریم خصوصی را پوشش می‌دهد. انتظارات زمان بندی به روز شده؛ توضیحات اساسی در مورد اینکه چگونه Google مشاهدات انجام شده توسط اشخاص ثالث را در نظر گرفته است. و خلاصه ای از تعاملات بین Google و CMA، از جمله بازخورد از CMA و رویکرد Google برای پرداختن به بازخورد.

Google CMA را در خصوص پیشرفت پیشنهادات جعبه ایمنی حریم خصوصی در جلسات منظم وضعیت خود که مطابق با بند 17 (ب) تعهدات برنامه ریزی شده است، به روز نگه می دارد. علاوه بر این، تیم اسناد توسعه‌دهنده را حفظ می‌کند که مروری بر ویژگی‌های اصلی تبلیغات خصوصی و تغییرات کوکی‌ها ، همراه با اجرای API و اطلاعات وضعیت ارائه می‌دهد. به‌روزرسانی‌های کلیدی در وبلاگ توسعه‌دهنده به همراه به‌روزرسانی‌های هدفمند به اشتراک‌گذاشته‌شده در فهرست‌های پستی توسعه‌دهنده فردی به اشتراک گذاشته می‌شوند.

با در نظر گرفتن مشاهدات انجام شده توسط اشخاص ثالث

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

آرا
Attribution Reporting API
چیپس
کوکی هایی که دارای حالت تقسیم شده مستقل هستند
DSP
پلتفرم سمت تقاضا
FedCM
مدیریت اعتبار فدرال
IAB
دفتر تبلیغات تعاملی
بیجاشدگان داخلی
ارائه دهنده هویت
IETF
کارگروه مهندسی اینترنت
IP
آدرس پروتکل اینترنت
openRTB
مناقصه در زمان واقعی
OT
آزمایش مبدا
PA API
API مخاطب محافظت شده (FLEDGE سابق)
PatCG
گروه اجتماعی فناوری تبلیغات خصوصی
RP
حزب اتکا
RWS
مجموعه‌های وب‌سایت مرتبط (سست‌های شخص اول سابق)
SSP
پلت فرم سمت عرضه
UA
رشته عامل کاربر
UA-CH
نکات مشتری عامل کاربر
W3C
کنسرسیوم وب جهانی
WIPB
کوری IP ارادی

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

موضوع بازخورد خلاصه پاسخ کروم
آینده Sandbox حریم خصوصی با توجه به اعلام عدم ادامه معرفی مکانیزم انتخاب کاربر برای 3PC، برخی از APIها در صورت وجود 3PC مفیدتر از بقیه هستند و برخی دیگر برای مفید بودن باید تکامل یابند. حوزه‌های بالقوه دیگری برای سرمایه‌گذاری برای Chrome فراتر از APIهای Privacy Sandbox وجود دارد. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PC به کاربران در Chrome حفظ خواهد شد، ما از بازخورد قدردانی می‌کنیم و به تعامل با سهامداران ادامه می‌دهیم تا نقشی را که APIهای Sandbox Privacy می‌توانند در آینده ایفا کنند و همچنین برای کاوش در زمینه‌های جدید برای سرمایه‌گذاری‌های آتی ایفا کنند.
جعبه ایمنی حریم خصوصی برخی از شرکت‌کنندگان اکوسیستم از اعلام عدم ادامه معرفی مکانیزم انتخاب کاربر برای 3PC ناامید شده‌اند، اما به کار انجام‌شده افتخار می‌کنند، از چالش‌های فنی در جعبه ایمنی حریم‌خصوصی قدردانی می‌کنند و بر ارزش رابطه کاری مشترک خود با Chrome و سودمندی کمک هزینه تست بازار تأکید کرده‌اند. ما از بازخورد قدردانی می‌کنیم و موافقیم که Chrome می‌تواند و باید با توسعه‌دهندگان برای ایجاد فناوری‌هایی همکاری کند که حریم خصوصی آنلاین را بهبود می‌بخشد و در عین حال اینترنت پشتیبانی‌شده از تبلیغات را حفظ می‌کند.
به اشتراک گذاری داده های مرورگر اشتراک گذاری داده با واسطه مرورگر یک فناوری قانع کننده با پتانسیل برای رسیدگی به ناکارآمدی های بازار و مشکلات اعتماد است. مرورگر به عنوان زمینه اجرای شخص ثالث برای همکاری ارزش دارد. ما از بازخورد قدردانی می‌کنیم و موافقیم که Chrome می‌تواند و باید در ایجاد فناوری‌هایی که اعتماد بین توسعه‌دهندگان و کاربران همکار را افزایش می‌دهد، به توسعه‌دهندگان کمک کند.
ترافیک کروم سهم ترافیک بدون کوکی در Chrome و سهم ترافیک برای حالت ناشناس چقدر است؟ همانطور که توسط CMA در " اطلاعیه از قصد آزادسازی تعهدات " اشاره شده است، حالت ناشناس فقط بر بخش بسیار کوچکی از فعالیت مرور تأثیر می گذارد. در هر یک از بریتانیا و منطقه اقتصادی اروپا، حالت ناشناس کروم نشان‌دهنده موارد زیر است: کمتر از 10٪ از پیمایش‌ها در دستگاه‌هایی که روی سیستم عامل Android کار می‌کنند. و کمتر از 10٪ از ناوبری در دستگاه های در حال اجرا بر روی سیستم عامل ویندوز. این معیارها فقط به پیمایش در Chrome مبتنی بر Chromium در بریتانیا و منطقه اقتصادی اروپا اشاره دارد.
ما اطلاعات مربوط به مرورگرهایی که 3 رایانه شخصی را مسدود می کنند به اشتراک نمی گذاریم.
توسعه‌دهندگان ممکن است تعیین کنند که چه زمانی کوکی‌ها با استفاده از سربرگ‌های دسترسی به فضای ذخیره‌سازی پارتیشن بندی می‌شوند و بر این اساس از اقدامات کاهشی موجود استفاده کنند.
برچسب‌های آزمایش کروم برنامه Chrome برای 1٪ از ترافیک بدون کوکی که برای آزمایش در سال 2024 فعال شد چیست؟ ما در حال حاضر برنامه ای برای اشتراک گذاری نداریم، اما قصد داریم به محض در دسترس قرار گرفتن آنها را به صورت عمومی به اشتراک بگذاریم.
تست کروم آیا راه‌اندازی برچسب آزمایشی فعلی شامل درمان برای سناریوهایی است که در آن هر دو 3PC در دسترس هستند و APIهای Privacy Sandbox فعال هستند؟ راه‌اندازی برچسب آزمایشی فعلی شامل درمان برای 3PC و APIهای Privacy Sandbox در قالب حالت A است.
جعبه ایمنی حریم خصوصی برخی از تبلیغ‌کنندگان، APIهای Privacy Sandbox را پیچیده می‌دانند و به‌دلیل تمرین‌های آمادگی قبلی، بی‌تفاوتی را تجربه می‌کنند، چگونگی تعیین کمیت مزیت برای پذیرندگان اولیه را زیر سؤال می‌برند، و به دنبال آموزش در مورد اثرات هدف‌گیری مجدد، جستجو و اندازه‌گیری هستند. ما از بازخوردها قدردانی می کنیم و احساسات مربوط به پیچیدگی فن آوری و تمرینات آمادگی را درک می کنیم.
با توجه به درک عملکرد فناوری‌های جعبه ایمنی حریم خصوصی، نتایج آزمایش ما نشان داد که مشارکت در اکوسیستم یک عامل مهم در درک عملکرد راه‌حل‌های جعبه ایمنی حریم خصوصی است. آزمایش در حجم کم نمی تواند پویایی بازار و انگیزه های استفاده از فناوری ها در مقیاس را بازتولید کند.

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

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

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

موضوعات

موضوع بازخورد خلاصه پاسخ کروم
عملکرد و علاقه مفید به موضوعات API با پیشرفت‌ها بازخورد سهامداران سمت خرید نشان می‌دهد که Topics API سیگنال ارزشمندی است و منجر به داده‌های Cost per Impression (CPM) می‌شود که با آن برای مخاطبان 3PC، برای کمپین‌های تبلیغ‌کننده رقابت می‌کند. برخی ناشران سیگنال Topics API را نسبت به سیگنال‌های وب باز استاندارد با کیفیت‌تر می‌دانند. با توجه به این بازخورد در مورد ابزار Topics API، سهامداران درخواست بهبودهایی مانند بهبود وفاداری طبقه بندی، سازگاری، و گسترش کنترل های ناشر برای ایجاد پذیرش گسترده تر دارند. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
مفید بودن برای
انواع مختلف
ذینفعان		 از آنجایی که طبقه‌بندی‌کننده Topics در حال حاضر فقط از نام میزبان صفحه برای تعریف موضوعات مربوطه استفاده می‌کند، سایت‌های بزرگ با محتوای متنوع موضوعات عمومی را ارائه می‌کنند در حالی که سایت‌های کوچک موضوعات خاص با ارزش تبلیغاتی بیشتری را ارائه می‌کنند. پاسخ ما مشابه فصل های قبل است:
همانند 3PCها، تفاوتی در ارزش اطلاعات ارائه شده توسط سایت های مختلف وجود دارد. سایت‌های با علاقه در ارزش خود متناقض هستند: همه سایت‌های با علاقه دارای محتوای تجاری با ارزش نیستند و بنابراین ارزش کمتری دارند. اینها سایت هایی هستند که از Topics API بهره مند می شوند. ما امکان طبقه‌بندی در سطح صفحه را به جای طبقه‌بندی در سطح سایت در نظر گرفته‌ایم، با این حال، تعدادی از نگرانی‌های مهم حریم خصوصی و امنیتی با چنین طبقه‌بندی وجود دارد.
موضوعات طبقه بندی به اندازه کافی دانه بندی نشده است Topics API جزئیات کافی را برای ناشران خبری با بخش‌های محتوای متنوع در یک دامنه فراهم نمی‌کند، و به طور بالقوه مفید بودن API را برای هدف‌یابی تبلیغات محدود می‌کند. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
بهبود طبقه بندی به ناشران اجازه دهید به Chrome اجازه دهند تا موضوعات را بر اساس محتوای صفحه (مانند سر، بدن) طبقه بندی کند. ما در حال بررسی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم.
سیاست درخواست توضیح در مورد دستورالعمل‌های مربوط به استفاده از Topics API در ارتباط با اطلاعات 3PC. هیچ مشکلی برای استفاده از Topics API و 3PC وجود ندارد، زیرا Topics API زیرمجموعه ای از عملکردهای 3PC را ارائه می دهد.
مشاهده-مرور-سربرگ موضوعات درخواست توضیح در مورد اجرای سربرگ Observe-Browse-Topics، به ویژه اینکه آیا بازگرداندن مداوم هدر باعث ایجاد مشکل می شود یا خیر. بازگرداندن مداوم هدر Observe-Browse-Topics: ?1 هیچ مشکل فنی ایجاد نمی کند.
مرورگر این سیگنال را به طور موثر مدیریت می کند، فقط به این نکته توجه می کند که بازدید از صفحه برای محاسبه موضوع بدون ایجاد تکرار یا خطا واجد شرایط است. در حالی که در هر صفحه لازم نیست، ارسال آن به عنوان یک سربرگ استاندارد در تمام اسناد سطح بالا یک استراتژی معتبر و ساده است.
دسته بندی طبقه بندی درخواست به روز رسانی آخرین طبقه بندی موضوعات با موضوعات جدید. ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم در اینجا استقبال می کنیم.
مقادیر پوچ درخواست راهنمایی برای بهبود عملکرد Topics API و درک دلایل پشت پاسخ‌های پوچ، مانند فیلتر کردن یا حساسیت. برای وضوح، پاسخ های null یا خالی از Topics API یک ویژگی حریم خصوصی مورد انتظار است، نه یک خطا.
پاسخ null می تواند ناشی از موارد زیر باشد:
• قوانین حفظ حریم خصوصی: یک شانس null تصادفی 5٪، یا به این دلیل که اسکریپت شما کاربر را در سایت های مرتبط با آن موضوع "مشاهده" نکرده است.
• وضعیت کاربر: سابقه مرور ناکافی، استفاده از حالت ناشناس، یا انصراف کاربر در تنظیمات حریم خصوصی تبلیغات Chrome.
• خطاهای فنی: سایت های ناشر باید سرصفحه Observe-Browse-Topics: ?1 را ارسال کنند، و هر فریم فراخوانی به allow="Browse-topics" نیاز دارد.
برای بررسی، از صفحه اشکال زدایی chrome://topics-internals استفاده کنید تا ببینید مرورگر شما چه موضوعاتی را محاسبه کرده است و چرا.
در حالی که ویژگی‌های حریم خصوصی از نرخ پر شدن ۱۰۰٪ جلوگیری می‌کنند، می‌توانید عملکرد را با موارد زیر بهبود بخشید:
• کار با ناشران: مطمئن شوید که شرکای شما به درستی هدر Observe-Browse-Topics: ?1 را در سایت های خود ارسال می کنند.
• تأیید کد شما: اگر از iframe استفاده می کنید، تأیید کنید که خط مشی allow="Browse-topics" وجود دارد.

API مخاطبان محافظت شده

موضوع بازخورد خلاصه پاسخ کروم
پذیرش PA API با هزینه و پیچیدگی مانع شده است پذیرندگان با استناد به هزینه‌های عملیاتی، کمبود تقاضای تبلیغ‌کننده و حجم کم موجودی صرافی‌ها، ادغام‌های API مخاطب محافظت‌شده (PA API) را از اولویت خارج می‌کنند یا عقب می‌اندازند.
برخی از بازخوردها شامل مزایای پتانسیل PA API بود، مانند توانایی آن در ارائه مخاطبان بادوام و دسترسی برتر به دلیل نرخ تطابق بالا.		 با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
قابلیت کراس پلت فرم عملکرد چند پلتفرمی باید با استفاده از PA API در سراسر پلتفرم‌ها برای باز کردن قابلیت‌های هدف‌گیری مجدد و مخاطبان بیشتر پشتیبانی شود. Google باید گروه‌های علاقه (IG) ثبت‌شده در Chrome را فعال کند تا هنگام ارائه تبلیغات در محیط‌های بومی یا در نمای وب در دسترس باشند و گروه‌های علاقه ثبت‌شده در Android باید در حراج‌های Chrome در دسترس باشند. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
directFromSellerSignals با محدود کردن مقدار اطلاعات موجود در حراج متنی، شرکت کنندگان در حراج همیشه از طریق سرور تبلیغات گوگل هدایت می شوند. یک ناشر باید ابتدا با همه شرکای مبادله خود تماس بگیرد، سپس Google Ad Manager (GAM) را برای اجرای حراج متنی و در نهایت به GAM اجازه دهد تا حراج های IG را فراخوانی کند. بدون دانستن نتیجه حراج متنی در زمان واقعی، هیچ رقیبی نمی تواند به طور منصفانه یک تصمیم سطح بالا را تنظیم کند.

ویژگی directFromSellerSignals در PA API ممکن است در مورد اطلاعات حراج شفافیت نداشته باشد و به طور بالقوه مانع از دسترسی به داده های ضروری شود. Google باید directFromSellerSignals را حذف کند یا آن را به روز کند تا نتوان از آن برای پنهان کردن قیمت تسویه حراج سرور تبلیغات استفاده کرد. برای مثال، قیمت متنی را می‌توان از طریق یک فیلد شفاف، غیرقابل تغییر و امضا شده از طریق Chrome منتقل کرد که همه شرکت‌کنندگان حراج (و ناشر) می‌توانند به آن دسترسی داشته باشند و تأیید کنند.		 پاسخ ما نسبت به فصل های گذشته بدون تغییر است:
پاسخ کروم :
اطلاعات ارسال شده به runAdAuction() معلوم نیست که از فروشنده می آید مگر اینکه فروشنده runAdAuction() را از iframe خودش فراخوانی کند. در یک حراج چند فروشنده، غیرممکن است که همه فروشندگان فریمی را با نام runAdAuction() ایجاد کنند. directFromSellerSignals با بارگیری محتوا از یک بسته منبع فرعی که از مبدا فروشنده بارگیری شده بود به این مشکل پرداخت. این تضمین می کند که صحت و یکپارچگی اطلاعات ارسال شده به حراجی از پیکربندی های فروشنده-حراج قابل دستکاری نیست. اگر ناشران بخواهند از PA API برای درک هر یک از اطلاعاتی که ارائه دهندگان فناوری آنها به حراج های PA منتقل می کنند استفاده کنند، می توانند این قابلیت را از آن ارائه دهندگان فناوری بخواهند.
پاسخ مدیر تبلیغات گوگل :
ما برای سال‌ها تمرکز شدیدی بر عادلانه بودن حراج داشته‌ایم، از جمله قول داده‌ایم که هیچ قیمتی از منابع تبلیغاتی تضمین‌نشده ناشر، از جمله قیمت‌های اقلام خطی غیر تضمینی، با خریدار دیگری قبل از پیشنهاد در حراج به اشتراک گذاشته نمی‌شود، که بعداً در تعهدات خود به سازمان رقابت فرانسه مجدداً تأیید کردیم.
برای حراج‌های مخاطب محافظت‌شده، ما قصد داریم با استفاده از directFromSellerSignals به قول خود عمل کنیم و قبل از اتمام حراج در حراج‌های چند فروشنده، پیشنهاد هیچ شرکت‌کننده حراج را با هیچ شرکت‌کننده دیگری در حراج به اشتراک نگذاریم. برای روشن بودن، همانطور که در این به‌روزرسانی توضیح داده شد، ما قیمت حراج متنی را با حراج مؤلفه خودمان نیز به اشتراک نمی‌گذاریم.
گزارش دهی درخواست اضافه کردن یک نهاد تجزیه و تحلیل/گزارش برای فعال کردن گزارش‌دهی متمرکز. ما در حال بحث در مورد این درخواست در اینجا هستیم و از بازخورد اضافی استقبال می کنیم.
K-ناشناس بودن در buyerReportingId امکان کنار گذاشتن پیشنهادها بر اساس ناشناس بودن «buyerReportingId» برای تسهیل نظارت بر مخاطب و تعهدات گزارش با ارائه دهندگان داده شخص ثالث. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
اشکال زدایی بهبود یافته در اسکریپتgeneBid درخواست مکانیزمی برای شناسایی سریع مرحله خاص یا "نقطه شکست" در اسکریپتgeneBid که در آن فرآیند در حال شکست است. ما از استفاده مطلوب از اندازه‌گیری‌های بلادرنگ به عنوان مکانیزم تنظیم نقطه شکست برای حراج‌های روی دستگاه آگاه هستیم. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
شنوندگان رویداد برای نظارت بر وضعیت runAdAuction پیشنهاد اضافه کردن پشتیبانی شنونده رویداد به تابع navigator.runAdAuction PA API برای بهبود نظارت بر چرخه عمر حراج تبلیغات. ما در حال ارزیابی این درخواست هستیم و از بازخورد اضافی از اکوسیستم در اینجا استقبال می کنیم.
استفاده از API درخواست برای توضیح اینکه چگونه PA API و API Reporting Attribution (ARA) می‌توانند موارد استفاده از تبلیغات وب را در غیاب 3PC، به ویژه برای کاربرانی که از 3PC انصراف داده‌اند اما از APIهای Privacy Sandbox خارج نشده‌اند، و در سناریوهایی که شامل همگام‌سازی کوکی‌ها و WebView ناموفق است، پشتیبانی کند؟ با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
تأخیر تأخیر مرتبط با PA API می‌تواند مانع پذیرش شود، زیرا ناشران ممکن است در صورت زیاد بودن تأخیر PA API را غیرفعال کنند. چندین بهبود در تأخیر روی دستگاه در چند فصل گذشته انجام شد. ایجاد و مقیاس بندی خدمات مناقصه و مزایده (B&A) در صورت لزوم ادامه دارد. راهنمای بهترین شیوه‌های تأخیر ما به‌روزرسانی شد تا اطلاعات بیشتری در مورد نحوه بهره‌گیری از این ویژگی‌ها داشته باشد. ما همچنین در حال بررسی توسعه بهبودهای جدید تأخیر هستیم که برخی از آنها را می توان در اینجا مشاهده کرد.
رفتار گزارشگری در B&A (تست در مقابل تولید) توضیح در مورد تفاوت در رفتار ورود به سیستم بین حالت های آزمایش و تولید برای خدمات B&A. به طور خاص، در دسترس بودن گزارش‌های ابری و تأثیر حالت تولید بر ورود به سیستم. اول، مهم است که بین ساخت‌های prod و non_prod و پارامتر جداگانه TEST_MODE تمایز قائل شویم، که به سادگی یک کلید رمزگذاری آزمایشی سخت‌کد شده را فعال می‌کند. توضیح زیر بر روی انواع ساخت تمرکز دارد.
در ساخت‌های non_prod ، سرورهای B&A دارای یک سطح پرحرفی قابل تنظیم برای ورود به سیستم هستند. این گزارش‌های دقیق در جریان‌های استاندارد stdout/stderr نوشته می‌شوند. در Google Cloud، اینها از طریق رابط ورود به سیستم بومی قابل دسترسی هستند، و در سرویس‌های وب آمازون، آنها را می‌توان در گزارش‌های کنسول پیوست شده یافت.
برای ساخت‌های prod ، رفتار ورود به سیستم محدودتر است. سطح پرحرفی ثابت است و قابل تغییر نیست. در حالی که برخی از گزارش‌های غیرمرتبط با حریم خصوصی، مانند پیام‌های راه‌اندازی سرور و اکثر خطاهای خرابی، هنوز در stdout/stderr چاپ می‌شوند، هیچ گزارش خاص درخواستی از طریق این کانال در دسترس نیست. تنها گزارش‌های مربوط به هر درخواست از یک بیلد prod برای درخواست‌هایی هستند که حاوی یک نشانه اشکال‌زدایی رضایت‌بخش هستند و این موارد منحصراً از طریق OpenTelemetry صادر می‌شوند. بسیار مهم است که از اشکال‌زدایی رضایت‌بخش استفاده نکنید، زیرا ترافیک سنگین می‌تواند عملکرد سرور را کاهش داده و منجر به خرابی بررسی سلامت شود.
با توجه به معیارها ، همه از طریق OpenTelemetry صادر می شوند. معیارهای غیر حساس به حریم خصوصی همیشه همانطور که هستند، بدون هیچ گونه "نویز" صادر می شوند. برعکس، معیارهای حساس به حریم خصوصی زمانی که از سروری که در حالت تولید کار می‌کند صادر می‌شوند، همیشه "نویز" می‌کنند. پیکربندی خاص تله متری تعیین می کند که آیا این معیارهای حساس به حریم خصوصی به صورت نویز، بدون نویز یا هر دو صادر می شوند.
برای ایمنی برند، مسیر کامل صفحه را در سیگنال‌های مناقصه معتمد قرار دهید درخواست به‌روزرسانی PA API برای گنجاندن مسیر URL کامل صفحه سطح بالا، علاوه بر نام میزبان، در درخواست واکشی برای TrustedBiddingSignals.
مورد استفاده اولیه، فعال کردن کنترل‌های ایمنی بیشتر برند است. تبلیغ‌کنندگان اغلب نیاز دارند تا تبلیغات را از نمایش در بخش‌های خاصی از یک دامنه (مثلاً news-site.com/politics) مسدود کنند، در حالی که به طور کلی با دامنه راحت هستند. از آنجایی که این لیست های بلاک می توانند میلیون ها ورودی داشته باشند، باید در سمت سرور ارزیابی شوند. مشخصات فعلی که فقط نام میزبان را ارسال می کند، انجام این ارزیابی لازم در سطح مسیر را برای سرور trustedBiddingSignals غیرممکن می کند و قابلیت های ایمنی نام تجاری را محدود می کند.		 ما در حال حاضر در حال بحث در مورد این موضوع در اینجا هستیم، پس از بحث های گسترده قبلی، که می توان در اینجا مشورت کرد، و ما از بازخورد اضافی استقبال می کنیم.
با این حال، ما می‌خواهیم توضیح دهیم که فقط زمانی به اضافه کردن این اطلاعات فکر می‌کنیم که واکشی trustedBiddingSignals به سروری می‌رود که در داخل یک محیط اجرای مورد اعتماد (TEE) اجرا می‌شود.

حراج محافظت شده (خدمات B&A)

موضوع بازخورد خلاصه پاسخ کروم
در دسترس بودن تست اطلاعات مربوط به در دسترس بودن Key/Value (KV) v2 برای آزمایش در محیط‌های Chrome و B&A. KV v2 در B&A و Chrome در دسترس است. راهنمایی اضافی در اینجا موجود است.
پیاده سازی سرور KV درخواست توضیح در مورد استفاده از سرور KV، به ویژه در مورد نگاشت URL های رندر خلاقانه برای درخواست داده، لزوم هماهنگی بین SSP و DSP برای تعریف پارامترها در URL رندر، و در دسترس بودن مستنداتی که هماهنگی مورد نیاز و ذخیره داده ها را در حالت KV مشخص می کند. سرویس KV از renderURL به عنوان یک کلید استفاده می کند. اگر URL جدید باشد، ذخیره می شود. اگر وجود داشته باشد، مقدار آن برای استفاده در scoreAd برگردانده می شود. فرمت بازگشت به تنظیمات بستگی دارد: "Bring Your Own Server" (BYOS) هر مقداری را اجازه می دهد، در حالی که سرویس Trusted KV به یک تابع تعریف شده توسط کاربر نیاز دارد.
اگرچه همیشه لازم نیست، هماهنگی با DSPها برای ویژگی‌هایی مانند جایگزینی ماکرو (به عنوان مثال، ${AD_WIDTH}) در renderURL ضروری است، که سفارشی‌سازی و تأیید تبلیغات پویا را امکان‌پذیر می‌کند.
توصیه می کنیم برای تعیین سطح هماهنگی لازم با یک تست ساده با یک DSP شروع کنید. ما همچنین در حال به روز رسانی اسناد KV خود هستیم و پس از در دسترس قرار گرفتن آن را به صورت عمومی به اشتراک خواهیم گذاشت.
BYOS برای B&A چرا B&A حالت BYOS مشابه حالت BYOS KV را ارائه نمی دهد؟ B&A به یک TEE نیاز دارد که از یک مدل BYOS جلوگیری می کند، زیرا ترکیبات داده های بسیار حساس را مدیریت می کند که نیاز به اجرای مکانیسم های حفظ حریم خصوصی دارند، همانطور که در زیر توضیح داده شده است.
برای DSP ها :
B&A زمینه ناشر را پردازش می کند (به طور بالقوه URL کامل اگر به صراحت توسط فروشنده از طریق auctionSignals / perBuyerSignals ارسال شود) همراه با اطلاعات دقیق IG کاربر. TEE برای پردازش ایمن این ترکیب و جلوگیری از شناسایی مجدد کاربر بالقوه ضروری است. در KV BYOS، URL کامل قابل ارسال نیست.
برای SSP ها :
حتی دانستن ترکیبی از IGهای شرکت کننده (و صاحبان DSP آنها) در یک حراج می تواند یک امضای شناسایی ایجاد کند. این جایی است که راه حل chaffing وارد عمل می شود که نیاز به استفاده از TEE دارد.
بنابراین، پردازش امن این سیگنال‌های حساس ترکیبی و اجرای مکانیسم‌های حفظ حریم خصوصی، محیط کنترل‌شده و تایید شده یک TEE را الزامی می‌کند.

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

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

موضوع بازخورد خلاصه پاسخ کروم
سیاست نویز پیاده سازی ARA برای برخی از فعالان بازار ارزشمند بوده است و گوگل باید به حفظ گزارش در سطح رویداد ادامه دهد. Google باید سیاست نویز را در سناریوهایی که هر دو ARA و 3PC در دسترس هستند، کاهش دهد. تبلیغ‌کنندگان عملکرد به‌طور فزاینده‌ای از پیاده‌سازی میدان «ارزش» فعلی رویداد انعطاف‌پذیر ARA استفاده می‌کنند و یک خط‌مشی کمتر محدودکننده نویز به کاهش تأخیرها و گزارش‌های نادرست کمک می‌کند. این مکانیسم بخشی اساسی از طراحی ARA است که با جلوگیری از ردیابی فردی از حریم خصوصی کاربر محافظت می کند. ما بازخوردهای مربوط به چالش‌های گزارش‌دهی ناشی از نویز را در نظر می‌گیریم، زیرا همچنان به ارزیابی نقش Privacy Sandbox API در آینده و همچنین هرگونه پیشرفت احتمالی آینده، با توجه به اعلامیه Google در آوریل 2025 مبنی بر حفظ رویکرد فعلی برای ارائه انتخاب 3PC به کاربران در Chrome ادامه می‌دهیم.
نقشه راه و پشتیبانی بلند مدت درخواست نقشه راه محصول برای ARA و همچنین تایید سرمایه گذاری و پشتیبانی بلند مدت با توجه به اعلام عدم ادامه معرفی مکانیزم انتخاب کاربر برای 3PC. تیم Privacy Sandbox در حال تعامل با اکوسیستم است تا نقشی که APIهای Privacy Sandbox در آینده ایفا خواهند کرد و ارزیابی هر گونه سرمایه گذاری در آینده است.
اندازه‌گیری بین محیطی (برنامه به وب) درخواست راه‌حلی که شامل استفاده از ARA برای تسهیل اندازه‌گیری بین محیطی، ارائه یک جریان داده پاک‌تر و مطمئن‌تر، افزایش توانایی اتصال تعاملات کاربر در پلتفرم‌های مختلف است. برنامه به وب در همان دستگاه قبلاً توسط ARA پشتیبانی می شود. می‌توانید جزئیات بیشتر در مورد راه‌حل اندازه‌گیری برنامه متقابل و وب را در اینجا و اینجا بیابید.
اسناد بین مرورگر یک رویکرد یکپارچه و متقابل مرورگر به ARA به طور چشمگیری توانایی اندازه گیری ROI در وب باز را بهبود می بخشد و یک جایگزین پایدار پیش از تغییرات بالقوه نظارتی ارائه می دهد. Chrome باید در راه حلی مانند این با تیم Safari همکاری کند. ما در حال کاوش یک API قابل همکاری با سایر فروشندگان مرورگر در گروه‌های PATCG و PATWG در W3C هستیم. با توجه به اینکه این کار مقدماتی است، از ذینفعان استقبال می شود که پیشرفت ما را در اینجا بررسی کنند.
اندازه گیری بین دستگاهی/آفلاین ناتوانی در پشتیبانی از اندازه گیری تبدیل بین دستگاهی در ARA یک محدودیت قابل توجه است. اندازه گیری تبدیل آنلاین به آفلاین نیز بسیار مهم است و مرورگر می تواند در همکاری با فروشندگان اندازه گیری نقش داشته باشد. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
اسناد چند لمسی درخواست اجازه دادن به تبلیغ‌کنندگان برای استفاده از داده‌های جعبه ایمنی حریم خصوصی به‌عنوان یک "حقیقت پایه" بی‌طرفانه برای اعتبارسنجی و کالیبره کردن مدل‌های ارجاع موجود خود. این را می توان با استفاده از داده های ارائه شده توسط مرورگر ARA به عنوان یک سیگنال کالیبراسیون قابل اعتماد، ایجاد یک خط پایه از حقیقت به دست آورد. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
اندازه‌گیری ترافیک بدون رضایت/منصرف یک راه حل حفظ حریم خصوصی، مانند Interoperable Private Attribution، اندازه گیری ترافیک بدون رضایت را امکان پذیر می کند. این به درک جامع تری از عملکرد کمپین با گنجاندن داده‌های کاربرانی که از ردیابی منصرف شده‌اند، کمک می‌کند و شکاف بزرگی در اندازه‌گیری ایجاد شده توسط الزامات رضایت را برطرف می‌کند. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
انتساب سرور به سرور درخواست اجازه دادن به فن‌آوری‌های تبلیغاتی با زیرساخت‌های پیشرفته سمت سرور برای ادغام با ARA به روشی انعطاف‌پذیرتر، و در عین حال حفظ حریم خصوصی کاربر، موارد استفاده‌ای را که مدیریت آن‌ها صرفاً در سمت مشتری دشوار است، در نظر می‌گیرد. با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.
ثبت نام چند دامنه به دنبال توضیح در مورد محدودیت ها و هشدارها هنگام ثبت دامنه های متعدد با ARA، به ویژه در مورد سرویس تجمیع و انتساب منبع متقابل. در زیر محدودیت های کلیدی هنگام استفاده از ARA با دامنه های متعدد آورده شده است:
• انتساب به یک مبدا اختصاص دارد. شما نمی توانید یک کلیک از یکی از دامنه های خود را با یک تبدیل در دامنه دیگر مطابقت دهید. Attribution هم برای منبع و هم برای ماشه به همان مبدأ بسته می شود.
• سرویس Aggregation از دسته بندی چند منبع پشتیبانی نمی کند. گزارش ها از مبداهای مختلف باید دسته بندی شده و جداگانه پردازش شوند. ما در حال بررسی راه هایی برای حمایت از این امر در آینده هستیم.
به طور خلاصه، در حالی که چندین دامنه را می توان تحت یک موجودیت ثبت کرد، همه توابع ARA، مانند تخصیص و تجمیع، در حال حاضر باید بر اساس مبدا مدیریت شوند.

سرویس تجمع

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

Private Aggregation API

موضوع بازخورد خلاصه پاسخ کروم
محدودیت ها و سطوح نویز نگرانی‌های مربوط به محدودیت‌های مربوط به اندازه‌های کلید تجمیع و مقادیر تجمع در API انباشت خصوصی. اندازه‌های کلید و مقدار جمع‌آوری به گونه‌ای انتخاب شدند که دانه‌بندی بالایی داشته باشند در حالی که هزینه‌های شبکه و ذخیره‌سازی را محدود می‌کردند. همچنین توصیه می‌کنیم هنگام اختصاص کلیدها از هش برای به حداکثر رساندن انعطاف‌پذیری استفاده کنید.
در حالی که عوامل دیگری برای محافظت از داده های کاربر وجود دارد، افزودن نویز بخش مهمی از حفاظت از حریم خصوصی API جمع آوری خصوصی است.
با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PC به کاربران در Chrome حفظ خواهد شد، ما بازخوردها را در نظر می گیریم و به ارزیابی انتخاب پارامترهای مناسب در کنار بررسی نقشی که APIهای Sandbox Privacy در آینده ایفا خواهند کرد، ادامه خواهیم داد.
حریم خصوصی در مقابل سودمندی رویکرد Privacy Sandbox ممکن است حریم خصوصی را بر ابزار اولویت قرار دهد، که به طور بالقوه مانع پذیرش می شود. پیشنهادی برای امکان اشتراک‌گذاری دقیق‌تر داده با رضایت کاربر برای بهبود اندازه‌گیری و شخصی‌سازی آگهی. اندازه‌های کلید و مقدار جمع‌آوری به گونه‌ای انتخاب شدند که دانه‌بندی بالایی داشته باشند در حالی که هزینه‌های شبکه و ذخیره‌سازی را محدود می‌کردند. همچنین توصیه می‌کنیم هنگام اختصاص کلیدها از هش برای به حداکثر رساندن انعطاف‌پذیری استفاده کنید.
با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3 رایانه شخصی به کاربران در Chrome حفظ خواهد شد، هنگام ارزیابی نقش Privacy Sandbox APIها در آینده، این بازخورد را در نظر می گیریم.

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

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

موضوع بازخورد خلاصه پاسخ کروم
تشخیص هرزنامه اگر اولین درخواست از وب‌سایتی که از سیستم تشخیص هرزنامه استفاده می‌کند به نکات مشتری متکی باشد، سیستم ردیابی یا تشخیص ممکن است در شناسایی یا طبقه‌بندی مناسب درخواست ناکام باشد. موارد استفاده که متکی به دسترسی به User-Agent Clients (UA-CH) در اولین درخواست است، باید از نکات کلیدی مشتری استفاده کند.
بازخورد API Sec-CH-USA-Wow64 را منسوخ کنید زیرا دیگر برای وب مدرن مرتبط نیست. ما در حال بررسی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. ما همچنین بازخورد دریافت کرده ایم مبنی بر اینکه گسترش wow64 فراتر از ویندوز مفید است.

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

موضوع بازخورد خلاصه پاسخ کروم
کنترل ها تغییر درخواست برای محافظت از IP برای سایت‌ها برای استفاده انتخابی خارج از حالت ناشناس. ما از بازخورد قدردانی می کنیم و از ورودی های اضافی در مورد این موضوع در اینجا استقبال می کنیم.
رفتار نادرست آیا توکن‌های آشکار احتمالی (PRT) که منجر به یک مقدار NULL می‌شوند، وقتی پلیس درخواست افشای آدرس IP را برای سوءرفتار پلتفرم می‌کند، از شناسایی مجرم جلوگیری می‌کند؟ اگر دامنه ای منحصراً برای کشف تقلب و سوء استفاده استفاده می شود، احتمالاً در فهرست دامنه های ماسک شده (MDL) قرار نمی گیرد و بنابراین تحت تأثیر محافظت IP قرار نمی گیرد. در نتیجه، PRT برای آن دامنه ها مورد نیاز نخواهد بود.
اگر دامنه ای در MDL گنجانده شود، PRT ها در حال حاضر تنها راه برای یادگیری آدرس IP اصلی برای درخواست پروکسی هستند. از آنجایی که PRT ها به طور خاص برای پشتیبانی از تجزیه و تحلیل انبوه طراحی شده اند، نه شناسایی فردی، این درست است که PRT ها در بیشتر موارد حاوی آدرس IP نیستند. با این حال، انتظار داریم که این تأثیر محدودی در سناریوی توصیف شده داشته باشد، زیرا محافظت IP فقط در زمینه شخص ثالث اعمال می شود، به این معنی که ناشران همچنان آدرس های IP غیر پروکسی را برای تعاملات شخص اول دریافت می کنند، مانند بازدید کاربران از سایت یک پلت فرم آنلاین.
ضد کلاهبرداری ویژگی‌های اقدامات ضد کلاهبرداری Google برای محافظت از IP، از جمله جزئیات دسترسی محدودکننده نرخ به پراکسی‌ها و صدور رمز احراز هویت، و موارد استفاده خاص برای PRT چیست؟ ما تأیید می‌کنیم که نشانه‌های محدودکننده نرخ و احراز هویت در IP Protection برای جلوگیری از کلاهبرداری تبلیغاتی توسط ربات‌ها با دسترسی بیش از حد پراکسی‌ها، همانطور که در استراتژی ضد کلاهبرداری و ضد هرزنامه توضیح داده شده است، طراحی شده‌اند. موارد استفاده بیشتر برای PRT در مستندات توضیحی PRT در اینجا مشخص شده است.
حالت ناشناس آیا محافظت IP در حالت ناشناس همچنان برای Q3 برنامه ریزی شده است؟ در حال حاضر هیچ تغییری در جدول زمانی Q3 برای راه اندازی IP Protection در حالت ناشناس وجود ندارد.

کاهش ردیابی جهش

موضوع بازخورد خلاصه پاسخ کروم
بازخورد API کروم باید به جای تقسیم آنها هنگام استفاده از کاهش ردیابی گزاف گویی (BTM) ، دسترسی به کوکی/ذخیره سازی را مسدود کند ، و با استناد به رفتار ناخواسته و سردرگمی از روش "پارتیشن بندی" سافاری. ما از این پیشنهاد استقبال می کنیم. در حال حاضر ، BTM شامل پارتیشن بندی کوکی/ذخیره سازی نیست و در عوض آن را پس از یک دوره فضل حذف می کند. اگر طرح های بعدی به BTM وجود داشته باشد که شامل اقدام فوری نسبت به کوکی ها باشد ، ما قصد داریم که کوکی ها را برای تقسیم آنها مسدود کنیم.

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

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

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

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

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

موضوع بازخورد خلاصه پاسخ کروم
درخواست ویژگی API درخواست اضافه کردن نمودارهای تبلیغاتی و کلیک در ذخیره سازی مشترک. ما با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PCS در Chrome حفظ می شود ، این بازخورد را مورد توجه قرار می دهیم.

تراشه

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

فدستان

موضوع بازخورد خلاصه پاسخ کروم
استفاده از API واسطه ای خاموش برای کاربران با حساب های متعدد و خطای خاصی انجام نمی شود. رفتار واسطه گر خاموش یک ویژگی طراحی شده توسط طراحی است ، زیرا برای یک مورد بسیار خاص با یک حساب موجود در نظر گرفته شده است. توصیه این است که به جای آن از واسطه گری "اختیاری" استفاده کنید ، که در آن FEDCM در صورت عدم امکان واسطه خاموش ، به انتخاب کننده حساب کاربری می پردازد.
استفاده از API navigator.credentials.get خطاهای عمومی را برمی گرداند ، و از ضبط دلایل رد خاص مانند اخراج کاربر یا دوره های Cooldown جلوگیری می کند. عدم توانایی توسعه دهندگان بین کاربر رد گفتگوی FEDCM در مقابل خطای شبکه در مقابل FEDCM که در یک دوره "Cooldown" قرار دارد به دلیل اینکه کاربر قبلاً گفتگو را رد کرده بود نیز از ویژگی طراحی است ، به معنای حفظ حریم خصوصی کاربر است. نگرانی این است که چنین توانایی ای به وب سایت ها اجازه می دهد تا وضعیت ورود کاربر را در ارائه دهندگان هویت مختلف (IDP) استنباط کنند.
وارد شوید رفتار انتخاب حساب متناقض با چندین حساب امضا شده مشاهده شد. هنوز مشخص نیست که آیا عدم توانایی متناوب در انتخاب یک حساب خاص در یک سناریوی با حساب چند علامت گذاری شده ، یک اشکال متناوب در FEDCM است یا برخی از موارد مربوط به سیستم آزمایش است. ما برای حل این مسئله با خبرنگار همکاری می کنیم و برای درک بهتر این مسئله از جزئیات بیشتر خواسته ایم.
استفاده از API اگر کاربر هنگام مجوز با FEDCM ، گفتگو را رد کند ، این واقعیت که آنها در حالت Cooldown هستند از طریق خطای قابل قبول گزارش نمی شود. بله ، این مورد خواهد بود و این می تواند کد خطای عمومی را به منظور حفظ حریم شخصی کاربر ایجاد کند.
استفاده از API چرا FEDCM پس از "تأیید خودکار" به یک دوره آرام 10 دقیقه ای می رود؟ با توجه به اینکه اعتبار سنجی خودکار بدون یک اقدام توسط کاربر اتفاق می افتد ، اگر کاربر بخواهد به وب سایت برگردد اما با یک حساب متفاوت وارد سیستم شود ، به یک دوره زمانی نیاز دارد که FEDCM آنها را تأیید کند. "دوره آرام" این فرصت را برای کاربران فراهم می کند تا با استفاده از یک حساب کاربری متفاوت ، به صورت دستی وارد سیستم شوند. این پست وبلاگ جزئیات بیشتری در مورد این "دوره آرام" دارد.
FEDCM سبک وزن نگرانی از اینکه پیشنهاد سبک FEDCM به دلیل نیاز به پشتیبانی از دو پیاده سازی ناسازگار ، پیچیدگی اضافی را برای IDP ها معرفی می کند (FEDCM در مقابل FEDCM سبک وزن). FEDCM سبک وزن با FEDCM سنتی سازگار است. IDP ها می توانند از کدام روش اجرای استفاده کنند و برای پشتیبانی از هر دو مورد نیاز نخواهند بود.
FEDCM سبک وزن یک مکانیسم فشار برای FEDCM است. اگر یک IDP تصمیم به استفاده از این ویژگی کند ، می تواند هنگام ورود کاربر ، اطلاعات حساب را به مرورگر سوق دهد ، به طوری که وقتی یک طرف متکی (RP) FEDCM را فراخوانی می کند ، به جای نقطه پایانی حساب IDP ، این حساب از مرورگر بازیابی می شود.
FEDCM سبک وزن نگرانی در مورد قرار گرفتن در معرض داده های کاربر شخصی مانند نام ، ایمیل و تصویر پروفایل در RP در پیشنهاد FEDCM سبک وزن. پیشنهاد FEDCM سبک وزن از زمان دریافت این بازخورد ، برای حذف نام ، ایمیل و تصویر پروفایل از پاسخ روش به روز شده است.
FEDCM سبک وزن به نظر می رسد مدیریت چندین حساب امضا شده در پیشنهاد سبک وزن FEDCM بسیار سفت و سخت است. این پیشنهاد در حال حاضر از طول عمر جلسه فردی یا حالت های ورود به سیستم در هر حساب پشتیبانی نمی کند. انقضا در حال حاضر با IDP در شیء اعتبار گره خورده است. ما انقضاء هر حساب را به عنوان یک سؤال باز ذکر کرده ایم و این بازخورد را برای تحولات آینده در نظر خواهیم گرفت.
FEDCM سبک وزن تمایز بین "امضا شده در" و "در دسترس برای انتخاب" به وضوح تعریف نشده است ، که می تواند بر تجربه کاربر برای پیشنهاد سبک FEDCM تأثیر بگذارد. ما در حال حاضر از توانایی تشخیص اینکه اگر یک حساب وارد شده یا از سیستم خارج شده در رابط کاربری FEDCM (UI) وارد شده باشد ، پشتیبانی نمی کنیم. حساب های ورود به سیستم نباید ذکر شود.
اگر یک حساب کاربری از سیستم خارج شده و لیست شده باشد ، و کاربر حسابی را انتخاب می کند که به طور فعال وارد سیستم نشده است ، می توان از API ادامه استفاده کرد تا کاربر دوباره وارد سیستم شود.
استفاده از API ناسازگاری بین قسمت given_name در getUserInfo و استفاده از آن در UI FEDCM. این موضوع در اینجا با Mozilla در اینجا مورد بحث قرار گرفت تا در مورد نحوه برخورد given_name در getUserInfo تراز شود.
استفاده از API همه زمینه های مورد استفاده در UI از IdentityProviderAccount به getUserInfo ، به طور خاص tel و username ارائه نشده است ، که نیاز به هماهنگ سازی را نشان می دهد. بحث و گفتگو با موزیلا و سایر اعضای گروه جامعه FEDID در حال پیشرفت در مورد مسئله آشتی است که زمینه های IdentityProviderAccount به getUserInfo.
شرکت FEDCM درخواست پشتیبانی FEDCM برای موارد استفاده از IDP سازمانی. مسئله اصلی نیاز به یک مکانیسم قابل اعتماد برای IDPS برای نشان دادن به مرورگرهایی است که سرپرستان از قبل به شما اطمینان داده اند تا به کاربر اجازه دهد به RP های خاصی دسترسی پیدا کند که توسط ردیاب های وب قابل تقلید و/یا سوء استفاده نباشد. این مورد در جلسه 22 آوریل FedID CG (لطفاً در اینجا یادداشت های جلسه را پیدا کنید) مورد بحث قرار گرفت و ترکیبات پسوندهای مرورگر و سیاست های سازمانی (برای دستگاه های مدیریت شده) به عنوان راه حل های بالقوه ارائه شد. ما در اینجا از بازخورد اضافی در مورد این موضوع استقبال می کنیم.

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

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

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

،

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

گوگل این گزارش سه ماهه را به عنوان بخشی از تعهدات خود در مورد رقابت و مرجع رقابت و بازارها ("CMA") تحت بند 12 ، 17 (ج) (ii) و 32 (الف) تهیه کرده است. این گزارش ، پیشرفت Google را در پیشنهادات ماسه جعبه حریم خصوصی پوشش می دهد. انتظارات زمان بندی به روز شده ؛ توضیحات اساسی در مورد چگونگی در نظر گرفتن مشاهدات Google توسط اشخاص ثالث. و خلاصه ای از تعامل بین Google و CMA ، از جمله بازخورد از رویکرد CMA و Google برای پرداختن به بازخورد.

Google در جلسات وضعیت منظم خود که مطابق با بند 17 (ب) تعهدات برنامه ریزی شده است ، CMA را با پیشنهادات ماسه ای حریم خصوصی به روز کرده است. علاوه بر این ، این تیم مستندات توسعه دهنده را حفظ می کند که مروری بر ویژگی های اصلی تبلیغات خصوصی و تغییرات کوکی ، همراه با اجرای API و اطلاعات وضعیت ارائه می دهد. به روزرسانی های کلیدی در وبلاگ توسعه دهنده به همراه به روزرسانی های هدفمند به اشتراک گذاشته شده در لیست پستی های توسعه دهنده فردی به اشتراک گذاشته می شود.

با در نظر گرفتن مشاهدات انجام شده توسط اشخاص ثالث

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

آرا
گزارش انتساب API
تراشه
کوکی هایی که دارای وضعیت تقسیم شده مستقل هستند
DSP
بستر سمت تقاضا
فدستان
مدیریت اعتبار فدرال
IAB
دفتر تبلیغات تعاملی
بیجاشدگان داخلی
ارائه دهنده هویت
IETF
کارگروه مهندسی اینترنت
IP
آدرس پروتکل اینترنت
OpenRTB
مناقصه در زمان واقعی
OT
آزمایش مبدا
API PA
API مخاطبان محافظت شده (قبلاً Fleedge)
پتک
گروه جامعه فناوری تبلیغات خصوصی
RP
متکی به حزب
RWS
مجموعه های وب سایت مرتبط (مجموعه های شخص اول)
SSP
بستر عرضه
UA
رشته عامل کاربر
ua-ch
نکات مشتری عامل کاربر
W3C
کنسرسیوم وب جهانی
WIPB
نابینایی IP اراده

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

موضوع بازخورد خلاصه پاسخ کروم
آینده ماسه حریم خصوصی با توجه به اعلام اینکه با معرفی مکانیسم انتخاب کاربر برای 3pcs ، برخی از API ها در هنگام حضور 3 قطعه و برخی دیگر برای مفید بودن نیاز به تکامل دارند. زمینه های بالقوه دیگری برای سرمایه گذاری برای Chrome فراتر از API های ماسه ای حریم خصوصی وجود دارد. ما از بازخورد قدردانی می کنیم و به منظور ارزیابی نقشی که API های ماسه ای حریم خصوصی می توانند در پیش رو داشته باشند ، با ذینفعان درگیر می شویم و همچنین با توجه به اعلامیه در آوریل 2025 گوگل مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PCS در کروم ، حفظ می شود ، زمینه های جدید را برای سرمایه گذاری در آینده کشف می کنیم.
صندوقچه حریم خصوصی برخی از شرکت کنندگان در اکوسیستم از این اعلامیه ناامید شده اند که با معرفی مکانیسم انتخاب کاربر برای 3PC ، اما به کار انجام شده افتخار می کنند ، آنها از چالش های فنی موجود در ماسهبازی حریم خصوصی قدردانی می کنند ، و بر ارزش روابط کاری مشترک آنها با کروم و ابزار کمک هزینه تست بازار تأکید کرده اند. ما از بازخورد قدردانی می کنیم و موافقت می کنیم که Chrome می تواند و باید با توسعه دهندگان همکاری کند تا فن آوری هایی را ایجاد کند که ضمن حفظ اینترنت پشتیبانی تبلیغاتی ، حریم شخصی آنلاین را بهبود بخشد.
به اشتراک گذاری داده های مرورگر اشتراک گذاری داده های با واسطه مرورگر یک فناوری قانع کننده با پتانسیل رسیدگی به ناکارآمدی بازار و مسائل اعتماد است. این مرورگر به عنوان زمینه اعدام شخص ثالث برای همکاری ارزش دارد. ما از بازخورد قدردانی می کنیم و موافقت می کنیم که Chrome می تواند و باید در ایجاد فناوری هایی که باعث افزایش اعتماد بین توسعه دهندگان و کاربران می شود ، به توسعه دهندگان کمک کند.
ترافیک کروم سهم ترافیک Cookieless در Chrome و سهم ترافیک برای حالت ناشناس چیست؟ همانطور که توسط CMA در " توجه به قصد انتشار تعهدات " خود ذکر شد ، حالت ناشناس فقط بخش بسیار کمی از فعالیت مرور را تحت تأثیر قرار می دهد. در هر یک از انگلستان و EEA ، حالت ناشناس Chrome نشان می دهد: کمتر از 10 ٪ از ناوبری ها در دستگاه هایی که در سیستم عامل Android کار می کنند. و کمتر از 10 ٪ از ناوبری ها در دستگاه هایی که در سیستم عامل ویندوز کار می کنند. این معیارها فقط مربوط به ناوبری ها فقط در کروم مبتنی بر کروم در انگلستان و EEA است.
ما داده های مربوط به مرورگرهایی را که مسدود شده 3PC را به اشتراک نمی گذاریم ، به اشتراک نمی گذاریم.
توسعه دهندگان ممکن است تعیین کنند که کوکی ها با استفاده از هدر دسترسی به ذخیره سازی تقسیم می شوند و از این طریق از کاهش های موجود استفاده می کنند.
برچسب های آزمایش Chrome برنامه Chrome برای 1 ٪ از ترافیک Cookieless که برای آزمایش در سال 2024 فعال شده است چیست؟ ما در حال حاضر برنامه ای برای به اشتراک گذاشتن نداریم ، اما قصد داریم آنها را به محض موجود در دسترس عمومی به اشتراک بگذاریم.
تست کروم آیا تنظیم برچسب آزمایش فعلی شامل درمانی برای سناریوهایی است که هر دو 3 قطعه در دسترس هستند و API های ماسه ای حریم خصوصی فعال هستند؟ تنظیم برچسب آزمایش فعلی شامل درمان هر دو 3PC و API های ماسه ای حریم خصوصی در قالب حالت A است.
صندوقچه حریم خصوصی برخی از تبلیغ کنندگان به دلیل تمرینات قبلی آمادگی قبلی ، از چگونگی کمیت مزیت برای پذیرندگان اولیه استفاده می کنند و به دنبال آموزش در مورد اثرات بازپرداخت ، آینده نگر و اندازه گیری هستند. ما از بازخورد قدردانی می کنیم و احساسات مربوط به پیچیدگی فن آوری و تمرینات آمادگی را درک می کنیم.
با توجه به درک عملکرد فن آوری های فعلی Sandbox Privacy ، نتایج آزمایش ما نشان داد که مشارکت اکوسیستم یک عامل مهم در درک عملکرد راه حل های ماسهبازی حریم خصوصی است. آزمایش در حجم کم نمی تواند پویایی بازار و انگیزه های استفاده از فناوری ها را در مقیاس بازتولید کند.

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

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

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

موضوعات

موضوع بازخورد خلاصه پاسخ کروم
عملکرد و علاقه به ابزار در موضوعات API با پیشرفت ها بازخورد از ذینفعان طرف خرید نشان می دهد که API مباحث یک سیگنال ارزشمند است و منجر به هزینه هر تصور (CPM) می شود که برای مخاطبان 3pc ، برای تبلیغات تبلیغاتی با آن رقابتی است. برخی از ناشران سیگنال API موضوعات را با کیفیت بیشتر از سیگنال های استاندارد وب باز می دانند. با توجه به این بازخورد در مورد مباحث مربوط به ابزار API ، ذینفعان در حال درخواست پیشرفت هایی هستند ، مانند بهبود وفاداری ، سازگاری ، و گسترش کنترل های ناشر برای هدایت پذیرش گسترده تر. ما با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PCS در Chrome حفظ می شود ، این بازخورد را مورد توجه قرار می دهیم.
سودمندی برای
انواع مختلف
ذینفعان		 از آنجا که طبقه بندی کننده مباحث در حال حاضر فقط از نام میزبان صفحه برای تعریف مباحث مربوطه استفاده می کند ، سایت های بزرگ با محتوای متنوع مباحث عمومی را به خود اختصاص می دهند در حالی که سایت های کوچک با ارزش تبلیغاتی بیشتر مباحث طاقچه ای را ارائه می دهند. پاسخ ما شبیه به محله های قبلی است:
مانند 3pcs ، تفاوت در ارزش اطلاعاتی که توسط سایت های مختلف کمک می کند وجود دارد. سایت های سودآوری در سهم ارزش خود متناقض هستند: همه سایتهای منافع طاقچه دارای محتوای قابل ارزش تجاری نیستند و بنابراین ارزش کمتری دارند. این سایت هایی هستند که از API مباحث بهره مند می شوند. ما امکان طبقه بندی سطح صفحه را به جای طبقه بندی در سطح سایت در نظر گرفته ایم ، با این حال ، تعدادی از نگرانی های مهم حفظ حریم خصوصی و امنیتی با چنین طبقه بندی وجود دارد.
مباحث طبقه بندی به اندازه کافی گرانول نیست مباحث API برای ناشران اخبار با بخش های متنوع در یک دامنه واحد ، دانه بندی کافی را فراهم نمی کند ، و به طور بالقوه سود API را برای هدف قرار دادن تبلیغ محدود می کند. ما با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PCS در Chrome حفظ می شود ، این بازخورد را مورد توجه قرار می دهیم.
بهبود طبقه بندی به ناشران اجازه دهید مجوزهای Chrome را برای طبقه بندی موضوعات بر اساس محتوای صفحه (به عنوان مثال ، سر ، بدن) ارائه دهند. ما در حال بررسی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم.
سیاست درخواست شفاف سازی در مورد دستورالعمل های مربوط به استفاده از API مباحث در رابطه با اطلاعات 3pc. در استفاده از هر دو موضوع API و 3PC هیچ مشکلی وجود ندارد ، زیرا مباحث API زیر مجموعه ای از ویژگی های 3pcs را ارائه می دهد.
مشاهده هدر مروارید درخواست شفاف سازی در مورد اجرای هدر Observe-Topics ، به طور خاص آیا بازگشت مداوم عنوان باعث ایجاد مشکلات می شود. به طور مداوم بازگرداندن Observe-Browse-Topics: ?1 هدر هیچ مسئله فنی ایجاد نمی کند.
مرورگر این سیگنال را به طور کارآمد کنترل می کند ، به سادگی خاطرنشان می کند که بازدید از صفحه واجد شرایط محاسبه موضوع بدون ایجاد تکثیر یا خطا است. در حالی که در هر صفحه مورد نیاز نیست ، ارسال آن به عنوان یک عنوان استاندارد در تمام اسناد سطح بالا یک استراتژی معتبر و ساده است.
دسته بندی های طبقه بندی درخواست برای به روزرسانی آخرین موضوعات طبقه بندی با موضوعات جدید. ما این درخواست را در نظر می گیریم و از بازخورد اضافی از اکوسیستم در اینجا استقبال می کنیم.
مقادیر پوچ درخواست راهنمایی در مورد بهبود مباحث عملکرد API و درک دلایل پاسخ های تهی مانند فیلتر یا حساسیت. برای وضوح ، پاسخ های null یا خالی از مباحث API یک ویژگی حفظ حریم خصوصی مورد انتظار است ، نه خطایی.
پاسخ null می تواند ناشی از:
• قوانین حفظ حریم خصوصی: 5 ٪ شانس null تصادفی ، یا به این دلیل که اسکریپت شما کاربر را در سایت های مربوط به آن موضوع "مشاهده نکرده است".
• وضعیت کاربر: سابقه مرور کافی ، استفاده از حالت ناشناس یا کاربر در تنظیمات حریم خصوصی تبلیغات Chrome انتخاب کرده است.
• خطاهای فنی: سایت های ناشر باید Observe-Browse-Topics: ?1 هدر ، و هرگونه تماس تلفنی نیاز به allow="Browse-topics" دارد.
برای بررسی ، از صفحه اشکال زدایی chrome://topics-internals استفاده کنید تا ببینید مرورگر شما چه موضوعاتی را محاسبه کرده است و چرا.
در حالی که ویژگی های حریم خصوصی مانع از سرعت 100 ٪ پر شدن می شود ، می توانید عملکرد را بهبود بخشید:
• کار با ناشران: اطمینان حاصل کنید که شرکای خود به درستی Observe-Browse-Topics: ?1 هدر را در سایت های خود.
• تأیید کد خود: اگر از iframes استفاده می کنید ، تأیید کنید که خط مشی allow="Browse-topics" در دسترس است.

API مخاطبان محافظت شده

موضوع بازخورد خلاصه پاسخ کروم
پذیرش PA API مانع هزینه و پیچیدگی شد پذیرندگان با استناد به هزینه های عملیاتی ، عدم تقاضای تبلیغ کننده و حجم کم موجودی از مبادلات ، با استناد به هزینه های عملیاتی ، عدم تقاضای تبلیغاتی و حجم کم موجودی از مبادلات ، محروم هستند و یا از بین می روند.
برخی از بازخورد شامل مزایای پتانسیل PA API ، مانند توانایی آن در ارائه مخاطبان با دوام و دسترسی برتر به دلیل نرخ مسابقه بالا است.		 ما با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PCS در Chrome حفظ می شود ، این بازخورد را مورد توجه قرار می دهیم.
قابلیت عملکرد متقابل عملکرد متقابل پلاک باید با استفاده از API PA در سراسر سیستم عامل ها برای باز کردن بازپرداخت بیشتر و قابلیت هدف قرار دادن مخاطبان پشتیبانی شود. Google باید گروه های ذی نفع (IGS) را که در Chrome ثبت شده اند ، در هنگام ارائه تبلیغات در محیط های بومی یا در WebView ، در دسترس باشد و گروه های ذینفع ثبت شده در Android در حراج های Chrome در دسترس باشند. ما با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PCS در Chrome حفظ می شود ، این بازخورد را مورد توجه قرار می دهیم.
DirectRomsellersignals با محدود کردن میزان اطلاعات موجود در حراج متنی ، شرکت کنندگان در حراج همیشه از طریق سرور AD Google هدایت می شوند. ناشر باید ابتدا با تمام شرکای Exchange خود تماس بگیرد ، سپس Google Ad Manager (GAM) دوم را برای اجرای حراج متنی انجام دهد و در نهایت اجازه می دهد تا GAM حراج های IG را فراخوانی کند. بدون دانستن نتیجه حراج متنی در زمان واقعی ، هیچ رقیبی نمی تواند تصمیم گیری در سطح بالا را به طور عادلانه ارکستر کند.

ویژگی DirectFromSellersignals در PA API ممکن است در مورد اطلاعات حراج شفافیت نداشته باشد ، که به طور بالقوه مانع از توانایی دسترسی به داده های لازم می شود. Google باید یا DirectFromSellersignals را حذف کند یا آن را به روز کند ، بنابراین نمی توان از آن برای پنهان کردن قیمت پاکسازی حراج سرور تبلیغ استفاده کرد. به عنوان مثال ، قیمت متنی می تواند از طریق یک زمینه شفاف ، تغییر ناپذیر و امضا شده از طریق Chrome منتقل شود که همه شرکت کنندگان حراج (و ناشر) می توانند به آن دسترسی پیدا کنند و تأیید کنند.		 پاسخ ما از سه ماهه قبلی بدون تغییر است:
پاسخ کروم :
اطلاعات منتقل شده در Runadauction () مشخص نیست که از فروشنده حاصل می شود ، مگر اینکه فروشنده از Iframe خود Runadauction () تماس بگیرد. در یک حراج چند فروش ، غیرممکن می شود که همه فروشندگان قاب فراخوانی Runadauction () را ایجاد کنند. DirectFromSellersignals با بارگیری محتوا از یک بسته فرعی که از منشأ فروشنده بارگیری شده است ، به این مسئله پرداخته است. این تضمین می کند که اصالت و یکپارچگی اطلاعات منتقل شده در حراج از تنظیمات حراج های فروشنده قابل دستکاری نیست. اگر ناشران بخواهند از PA API برای درک هر یک از اطلاعاتی که ارائه دهندگان فناوری خود را به حراج های PA منتقل می کنند ، استفاده کنند ، می توانند از این ارائه دهندگان فناوری برای این قابلیت بخواهند.
پاسخ مدیر تبلیغات گوگل :
ما سالهاست که تمرکز جدی بر انصاف حراج داشته ایم ، از جمله قول ما مبنی بر اینکه هیچ قیمتی از منابع تبلیغاتی غیر ضمانت ناشر ، از جمله قیمت کالاهای غیر تضمین شده خط ، قبل از پیشنهاد در حراج ، با یک خریدار دیگر به اشتراک گذاشته می شود ، که بعداً در تعهدات خود به اقتدار رقابت فرانسه تأیید شدیم.
برای حراج های مخاطبان محافظت شده ، ما قصد داریم با اعمال استفاده از DirectFromSellersignals ، قول خود را حفظ کنیم و پیشنهاد هیچ یک از شرکت کنندگان در حراج را با هیچ یک از شرکت کنندگان در حراج دیگر قبل از اتمام حراج در حراج های چند فروش به اشتراک نگذاریم. برای روشن شدن ، ما همانطور که در این بروزرسانی توضیح داده شده است ، قیمت حراج متنی را با حراج مؤلفه خود به اشتراک نمی گذاریم.
گزارش دهی درخواست اضافه کردن یک نهاد تجزیه و تحلیل/گزارش دهی برای فعال کردن گزارش های متمرکز. ما در اینجا در مورد این درخواست بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
ناشناس بودن K در BuyerReportIdID امکان حذف پیشنهادات بر اساس ناشناس بودن K "BuyerReportIndId" برای تسهیل در زمینه کنترل مخاطبان و گزارش تعهدات با ارائه دهندگان داده های شخص ثالث. ما با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PCS در Chrome حفظ می شود ، این بازخورد را مورد توجه قرار می دهیم.
اشکال زدایی بهبود یافته در اسکریپت تولیدی درخواست مکانیسم برای شناسایی سریع مرحله خاص یا "نقطه شکست" در اسکریپت تولیدی که در آن فرایند ناکام است. ما از استفاده مطلوب از اندازه گیری های زمان واقعی به عنوان یک مکانیسم تنظیم نقطه شکست برای حراج های روی دستگاه آگاه هستیم. ما با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PCS در Chrome حفظ می شود ، این بازخورد را مورد توجه قرار می دهیم.
شنوندگان رویداد برای نظارت بر وضعیت Runadauction پیشنهاد برای اضافه کردن پشتیبانی شنونده رویداد به عملکرد Navigator PA API. ما در حال ارزیابی این درخواست هستیم و از بازخورد اضافی از اکوسیستم در اینجا استقبال می کنیم.
استفاده از API درخواست برای روشن شدن چگونگی API PA API و Attribution API (ARA) می تواند از موارد استفاده از تبلیغات وب در غیاب 3pcs ، به ویژه برای کاربرانی که از 3 قطعه خارج شده اند اما از API های ماسهبازی حریم خصوصی خارج شده اند ، پشتیبانی کنند و در سناریوهای مربوط به همگام سازی کوکی و نمای وب و نمای وب؟ ما با توجه به اعلامیه Google در آوریل 2025 مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3PCS در Chrome حفظ می شود ، این بازخورد را مورد توجه قرار می دهیم.
تأخیر تأخیر در ارتباط با PA API می تواند مانع پذیرش شود ، زیرا ناشران ممکن است در صورت تأخیر خیلی زیاد ، API PA را غیرفعال کنند. در چند چهارم گذشته پیشرفت های متعددی در تأخیر در دستگاه انجام شد. مناقصه و حراج (B&A) ساختمان و مقیاس گذاری در صورت لزوم ادامه می یابد. راهنمای بهترین روشهای تأخیر ما به روز شد تا اطلاعات بیشتری در مورد نحوه استفاده از این ویژگی ها را در بر بگیرد. ما همچنین در حال بررسی پیشرفت های جدید تأخیر هستیم که برخی از آنها در اینجا قابل مشاوره است.
رفتار ورود به سیستم در B&A (تست در مقابل تولید) توضیح در مورد تفاوت در رفتار ورود به سیستم بین حالت های آزمایش و تولید برای خدمات B&A. به طور خاص ، در دسترس بودن سیاهههای مربوط به ابر و تأثیر حالت تولید در ورود به سیستم. اول ، مهم است که بین Prod در مقابل ساخت و سازهای غیر_پرود و پارامتر جداگانه test_mode ، که به سادگی یک کلید رمزگذاری آزمایش سخت را امکان پذیر می کند ، مهم باشد. توضیحات زیر بر روی انواع ساخت متمرکز است.
در ساختهای غیر_Prod ، سرورهای B&A از سطح کلامی قابل تنظیم برای ورود به سیستم برخوردار هستند. این سیاهههای مربوطه به جریان های استاندارد STDOUT/STDERR نوشته شده است. در Google Cloud ، اینها از طریق رابط ورود به سیستم بومی قابل دسترسی هستند و در سرویس های وب آمازون ، آنها را می توان در سیاهههای مربوط به کنسول پیوست یافت.
برای ساخت محصولات ، رفتار ورود به سیستم محدودتر است. سطح کلامی ثابت است و قابل تغییر نیست. در حالی که برخی از سیاهههای مربوط به صرفه جویی ، مانند پیام های راه اندازی سرور و بیشتر خطاهای تصادف ، هنوز هم به Stdout/Stderr چاپ می شوند ، هیچ سیاهه های مخصوص درخواست از طریق این کانال در دسترس نیست. تنها سیاهههای مربوط به هرگونه درخواست از ساخت و ساز برای درخواست های حاوی یک نشانه اشکال زدایی رضایت یافته است و اینها به طور انحصاری از طریق OpenTelemetry صادر می شوند. استفاده از اشکال زدایی رضایت بخش به طور کم اهمیت است ، زیرا ترافیک سنگین می تواند عملکرد سرور را تخریب کرده و منجر به خرابی های بررسی سلامت شود.
با توجه به معیارها ، همه از طریق Opentelemetry صادر می شوند. معیارهای حساس به صرفه جویی همیشه به عنوان و بدون هیچ گونه "نوازی" صادر می شوند. در مقابل ، معیارهای حساس به حریم خصوصی همیشه هنگام صادر کردن از سرور در حالت تولید ، "بدون استفاده" می شوند. پیکربندی تله متری خاص تعیین می کند که آیا این معیارهای حساس به حریم خصوصی به عنوان Noised ، Noized یا هر دو صادر می شوند.
مسیر صفحه کامل را در سیگنال های مناقصه قابل اعتماد برای ایمنی برند وارد کنید درخواست به روزرسانی در PA API برای شامل مسیر کامل URL صفحه سطح بالا ، علاوه بر نام میزبان ، در درخواست FETCH برای TrustedBiddingSignals.
مورد استفاده اصلی امکان کنترل بیشتر ایمنی برند گرانول است. تبلیغ کنندگان غالباً باید در بخش های خاص یک دامنه (به عنوان مثال ، news-site.com/politics) در حالی که به طور کلی با دامنه راحت هستند ، از حضور در بخش های خاص یک دامنه (به عنوان مثال ، news-site.com/politics) جلوگیری کنند. از آنجا که این لیست ها می توانند میلیون ها مدخل باشند ، باید در سمت سرور ارزیابی شوند. مشخصات فعلی ، که فقط نام میزبان را ارسال می کند ، باعث می شود سرور TrustedBiddingsignals بتوانند این ارزیابی سطح مسیر را انجام دهند و قابلیت های ایمنی برند را محدود کنند.		 ما در حال حاضر در اینجا ، پس از بحث های گسترده قبلی ، در اینجا بحث می کنیم که می توان در اینجا مشورت کرد و از بازخورد اضافی استقبال می کنیم.
با این حال ، ما می خواهیم روشن کنیم که ما فقط در نظر داریم این اطلاعات را اضافه کنیم وقتی که Fetch Trustedbiddingsignals به سرور می رود که در داخل یک محیط اجرای قابل اعتماد (TEE) کار می کند.

حراج محافظت شده (خدمات B&A)

موضوع بازخورد خلاصه پاسخ کروم
در دسترس بودن آزمایش اطلاعات مربوط به در دسترس بودن کلید/مقدار (KV) V2 برای آزمایش در هر دو محیط Chrome و B&A. KV V2 هم در B&A و هم در Chrome در دسترس است. راهنمایی های اضافی در اینجا موجود است.
اجرای سرور KV درخواست شفاف سازی در مورد استفاده از سرور KV ، به طور خاص در مورد نقشه برداری از URL های ارائه دهنده خلاق برای درخواست داده ، ضرورت هماهنگی بین SSPS و DSPS برای تعیین پارامترها در URL رندر ، و در دسترس بودن مستندات تشریح هماهنگی و ذخیره داده های مورد نیاز در حالت KV. سرویس KV از Renderurl به عنوان یک کلید استفاده می کند. اگر URL جدید باشد ، ذخیره می شود. اگر وجود داشته باشد ، مقدار آن برای استفاده در Resperead بازگردانده می شود. فرمت بازگشت به تنظیمات بستگی دارد: "سرور خود را بیاورید" (BYOS) به هر مقدار اجازه می دهد ، در حالی که سرویس KV قابل اعتماد به یک عملکرد تعریف شده توسط کاربر نیاز دارد.
در حالی که همیشه مورد نیاز نیست ، هماهنگی با DSPS برای ویژگی هایی مانند جایگزینی کلان (به عنوان مثال ، $ {ad_width}) در Renderurl ضروری است ، که امکان شخصی سازی و تأیید آگهی پویا را فراهم می کند.
توصیه می کنیم با یک آزمایش ساده با یک DSP شروع کنید تا سطح هماهنگی لازم را تعیین کنید. ما همچنین در حال به روزرسانی مستندات KV خود هستیم و یک بار در دسترس عمومی آن را به اشتراک خواهیم گذاشت.
BYOS برای B&A چرا B&A حالت BYOS را شبیه به حالت BYOS KV ارائه نمی دهد؟ B&A به یک TEE نیاز دارد و از یک مدل BYOS جلوگیری می کند ، زیرا از ترکیب داده های بسیار حساس استفاده می کند که به اجرای مکانیسم های حفظ حریم خصوصی نیاز دارد ، همانطور که در زیر توضیح داده شده است.
برای DSP ها :
زمینه B&A فرآیند ناشر (به طور بالقوه URL کامل در صورتی که صریحاً توسط فروشنده از طریق حراج / perbuyersignals ارسال شود) همراه با داده های دقیق IG کاربر. TEE برای پردازش ایمن این ترکیب و جلوگیری از شناسایی مجدد احتمالی کاربر ضروری است. در KV BYOS ، URL کامل ارسال نمی شود.
برای SSP ها :
حتی دانستن ترکیب IG های شرکت کننده (و صاحبان DSP آنها) در حراج می تواند یک امضای شناسایی ایجاد کند. این جایی است که راه حل Chaffing در حال پخش است ، که نیاز به استفاده از یک TEE دارد.
بنابراین ، پردازش ایمن این سیگنال های حساس ترکیبی و اجرای مکانیسم های حفظ حریم خصوصی ، محیط کنترل شده و گواهی یک TEE را موظف می کند.

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

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

موضوع بازخورد خلاصه پاسخ کروم
سیاست سر و صدا اجرای ARA برای برخی از شرکت کنندگان در بازار بسیار ارزشمند بوده است و Google باید همچنان گزارش های سطح رویداد را حفظ کند. Google باید در سناریوهایی که ARA و 3PC در دسترس هستند ، آرامش خط مشی سر و صدا را در نظر بگیرند. تبلیغ کنندگان عملکرد به طور فزاینده ای از اجرای میدان فعلی "ارزش" رویداد ARA Flex استفاده می کنند و یک سیاست سر و صدای محدود کننده کمتر محدود کننده به کاهش تأخیرها و گزارش های نادرست کمک می کند. این مکانیسم بخشی اساسی از طراحی ARA است که به منظور محافظت از حریم شخصی کاربر با جلوگیری از ردیابی فردی است. ما با توجه به اعلامیه در آوریل 2025 گوگل مبنی بر اینکه رویکرد فعلی برای ارائه انتخاب 3pcs در کروم حفظ می شود ، بازخورد در مورد چالش های گزارش دهی ناشی از سر و صدا را در نظر می گیریم ، زیرا ما همچنان به ارزیابی نقشی که API های ماسه ای حریم خصوصی در پیش می رود ، و همچنین هرگونه پیشرفت بالقوه آینده را ارزیابی می کنیم ، ادامه خواهیم داد.
نقشه راه و پشتیبانی بلند مدت درخواست نقشه راه محصول برای ARA ، و همچنین تأیید سرمایه گذاری و پشتیبانی بلند مدت با توجه به اعلام این اعلامیه برای عدم ارائه مکانیسم انتخاب کاربر برای 3pc. تیم Sandbox Privacy با اکوسیستم درگیر است تا نقشی را که API های Sandbox Pliction Pliction در پیش می گیرند و هرگونه سرمایه گذاری در آینده را ارزیابی می کنند ، درک کنند.
اندازه گیری متقابل محیط (برنامه به WEB) درخواست راه حلی که شامل استفاده از ARA برای تسهیل اندازه گیری متقابل محیط ، ارائه یک جریان داده تمیزتر و قابل اطمینان تر است و باعث افزایش توانایی اتصال تعامل کاربر در سیستم عامل های مختلف می شود. برنامه به WEB در همان دستگاه قبلاً توسط ARA پشتیبانی می شود. می توانید جزئیات بیشتری را در مورد برنامه متقاطع و راه حل اندازه گیری وب در اینجا و اینجا بیابید.
انتساب مرورگر متقاطع یک رویکرد یکپارچه و متقاطع به ARA به طور چشمگیری توانایی اندازه گیری ROI را در وب باز بهبود می بخشد و یک جایگزین پایدار را پیش از تغییرات نظارتی احتمالی فراهم می کند. Chrome باید با تیم سافاری در مورد راه حلی مانند این همکاری کند. We are already exploring an interoperable API with other browser vendors in the PATCG and PATWG groups within the W3C. Noting that this work is preliminary, stakeholders are welcome to consult our progress here .
Cross-Device/Offline Measurement Inability to support cross-device conversion measurement within ARA is a significant limitation. Measuring online-to-offline conversions is also significantly important, and the browser could play a role in collaborating with measurement vendors. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Multi-Touch Attribution Request to allow advertisers to use Privacy Sandbox data as an unbiased "ground truth" to validate and calibrate their existing attribution models. This can be achieved by using ARA's browser-provided data as a reliable calibration signal, creating a baseline of truth. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Consentless/Opted-Out Traffic Measurement A privacy-preserving solution, such as Interoperable Private Attribution, would enable measurement for consentless traffic. This would allow for a more comprehensive understanding of campaign performance by including data from users who have opted out of tracking, addressing a major gap in measurement created by consent requirements. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Server-to-Server Attribution Request to allow ad techs with sophisticated server-side infrastructure to integrate with ARA in a more flexible way, accommodating use cases that are difficult to manage purely on the client side, while maintaining user privacy. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Multi-Domain Enrollment Seeking clarification on limitations and caveats when enrolling multiple domains with ARA, particularly concerning the aggregation service and cross-origin attribution. Below are the key limitations when using ARA with multiple domains:
• Attribution is scoped to a single origin. You cannot match a click from one of your domains to a conversion on another. Attribution is sandboxed to the same origin for both the source and trigger.
• The Aggregation Service does not support multi-origin batching. Reports from different origins must be batched and processed separately. We are exploring ways to support this in the future.
Briefly, while multiple domains can be enrolled under one entity, all ARA functions, such as attribution and aggregation, must currently be handled on a per-origin basis.

Aggregation Service

No feedback received this quarter.

Private Aggregation API

Feedback Theme خلاصه Chrome Response
Limits and Noise Levels Concerns regarding limitations on aggregation key sizes and aggregation values within the Private Aggregation API. Aggregation key and value sizes were chosen to have high granularity while limiting network and storage costs. We also recommend using hashing when assigning keys to maximize flexibility.
While there are other factors protecting user data, adding noise is an important piece of the Private Aggregation API's privacy protections.
We are taking into consideration the feedback and will continue to evaluate the appropriate parameter choices alongside our consideration of the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Privacy vs. Utility The Privacy Sandbox's approach may prioritize privacy over utility, potentially hindering adoption. Suggestion to allow more granular data sharing with user consent to improve measurement and ad personalization. Aggregation key and value sizes were chosen to have high granularity while limiting network and storage costs. We also recommend using hashing when assigning keys to maximize flexibility.
We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.

Limit Covert Tracking

User Agent Reduction/User Agent Client Hints

Feedback Theme خلاصه Chrome Response
Spam Detection If the first request from a website that uses a spam detection system relies on client hints, the tracking or detection system could fail to identify or properly categorize the request. Use cases that rely on having access to User-Agent Client Hints (UA-CH) on the first request should make use of critical client hints .
API Feedback Consider deprecating Sec-CH-USA-Wow64 as it is no longer relevant for the modern web. We are considering this request and welcome additional feedback here . We have also received feedback that it would be useful to extend wow64 beyond Windows.

IP Protection (formerly Gnatcatcher)

Feedback Theme خلاصه Chrome Response
کنترل ها Request for IP Protection toggle for sites to use selectively outside of Incognito mode. We appreciate the feedback and we welcome additional input on this issue here .
رفتار نادرست Will Probabilistic Reveal Tokens (PRTs) resulting in a NULL value prevent perpetrator identification when police request IP address disclosure for platform misconduct? If a domain is used exclusively for fraud and abuse detection, it's likely not included in the Masked Domain List (MDL) and therefore not impacted by IP Protection. Consequently, PRTs would not be needed for those domains.
If a domain is included in the MDL, PRTs are currently the only way to learn the original IP address for a proxied request. As PRTs are specifically designed to support aggregate analysis, not individual identification, it is true that PRTs will not contain an IP address in most cases. We expect this to have limited impact in the described scenario, however, as IP Protection applies only in the third-party context, meaning that publishers will continue to receive un-proxied IP addresses for first-party interactions, such as users visiting the site of an online platform.
ضد کلاهبردار What are the specifics of Google's anti-fraud measures for IP Protection, including details on rate-limiting access to proxies and authentication token issuance, and what are the specific use cases for PRTs ? We confirm that rate-limiting and authentication tokens in IP Protection are designed to prevent bots from performing ad fraud by over-accessing proxies, as detailed in the anti-fraud and anti-spam strategy. Further use cases for PRTs are outlined in the PRT explainer documentation here .
حالت ناشناس Is IP Protection in Incognito mode still planned for Q3? There are currently no changes to the Q3 timeline for IP Protection launch in Incognito mode.

Bounce Tracking Mitigations

Feedback Theme خلاصه Chrome Response
API Feedback Chrome should block cookie/storage access rather than partitioning them when applying Bounce Tracking Mitigations (BTM), citing unintended behavior and confusion from Safari's "partitioning" method. We welcome this suggestion. Currently, BTM does not involve cookie/storage partitioning and instead deletes it after a grace period. If there are any later designs to BTM that involve immediate action towards cookies, we intend to prefer blocking cookies over partitioning them.

Strengthen cross-site privacy boundaries

No feedback received this quarter.

Fenced Frames API

No feedback received this quarter.

Shared Storage API

Feedback Theme خلاصه Chrome Response
API Feature Request Request to append ad views and clicks in Shared Storage. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.

CHIPS

Feedback Theme خلاصه Chrome Response
API Question Request for clarification on how Chrome's 3PC controls interact with CHIPS, specifically whether non-partitioned cookies are converted to partitioned ones when 3PCs are disabled, and if partitioned cookies remain active. Non-partitioned cookies will not be stored, retrieved, or sent in a third-party context when 3PCs are disabled. Partitioned cookies, however, will continue to be stored, retrieved, and sent in a third-party context, as their functionality is not impacted by browser settings that disable 3PCs.
Privacy Concern Concern that an embedded party with a persistent identifier, such as for Single Sign-On, might still enable both embedding and embedded parties to gain a global digital identifier, even with partitioned cookies. While an embedded party may have a persistent identifier, this identifier, when stored in a partitioned cookie, is only accessible on the site where the cookie was set by the embed. Cross-site joining of this identifier would require a login action, which already allows for the exchange of an identifier in the form of an authentication token, even without the use of partitioned cookies.

FedCM

Feedback Theme خلاصه Chrome Response
استفاده از API Silent mediation failing for users with multiple accounts with no specific error. The silent mediation behavior is a by-design feature, as it is intended for a very specific case with just one available account. The recommendation is to use the "optional" mediation instead, in which FedCM falls back to presenting the user with an account chooser if silent mediation is not possible.
استفاده از API navigator.credentials.get returns generic errors, preventing capture of specific rejection reasons like user dismissal or cooldown periods. The inability for developers to distinguish between the user dismissing the FedCM dialog vs. a network error vs. FedCM being in a "cooldown period" due to the user having previously dismissed the dialog is also a by design feature, meant to preserve the user's privacy. The concern is that such a capability would allow websites to infer the user's login state on different Identity Providers (IdPs).
وارد شوید Inconsistent account selection behavior with multiple signed-in accounts was observed. It is unclear whether the intermittent inability to select a specific account in a multiple-signed-in-account scenario is an intermittent bug in FedCM or some issue involving the testing system. We are working with the reporter to resolve this issue, and have asked for further details in order to better understand the issue.
استفاده از API If the user dismisses the dialog while authorising with FedCM, the fact that they are in the cooldown state is not reported via a catchable error. Yes, that would be the case and this would produce the generic error code in order to preserve user privacy.
استفاده از API Why does FedCM go into a 10-minute quiet period after a successful "auto-reauthentication"? Given that auto-reauthentication happens without a user-initiated action, if the user wanted to go back to the website but sign in with a different account, they would need a period of time when FedCM does not auto-reauthenticate them. The "quiet period" provides the opportunity for users to manually sign in using a different account. This blog post has further details on this "quiet period".
Lightweight FedCM Concerns that the Lightweight FedCM proposal introduces additional complexity for IdPs due to the need for supporting two incompatible implementations (FedCM vs. Lightweight FedCM). Lightweight FedCM is compatible with traditional FedCM. IdPs can choose which implementation method to use and will not be required to support both.
Lightweight FedCM is a push mechanism for FedCM. If an IdP chooses to use this feature, they can push the account information to the browser when the user logs in, so that, when a Relying Party (RP) invokes FedCM, the account would be retrieved from the browser, instead of the IdP's accounts endpoint.
Lightweight FedCM Concerns about the exposure of personal user data such as name, email, and profile picture to the RP in the Lightweight FedCM proposal. The proposal for Lightweight FedCM has been updated since receiving this feedback, to remove the name, email, and profile image from the method response.
Lightweight FedCM Managing multiple signed-in accounts appears to be too rigid in the Lightweight FedCM proposal. The proposal does not currently support individual session lifetimes or nuanced login states per account. Expiration is currently tied to the IdP within the credentials object. We have noted per-account expiration as an open question and will take this feedback into consideration for future developments.
Lightweight FedCM The distinction between "signed in" and "available for selection" is not clearly defined, which could impact the user experience for the Lightweight FedCM proposal. We do not currently support the ability to distinguish if an account is logged in or logged out in the FedCM User Interface (UI). Logged out accounts should not be listed.
If an account is logged out and listed, and a user selects the account that is not actively logged in, the Continuation API can be used to have the user log back in.
استفاده از API Inconsistency between the given_name field in getUserInfo and its usage in the FedCM UI. This issue was discussed further with Mozilla here , in order to align on how given_name should be treated in getUserInfo .
استفاده از API Not all fields used in the UI from IdentityProviderAccount are provided to getUserInfo , specifically tel and username , suggesting a need for synchronization. The discussion with Mozilla and other FedID Community Group members is progressing on the issue of reconciling which fields from IdentityProviderAccount get sent to getUserInfo.
Enterprise FedCM Request for FedCM support for Enterprise IdP use cases. The key issue is the need for a trusted mechanism for IdPs to signal to browsers that administrators have pre-consented to allow the user to access specific RPs that cannot be mimicked and/or abused by Web trackers. This was discussed in the 22 April FedID CG meeting (please find here notes of the meeting) and combinations of browser extensions and Enterprise Policies (for managed devices) were put forth as potential solutions. We welcome additional feedback on this issue here .

Fight spam and fraud

Private State Token API (and other APIs)

No feedback received this quarter.