گزارش بازخورد - 2025 Q1

گزارش فصلی برای سه ماهه اول 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/فناوری خاصی

موضوع بازخورد خلاصه پاسخ کروم
انتخاب کاربر مشخص نیست رویکرد به روز شده گوگل برای افزایش انتخاب کاربر چگونه خواهد بود، چگونه به کاربران ارائه می شود و نرخ های پیش بینی شده انتخاب کردن/انصراف. اطلاعات بیشتری برای تشخیص این مورد از منسوخ شدن کوکی های شخص ثالث مورد نیاز است. در آوریل 2025، Google یک پست وبلاگی را در مورد مراحل بعدی برای حفاظت از Sandbox حریم خصوصی و ردیابی در Chrome منتشر کرد و اعلام کرد که Google تصمیم گرفته است رویکرد فعلی را برای ارائه کوکی‌های شخص ثالث به کاربران در Chrome حفظ کند و درخواست مستقل جدیدی برای کوکی‌های شخص ثالث ارائه نخواهد کرد.
ما به روز رسانی های بیشتری را در صورت وجود ارائه خواهیم کرد.
انگشت نگاری Google هیچ اطلاعاتی را با ناشران یا بازاریاب‌ها درمورد اینکه چگونه می‌توانند به هر جایگزینی برای سیستم‌های تبلیغاتی Google اعتماد کنند، بدون استفاده از هویت مصرف‌کننده پرخطر به‌عنوان کلید تطبیق مشترک (یعنی اثرانگشت) به اشتراک نگذاشته است. ما چندین سیستم تبلیغات غیر Google را برجسته کرده‌ایم که راه‌حل‌هایی را به ناشران و بازاریابان ارائه می‌دهند که تا حدی بر اساس APIهای جعبه ایمنی حریم خصوصی ساخته شده‌اند. این شامل سیستم‌های تبلیغاتی غیر Google در بازارها و کانال‌ها می‌شود. جزئیات بیشتر و مطالعات موردی در بخش منابع تجاری privacysandbox.com در اینجا موجود است.
جعبه ایمنی حریم خصوصی APIهای Privacy Sandbox جایگزین اجزای داده‌های اینترنتی با محصولات نهایی خود Google می‌شوند. از آنجایی که جایگزین Google یک API است، دسترسی به محصولی را که مالک و تحت کنترل خود است، و محصولی که مشمول شرایط و ضوابطی است که Google در اختیار دارد، ارائه می دهد. این جایگزینی برای اجزایی نیست که توسط دیگران برای تولید محصولات نهایی خود استفاده می شود. APIهای Privacy Sandbox به دنبال تعامل گسترده با تنظیم‌کننده‌ها و طیف وسیعی از ذینفعان اکوسیستم توسعه و پیاده‌سازی شده‌اند. همانند سایر فناوری‌های پلت‌فرم، APIهای Privacy Sandbox باید در نظر داشته باشند که به‌عنوان مؤلفه‌هایی در محصولات نهایی دیگران استفاده می‌شوند و ما از تلاش‌های اکوسیستم برای توسعه فناوری‌های اضافی برای کار در کنار APIهای Privacy Sandbox استقبال می‌کنیم.
انتخاب کاربر درخواست اطلاعات در مورد اینکه آیا رویکرد به‌روزرسانی شده Google برای رایانه‌های شخصی 3 در Chrome الزامات قانونی خاصی را برآورده می‌کند، که ممکن است بر تجربه پلتفرم مدیریت رضایت سهامداران تأثیر بگذارد. در آوریل 2025، Google یک پست وبلاگی را در مورد مراحل بعدی برای حفاظت از Sandbox حریم خصوصی و ردیابی در Chrome منتشر کرد و اعلام کرد که Google تصمیم گرفته است رویکرد فعلی را برای ارائه کوکی‌های شخص ثالث به کاربران در Chrome حفظ کند و درخواست مستقل جدیدی برای کوکی‌های شخص ثالث ارائه نخواهد کرد.
ما به روز رسانی های بیشتری را در صورت وجود ارائه خواهیم کرد.
جدول زمانی Sandbox حریم خصوصی و پذیرش فناوری‌های تبلیغاتی تست Privacy Sandbox API را متوقف کرده‌اند و به دنبال دلایل قوی‌تری برای سرمایه‌گذاری مجدد در این فناوری‌ها برای فعالیت‌های محصول و بازاریابی هستند. تصمیم‌های سرمایه‌گذاری مجدد آن‌ها به شدت تحت‌تاثیر نیاز به وضوح بیشتر در جدول زمانی انتخاب کاربر، و همچنین نگرانی‌ها در مورد تأخیر API مخاطب محافظت‌شده (PA API) و نقشه راه B&A است. علاوه بر این، نگرانی‌هایی در مورد بررسی تعهدات CMA آتی وجود دارد، به‌ویژه در مورد نقش Google به‌عنوان محرک اصلی فناوری‌های جعبه ایمنی حریم خصوصی بدون تکیه بر شناسه‌های 3P، و جهت کلی آینده ابتکار برای اطلاع‌رسانی استراتژی‌های سرمایه‌گذاری. در آوریل 2025، Google یک پست وبلاگی را در مورد مراحل بعدی برای حفاظت از Sandbox حریم خصوصی و ردیابی در Chrome منتشر کرد و اعلام کرد که Google تصمیم گرفته است رویکرد فعلی را برای ارائه کوکی‌های شخص ثالث به کاربران در Chrome حفظ کند و درخواست مستقل جدیدی برای کوکی‌های شخص ثالث ارائه نخواهد کرد. ما به روز رسانی های بیشتری را در صورت وجود ارائه خواهیم کرد.

حراج‌های Chrome PA API نسبت به سال گذشته 35 درصد سریع‌تر هستند. علاوه بر این، ما شاهد افزایش قابل توجهی در استفاده از حراج های موازی بوده ایم که برد بزرگتری را برای آن حراج ها فراهم می کند.

نقشه راه فعلی B&A ما در اینجا موجود است.
جدول زمانی سندباکس حریم خصوصی چه چیزی در صفحه تایم لاین جعبه ایمنی حریم خصوصی به روز شد؟ یک نمای کلی برای Topics API اخیراً به صفحه Timeline Sandbox Privacy اضافه شده است.
جعبه ایمنی حریم خصوصی آیا مقالات تحقیقاتی در مورد Privacy vs. Utility وجود دارد که به درک تأثیر Privacy Sandbox بر درآمد کمک کند؟ مطالعات موردی بازار مربوطه که به این سؤالات می پردازد در اینجا در دسترس است و نتایج حاصل از آزمایش APIهای جعبه ایمنی حریم خصوصی در اینجا در دسترس است.
پذیرش جعبه ایمنی حریم خصوصی یکی از پذیرنده‌های اولیه، چالش‌های اولیه را با APIهای Privacy Sandbox به دلیل پذیرش کند توسط شرکت‌های بزرگ‌تر گزارش کرد که بر راه‌اندازی‌های آزمایشی تأثیر گذاشت. با این حال، با وجود این، رویکرد مشترک تیم Privacy Sandbox و پاسخگویی به بازخورد مورد قدردانی قرار گرفت. ما از بازخورد پذیرنده اولیه قدردانی می کنیم. ما متعهد به همکاری با پذیرندگان اولیه هستیم و به تعامل با اکوسیستم و جمع‌آوری بازخورد در حین ارزیابی نقش فناوری‌های جعبه ایمنی حریم خصوصی در حمایت از اکوسیستم، ادامه خواهیم داد.
تست کروم نگرانی در مورد توانایی ادامه آزمایش جعبه ایمنی حریم خصوصی پس از حذف برچسب‌های آزمایشی که تفاوت قابل‌توجهی در کیفیت ترافیک بین Chrome با 3 رایانه غیرفعال (حالت B) و کاربرانی که شخصاً 3 رایانه شخصی را در تنظیمات Chrome غیرفعال کرده‌اند، برجسته می‌کنند. پاسخ ما مشابه فصل های قبل است:

تیم Privacy Sandbox می‌داند که شرکت‌ها مایلند به استفاده از برچسب‌های لغو کوکی‌ها ادامه دهند. روند گسترش در دسترس بودن برچسب ها شبیه به گسترش آزمایش مبدا است. پشتیبانی از برچسب ها در موارد متعددی گسترش یافته است. ما در نظر داریم پشتیبانی گسترده‌تری را برای برچسب‌های لغو کوکی پیشنهاد کنیم و به‌روزرسانی‌های blink-dev را در صورت وجود به اشتراک خواهیم گذاشت.

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

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

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

موضوعات

موضوع بازخورد خلاصه پاسخ کروم
انتخاب کردن در/خارج شدن آیا تأیید Google مبنی بر اینکه جستجوی Google از تصمیم سایت برای انصراف از Topics API به عنوان سیگنال رتبه بندی استفاده نمی کند، Google را از استفاده از تصمیم سایت برای شرکت در Topics API به عنوان سیگنال رتبه بندی محدود می کند؟ پاسخ ما مشابه فصل های قبل است:

تیم Privacy Sandbox هماهنگی نکرده یا از سازمان جستجو درخواست نکرده است که از رتبه بندی صفحه به عنوان انگیزه ای برای وب سایت ها برای استفاده از Topics API استفاده کند. جستجوی Google از تصمیم سایت برای پشتیبانی (یا عدم پشتیبانی) از Topics API به عنوان سیگنال رتبه بندی استفاده نمی کند.
قابلیت مشاهده استفاده درخواست مکانیزم مشاهده‌پذیری برای یک SSP یا فناوری تبلیغات عمومی تا بتواند ببیند آیا اجرای Topics API در وب مورد استفاده قرار می‌گیرد یا خیر. ما در حال ارزیابی پشتیبانی از این عملکرد هستیم و اگر این ویژگی اولویت بالایی داشته باشد، از بازخورد اضافی اکوسیستم استقبال می کنیم .
حریم خصوصی سوالاتی در مورد رضایت و پتانسیل شناسایی مجدد. ما در حال حاضر در حال بحث در مورد این موضوع در اینجا هستیم و از بازخوردهای اضافی استقبال می کنیم.

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

موضوع بازخورد خلاصه پاسخ کروم
PA API & GAM/AdX Google هیچ درخواستی برای GAM/AdX برای ناشر ارسال نمی کند که می خواهد به سرور تبلیغات ناشر رقیب تکیه کند. Google باید ناشران رقیب را قادر سازد تا فروشندگان حراج PA API سطح بالا را برای کنترل حراج نهایی انتخاب کنند. اطلاعات PA API برای GAM در دسترس خواهد بود اما برای SSP های رقیب محدود می شود. در نتیجه، ناشران قادر به مقایسه عملکرد تقاضای منبع PA API در GAM نیستند، مانند AdX یا SSP های ادغام شده در PA API. پاسخ کروم:
استاندارد PA API به گونه ای طراحی شده است که انعطاف پذیر باشد و به طرف های مختلف اجازه می دهد حراج سطح بالا را اجرا کنند. این انتخاب به پیاده سازی ها و قابلیت های خاص ارائه شده توسط سرور تبلیغاتی ناشر (چه GAM یا دیگری) و سایر شرکت های مشارکت کننده در اکوسیستم بستگی دارد.
طراحی با محوریت حریم خصوصی PA API، گزارش ریز را برای همه شرکت کنندگان به طور مداوم محدود می کند. داده‌های خاص گزارش‌شده از حراج PA API مشمول همان قوانین و محدودیت‌های تعریف شده توسط API و حفظ حریم خصوصی برای همه شرکت‌کنندگان، از جمله هر SSP است.
ناشران از گزارش‌های انبوه و حفظ حریم خصوصی PA API برای ارزیابی عملکرد استفاده می‌کنند. این امکان ارزیابی سهم کلی تقاضا از طریق PA API را فراهم می‌کند و امکان مقایسه با کانال‌های تقاضای دیگر را فراهم می‌کند، مطابق با اصول حریم خصوصی API بر اساس طراحی.

پاسخ ارائه شده توسط Google Ad Manager:
برای دسترسی به تقاضای AdX، ناشران ملزم به استفاده از عملکرد سرور تبلیغات GAM نیستند. علاوه بر این، PA API نسبت به کسانی که حراج را در طرح‌های تک‌فروشنده و چند فروشنده آغاز می‌کنند، ناشناس است.
فروشنده سطح بالا فروشنده سطح بالا (TLS) به اطلاعاتی دسترسی دارد که هیچ یک از فروشندگان اجزای دیگر به آن دسترسی ندارند، و این باعث نگرانی در مورد دسترسی نابرابر به اطلاعات می شود. در حالی که هر موجودیتی می تواند TLS باشد، برای دسترسی به تقاضای AdX، ناشران باید از GAM به عنوان سرور تبلیغات ناشر استفاده کنند. این امر انگیزه ای برای استفاده از GAM به عنوان سرور تبلیغات ناشر ایجاد می کند و یک مزیت رقابتی برای Google ایجاد می کند. پاسخ کروم:
طراحی PA API تعیین نمی کند که کدام نهاد می تواند به عنوان یک TLS عمل کند. نقش TLS مستلزم هماهنگی حراج و دسترسی به اطلاعات حراج مرتبط بر اساس ساختار API است.

پاسخ ارائه شده توسط Google Ad Manager:
ما برای سال‌ها تمرکز شدیدی بر عادلانه بودن حراج داشته‌ایم، از جمله قول داده‌ایم که هیچ قیمتی از منابع تبلیغاتی تضمین‌نشده ناشر، از جمله قیمت‌های اقلام خطی غیر تضمینی، با خریدار دیگری قبل از پیشنهاد در حراج به اشتراک گذاشته نمی‌شود، که بعداً در تعهدات خود به سازمان رقابت فرانسه مجدداً تأیید کردیم.
برای حراج‌های PA API، ما قصد داریم به قول خود عمل کنیم و قبل از اتمام حراج در حراج‌های چند فروشنده، پیشنهاد هیچ شرکت‌کننده در حراج را با هیچ شرکت‌کننده دیگری در حراج به اشتراک نگذاریم. برای واضح بودن، همانطور که در این به‌روزرسانی توضیح داده شده است ، قیمت حراج متنی را با هیچ حراج مؤلفه‌ای از جمله حراج خودمان به اشتراک نمی‌گذاریم. علاوه بر این، ما از اطلاعات مربوط به تنظیمات حراج اجزا، از جمله سیگنال‌های ارائه شده توسط خریداران به SSPها، به عنوان بخشی از حراج خود استفاده نمی‌کنیم.
علاوه بر این، همانطور که در بالا ذکر شد، GAM نیازی ندارد که ناشران از عملکرد سرور تبلیغاتی آن برای دسترسی به تقاضای AdX استفاده کنند.

در نهایت، همانطور که قبلاً در گزارش سه ماهه دوم / سه ماهه سوم 2024 گوگل اشاره شد ، پلتفرم‌های بایساید Google - Google Ads (که قبلا AdWords نامیده می‌شد) و DV360 - از صرافی‌های غیر Google، از جمله از طریق API PA، برداشت‌ها را خریداری می‌کنند.
PA API & GAM/AdX درک فعال کردن PA API در 100٪ موجودی برای ناشران دشوار است زیرا برچسب گذاری گزینه هدف را روشن نمی کند. برای SSPها، که ابزار اصلی دسترسی به موجودی آنها اغلب از طریق یک حراج چند سطحی با GAM که به عنوان TLS عمل می‌کند، عملاً هیچ راهی برای انجام آزمایش‌ها یا کسب درآمد از طریق PA API بدون قرار گرفتن در GAM وجود ندارد. پاسخ کروم:
استاندارد PA API نقش‌های فنی (مانند TLS و فروشنده مؤلفه) و فرآیند حراج را تعریف می‌کند و امکان انعطاف‌پذیری را برای پلتفرم‌ها در اجرای این نقش‌ها فراهم می‌کند.

فعالیت‌های عملیاتی - مانند پیکربندی، هماهنگی و توافق‌ها - توسط طرف‌های اجراکننده (ناشران، SSPها، ارائه‌دهندگان TLS) مدیریت می‌شوند تا مشارکت با استفاده از چارچوب PA API را تسهیل کنند.

پاسخ ارائه شده توسط Google Ad Manager:
همانطور که در مرکز راهنمای ما توضیح داده شده است، Ad Manager به ناشران کنترلی را برای فعال کردن آزمایش با فروشندگان مؤلفه غیر Google، مانند SSPهای دیگر، در 100٪ موجودی ناشر که در آن API برای استفاده در دسترس است، ارائه می‌دهد (با نادیده گرفتن هرگونه نمونه‌گیری یا کاهشی که ممکن است GAM اعمال کند).

اگر ناشر این کنترل را فعال کند، هرگاه فروشنده مؤلفه غیر Google پیکربندی حراجی را ارائه دهد، GAM تلاش می‌کند تا حراجی سطح بالایی را همراه با حراج مؤلفه ارائه‌شده اجرا کند، مشروط بر اینکه ناشر رضایت لازم کاربر را برای انجام این کار کسب کرده باشد. GAM برای ناشران روشن می کند که این کنترل ممکن است بر عملکرد تأثیر بگذارد، به طوری که ناشر بتواند تصمیمی آگاهانه بگیرد.
سمت سرور در مقابل روی دستگاه راه‌حل‌های سمت سرور، مانند Bidding و Auction (B&A)، با حفظ حریم خصوصی، قابلیت حل برای شکل‌دهی ترافیک را دارند. راه‌حل‌های سمت سرور تنها مسیر قابل اجرا به جلو هستند و Google باید راه‌حل‌های روی دستگاه را کنار بگذارد. هدف Privacy Sandbox پشتیبانی از راه‌حل‌های حراج سمت سرور (خدمات B&A) و راه‌حل‌های مزایده روی دستگاه، ارائه گزینه‌هایی برای رفع نیازهای مختلف فناوری تبلیغات و موارد استفاده است.
امنیت حراج حملات به پیشنهادات PA API اساساً برای مناقصه و مزایده روی دستگاه رد صلاحیت می‌شوند، این مسئله توسط ذینفعان حل نشده در نظر گرفته نمی‌شود و آنها همچنان به درخواست ضمانت‌های فنی برای اطمینان از دستکاری نشدن پیشنهادهای PA API و همچنین یک حالت اشکال‌زدایی جامع برای ارائه تشخیص رویداد در زمان واقعی و اشکال‌زدایی کارآمد می‌پردازند. اطمینان از یکپارچگی حراج PA API، از جمله کاهش حملات احتمالی، یک تمرکز کلیدی در جعبه ایمنی حریم خصوصی است. طراحی API شامل معیارهای یکپارچگی است و ما از بحث فنی بیشتر در مورد نگرانی های خاص استقبال می کنیم.

ما لیست مفصلی از حملات احتمالی به PA API و اقدامات کاهشی خود را در جلسه گروه جامعه ضد کلاهبرداری W3C در ماه می 2024 ارائه و مورد بحث قرار دادیم. ما از بحث‌ها و بازخوردهای بیشتر در مورد اینکه «حمله‌های احتمالی به پیشنهادات PA API» نگران‌کننده هستند، استقبال می‌کنیم.
ترافیک بدون کوکی آیا راهی برای فعال کردن PA API فقط در ترافیک بدون کوکی برای آزمایش یا اهداف دیگر وجود خواهد داشت؟ فناوری های تبلیغاتی می توانند تشخیص دهند که آیا 3PC وجود دارد یا خیر. در اینجا با جزئیات بیشتر توضیح داده شده است.
شناسه صندلی با توجه به پیشنهاد Seat ID ، آگاهی از شناسه صندلی برای اکثر درخواست‌های پیشنهادی ضروری است که باعث نگرانی در مورد گره زدن شناسه صندلی به ثبت نام خلاقانه می‌شود. علاوه بر این، آیا فقط برای "تبلیغ اصلی" یا همچنین برای تبلیغات جزء اعمال می شود؟ پیشنهاد BuyerAndSellerReportingId نگرانی در مورد عدم وجود شناسه صندلی خریدار در هنگام ثبت نام خلاقانه برای آگهی اصلی را برطرف می کند. هدف این شناسه این است که شناسه صندلی خریدار را به فروشنده ارسال کند. ما در حال ارزیابی پشتیبانی از تبلیغات مؤلفه هستیم.
نظارت و گزارش درخواست ویژگی برای نظارت بی‌درنگ (RTM) برای (1) ارسال گزارش‌های RTM برای حراج‌های لغو شده و همچنین (2) سطل‌های جدید پر از مرورگر برای مشخص کردن نوع لغو رخ داده. RTM راه حل مناسبی برای بررسی نرخ مشارکت به نظر نمی رسد. RTM به‌عنوان یک API نظارتی با تأخیر کم طراحی شده است تا قطع‌های بحرانی، ناگهانی و موقت را بگیرد. در مقابل، نرخ مشارکت نیازی به گزارش تاخیر کم ندارد و یک قطع موقت و ناگهانی بحرانی نیست. نگرانی در مورد نرخ مشارکت به طور موثر توسط فروشندگانی که خریداران با آنها همکاری می کنند، پاسخ داده می شود و نه توسط خریدارانی که از طریق مرورگر تحقیق می کنند.

علاوه بر این، از آنجایی که حراج های لغو شده بسیار رایج هستند، اگر مرورگر گزارش های RTM را از هر حراج لغو شده تولید کند، می تواند گزارش های RTM را برای قطعی های واقعی خفه کند.
مستندات
شفاف سازی		 گزارش یک عدم تطابق اسناد در توضیح دهنده API PA که بیان می کند که nonce باید یک رشته UUID باشد، اما در واقع یک وعده را برمی گرداند. در اینجا یک توضیح پیشنهاد شده است.
منجمد شده
زمینه		 هنگام کار با متن ثابت، چه گزینه‌هایی برای رسیدگی به مسائل و چالش‌های مربوط به (1) بسته‌بندی، (2) کتابخانه‌های خارجی، و (3) انواع داده‌های پشتیبانی‌نشده در دسترس هستند؟ ما در اینجا به این سوال پاسخ داده ایم.
مشخصات Private Aggregation API یک عملیات shareToHistogramOnEvent را اضافه کرد. در نتیجه، تعریف در PA API تبدیل به یک عملیات اضافه بار شد، و عملیات Web IDL "نباید در سراسر رابط، رابط جزئی [...]" بیش از حد بارگذاری شود ، بنابراین این تعریف اکنون نامعتبر است. در حالی که ما تغییرات مشابه را در هر دو ادغام می کنیم، این مسئله به یک ناهماهنگی موقت بین API PA و مشخصات جمع آوری خصوصی اشاره می کند. ما یک درخواست کشش را برای رسیدگی به این موضوع ادغام کرده ایم.
گروه های علاقه مند درخواست راهنمایی در مورد روش توصیه شده و کارآمد از نظر منابع برای پایان دادن به مشارکت در مناقصه گروه ذینفع (IG) در صورت توقف کمپین. در اینجا چند پیشنهاد وجود دارد که می توانیم ارائه دهیم:

ما معتقدیم که کمترین تأخیر، کمترین مکانیسم دائمی و همچنین کمترین مکانیسم آزادسازی منبع، استفاده از سیگنال‌های پیشنهادی بلادرنگ برای اطلاع‌رسانی generateBid() برای توقف پیشنهاد است.

گزینه دومی که از منابع کمتری استفاده می‌کند، اولویت منفی برای آن IG در پاسخ سیگنال‌های پیشنهادی بی‌درنگ است، زیرا این امر حتی فراخوانی generateBid() را متوقف می‌کند.

گزینه سوم، که حتی از منابع کمتری استفاده می کند، حذف تبلیغات از IG است. IGهای بدون تبلیغات دارای generateBid() آنها فراخوانی نمی شود.

گزینه چهارم، که حتی از منابع کمتری استفاده می کند، حذف biddingLogicURL از IG است. در این مرحله، IG همچنان می تواند به روز شود/به آن ملحق شود تا دوباره فعال شود.

گزینه‌های بیشتر حول خروج از IG می‌چرخند، یا از طریق leaveAdInterestGroup() یا clearOriginJoinedAdInterestGroups() یا از طریق IG در حال انقضا.

همانطور که در بالا مشخص شد، گزینه های مختلف پیامدهای تاخیر و مصرف منابع متفاوتی دارند. فناوری های تبلیغاتی می توانند گزینه ای را انتخاب کنند که بهترین معاوضه را برای موارد استفاده خاص آنها دارد.
مخاطبان درخواست مکانیزمی برای اجرای عملیات منطقی بر روی مخاطبان ساخته شده (مثلاً توانایی هدف قرار دادن یک تقاطع IG A و B) با PA API، اجرای عملیات منطقی روی مخاطبان از همان سایت امروز قابل دستیابی است. عملیات منطقی مخاطبان در سایت‌های مختلف امروز برای ملاحظات حریم خصوصی همانطور که در مدل حریم خصوصی ما توضیح داده شده پشتیبانی نمی‌شوند. ما به انجام تحقیقات در این زمینه ادامه می دهیم و هر گونه به روز رسانی را در طول مسیر به اشتراک خواهیم گذاشت.
درخواست ویژگی پیشنهاد حذف محدودیت در پیشنهادهای اضافی که نیاز به شناسایی TLS از قبل دارد. ما در حال حاضر در حال بحث در مورد این پیشنهاد در اینجا هستیم و از بازخورد اضافی استقبال می کنیم.
رویکرد به روز شده برای 3PC در Chrome آیا APIهای Privacy Sandbox مانند PA API عموماً در دسترس همه کاربران Chrome Stable باقی می‌مانند یا APIها (یا زیرمجموعه‌ای از APIها) فقط برای کاربرانی که 3PC را رد کرده‌اند در دسترس خواهند بود؟ ما قصد نداریم تصمیم کاربر برای رد کردن 3PC روی در دسترس بودن APIهای Privacy Sandbox در Chrome Stable تأثیر بگذارد.
سیگنالینگ پیشرفته آیا برنامه‌ای برای افزودن عملکردی وجود دارد که نشان دهد آیا TLS قصد دارد یک حراج PA API را اجرا کند؟ ما در حال ارزیابی پشتیبانی از این عملکرد هستیم. ما جزئیات بیشتر در مورد زمان بندی را در صورت در دسترس بودن به اشتراک خواهیم گذاشت و از بازخورد اضافی در مورد این درخواست استقبال می کنیم.
شناسه معامله نگرانی از اینکه نیاز به سرور KV در پیشنهاد Deal ID ممکن است یک فرآیند گران و زمان بر سمت سرور باشد. پیشنهاد Deal ID به SSPها اجازه می‌دهد تا متادیتای شناسه‌های معامله انتخابی را در طول مزایده‌های PA از سرور ارزش کلید جستجو کنند، به طوری که نیازی به بارگذاری تمام ابرداده‌های مربوط به معامله روی دستگاه نداشته باشند. این پیشنهاد در پاسخ به درخواست‌های SSPها توسعه می‌یابد، و ما از بازخورد اکوسیستم اضافی در اینجا استقبال می‌کنیم.

ما می‌دانیم که برای راه‌اندازی سرور ارزش کلیدی نیاز به کار است، اما به طور کلی هنوز فکر می‌کنیم که این یک مزیت خالص برای شرکت‌های فناوری تبلیغات است. ما همچنان از بازخوردها و پیشنهادات برای تسهیل این فرآیند استقبال می کنیم.
دربندی فرکانس متقاطع IG درخواست محدودیت فرکانس متقاطع از طریق PA API. محدودیت فرکانس متقاطع IG دارای ویژگی های چالش برانگیز حریم خصوصی است که ما نتوانسته ایم راه حلی برای آن پیدا کنیم.

اگر این ویژگی از اولویت بالایی برخوردار باشد، از بازخورد اضافی اکوسیستم استقبال می کنیم.
شناسه معامله و گزارش شناسه صندلی درخواست توانایی برای دریافت معامله یا قرار دادن شناسه‌های صندلی در گزارش‌دهی انبوه. عملکردهای شناسه گزارشی که در اینجا روی آنها کار می کنیم، گزارش شناسه معاملات و صندلی را ممکن می کند.

SelectBuyerAndSellerReportingId به reportResult() ارائه می شود، بنابراین ساده ترین راه برای گزارش آن از طریق گزارش سطح رویداد (یعنی رمزگذاری شناسه Deal در URL ارسال شده به sendReportTo()) است. اگر قرار باشد از گزارش انبوه استفاده شود، این کار نیز قابل انجام است.

ویژگی گزارش شناسه در حال حاضر برای 10٪ از ترافیک کانال Chrome Stable فعال است. ما در حال ارزیابی گسترش راه اندازی به 100٪ هستیم.
گروه های علاقه مند از همان ترتیب اولویت در هر دو انتخاب و ارزیابی IG استفاده کنید و از آن ترتیب اولویت در همه حالت های ارزیابی استفاده کنید. ما در حال حاضر در حال بحث در این مورد در اینجا هستیم و از بازخوردهای اضافی استقبال می کنیم.
گروه های علاقه مند پیشنهاد استفاده از فعال‌سازی و تفویض اختیار مخاطب به عنوان راه‌هایی برای افزایش پذیرش API Sandbox Privacy. ما از این درخواست چندین ذینفع آگاه هستیم و در حال بررسی راه حل هستیم.

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

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

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

موضوع بازخورد خلاصه پاسخ کروم
خدمات K/V درخواست‌های مرورگر به سرور KV فروشنده چگونه دسته‌بندی می‌شوند؟ برای یک فروشنده، درخواست از مرورگر چگونه خواهد بود - درخواست GET یا POST؟ بعلاوه در مورد الزامات ناشناس بودن k نیاز به توضیح است. برای نسخه 1، Chrome یک درخواست GET به سرویس KV فروشنده ارسال می‌کند تا trustedScoringSignalsURL با سیگنال‌های موجود در پارامترهای درخواست درخواست واکشی کند. پارامترها شامل hostname ، renderUrls ، adComponentRenderUrls ، و experimentGroupId هستند. ما در حال حاضر در حال آزمایش برخی برنامه‌های افزودنی برای ارسال اطلاعات اضافی برای اسکن خلاق هستیم، اما هنوز راه‌اندازی نشده است.

هنگام تنظیم maxTrustedScoringSignalsURLLength روی 0، Chrome به طور بالقوه می‌تواند همه سیگنال‌ها را در یک درخواست جمع کند (احتمالاً از هر محدودیت طول URL در سرور خود فراتر می‌رود)، اما تضمین نمی‌شود. Chrome در حال حاضر انتخاب می‌کند که اگر درخواست‌ها در فاصله ۱۰ میلی‌ثانیه از یکدیگر ارسال شوند، درخواست‌ها را در همان دسته قرار دهد، اگرچه ما در حال حاضر در حال بررسی نحوه بهینه‌سازی این هستیم.

هنگام کار با TrustedScoringSignals، به یاد داشته باشید که Chrome به هدرهای کش احترام می گذارد. سرصفحه‌هایی مانند Stale-While-Revalidate "Cache-Control" می‌توانند با اجازه دادن به Chrome برای استفاده از کپی ذخیره‌شده (و به‌روزرسانی حافظه پنهان برای حراج بعدی)، متوسط ​​تأخیر را کاهش دهند و به‌طور مؤثر سیگنال‌های دریافتی را از مسیر بحرانی حذف کنند.

در نهایت، در مورد k-ناشناس بودن، به نظر می رسد بخش خاص توضیح دهنده قدیمی است. در ابتدا می‌خواستیم نشانی‌های اینترنتی سیگنال‌های مورد اعتماد k-ناشناس باشند، اما این الزام حذف شد. این جمله را از توضیح دهنده حذف می کنیم.
خدمات B&A ارتقاء به آخرین نسخه B&A زمان زیادی می برد. زمان ساخت سریعتر یا تصاویر از پیش ساخته شده مفید خواهد بود. فناوری های تبلیغاتی می توانند باینری ها را به تنهایی بسازند و با استفاده از هش های ارائه شده اعتبار سنجی کنند. بررسی امکان ارائه مصنوعات از پیش ساخته یا بهبود زمان ساخت در آینده را در نظر خواهیم گرفت.
درخواست ویژگی API درخواست سازگاری macOS برای اسکریپت‌های ساخت، تصاویر کانتینر و ابزارهای فراخوانی Bidding & Auction Services (B&A) برای تسهیل توسعه و آزمایش محلی. ما در حال حاضر از amd64 پشتیبانی می کنیم که برای استقرار در سیستم عامل های ابری پشتیبانی شده (GCP و AWS) کافی است. ممکن است در آینده پشتیبانی از معماری های دیگر را بررسی کنیم.
AWS آیا داشتن نقش های IAM یک نیاز برای ساخت های تولید ایجاد می کند؟ بله، نقش های IAM برای مجوزهای مناسب و ارتباط با هماهنگ کننده ها مورد نیاز است. از کلیدها برای رمزگشایی متن رمزی ProtectedAudienceInput استفاده می‌شود که در دستگاه تولید می‌شود. علاوه بر این، این نقش‌ها برای گذراندن گواهی سرور/TEE ساخت‌های تولید با همان هماهنگ‌کننده‌ها مورد نیاز هستند. در راهنمای سلف سرویس ما به این موضوع با جزئیات بیشتر پرداخته شده است.
پرچم های B&A با توجه به اینکه امروزه این تعاریف در کد Terraform، فایل‌های cc و فایل‌های اولیه قرار دارند، درخواست می‌کنیم که تعاریف پرچم‌های B&A موجود در اسناد فهرست شوند، اما فناوری‌های تبلیغاتی از مستندات روی این پرچم‌ها بهره می‌برند و از آن به عنوان منبع حقیقت برای درک نحوه سفارشی‌سازی استقرارها استفاده می‌کنند. ما در حال بررسی امکان مستندسازی توضیحات پرچم های Terraform هستیم و از بازخورد اضافی در اینجا استقبال می کنیم.
AWS
خدمات مناقصه		 به دنبال راهنمایی در مورد خدمات پیشنهادی در AWS و رفتار و پیکربندی پیش‌فرض ورود به سیستم. برای اشکال‌زدایی سرویس‌های مناقصه خود در TEE (مانند سرویس Bidding)، توصیه می‌کنیم از اشکال‌زدایی موافق با Ad Tech استفاده کنید. این به شما این امکان را می‌دهد تا ثبت جزئیات را فعال کنید و داده‌های درخواست/پاسخ را برای درخواست‌های آزمایشی خاص خود مستقیماً از مشتری خود دریافت کنید تا به اشکال‌زدایی کمک کند.
TEE K/V
مستندات		 درخواست توضیح در مورد آغاز اجرای TKV همانطور که در سایت توسعه بیان شده است. ما قبل از نیاز به استفاده از TEE اطلاع کافی ارائه خواهیم کرد. تا آن زمان، می‌توانید به استفاده از سرور خود برای سیگنال‌های کلید/مقدار بی‌درنگ ادامه دهید.
تست و آنالیز B&A تجزیه و تحلیل و آزمایش B&A همچنان پرهزینه است و به نظر آماده تولید نیست. برای بررسی بیشتر به اطلاعات بیشتری در مورد تجزیه و تحلیل هزینه و عواملی که منجر به ارزیابی آمادگی تولید می شود نیاز داریم.
بهینه سازی سرور قابل اعتماد پیشنهادی برای ادغام پارامترهای خاص فروشندگان جزء در یک پارامتر inputsPerSeller ، با استفاده از یک رشته JSON برای مقدار آن. ما در حال بحث در مورد این پیشنهاد هستیم و از بازخورد اضافی در اینجا استقبال می کنیم.
امنیت چگونه خطرات امنیتی ناشی از TKV با استفاده از B&A کاهش می یابد؟ جلوگیری از تماس های خارجی به TKV امکان پذیر است. امروزه در GCP به طور کامل پشتیبانی و قابل تنظیم است.

برای AWS، به دلیل منسوخ شدن AWS App Mesh، که قبلاً این قابلیت را فعال کرده بود، باید پشتیبانی بیشتری ایجاد شود. ما از بازخورد اضافی در اینجا استقبال می کنیم.
خدمات B&A درخواست شفافیت در روایت/کامنت ها در مورد ارزش جریان HTTP برای بهینه سازی B&A. Privacy Sandbox از قابلیت‌های پخش جریانی در انتقال داده‌های B&A پشتیبانی می‌کند تا تأخیر را برای فناوری‌های تبلیغاتی که استفاده از آن را انتخاب می‌کنند بهبود بخشد. بهینه سازی عملکرد اختیاری در حالت ترکیبی است.
پیش فرض درخواست به‌روزرسانی‌ها برای مشارکت در کتابخانه منبع باز Prebid برای فعال کردن ویژگی‌های PA API B&A برای اکوسیستم. در مارس 2025، کروم بهینه‌سازی Prebid-Preferred را در حالت پایدار راه‌اندازی کرد، همانطور که در نقشه راه عمومی B&A مستند شده است (به مارس 2025 مراجعه کنید ).
شکل دهی ترافیک درخواست مکانیسم‌هایی برای ثبت سیگنال‌های متنی دریافت‌شده توسط B&A برای درک بهتر زمانی که IGها فعال می‌شوند و منطق «نیت به پیشنهاد» آن‌ها را در پاسخ متنی بهبود می‌بخشند. این امکان استفاده بهتر از منابع شبکه را برای جلوگیری از "ترافیک بی فایده" (معروف به شکل دهی ترافیک) فراهم می کند. ما در حال حاضر در حال بحث در مورد یک پیشنهاد در اینجا هستیم و از بازخورد اضافی استقبال می کنیم.
مستندات
شفاف سازی		 توضیح لازم در مورد خطای «سرویس/پراکسی Vsock قابل دسترسی نیست» در راه‌اندازی یکپارچه‌سازی تست B&A مشاهده شد. این به دلیل حداقل نیازهای حافظه است . توضیح دهنده پیکربندی AWS برای منعکس کردن این نیاز به روز شده است.

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

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

موضوع بازخورد خلاصه پاسخ کروم
داده های زمان واقعی فقدان داده های زمان واقعی بر همه افراد در صنعت تأثیر می گذارد. تأخیر در داده‌های هم‌زمان یک مشکل جدی برای تبلیغ‌کنندگان است، خریداران به پلتفرم‌هایی می‌روند که دارای Google Analytics هستند، زیرا تنها جایی است که می‌توانند مدرکی برای دستیابی به مخاطبان دریافت کنند. تأخیرهای بی‌درنگ داده که بخشی از API گزارش انتساب (ARA) است به‌عنوان مکانیسم‌های حفاظت از حریم خصوصی برای کاهش توانایی فناوری‌های تبلیغاتی برای استفاده از گزارش‌های سطح رویداد برای ردیابی کاربران در سراسر سایت‌ها اجرا می‌شوند. با این حال، ARA با اجازه دادن به گزارش‌های سطح رویداد برای داشتن یک پنجره گزارش حداقل 1 ساعته و با اجازه دادن به گزارش‌های انبوه برای ارسال فوری به فناوری‌های تبلیغاتی بدون تأخیر، انعطاف‌پذیری را در نحوه ارائه گزارش‌های انتساب فراهم می‌کند.
استفاده از API درخواست تأیید در مورد پیکربندی صحیح برای جریان ارجاع برنامه متقاطع وب، به‌ویژه هنگامی که اسناد وب به وب و وب به برنامه را به صورت موازی اجرا می‌کنید. هنگامی که کمپین های وب به وب و وب به برنامه را به صورت موازی اجرا می کنید، فناوری تبلیغات باید تنها یک پلت فرم را برای ثبت هر منبع یا محرک انتخاب کند تا از شمارش مضاعف جلوگیری شود. ما اکیداً توصیه می‌کنیم تا جایی که ممکن است از سیستم عامل (OS) استفاده کنید، زیرا سیستم عامل توانایی انجام اسناد وب به وب و وب به برنامه را دارد، تا زمانی که منابع وب و راه‌اندازها به درستی واگذار شده باشند. این به معنای پاسخ دادن با سرصفحه Attribution-Reporting-Register-OS-Source برای منابع و Attribution-Reporting-Register-OS-Trigger سرصفحه برای محرک ها است.

سرصفحه Attribution-Reporting-Support را می‌توان برای تشخیص اینکه آیا Chrome و/یا پشتیبانی در سطح Android وجود دارد یا خیر، استفاده کرد. هدر Attribution-Reporting-Info زمانی مفید است که هیچ عنوان Attribution-Reporting-Support در درخواست وجود نداشته باشد، در این صورت مرورگر بر اساس در دسترس بودن پشتیبانی پلت فرم در دستگاه کاربر، تصمیم ثبت پلت فرم را می گیرد.
مشخصات API به دنبال توضیح در مورد سرصفحه درخواست HTTP Attribution-Reporting-Support که توسط API گزارش انتساب تنظیم شده است و اینکه آیا سرصفحه شامل کلیدهای وب و سیستم عامل بدون توجه به پلتفرم است یا خیر. سرصفحه Attribution-Reporting-Support منوط به اضافه کردن پارامترهای "GREASE" توسط مرورگر است تا اطمینان حاصل شود که سرورها از تجزیه کننده سرصفحه ساختار یافته مطابق با مشخصات استفاده می کنند. برای این هدر، فقط کلیدهای ساختاریافته باید تفسیر شوند. مقادیر و پارامترها در حال حاضر استفاده نمی شوند. برای مثال اینجا را ببینید.
گزارش گیری مبتنی بر 3PC درخواست راهنمایی در مورد نحوه عیب‌یابی مغایرت‌های اندازه‌گیری بین ARA و 3PC در کمپین‌های تبلیغاتی. ARA از دو نوع گزارش اشکال‌زدایی پشتیبانی می‌کند که می‌توان از آنها برای عیب‌یابی و اشکال‌زدایی مغایرت‌ها استفاده کرد. گزارش‌های اشکال‌زدایی Attribution-success را می‌توان برای مقایسه آسان نتایج ARA با نتایج سایر فناوری‌های اندازه‌گیری استفاده کرد، و گزارش‌های اشکال‌زدایی Verbose را می‌توان برای دریافت اطلاعات بیشتر و عیب‌یابی مشکلات احتمالی در ثبت‌های انتساب استفاده کرد.
استفاده از API در حالی که آزمایش ARA برخی از موارد کشف شده است: گزارش ناکافی دانه ای که منجر به داده های پر سر و صدا و بهینه سازی کمپین انعطاف پذیر می شود ، آستانه های بالا به استثنای تبلیغ کنندگان کوچکتر و مشکل در مقایسه کمپین ها به دلیل شاخص های عملکردی متناقض. ARA با ارائه پارامترهای مختلف که می توانند فناوری های تبلیغاتی را برای دستیابی به موارد استفاده از اندازه گیری خاص خود تنظیم کنند ، انعطاف پذیری را فراهم می کند. گزارش های سطح رویداد از گزارش دهی انعطاف پذیر در سطح رویداد پشتیبانی می کند که به فناوری های تبلیغاتی اجازه می دهد ویندوز گزارش دهی خود ، تعداد گزارش هایی را که می توانند دریافت کنند و داده های ماشه ای که می خواهند اندازه گیری کنند ، شخصی سازی کنند و این می تواند تأثیر نویز را بر روی داده های آنها تغییر داده و به آنها امکان دستیابی به موارد مختلف را بدهد. به طور مشابه ، گزارش های کل دارای روش های مختلفی هستند که می توانند تنظیمات خود را از جمله تعداد ابعادی که ردیابی می کنند ، فرکانس دسته بندی آنها و استفاده از بودجه مشارکت برای تغییر تأثیر نویز و دستیابی به موارد مختلف استفاده را سفارشی کنند.
مشخصات API سوال در مورد وابستگی ARA به 3pcs ، به طور خاص در مورد اینکه آیا در مرحله آزمایشی که به این 3 قطعه نیاز دارد باقی مانده است. ARA مستقل از 3pcs فعال است ، اما 3pcs باید فعال شود تا گزارش اشکال زدایی انتقالی ARA اجازه دهد تا نتایج ARA را با نتایج انتساب مبتنی بر کوکی مقایسه کند.
استفاده از API پرس و جو در مورد ثبت منابع برای انتساب برنامه به WEB در نسخه های قدیمی Android (11 ، 12 و 13) با استفاده از ARA. ARA در حال حاضر در Android S و بالاتر (12+) پشتیبانی می شود.
استفاده از API درخواست ARA Opt-In نرخ و جزئیات توزیع. پاسخ ما از محله های قبلی بدون تغییر است:

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

سرویس تجمیع

موضوع بازخورد خلاصه پاسخ کروم
درخواست ویژگی درخواست های ویژگی برای خدمات جمع آوری:

ادغام های سرور به سرور ، اندازه گیری دستگاه متقابل ، سهولت انتساب چند لمسی و گزارش سهم ، انتساب omnichannel و پشتیبانی از حلقه های بهینه سازی پیشرفته ML (به عنوان مثال ، آموزش مدل خصوصی).		 ما در حال ارزیابی این درخواست ها هستیم و در صورت وجود جزئیات بیشتر را به اشتراک خواهیم گذاشت.

ما از بازخورد اضافی از اکوسیستم در مورد اینکه آیا این درخواست ها در اولویت قرار دارند استقبال می کنیم.
درخواست ویژگی به منظور کاهش نگرانی های مربوط به تنظیم مجدد هنگام به روزرسانی در هنگام به روزرسانی خدمات جمع آوری ، درخواست تنظیم پارامتر EBS Delete_On_termination را در True در محیط Terraform انجام دهید. ما در حال ارزیابی این درخواست هستیم و در صورت وجود جزئیات بیشتر را به اشتراک خواهیم گذاشت.

ما از بازخوردهای اضافی از اکوسیستم در مورد اینکه آیا این درخواست در اینجا اولویت است ، استقبال می کنیم.
مستندات
شفاف سازی		 درخواست راهنمایی در مورد آنچه می تواند تغییر کند (به عنوان مثال آستانه نظارت) و آنچه باید دست نخورده باقی بماند. ما در حال ارزیابی انتشار مستندات و راهنمایی های اضافی در مورد سفارشی سازی های موجود برای خدمات جمع آوری هستیم.
استقرار درخواست شفاف سازی در مورد عدم استقرار جدید در فرماندهی Bazel. عدم موفقیت در استقرار می تواند به دلیل نسخه عکس مورد استفاده در محیط زیست اتفاق بیفتد.

مستندات برای پوشش اشکال زدایی در مورد خرابی های Terraform و همچنین نشان دهنده نسخه مورد نیاز Bazel تنظیم می شود.

API تجمع خصوصی

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

در مورد نمایش داده های Wildcard ، ما این درخواست را ارزیابی می کنیم و در صورت وجود جزئیات بیشتری را به اشتراک می گذاریم.

در مورد قانون "بدون نسخه" ، به منظور فعال کردن آزمایش ، ما به طور موقت از حالت اشکال زدایی به منظور دور زدن این قانون پشتیبانی می کنیم. این در اینجا با جزئیات بیشتری بیان شده است.
شناسه و سطل فیلتر آیا امکان درخواست به سرویس جمع آوری همان سطل با دو شناسه فیلتر مختلف در دو اجرا جداگانه ، یعنی ، آیا شناسه فیلتر می تواند به عنوان یک پارتیشن بندی تکمیلی دامنه ها عمل کند؟ بله ، این ویژگی پشتیبانی می شود. هنگام انجام تجمع ، فقط مشارکت با شناسه فیلتر مطابق با لیست در پارامترهای شغلی پردازش می شود و بقیه برای پردازش در اجرا (های) جداگانه در دسترس خواهند بود.
انتساب چند لمسی درخواست های شفاف سازی در مورد اجرای انتساب چند لمسی (MTA):

1) آیا اگر مقدار تجمع از 2^16 تجاوز نکند ، محدودیتی برای تعداد مشارکت ها وجود دارد؟

2) آیا محدودیتی برای تعداد کلیدهای تجمع منحصر به فرد (سطل) وجود دارد که می تواند برای یک زمینه معین ذخیره شود؟

3) چگونه خدمات خلاصه خدمات جمع آوری گزارش می دهد که هر نماینده کاربر (مرورگر) دارای یک کلید تجمع منحصر به فرد است ، همانطور که احتمالاً در MTA وجود دارد؟		 1) ما محدودیت های پیش فرض سهم را ایجاد کرده ایم ، اما گزینه هایی برای تماس گیرنده API وجود دارد که همانطور که در اینجا توضیح داده شده است ، آنها را نادیده بگیرد. هدف از محدودیت ها کمک به تماس گیرندگان API برای مدیریت هزینه گزارش های پردازش در سرویس جمع آوری است.

2) چنین محدودیتی وجود ندارد ، اگرچه فناوری های تبلیغاتی باید دانه کلیدهای تجمع را برای بهبود نسبت سیگنال به نویز در نظر بگیرند ، همانطور که در اینجا توضیح داده شده است.

3) لطفاً به این راهنمایی ، به ویژه راهنمایی سیگنال به نویز که در بالا در مورد مورد 2 خطاب شده است) مراجعه کنید.

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

نکات مربوط به کاهش کاربر/کاربر-عامل

موضوع بازخورد خلاصه پاسخ کروم
درخواست ویژگی درخواست اضافه کردن SEC-CH-UA-ROBOT به نکات مشتری عامل کاربر (UA-CH) زیرا این امکان را به سرورها می دهد تا ترافیک خودکار را برای سازگاری با محتوا ، امنیت و تجزیه و تحلیل شناسایی کنند. این یک مورد مهم است که در سایر گروه های استاندارد مورد بحث قرار می گیرد (برای جزئیات بیشتر به اینجا مراجعه کنید) ، و ما به طرفین علاقه مند می کنیم با ارائه بازخورد خود شرکت کنند. با این حال ، ما در نظر می گیریم که UA-Ch ممکن است راه حل مناسب نباشد ، با توجه به اینکه هدر درخواست HTTP می تواند به راحتی با ترافیک خودکار دستکاری شود.

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

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

علاوه بر این ، برای محافظت از حریم خصوصی کاربران در زمینه نیاز به احراز هویت ، طراحی توکن ما با علامت کور است به این معنی که نشانه صادر شده در هنگام ورود به سیستم متفاوت است با نشانه ای که در طول پروکسی استفاده می شود ، بنابراین نشانه های صادر شده نمی توانند بعداً با هویت Google کاربر مرتبط شوند. این بدان معناست که Google نمی داند کاربر چه کسی است که این ترافیک کاربر در حالت ناشناس قرار دارد ، با وجود نیاز به احراز هویت به دلایل ضد کلاهبرداری.
حریم خصوصی آدرس IP استفاده از IPS گامی در جهت اشتباه است. آنها نمی توانند مانند کوکی ها از مرورگر حذف شوند و کاربران همان کنترل شفافیت را با کوکی ها ندارند. اگر کوکی ها از بین بروند ، صنعت به عنوان یک راه حل جایگزین به سمت استفاده از IPS حرکت می کند و اولویت حفظ خود را بر حریم خصوصی قرار می دهد. به عنوان یک پلتفرم ، Chrome قصد دارد ویژگی هایی را در اختیار کاربران قرار دهد که تجربه مرور خود را در وب بهبود بخشد. برای کاربران Chrome که تصمیم می گیرند در ناشناس مرور کنند ، این بدان معناست که با محدود کردن در دسترس بودن اطلاعات آدرس IP در زمینه های شخص ثالث ، محافظت های پیشرفته ای را در برابر ردیابی متقابل سایت ارائه می دهند.
لیست دامنه نقاب دار معیارهای انتخاب در لیست دامنه نقاب دار (MDL) چیست؟ Chrome معیارهایی را برای شناسایی اینکه کدام دامنه ها باید در MDL باشند ، تهیه کرده و بنابراین آدرس های IP ماسک شده را در یک زمینه شخص ثالث دریافت می کنند. Google با Inconnect.me ، یک رهبر برجسته حفظ حریم خصوصی اینترنت که با سایر مرورگرهای وب نیز همکاری می کند ، همکاری کرده است. Chrome برای شناسایی دامنه هایی که با معیارهای تعیین شده Chrome مطابقت دارند ، از Inconnect.ME استفاده می کند. علاوه بر این ، Chrome روشی را برای شناسایی توابع JavaScript که به طور گسترده استفاده می شود که خروجی های مداوم از API های وب پایدار و بالا آنتروپی را ارائه می دهد ، تهیه کرده است و بنابراین می تواند برای ساخت شناسه های احتمالی آنتروپی بالا استفاده شود. این توابع سپس هنگامی که در وب سایت ها در یک متن شخص ثالث بارگذاری می شوند ، شناسایی می شوند و در نتیجه لیستی از دامنه هایی که با این خصوصیات که بخشی از MDL می شوند ، به اسکریپت ها خدمت می کنند و به همین دلیل مجاورت می شوند. خط لوله تشخیص که به دنبال این الگوهای سوء استفاده API است ، تمام حوزه ها ، از جمله دامنه های خود Google را در نظر می گیرد.
پیشگیری از تقلب بازخورد در مورد احتمالی نشان می دهد که توکن ها (PRTs) که 24 ساعته پیشنهادی تأخیر را نشان می دهد و نرخ ها را نشان می دهد که مانع از تشخیص کلاهبرداری در زمان واقعی می شود. درخواست تاخیر کوتاهتر (تأخیر 1 ساعته) و نرخ بالاتر (حداقل دو رقمی). پیشنهادات بیشتر شامل فعال کردن نرخ دیفرانسیل بر اساس سیگنال های ریسک (VPN ، مرورگرهای خودکار) و اجازه آشکار کردن هدفمند از نشانه های خاص است. بیشتر توسعه دهندگان ما با آنها صحبت کردیم تا گزارش های ساعتی را به مشتریان خود ارائه دهند و چندین لیست Blocklist IP را در طول روز به روز کنید. یک دوره تأخیر کوتاه تر به روزرسانی های مکرر را امکان پذیر می کند ، و زیر یک ساعت ، اندازه گیری IVT را در آمار ساعتی دوباره قابل استفاده می کند ، اما همچنین به طور بالقوه احتمال شناسایی مجدد کاربران را افزایش می دهد. ما برای کاوش در کاهش دوره های تأخیر و تغییر نرخ آشکار بر اساس مطالعات اکوسیستم ، و بازخورد ذینفعان و بازخورد اضافی در اینجا استقبال می کنیم.
لیست دامنه نقاب دار سؤال مربوط به گنجاندن دامنه در MDL با وجود عدم استفاده از تبلیغات تبلیغاتی. این نگرانی که این امر می تواند "پل زدن" را قادر به ایجاد پروفایل بر اساس آدرس های IP کند. ما اهمیت اجرای یک فرایند تجدید نظر را برای رویکرد مبتنی بر لیست خود تشخیص می دهیم. تجدید نظر به شرکتها اجازه می دهد تا ادعا کنند که دامنه آنها در MDL معیارهای ورود به مطالعه را برآورده نمی کند و باید حذف شود ، در نتیجه این امکان را می دهد که همچنان آدرس های IP اصلی کاربران را در یک زمینه شخص ثالث در حالت ناشناس دریافت کند.

ما اکنون روند تجدید نظر را برای ارائه صاحبان دامنه زمان کافی برای درخواست تجدید نظر و دریافت تصمیمی قبل از راه اندازی محافظت از IP در حالت ناشناس در Chrome Pateable راه اندازی کرده ایم.

جزئیات بیشتر در مورد روند تجدید نظر در اینجا موجود است.
لیست دامنه نقاب دار بازخورد مبنی بر اینکه ناشران در حال بررسی پیامدهای شرکای خود در MDL هستند. آنها توسط مقررات GEOIP در توضیح دهنده محافظت از IP اطمینان حاصل شدند. Chrome اهمیت حمایت از موارد استفاده مبتنی بر جغرافیایی را تشخیص می دهد. پروکسی آدرس های IP را نشان می دهد که محل درشت کاربر ، از جمله کشور را نشان می دهد. اطلاعات بیشتر در توضیحات جغرافیایی IP در دسترس است.
لیست دامنه نقاب دار سوال در مورد MDL آیا هدف قرار دادن سطح کشور هنوز در دسترس است یا خیر. Chrome اهمیت حمایت از موارد استفاده مبتنی بر جغرافیایی را تشخیص می دهد. پروکسی آدرس های IP را نشان می دهد که محل درشت کاربر ، از جمله کشور را نشان می دهد. اطلاعات بیشتر در توضیحات جغرافیایی IP در دسترس است.
تشخیص تقلب نگرانی در مورد تأثیر محافظت از IP در سیستم های تشخیص کلاهبرداری. آیا کاربران IPS پروکسی یا هدر را می بینند؟ آیا SSP ها و DSP ها همان آدرس IP پروکسی را برای استفاده خاص مشاهده می کنند؟ ناسازگاری می تواند بر تشخیص کلاهبرداری و OpenRTB تأثیر بگذارد. کاربران در حال مرور در حالت ناشناس با محافظت از IP که باعث ایجاد درخواست برای دامنه های MDL می شوند ، یک آدرس IP پروکسی را بر اساس یک Geofeed تعریف شده دریافت می کنند. سازمانها ممکن است درخواست PRT را به عنوان یک عنوان اضافی در ترافیک پراکنده منتقل کنند ، که در آن می توان نمونه کوچکی از IP های اصلی را پس از یک دوره تأخیر فاش کرد. ما گمان می کنیم بسیاری از SSP ها آدرس IP پروکسی شده خود را در درخواست های پیشنهاد سرور به شرکای تقاضای خود منتقل می کنند ، اما برنده DSP ها برای دیدن همان آدرس IP پروکسی در زمان تصور تضمین نمی شوند.
تشخیص تقلب سؤالات مربوط به فرکانس به روزرسانی پرونده جغرافیایی IP ، زمان بندی به روزرسانی برای جزئیات در مورد گزارش رفتار کلاهبرداری و PRT ها ، و اینکه چگونه فناوری تبلیغی باید فعالیت های کلاهبرداری را تشخیص دهد. توضیح دهنده PRTS زنده است ، همانطور که لیست آدرس های IP پروکسی و مناطق GEO نقشه برداری آنها نیز وجود دارد. توصیه می کنیم به طور دوره ای این پرونده را برای به روزرسانی و تغییرات بررسی کنید ، زیرا آدرس های IP با گذشت زمان می چرخند. آدرس ایمیل عمومی برای گزارش سوءاستفاده نزدیکتر به راه اندازی اعلام می شود.
موقعیت جغرافیایی درخواست لیست عمومی آدرس های IP که برای پروکسی ها استفاده می شود. آدرس IP نقشه برداری از پرونده به مکانهای خشن برای محافظت از IP در اینجا موجود است. لطفاً توجه داشته باشید که این پرونده به صورت دوره ای به روز می شود.
استفاده از API ادعا که به نظر می رسد محافظت از IP به طور پیش فرض روشن است و به کاربران گزینه انتخابی داده نمی شود. محافظت از IP برای کاربران در حالت ناشناس Chrome ، در سیستم عامل های Android و Desktop در دسترس خواهد بود. کاربران توانایی غیرفعال کردن محافظت از IP را خواهند داشت. برای نسخه های مدیریت شده از Chrome ، محافظت از IP می تواند فعال شود ، اما به طور پیش فرض خاموش خواهد بود.
استفاده از API پرس و جو در مورد در دسترس بودن پرچم آزمایش برای فعال کردن و آزمایش محافظت از IP در نسخه های کروم قناری و بتا. در حال حاضر ، ما یک پرچم آزمایش برای آزمایش ویژگی کامل محافظت از IP در دسترس نداریم. آزمایش های عملکردی که ما فقط ترافیک پروکسی را انجام می دهیم که به حوزه های Google می رود.
حریم خصوصی آدرس IP چگونه می توان تنظیمات سریع 3PC را هنگام حرکت یک مرورگر به حالت ناشناس کار کرد؟ 3pcs به طور پیش فرض در حالت ناشناس مسدود می شوند.
حالت ناشناس به دنبال شفاف سازی در مورد اینکه آیا محافظت از IP در حالت ناشناس در هنگام ورود کاربر به Chrome عمل می کند. اگر کاربر قبل از راه اندازی حالت ناشناس وارد Chrome نشده باشد ، محافظت IP فعال نیست. دلایل این امر برای اهداف ضد کلاهبرداری و سوءاستفاده است ، یعنی دسترسی محدود کننده نرخ به پروکسی ها. محافظت از IP از تأیید اعتبار مشتری برای محدود کردن توانایی بازیگران بد در استفاده از پروکسی ها برای تقویت حملات به خدمات به MDL استفاده می کند. بنابراین ، محافظت از IP فقط در دسترس کاربرانی خواهد بود که با استفاده از حساب Google که با آنها در مرورگر Chrome امضا شده اند ، قبل از باز کردن یک پنجره جدید ناشناس ، در مرورگر Chrome در دسترس هستند.
حالت ناشناس درخواست های ارزیابی تأثیر محافظت از IP قبل از راه اندازی ، از جمله:
(1) پیشنهاد برای استفاده از پرچم حالت مرورگر یا گزارش API کل برای تعیین میزان استفاده از حالت ناشناس.
(2) ارسال یک هدر محافظت از IP برای یک دوره قبل از فعال کردن ویژگی. و
(3) حمل این ویژگی به درصد کوچک و شناخته شده ترافیک برای برون یابی.		 ما علاقه اکوسیستم را به درک و اندازه گیری مقیاس و تأثیر محافظت از IP درک می کنیم. با این حال ، Chrome در جهت انتخاب کاربر برای مرور در حالت ناشناس خصوصی کار می کند. Chrome روشی را برای شناسایی کاربرانی که در حال مرور ناشناس هستند ، در معرض دید قرار نمی دهد و برای محدود کردن سیگنال های دیگر که ممکن است حالت مرور کاربر را نشان دهد ، اقدامات لازم را انجام داده است.

ما در حال بررسی راه هایی برای تسهیل این آزمایش هستیم بدون اینکه در حریم شخصی کاربرانی که در حالت ناشناس مرور می کنند تأثیر بگذارد و از بازخورد اضافی از اکوسیستم استقبال کنیم.

تخلیه های ردیابی گزاف گویی

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

فرآیند تجدید نظر مدیریت شده شخص ثالث که در گزارش Q2/Q3 CMA ذکر شده است ، مخصوص مناطقی است که گوگل در مورد ورود یا محرومیت شرکتهای انفرادی در لیست ها تصمیم می گیرد.
انطباق بحث در مورد چگونگی اطمینان از مرورگرها از انطباق با اقدامات موافقت قانونی در زمینه سناریوهای برجسته GDPR که در آن مرورگرها ممکن است اقدامات را سرکوب کنند (مانند تغییر مسیر یا تنظیم کوکی) که کاربران صریحاً به آن رضایت داده اند ، ایجاد اختلاف بین رضایت قانونی و تنظیمات حریم خصوصی مرورگر. مرورگر به ماهیت رابطه بین کاربر و یک وب سایت دید ندارد. علاوه بر این ، با رفتار فعلی BTM ، در حال حاضر راه حل هایی برای کاربر وجود دارد تا رضایت صریح را برای ردیابی گزاف گویی از یک سایت معین ارائه دهد.

اطلاعات بیشتر در مورد انطباق در سؤالات متداول مربوط به حریم خصوصی ما در دسترس است.
سایت های دوتایی به دنبال شفاف سازی در مورد اینکه آیا انتقال از WebView یا برنامه به WEB (Chrome) تحت BTM "سایت های دوگانه" در نظر گرفته می شود؟ این مرورگر در مورد اینکه آیا زنجیره گزاف گویی از طریق انتقال از WebView یا برنامه آغاز شده است ، مشاهده نمی کند.

از این رو ، BTM به آن جریان های خاصی نمی دهد. در عوض ، این جریان را به عنوان یک گزاف گویی بین سایت از "درباره: خالی" شروع می کند و با رفتار استاندارد پیش می رود.

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

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

پیوستن به فعالیت کاربر در مجموعه ها از طریق آدرس های IP ، نیاز به گنجاندن دامنه MDL در یک مجموعه دارد که نیاز به هماهنگی بین صاحب مجموعه و صاحب دامنه دارد. این خطر مشابه برای سایتهای منفرد (یعنی بدون RWS درگیر) با هماهنگی با دامنه های MDL اعمال می شود.

ما در اینجا با جزئیات بیشتر به این سؤال پاسخ داده ایم.

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

موضوع بازخورد خلاصه پاسخ کروم
تبلیغات بومی بازخوردی که فریم های حصارکشی ، همانطور که در حال حاضر طراحی شده است ، با مدل کسب و کار تبلیغاتی بومی آنها ناسازگار است ، که برای سازگاری انعطاف پذیر با محتوای اطراف ، نیاز به تبلیغات دارد. ما ارزیابی خود را از نیازهای اکوسیستم و ارائه قاب های حصار فعلی ادامه می دهیم. در هر صورت ، همانطور که قبلاً گفته شد ، فریم های حصارکشی زودتر از سال 2026 مورد نیاز خواهند بود.

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

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

چیپس

موضوع بازخورد خلاصه پاسخ کروم
اسناد API شفاف سازی مورد نیاز در مورد حمایت های امنیتی ارائه شده توسط کوکی های تقسیم شده در مقایسه با Samesite = کوکی های آرام و سخت. این پیشنهاد که این مستندات صریحاً باید بیان کند که کوکی های تقسیم شده همان سطح محافظت را در برابر XSS و حملات CSRF به عنوان SAMESITE = کوکی های آرام و سخت فراهم نمی کنند. ما توضیحات و مشخصات را برای روشن شدن معناشناسی و محافظت های ارائه شده توسط کوکی های پارتیشن به روز خواهیم کرد.

فدستان

موضوع بازخورد خلاصه پاسخ کروم
UI و امنیت بازخورد مبنی بر اینکه FEDCM UI بسیار شبیه به ورود به سیستم قبلی Google است ، تعیین عملکرد FEDCM به دلیل عدم پیگیری ارائه منفعل و توصیه ای برای زبان مستندات قوی تر در مورد PKCE دشوار است. ما به طور جدی با ذینفعان درگیر هستیم تا بازخورد آنها را برطرف کنیم. زمینه های بحث در حال انجام شامل راه هایی برای ارائه معیارهای بهتر برای آوارگان برای امکان پیگیری عملکرد FEDCM و پیشرفت های احتمالی برای رسیدگی به موارد استفاده جدید برای FEDCM در مورد موارد استفاده از اشتراک است.
استفاده از API هنگامی که یک کاربر صفحه را تازه می کند و با navigator.credentials.get برای ورود به سیستم تماس می گیرد ، یک پنجره پاپ آپ ظاهر می شود و کاربر را ملزم به کلیک برای ادامه می دهد ، که این یک تاخیر را بر تجربه کاربر معرفی می کند. آیا می تواند برای بهبود تجربه کاربر ، تکیه احزاب (RPS) را ذخیره کند. RP ها می توانند از کوکی های خود برای ذخیره نشانه استفاده کنند. سپس RPS می تواند کوکی های خود را بررسی کند تا مشخص کند آیا کاربر قبل از فراخوانی Navigator.credentials.get وارد سیستم شده است. ما در اینجا با جزئیات بیشتر به این موضوع پرداخته ایم.
انتخاب چند IDP چگونه مرورگر گزینه های ورود به سیستم برای ارائه دهندگان هویت چندگانه (IDP) را در FEDCM نمایش می دهد؟ اسناد توسعه دهنده اطلاعاتی در مورد نحوه نمایش چندین IDP دارد. ذینفعان می توانند با فعال کردن پرچم FEDCM-MULTI-IDP در Chrome: // پرچم ، با این قابلیت آزمایش کنند.
مرورگرها و آوارگان آیا ممکن است یک مرورگر مانند Chrome به عنوان خود IDP عمل کند؟ مرورگرها می توانند از داده های ذخیره شده و پروفایل خود به عنوان منبع معتبر تأیید اعتبار استفاده کنند. با توجه به این واقعیت که مرورگرها را می توان اصلاح کرد (به عنوان مثال از طریق پسوندها) ، هرگونه ادعای تأیید ایمیل که مستقیماً توسط مرورگر انجام می شود ، بدون تأیید اضافی مبتنی بر سرور قابل اعتماد نیست. به همین ترتیب ، یک راه حل کاملاً مبتنی بر مشتری توصیه نمی شود.

ما در اینجا با جزئیات بیشتر در مورد این موضوع بحث کرده ایم.
مشخصات API بحث در مورد اینکه آیا پارامتر برای الگوریتم IdentityCredential.Disconnect () باید مورد نیاز باشد یا اختیاری باشد. این اکنون برطرف شده است. جزئیات بیشتر را می توان در اینجا یافت.
امنیت API اگر RP دارای آسیب پذیری XSS باشد ، نگرانی های مربوط به نشت توکن در فرآیند ورود به سیستم FEDCM وجود دارد. یک مهاجم می تواند Navigator.credentials.get را در کد مخرب برای به دست آوردن نشانه اجرا کند. FEDCM خطرات XSS جدیدی ایجاد نمی کند. این خطرات ذاتی در برنامه های وب و پروتکل های AUT موجود است. برای کاهش این خطرات ، RP ها باید ادعای AUD را در نشانه های شناسه تأیید کنند و فقط ادعاهای صادر شده در منشأ خود را بپذیرند. همانطور که در اینجا مورد بحث قرار گرفت ، بهترین شیوه های گسترده برای اطمینان از این مبادله توکن که امروزه وجود دارد و برای استفاده با FEDCM در دسترس است.

علاوه بر این ، API دسترسی به ذخیره سازی می تواند با FEDCM مورد استفاده قرار گیرد ، و تماس های API دسترسی به ذخیره سازی به طور خودکار هنگام تماس قبلی FEDCM اعطا می شود. این باید جریان تغییر مسیر تعبیه شده را که در مورد موضوع GitHub مورد بحث قرار گرفته است ، فعال کند.
مشخصات API Client_Metadata_EndPoint یک قسمت مورد نیاز در پاسخ نقطه انتهایی برای FEDCM است. یک شیء خالی یک پاسخ معتبر است و کروم بی صدا یک پاسخ 404 را نادیده می گیرد ، و نشان می دهد که نقطه پایانی در عمل به عنوان اختیاری رفتار می شود. ما موافقیم که مشخصات می تواند تغییر کند تا این موضوع را منعکس کند و مشتری_metadata_endpoint را به یک قسمت اختیاری تبدیل کند.
استفاده از API نگرانی در مورد دشواری آزمایش اجرای FEDCM به دلیل رابط های کاربر کنترل شده با مرورگر که از طریق DOM قابل دسترسی نیستند. ما از API های اتوماسیون مرورگر برای آزمایش رگرسیون پشتیبانی می کنیم ، که ممکن است این نگرانی ها را برطرف کند. این API ها در اینجا ثبت شده اند.
مشخصات API پارامتر login_url ، که بخشی مورد نیاز پاسخ نقطه انتهایی پیکربندی است ، در بخش 3.2 مشخصات ثبت نشده است. ما یک به روزرسانی را به اسناد ارسال کرده ایم تا پارامتر login_url را در بخش 3.2 گنجانده شود.
مشخصات API نگرانی در مورد یک بردار ردیابی بالقوه در FEDCM. یک IDP می تواند شناسه ها را به عنوان پارامترهای مسیر در نقاط پایانی مشخص شده در پاسخ انتهای پیکربندی (Accounts_endPoint ، client_metadata_endpoint) وارد کرده و از این شناسه ها برای ارتباط با حساب و درخواست های فراداده مشتری استفاده کند. در حالی که ما شواهدی مبنی بر وارد کردن IDS IDS در این نقاط پایانی نداریم ، ما به طور جدی در حال بررسی کاهش برای رسیدگی به این مسئله هستیم.

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

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

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