گزارش فصلی برای سه ماهه چهارم سال 2023، خلاصه بازخورد اکوسیستم دریافت شده در مورد پیشنهادات جعبه ایمنی حریم خصوصی و پاسخ Chrome.
بهعنوان بخشی از تعهدات خود به CMA، Google موافقت کرده است که گزارشهای فصلی فرآیند تعامل با ذینفعان را برای پیشنهادات جعبه ایمنی حریم خصوصی خود به صورت عمومی ارائه کند (به پاراگرافهای 12 و 17(c)(ii) تعهدات مراجعه کنید). این گزارشهای خلاصه بازخورد Sandbox حریم خصوصی با جمعآوری بازخوردهای دریافتی توسط Chrome از منابع مختلف که در نمای کلی بازخورد فهرست شده است، ایجاد میشوند، از جمله اما نه محدود به: مشکلات GitHub، فرم بازخورد موجود در privacysandbox.com ، جلسات با سهامداران صنعت، و انجمن استانداردهای وب Chrome از بازخوردهای دریافتی از اکوسیستم استقبال می کند و به طور فعال در حال بررسی راه هایی برای ادغام آموخته ها در تصمیمات طراحی است.
مضامین بازخورد بر اساس شیوع در هر API رتبهبندی میشوند. این کار با جمعآوری مقدار بازخوردی که تیم Chrome در مورد یک موضوع خاص دریافت کرده و به ترتیب نزولی از نظر سازماندهی انجام میشود. مضامین رایج بازخورد با بررسی موضوعات بحث از جلسات عمومی (W3C، PatCG، IETF)، بازخورد مستقیم، GitHub و سوالات متداول مطرح شده از طریق تیمهای داخلی Google و فرمهای عمومی شناسایی شدند.
به طور خاص، صورتجلسات جلسات بدنه استاندارد وب بررسی شد و برای بازخورد مستقیم، سوابق Google از جلسات 1:1 ذینفعان، ایمیلهای دریافتی توسط مهندسان فردی، فهرست پستی API و فرم بازخورد عمومی در نظر گرفته شد. سپس گوگل بین تیمهای درگیر در این فعالیتهای ارتباطی مختلف هماهنگ کرد تا شیوع نسبی موضوعات در حال ظهور در رابطه با هر API را تعیین کند.
توضیحات پاسخهای Chrome به بازخورد از پرسشهای متداول منتشر شده، پاسخهای واقعی به مسائل مطرحشده توسط ذینفعان و تعیین موقعیت بهویژه برای اهداف این گزارش گزارش عمومی ایجاد شده است. با توجه به تمرکز فعلی توسعه و آزمایش، سؤالات و بازخوردها به ویژه در رابطه با موضوعات، مخاطبین محافظت شده و APIهای گزارش اسناد دریافت شد.
بازخورد دریافت شده پس از پایان دوره گزارش فعلی ممکن است هنوز پاسخی در نظر گرفته شده برای Chrome نداشته باشد.
واژه نامه کلمات اختصاری
- چیپس
- کوکی هایی که دارای حالت تقسیم شده مستقل هستند
- DSP
- پلتفرم سمت تقاضا
- FedCM
- مدیریت اعتبار فدرال
- FPS
- مجموعه های مهمانی اول
- IAB
- دفتر تبلیغات تعاملی
- بیجاشدگان داخلی
- ارائه دهنده هویت
- IETF
- نیروی ضربت مهندسی اینترنت
- IP
- آدرس پروتکل اینترنت
- openRTB
- مناقصه در زمان واقعی
- OT
- آزمایش مبدا
- PatCG
- گروه اجتماعی فناوری تبلیغات خصوصی
- RP
- حزب اتکا
- SSP
- پلت فرم سمت عرضه
- TEE
- محیط اجرای مورد اعتماد
- UA
- رشته عامل کاربر
- UA-CH
- نکات مشتری عامل کاربر
- W3C
- کنسرسیوم وب جهانی
- WIPB
- کوری IP ارادی
بازخورد عمومی، بدون API یا فناوری خاص
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
جدول زمانی 3PCD | اطلاعات بیشتر را در مورد جدول زمانی 3PCD به اشتراک بگذارید. | برای تسهیل آزمایش ، Chrome از 4 ژانویه 2024، 3 رایانه شخصی را بهطور پیشفرض برای 1 درصد از کاربران محدود کرد. با توجه به رفع نگرانیهای باقیمانده از CMA، Chrome قصد دارد به تدریج پشتیبانی از 3 رایانه شخصی را از سه ماهه سوم 2024 متوقف کند و در بقیه سالها ادامه یابد. 2024. |
جدول زمانی 3PCD | تأثیر زمان بندی 3PCD در سه ماهه چهارم 2024، زیرا همزمان با فصل تعطیلات است و می تواند تأثیر منفی بر ناشران داشته باشد. | هیچ زمان مناسبی برای منسوخ کردن 3PC وجود ندارد. ما بیش از یک سال است که مشخص کردهایم که قصد ما این بود که 3 رایانه شخصی را در نیمه دوم سال 2024 منسوخ کنیم. در حالی که ما نگرانی زمان بندی Q4 را درک می کنیم، ایجاد تغییرات جدول زمانی منجر به آمادگی کمتر صنعت شده است، نه بیشتر. |
آزمایش کروم (حالت a/b) | آیا تنظیمات آزمایشی برای حالت A و حالت B در هر نمونه یا هر نمایه کروم انجام می شود؟ | ما در اینجا توضیحاتی را در اسناد منتشر کردهایم که مرورگر Chrome در این زمینه به یک سرویس گیرنده Chrome اشاره میکند: نصب Chrome در دستگاه. هر دایرکتوری اطلاعات کاربر فردی یک کلاینت مجزا را تشکیل می دهد. |
محاکمه منسوخ شدن | اطلاعات بیشتر در مورد 3PCD Trial را به اشتراک بگذارید. | ما اطلاعات بیشتری در مورد آزمایشی 3PCD در اینجا به اشتراک گذاشته ایم. |
محاکمه منسوخ شدن | زمان کافی برای ارائه کدهای آزمایشی Deprecation در همه سایتها قبل از ژانویه 2024 وجود ندارد. | ما تصدیق میکنیم که بین باز شدن ثبتنامهای آزمایشی منسوخ شدن و شروع دوره آزمایشی با تسهیل Chrome و مسدود کردن 1٪ از کوکیها، زمان کوتاهی وجود دارد. برای رسیدگی به این محدودیتهای زمانی، Chrome یک دوره مهلت برای مبداهای شرکتکننده در حین کار برای استقرار نشانههای آزمایشی منسوخ ارائه میکند. در طول دوره مهلت، که تا اول آوریل 2024 ادامه خواهد داشت، مبداهای ثبتشده برای آزمایشی منسوخ شدن، به 3 رایانه شخصی در Chrome دسترسی خواهند داشت، حتی اگر هنوز توکنهای خود را اجرا نکرده باشند. هدف از این دوره مهلت جلوگیری از مشکلات سازگاری وب در مرحله انتقال است. مبداهای شرکتکننده باید قبل از پایان دوره مهلت، نشانههای آزمایشی منسوخ را مستقر کنند تا پس از پایان دوره مهلت، همچنان به 3 رایانه شخصی دسترسی داشته باشند. |
آزمایش کروم (حالت a/b) | حالت B برای اندازه گیری دقیق افت عملکرد بسیار کوچک است. | تعادل دقیقی بین درصد ترافیک و خطر تأثیر بر کاربران و عملکرد در سراسر وب وجود دارد. |
کنترل های تست | فقط بزرگترین ناشران با منابع توسعه قابل توجه می توانند عملکرد را در طول آزمایش درک کنند و آن را به CMA منتقل کنند. | ما در حال حاضر شاهد هستیم که ارائه دهندگان خدمات ناشر اطلاعات خود را به صورت عمومی با اکوسیستم گستردهتر به اشتراک میگذارند و انتظار داریم که با افزایش تستهای جعبه ایمنی حریم خصوصی، این وضعیت ادامه یابد. همچنین انتظار داریم که شرکتهای فناوری تبلیغاتی که در بالای APIهای Privacy Sandbox ایجاد میشوند، به توسعه ویژگیهایی که مشتریانشان میخواهند، مانند گزارشدهی بر اساس برچسبها، ادامه دهند. |
داده های شخص ثالث | نگرانی برای شرکت های داده شخص ثالث. | انواع مختلفی از شرکت های داده شخص ثالث وجود دارد. برخی ممکن است دو برابر شوند و به روشهای غیرشفاف ردیابی بین سایتی روی بیاورند. برخی دیگر ممکن است به فناوریهای تقویتکننده حریم خصوصی متمایل شوند و ارزشهای پیشنهادی جدیدی را با مشتریان خود ایجاد کنند. ما امیدواریم که بیشتر افراد دومی را انتخاب کنند و در مسیری حرکت کنند که هم کاربران و هم قانونگذاران به طور فزایندهای خواستار آن هستند. تغییر فرصت هایی برای تکامل و نوآوری ایجاد می کند. |
Google Ad Manager | برای اینکه ناشران چگونه می توانند جعبه ایمنی حریم خصوصی را آزمایش کنند، به راهنمایی بیشتر Google Ad Manager نیاز دارید. گزارش برای درک تأثیر ناشران کافی نیست. | پاسخ ارائه شده توسط Google Ad Manager: Google Ad Manager نحوه انجام آزمایش را با استفاده از برچسبهای آزمایشی با تسهیل Chrome در مرکز راهنمایی خود توضیح داده است. Ad Manager در حال حاضر گزارش هایی را در مورد موضوعات و مخاطبان محافظت شده به ناشران ارائه می دهد. از زمان این گزارش بازخورد، Ad Manager میتواند در مورد نمایشهای ارائهشده از طریق API مخاطب محافظتشده گزارش دهد و میتواند نشان دهد که آیا دادههایی از Topics API در یک نمایش داده شده وجود داشته است یا خیر. ناشران علاقهمند به گزارشهای پیچیدهتر مانند تقسیمبندی گزارشها بر اساس برچسبهای تسهیلشده Chrome، میتوانند این کار را با خواندن برچسبها مستقیماً از Chrome (با استفاده از اسناد Chrome ) انجام دهند و آنها را بهعنوان مقادیر کلیدی در درخواستهای آگهی به Ad Manager و گزارش ارزش کلیدی ارسال کنند. برای گزارش روی برچسب ها |
مشوق آزمون | نگرانی تبلیغکننده در مورد زمان کافی برای آزمایش Privacy Sandbox و احتمال تغییرات API مادی که ممکن است رخ دهد. | ما می دانیم که برخی از مردم زمان بیشتری می خواهند، اما بارها از صنعت شنیده ایم که تغییر جدول زمانی احتمالاً منجر به آمادگی کمتر اکوسیستم می شود، نه بیشتر. در حالی که جدول زمانی برای منسوخ کردن 3PC منوط به رسیدگی به هرگونه نگرانی رقابتی باقی مانده از سوی CMA است، ما همه را تشویق می کنیم تا برای 3PC در سال 2024 آماده شوند. مانند هر فناوری دیگری، APIهای Privacy Sandbox به تکامل خود ادامه خواهند داد. این تکامل ناشی از پیشرفت در فناوری ها و ورودی اکوسیستم است. همانطور که تغییرات ایجاد می کنیم، مسئولیت پذیر خواهیم بود و فکر نمی کنیم که تغییرات در فناوری باید به طور نامحدود مانع استفاده شود. |
CTV | هیچ مسیری برای پشتیبانی از ویدئوهای خطی یا CTV وجود ندارد. | ما مشتاقانه منتظر بررسی بیشتر موارد استفاده از CTV هستیم، اما فکر نمیکنیم APIهای دستگاههای CTV سد راه 3PCD در کروم باشند. |
سرورهای تبلیغاتی آگهی دهنده | به نظر می رسد گوگل هدف گذاری تبلیغات را به DV360 تغییر می دهد. چه پشتیبانی برای سرورهای تبلیغاتی تبلیغ کننده ارائه خواهد شد؟ | پاسخ ارائه شده توسط کروم: PA API برای سرورهای تبلیغاتی تبلیغکننده طراحی شده است تا تبلیغات نشان داده شده به کاربر را از طریق استفاده از iFrames/Fenced Frames و گزارش Beacon ارائه و اندازهگیری کند. علاوه بر این، آنها مانند امروز با احزاب بالادستی و پایین دستی برای ادغام در جریان خدمات کار خواهند کرد. |
Google Ads Data Manager | «مدیر دادههای تبلیغات Google» که اخیراً اعلام شده است، بر اساس مطابقت مشتری و تبدیلهای پیشرفته ساخته شده است، که به تبلیغکنندگان امکان میدهد دادههای مشتری شخص اول خود را با Google به اشتراک بگذارند تا تمام عملکردهای بازاریابی انجام شده توسط 3PC را حفظ کنند. چگونه این ویژگی جدید با تعهدات Google به CMA همخوانی دارد؟ | پاسخ ارائه شده توسط Google Ads: Google Ads Data Manager به سادگی آپلود دادههای شخص اول از سیستمهای ذخیرهسازی داده تبلیغکننده (سیستمهای ابری) را برای استفاده توسط تبلیغکنندگان برای مطابقت با مشتری (CM) و تبدیلهای پیشرفته (EC) تسهیل میکند، و این کار را برای مشاغل کوچک تا متوسط با تعداد کمتری آسانتر میکند. منابع فنی Google Ads Data Manager هیچ قابلیت خالص جدید را برای CM یا EC از نظر آدرسپذیری یا اندازهگیری تبلیغات در Google O&O یا ناشران شخص ثالث فعال نمیکند. پلتفرمهای تبلیغاتی Google مانند سایر شرکتهای فناوری تبلیغات به قابلیتهای موجود در فناوریهای جعبه ایمنی حریم خصوصی دسترسی دارند. |
تنظیمات کروم | صفحه تنظیمات داخلی Chrome باید اطلاعات بیشتری در مورد اندازه کوکی ها ارائه دهد. | عملکرد درخواستی از قبل در ابزار برنامهنویس Chrome موجود است. ما از بازخورد اضافی در مورد اینکه چرا این ویژگی باید در صفحه تنظیمات اولویت بندی شود، استقبال می کنیم. |
اکتشافی | Chrome برای حفظ تجربیات حیاتی کاربر در طول 3PCD از چه اکتشافی استفاده می کند؟ | پاسخ ما به این سوال را در GitHub ببینید. |
نسخه های مرورگر | مرورگرهای کروم پایدار را از ناپایدار متمایز می کنید؟ | تطبیق تقریبی نسخه اصلی Chrome با چرخه انتشار پایدار کارساز خواهد بود. |
انطباق | آیا کروم میتواند گزارشهای مربوط به SOX را ارائه دهد؟ | Chrome گزارشهای مرتبط با SOX را ارائه نمیکند. Privacy Sandbox API یکی از بسیاری از APIهای وب است که Chrome برای وبسایتهایی که کاربر بازدید میکند در دسترس قرار میدهد. مانند همه API های وب، تماس گیرنده API با Chrome برای استفاده از Privacy Sandbox API قراردادی منعقد نمی کند. دسترسی فقط به این بستگی دارد که آیا تماس گیرنده API الزامات فنی را برآورده می کند و کاربر تنظیمات مناسب را فعال کرده است یا خیر. اگر چنین است، تماس گیرنده API به تنهایی نحوه استفاده از API را تعیین می کند، از جمله اینکه چه داده هایی را ذخیره کند، چه پیشنهاداتی را ارائه دهد، چه گزارش هایی را درخواست کند و غیره. |
انطباق | گسترش پرسشهای متداول مطابق با جعبه ایمنی حریم خصوصی برای پاسخگویی به سؤالات بیشتر. | ما از بازخورد قدردانی می کنیم و قصد داریم سوالات متداول را بیشتر بسازیم. |
سوال کروم | آیا منسوخ شدن 3PC در Chrome بر در دسترس بودن 3PC در Android WebView (مرورگر تعبیه شده) تأثیر می گذارد؟ | ما در حال حاضر WebView را در این مرحله از عرضه و آزمایش API 3PCD یا Privacy Sandbox، فراتر از فعال کردن Cross App و Web Attribution Measurement شامل نمیکنیم. |
سوال API | چگونه می توان کلیک ها و برداشت های محصولات حمایت شده را ردیابی کرد؟ | این مورد استفاده توسط Attribution Reporting API پوشش داده شده است. |
جدول زمانی | چرا جدول زمانی برای 3PCD تغییر کرده است؟ | ما در اینجا دلایل را مورد بحث قرار داده ایم. |
افزونه کروم SSO | امکان استفاده از یک ورود به سیستم بین یک وبسایت و یک برنامه افزودنی Chrome پس از 3PCD را مجاز کنید. | ما در حال بحث در مورد این موضوع هستیم و از بازخورد در مورد موارد استفاده اضافی استقبال می کنیم. |
استفاده از API | آیا Google میتواند لیست شرکای مورد نظر برای آزمایش APIها را تأیید کند؟ | جزئیات آزمایشکنندگانی که خود را بهصورت عمومی معرفی کردهاند در GitHub برای APIهای زیر موجود است: - موضوعات API - API مخاطبان محافظت شده - Attribution Reporting API - فضای ذخیره سازی مشترک - چیپس |
ابتکار Utiq | دیدگاه کروم نسبت به ابتکار Utiq چیست؟ | ما در اینجا در حال بحث در این مورد هستیم. |
سوال کروم | چگونه کاربرانی را که بدون 3 کامپیوتر در حال مرور هستند شناسایی کنیم؟ | هیچ تنظیم صریحی برای تشخیص مسدود شدن 3PC وجود ندارد. برای یک رویکرد کلی "تشخیص ویژگی"، ما ایجاد درخواست iframe / بین سایتی و تلاش برای تنظیم یک کوکی مشابه برای مورد استفاده مورد نیاز را توصیه می کنیم نزدیکترین راه حل است. |
سوال کروم | آیا مرور در حالت ناشناس مانند اجرای آزمایش پرچم است (Chrome را با استفاده از پرچم خط فرمان --test-third-party-cookie-phaseout راه اندازی کنید)؟ | حالت ناشناس با پرچم متفاوت است. این پرچم نه تنها 3 رایانه شخصی را مسدود می کند، بلکه FedCM و پارتیشن بندی ذخیره سازی شخص ثالث را نیز فعال می کند. |
سوال کروم | جزئیات بیشتر در مورد تأثیر مورد انتظار 3PCD برای هر منطقه/کشور وقتی 1٪ اتفاق می افتد. | مشتریان به صورت تصادفی در سطح جهانی در 1٪ گنجانده می شوند، اگرچه ممکن است تغییرات منطقه ای وجود داشته باشد. به عنوان مثال، ممکن است تفاوت هایی در توزیع دستگاه ها و نسخه های کروم وجود داشته باشد. |
فن آوری های جایگزین برای افزایش حریم خصوصی | فناوریهای جایگزین افزایش حریم خصوصی باید اجازه داشته باشند که ردیابی بین دامنهای با حفظ حریم خصوصی را انجام دهند تا از انحصار دادهها در Chrome و Android جلوگیری کنند. | فرصت کافی برای توسعه دهندگان وجود دارد تا بر روی بلوک های ساختمانی که ما ارائه می دهیم و همچنین بلوک های ساختمان غیر Privacy Sandbox، پیشنهادات فناوری افزایش دهنده حریم خصوصی ایجاد کنند. |
مطالعه CookieGraph | دیدگاه کروم در مورد روش CookieGraph همانطور که در این مقاله در چارچوب Privacy Sandbox توضیح داده شده است چیست؟ | ما در حال بررسی این مقاله هستیم و از بازخوردهای بیشتر استقبال می کنیم . |
ثبت نام و تاییدیه
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
ثبت نام محدود است | Google شرایط استفاده خاصی را برای Privacy Sandbox API ها معرفی کرده است. شرایط به طور مؤثری از شرکتهایی جلوگیری میکند که در کمک به ناشران تخصص دارند تا بازدیدکنندگان رضایتمند را برای آزمایش و/یا ادغام ویژگیهای جعبه ایمنی حریم خصوصی در راهحل هویت خود بشناسند. شرایط و ضوابط به طور ناعادلانه توانایی آنها را برای کار در جعبه ایمنی حریم خصوصی محدود می کند. | فرآیند ثبت نام و تأیید شامل موافقت با شرایط استفاده از API نیست. در عوض، ثبتنام و تأیید مکانیسمهایی هستند که قصد دارند شفافیت را در مورد اینکه توسعهدهندگان کدام API را Privacy Sandbox مینامند و نحوه استفاده از دادههایی که به آنها دسترسی دارند، بهبود بخشد. به طور خاص، گواهی یک بیانیه عمومی است که نشان میدهد توسعهدهنده گواهیدهنده از APIها برای شناسایی کاربران در سراسر سایتها یا برنامهها استفاده نمیکند و در غیر این صورت حفاظت از حریم خصوصی APIها را دور نمیزند. این گواهی نیازی به ارائه بازنمایی در مورد استفاده توسعه دهندگان از داده ها یا فناوری های دیگر ندارد. |
ثبت نام جعبه ایمنی حریم خصوصی | چگونه نقطه تماس / آدرس ایمیل را برای گواهی به روز کنیم؟ | اطلاعات ثبت نام را می توان با استفاده از فرم ثبت نام به روز کرد. جزئیات بیشتر در اینجا موجود است. |
ثبت نام جعبه ایمنی حریم خصوصی | آیا می توانید سناریوهای قطع دسترسی را در صورت در دسترس نبودن گواهینامه روشن کنید؟ | Privacy Sandbox 3 هفته به یک مخاطب فنی اجازه می دهد تا فایل گواهی را برای سایت ثبت نام شده مجدداً ایجاد کند، قبل از اینکه شرکت ثبت نام شده دسترسی به (API های اندازه گیری و مرتبط) را ممنوع کند. |
ثبت نام جعبه ایمنی حریم خصوصی | چگونه می توانیم API ها را در یک محیط محلی با استفاده از نقاط پایانی غیر تولیدی آزمایش کنیم؟ | ما در اینجا به این سوال پاسخ داده ایم. |
نمایش محتوا و تبلیغات مرتبط
موضوعات
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
سودمندی برای انواع مختلف ذینفعان | ناشران نگران تأثیر موضوعات بر فروش مبتنی بر داده هستند. به سایت های بزرگتر یک موضوع کلی «اخبار» اختصاص داده شده است، هیچ داده ای آن را به ناشر خاص پیوند نمی دهد. ناشران متخصص در ازای اطلاعات محدود، داده های خود را ارائه می دهند. | ما تصدیق میکنیم که سایتهایی که دامنههای علاقه عمومی بیشتری دارند، احتمالاً نسبت به سایتهایی با دامنههای مورد علاقهی خاصتر، موضوعات مرتبط کمتری را ارائه میکنند. با این حال، همه سایتهای تخصصی موضوعات ارزشمند تجاری را ارائه نمیکنند. همچنین، این پویایی وضعیت موجود را منعکس میکند - اینکه برخی از سایتها ارزش بیشتری نسبت به سایرین در سیستمهای مرتبط آگهی مبتنی بر 3PC ارائه میکنند. Topics (و به طور کلی Privacy Sandbox) به ناشران کنترل بیشتری بر نحوه استفاده از اطلاعات آنها توسط شرکت های adtech که با آنها شریک هستند، ارائه می دهد. علاوه بر این، اطلاعات موجود از طریق Topics بسیار درشت تر از سیگنال های موجود است. |
سرورهای آگهی ناشر | سرورهای تبلیغات ناشر که از سرورهای تبلیغات اختصاصی استفاده می کنند ممکن است نتوانند مستقیماً Topics API را مشاهده کنند. | ما در اینجا در حال بحث در مورد این موضوع هستیم و از بازخوردهای اضافی استقبال می کنیم. |
تصدیق | گسترش الزامات گواهی برای رسیدگی به پیامدهای نامطلوب شناخته شده انتقال اطلاعات متقابل. | در حال حاضر، تصدیق برای پوشش این دسته وسیع از خطر نیست، بلکه برای رسیدگی به سوء استفاده از API است. |
حجم ترافیک موضوعات | حجم فعلی نمایشهای دریافتی برای آزمایش کافی نیست. | Chrome از بازخورد مربوط به حجم موضوعات موجود در اکوسیستم برنامهریزی آگاه است. ما در حال بررسی دلایل احتمالی هستیم - هم در مرورگر و هم در بین آزمایش کنندگان مربوطه. در صورت لزوم، Chrome تغییرات احتمالی طراحی API را ارزیابی میکند تا نرخ پوشش را افزایش دهد و آزمایش را در مقیاس کافی فعال کند و در عین حال حریم خصوصی کاربر را حفظ کند. |
استفاده از API | آیا محدودیت نرخ موضوعات API وجود دارد؟ | برای جلوگیری از سوء استفاده و محافظت از تجربه کاربران در وب، محدودیتهایی برای نرخ موضوعات وجود دارد. شما می توانید برخی از جزئیات بیشتر را در اینجا مشاهده کنید. |
طبقه بندی V2 | دستورالعمل IAB برای جزئیات موضوع در پروتکل باز RTB گنجانده شود؟ | بله، دستورالعملهای IAB درباره گنجاندن موضوعات در پروتکل Open RTB را میتوانید در اینجا پیدا کنید. |
تاثیر بر سیگنال های شخص اول | طبقهبندی موضوعات دانهبندی v2 همراه با فرآیندی برای برگرداندن بالاترین ارزش این بخشبندی دانهای (موضوعات برتر) بازار دادهها را در تبلیغات مخدوش میکند. | پاسخ ما نسبت به Q3 بدون تغییر باقی می ماند: «در حالی که طبقهبندی موضوعات دقیقتر ممکن است بهطور غیرمستقیم جذابیت راهحلهای دیگر را کاهش دهد، مانند راهحلهایی که مبتنی بر دادههای شخص اول ناشر یا راهحلهایی هستند که به معاملات مستقیم تکیه میکنند، با توسعه Topics API هدف اصلی ما اطمینان از پشتیبانی آن بر اساس علاقه است. از موارد تبلیغاتی بعد از 3PCD تا حد امکان به طور موثر برای همه ذینفعان استفاده می شود. اعتقاد ما این است که استفاده بیشتر از موضوعات، رقابت را به طور کلی بهبود می بخشد و برای کل اکوسیستم مفید خواهد بود." |
لیست آزمایش کنندگان | پذیرش Topics و PA API در بین ناشران شما چیست؟ | ما نمی توانیم چنین اطلاعاتی را به اشتراک بگذاریم. میتوانید به فهرست آزمایشکننده مراجعه کنید، جایی که ناشران میتوانند وضعیت آزمایش خود را به اشتراک بگذارند. |
انتخاب موضوعات | به کاربران اجازه میدهید به طور فعال موضوعات مورد علاقه خود را انتخاب کنند؟ | ما مطمئناً در نظر گرفتهایم که کاربران را قادر میسازیم تا به طور فعال موضوعات را اضافه کنند. ما قصد نداریم در کوتاه مدت به آن بپردازیم، اما آماده بررسی طولانی مدت آن هستیم. |
انتخاب موضوعات | اگر یک شرکت تبلیغاتی کدی در سایتی برای مشاهده موضوعات داشته باشد، آیا میتواند بداند چه موضوعاتی ممکن است مشاهده شود؟ | یک شرکت فناوری تبلیغات می تواند موضوعات مرتبط با یک سایت را تعیین کند. API این اطلاعات را در زمان واقعی به اشتراک نمی گذارد زیرا ممکن است هزینه های تأخیر ایجاد کند. |
طبقه بندی V2 | از آنجایی که Topics میتواند تا 3 موضوع را برگرداند، رفتار مورد انتظار با عرضه Taxonomy v2 چیست؟ | API همچنان تا 3 موضوع را برمی گرداند و نسخه طبقه بندی مربوطه برای هر موضوع را در پاسخ شامل می شود. |
(در فصل های گذشته نیز گزارش شده است) مشاهده موضوعات | به ناشران اجازه دهید به Chrome اجازه دهند تا موضوعات را بر اساس محتوای صفحه (مثلاً سر یا بدن) دسته بندی کند. | پاسخ ما نسبت به Q3 بدون تغییر باقی می ماند: "ما قبلاً ارائه عملکردی برای طبقهبندی سایتها به موضوعات بر اساس محتوای صفحه در نظر گرفتیم و تصمیم گرفتیم که بر اساس نگرانیهای مربوط به حفظ حریم خصوصی و امنیتی پیش نرویم. این پیشنهاد ممکن است برخی از این نگرانیها را کاهش دهد، اما مشخص نیست که تا چه حد. در دوره آتی آزمایش CMA، ما انتظار نداریم که این تغییر قبل از 3PCD رخ دهد. ما از بازخورد اضافی در اینجا استقبال می کنیم." |
انتخاب موضوعات | با توجه به عمومی بودن دامنه ها با موضوعات چگونه طبقه بندی می شوند؟ | ما فقط از نام میزبان برای طبقه بندی سایت ها به موضوعات استفاده می کنیم. سایتی که به طور گسترده طبقه بندی می شود از این بابت آسیبی نمی بیند. این به این دلیل است که اطلاعات متنی یک سایت همیشه برای حراج در سایت آنها در دسترس خواهد بود، که اطلاعات خاص تری را برای موضوع گسترده ارائه می دهد. |
طبقه بندی V2 | آرزوی همراستایی بهتر موضوعات با سایر استانداردها (به عنوان مثال IAB). | مایلیم در مورد اینکه چرا آنها به همسویی نزدیکتر بین طبقه بندی IAB و Topics امیدوار بودند بیشتر بدانیم. آنها برای پذیرش Topics API چه مراحلی را باید بردارند و چگونه طبقه بندی متمایزتر بر این مراحل تأثیر می گذارد؟ ما در حال بررسی انتشار یک نقشه بین طبقه بندی موضوعات و طبقه بندی محتوای IAB هستیم. درک این موضوع مفید خواهد بود که آیا انجام این کار چالش هایی را که ناشران با آن روبرو هستند برطرف می کند. |
ذخیره سازی و استفاده از داده ها | آیا اطلاعات بیشتری در مورد نحوه ذخیره داده ها و محل انتقال داده ها دارید؟ | اطلاعات موضوعات به صورت محلی در دستگاه کاربر تولید و ذخیره می شود. در صورت درخواست، API حداکثر 3 موضوع را به تماسگیرندگان برمیگرداند. از نظر Google، تماسگیرندگان مسئول رعایت مقررات محلی هنگام مدیریت و ذخیره اطلاعات موضوعات هستند. علاوه بر این، همه تماسگیرندگان باید تأیید کنند که از موضوعات برای شناسایی مجدد کاربران در سراسر سایتها استفاده نمیکنند. لطفاً برای جزئیات بیشتر به سؤالات متداول مربوط به رعایت حریم خصوصی مراجعه کنید. |
طبقه بندی V2 | تأثیر ارتقاء تاکسونومی موضوعات و وضعیت مرورگر هنگام انتقال از نسخه 1 به نسخه 2. | موضوعات استنباطشده با طبقهبندی قبلی هنوز در دسترس هستند و میتوانند در نهایت توسط فناوری تبلیغات تا زمانی که منقضی شوند (4 هفته) واکشی شوند. |
توضیحات API | تجربه کاربر از Topics API گمراه کننده است. | ما این بازخورد را با تیم UX به اشتراک گذاشته ایم. |
سوال API | دامنه های یاهو با توجه به عمومی بودن آنها چگونه با موضوعات طبقه بندی می شوند؟ | ما فقط از نام میزبان برای طبقه بندی سایت ها به موضوعات استفاده می کنیم. درک این نکته مهم است که سایتی که به طور گسترده طبقه بندی می شود از این موضوع آسیبی نمی بیند. |
نرخ در دسترس بودن موضوعات پایین است | آزمایشکنندگان حجم کم موضوعاتی را از Google Ad Manager دریافت میکنند. | Google Ad Manager چندین بهینه سازی را برای بهبود پوشش ارائه کرد - خریداران باید افزایش پوشش را مشاهده می کردند. برخی از عوامل مورد انتظار وجود دارد که ممکن است پوشش را محدود کند (به عنوان مثال ترجیحات کاربر، الزامات مشاهده توسط تماس گیرنده، به طور بالقوه برخی از تأخیرها / وقفه های زمانی). |
API مخاطب محافظت شده (FLEDGE سابق)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تفکیک | عدم شفافیت در مورد چگونگی تمایز SSPها به حراج جدید. | ما از چندین طرح استراتژیک شنیده ایم که مخاطبین محافظت شده و/یا سایر APIهای Sandbox حریم خصوصی را در جلو و مرکز قرار داده اند. تصویر بزرگتر، کاهش شناسههای متقابل همهجای سایت اغلب توسط بخش فروش اکوسیستم بهعنوان یک گام مثبت نه تنها از نظر حریم خصوصی، بلکه از نظر تجاری نیز تلقی میشود. کسب و کارهای کوچک و بزرگ که از این تغییر استقبال می کنند، احتمالاً فرصت پیدا می کنند. |
رندر آگهی | کروم به عنوان تنها راه برای ارائه تبلیغات، نوآوری را خفه می کند. رندر مخاطب محافظت شده، قابلیت اجرا استانداردهای امروزی در مورد تبلیغات بومی را کاهش می دهد. | رندر تبلیغات در مرورگرها همیشه از فناوری های مرورگر برای رندر استفاده می کنند. این تغییر نمی کند. شاید این نگرانی مختص برنامه هایی باشد که در آینده نیاز به استفاده از قاب های حصاردار در ارتباط با مخاطبان محافظت شده دارند. بخشی از دلیل اینکه این طرحها «در آینده» هستند، دقیقاً به این دلیل است که ما میخواهیم فناوری Fenced Frames از نوآوری و تمایز اکوسیستم در هنگام ارائه تبلیغات پشتیبانی کند. برای توسعهدهندگان و شرکتهای علاقهمند زمان وجود دارد تا در جهت فریمهای حصاردار که شامل نحوه پشتیبانی از رویکردهای تبلیغات بومی است، فکر کنند. |
ورودی | Concern Protected Audience API (PA API) تا زمانی که بسیاری از فناوریهای تبلیغاتی شروع به کاوش در APIهای Privacy Sandbox کردند کمابیش کامل شد. | APIها بر اساس چیزهایی که از استفاده و همچنین ایدههای جدیدی که از داخل و خارج از Chrome آمده است، به تکامل خود ادامه خواهند داد. رابطهای برنامهنویسی برنامهنویسی کاربردی اندازهگیری و مرتبط امروزی که به طور کلی در دسترس هستند، پایدار هستند، اما این بدان معنا نیست که توسعه متوقف شده است و ما از بازخورد اضافی استقبال میکنیم. |
طراحی حراج | طراحی مخاطب محافظت شده، تمام منطق ایجاد مخاطب و انتخاب تبلیغات را در دستان پلتفرم سمت خرید قرار میدهد، و توانایی یک SSP برای ارائه منطق ایجاد مخاطب و انتخاب آگهی برای کمپینهای اجرا شده بر روی پلتفرم خود را از بین میبرد. | مخاطب محافظت شده نسبت به اینکه چه کسی مخاطب ایجاد میکند و چه کسی برای مخاطبان پیشنهاد میدهد، ناشناس است. این امکان برای یک SSP وجود دارد که یک گروه علاقه (IG) ایجاد کند که برای مناقصه در دسترس قرار می دهد. همچنین این امکان برای یک SSP وجود دارد که منطق مناقصه را ارائه دهد، که به نظر می رسد با مسیری که بسیاری از SSP ها مستقیماً به آژانس ها می روند مطابقت دارد. در حالی که همیشه فضایی برای موارد استفاده اضافی وجود دارد، پایه های مخاطب محافظت شده به اندازه کافی انعطاف پذیر است تا از بسیاری از رویکردهای مختلف برای ایجاد و فعال سازی مخاطب پشتیبانی کند. ویژگیهای حریم خصوصی این بنیادها همچنین به این معنی است که دادههای خام سطح کاربر بین سایتها به اشتراک گذاشته نمیشود. |
طراحی حراج | آیا حراج مخاطب محافظت شده با تلاشهای بهینهسازی مسیر تامین اکوسیستم (SPO) برای کاهش کل واسطهها بین یک تبلیغکننده و یک ناشر و/یا تکرار یک فرصت تبلیغاتی مغایرت دارد؟ | خیر. اگر خریدار یکپارچه سازی مستقیم با ناشر ایجاد کند، یک تبلیغ برنده در مخاطبین محافظت شده حداکثر از دو نهاد فروشنده (مثلاً یک SSP و یک سرور تبلیغات ناشر) و به تعداد کمتری ارسال می شود. تکرار یک درخواست از طریق چند واسطه، انتخاب ناشر است. مخاطب محافظت شده نباید این موضوع را به یک شکل تحت تاثیر قرار دهد. حراج های مخاطب محافظت شده خارج از سیستم بلادرنگ سرور به سرور امروزی رخ می دهد تا اطلاعات کاربران بین سایتی درز نکند. برخی ممکن است بگویند این یک درخواست تبلیغاتی تکراری است. رسیدن به حریم خصوصی قابل اثبات فنی نیازمند برخی معاوضه است. با این حال، ممکن است در درازمدت اکوسیستم تصمیم بگیرد که از مخاطبان محافظت شده بدون حراج های سنتی سمت سرور استفاده کند. این انتخاب می تواند حتی به مسیرهای عرضه بهینه تر منجر شود. |
طراحی حراج | مخاطب محافظتشده به مدلی تغییر میکند که SSPها به ندرت «آخرین» حراجی هستند که در صفحه اجرا میشوند، اما با طراحی API مجبور به ورود به این مدل میشوند. | موافق نیستیم. پیادهسازیهای اولیهای که ما دیدهایم در واقع باعث میشود SSPهایی که در مزایدههای مؤلفه شرکت میکنند بتوانند خروجی حراج متنی را که قبل از اجرای حراج مخاطب محافظت شده رخ میدهد، شکست دهند. خروجیهای حراج مؤلفه SSP در مخاطب محافظت شده، پس از اجرای یک حراج کامل متنی، آخرین در نظر گرفته میشوند. |
طراحی حراج | حراج متنی ممکن است فقط برای ارائه سیگنال های داده در مورد فرصت حراج برای اطلاع رسانی حراج مخاطب محافظت شده مرتبط باشد. | ما انتظار داریم که مزایدههای متنی به دلایل بیشماری مانند معاملات، کمپینهای هدفدار مخاطبان شخص اول و بسیاری از سناریوهای متنی مرتبط باقی بماند. همچنین زمانی که هیچ IG وجود ندارد یا پیشنهادات در مخاطب محافظت شده به سطوح پایینی نمیرسند یا قوانین کیفیت آگهی را رعایت نمیکنند، ارزشمند است. |
شکل دهی ترافیک | DSPها در QPS ثابت کار می کنند. مناسب بودن مزایده های مخاطب محافظت شده، کاربرد زیرساخت های قدیمی را کاهش می دهد. | همانطور که متوجه شدیم، چیزی که با توجه به کوئری ها در ثانیه در حال تغییر است این است که بسیاری از SSP ها از شناسه های متقابل سایت به عنوان ویژگی برای تعیین ارسال یا عدم ارسال درخواست DSP استفاده می کنند. چه ناشر بخواهد حراج مخاطب محافظت شده را اجرا کند یا نه، این درست است. ما شکلدهی ترافیک را با بسیاری از SSPها بررسی کردیم و راهحلهایی از جمله ذخیرهسازی پنهان و فیلتر مبتنی بر زمینه پیدا کردیم. با گذشت زمان از توسعه دهندگان انتظار داریم که از مزیت Private Aggregation برای کمک به درک بیشتر ترجیحات پیشنهادی DSP و فیلتر کردن بر اساس آن استفاده کنند. در نهایت، برخی از زیرساختهای قدیمی که حول شناسههای متقابل ساخته شدهاند دیگر مفید نخواهند بود. |
سیگنال های موجود | عدم شفافیت در طیف کامل سیگنالهای موجود در هنگام وقوع حراج و نحوه توالی با حراج زمینهای آن را مضرات میکند. | به طور کلی، برای مناقصهدهندگان، اطلاعات میتواند هنگام ایجاد یک IG، از حراج متنی و از جستجوی کلید-مقدار در زمان واقعی، ارائه شود. برای امتیازآوران، هنگام پیکربندی حراج، میتوان اطلاعاتی از جمله اطلاعات متنی در مورد صفحه و حراج متنی، و همچنین از جستجوی بیدرنگ کلید-مقدار در RenderUrlهای تبلیغاتی ارائه کرد. |
(گزارش شده در سه ماهه قبل) رندر ویدیو | پشتیبانی از رندر ویدیو با استفاده از مخاطبان محافظت شده و فریم های حصاردار. | پاسخ ما نسبت به فصل های گذشته بدون تغییر است: "API Protected Audience از رندر ویدیو با استفاده از مکانیزمی که به iframes متکی است، پشتیبانی می کند. با این حال، ما هنوز راه حلی را طراحی نکرده ایم که با فریم های حصاردار سازگار باشد، و این یکی از دلایلی است که تصمیم گرفتیم اجرای فریم های حصاردار را تا سال 2026 به عقب برگردانیم. . این بدان معناست که اگر شریکی اکنون تصمیم به اجرای فریمهای حصاردار بگیرد، پشتیبانی از ویدیو برای آن شریک وجود ندارد." |
رندر ویدیو | پشتیبانی PA API برای ویدیو در iframe به ویدیوی HTML5 محدود می شود و از استاندارد VAST که به طور گسترده استفاده می شود پشتیبانی نمی کند. | پیادهسازی تبلیغات مبتنی بر VAST با استفاده از مکانیسم رندر iframe که امروزه در مخاطبین محافظتشده موجود است، امکانپذیر است. Google اذعان میکند که انجام این کار نیازمند مهندسی جدید از سوی خریداران، فروشندگان و پلتفرمهای تبلیغاتی ناشر است و ما همچنان به کار خود ادامه میدهیم تا انتقال از روشی که VAST در گذشته کار میکرده را تسهیل کنیم. |
(گزارش شده در سه ماهه قبل) مزایده های سطح بالا | امکان استفاده از سرور تبلیغات ناشر Google بدون اینکه به Google Ad Manager کنترل حراج سطح بالای PA API را بدهد. | پاسخ ما نسبت به فصل های گذشته بدون تغییر است: " پاسخ ارائه شده توسط Google Ad Manager: برنامههای Google Ad Manager برای API مخاطبان محافظتشده شامل پشتیبانی از سرور تبلیغات ناشر Google بدون کنترل حراج مخاطب محافظتشده سطح بالا، به دلایل زیر نیست. برای ارائه خدمات مناسب به مشتریان خود در بازار ارائه تبلیغات ناشر، سرور تبلیغات ناشر Google باید کنترل حراج مخاطب محافظت شده سطح بالا را حفظ کند. به عنوان یک سرور تبلیغات ناشر، نقش ما این است که پیشبینی ناشران را ارائه دهیم تا بتوانند در مورد کمپینهای فروش مستقیم بدون رزرو بیش از حد مذاکره کنند و رزروهای مستقیم خود را بهطور بهینه انجام دهند. انجام این کار مستلزم اجرای حراج نهایی برای مقایسه تمام تقاضاهای مستقیم و غیرمستقیم واجد شرایط است. پیش بینی و سرعت عملکردهای اصلی هستند که ناشران از یک سرور تبلیغات انتظار دارند. بدون پیش بینی دقیق، ناشران ممکن است در نهایت موجودی خود را بیش از حد بفروشند، که شهرت تجاری آنها را به خطر می اندازد. سرعتگیری نیز بسیار مهم است، زیرا ناتوانی در انجام قراردادهای رزرو با تبلیغکنندگان نیز به رابطه مستقیم ناشر-آگهیدهنده آسیب وارد میکند، که میتواند تأثیر قابلتوجهی بر تجارت ناشران داشته باشد. به طور خلاصه، بنابراین، ما فعالیت سرور تبلیغات ناشر در اجرای حراج مخاطب محافظت شده سطح بالا را متمایز از سایر فعالیت های سرور تبلیغات ناشر نمی دانیم." |
(گزارش شده در سه ماهه قبل) مستقیماز سیگنال های فروشنده | directFromSellerSignals به Google Ad Manager اجازه می دهد تا ناشر را از دیدن قیمت حراج متنی خود جلوگیری کند. | پاسخ ما نسبت به فصل های گذشته بدون تغییر است: " پاسخ کروم: اطلاعات ارسال شده به runAdAuction() معلوم نیست که از فروشنده می آید مگر اینکه فروشنده runAdAuction() را از iframe خودش فراخوانی کند. در یک حراج چند فروشنده، غیرممکن است که همه فروشندگان فریمی را ایجاد کنند که runAdAuction() را فراخوانی می کند. directFromSellerSignals با بارگیری محتوا از یک بسته منبع فرعی بارگیری شده از مبدا فروشنده، این مشکل را برطرف کرد. این تضمین میکند که صحت و یکپارچگی اطلاعات ارسال شده به حراج از پیکربندیهای فروشنده-حراج قابل دستکاری نیست. اگر ناشران بخواهند از API مخاطبان محافظت شده برای درک هر یک از اطلاعاتی که ارائهدهندگان فناوری آنها به حراجیهای مخاطب محافظت شده منتقل میکنند استفاده کنند، میتوانند این قابلیت را از آن ارائهدهندگان فناوری بخواهند. پاسخ ارائه شده توسط Google Ad Manager: ما سالها تمرکز زیادی بر عادلانه بودن حراج داشتهایم، از جمله قول دادهایم که هیچ قیمتی از منابع تبلیغاتی تضمیننشده ناشر، از جمله قیمت کالاهای خطی غیرتضمینشده، با خریدار دیگری قبل از پیشنهاد در حراج به اشتراک گذاشته نخواهد شد. که ما بعداً در تعهدات خود به سازمان رقابت فرانسه مجدداً تأیید کردیم. برای حراجهای مخاطب محافظتشده، ما قصد داریم با استفاده از directFromSellerSignals به قول خود عمل کنیم و قبل از اتمام حراج در حراجهای چند فروشنده، پیشنهاد هیچ شرکتکننده حراج را با هیچ شرکتکننده دیگری در حراج به اشتراک نگذاریم. برای روشن بودن، همانطور که در این بهروزرسانی توضیح داده شده است، ما قیمت حراج متنی را با حراج قطعات خودمان به اشتراک نمیگذاریم.» |
(گزارش شده در سه ماهه قبل) ارزش ناشناس بودن K | مقدار "K" به "k-anon" چگونه تعیین می شود و چه زمانی منتشر می شود؟ | ما مقدار K-anonymity را در دسامبر 2023 منتشر کردیم . پس از شروع فرآیند 3PCD، آستانه ناشناس بودن k را به مقدار نهایی 50 (k=50) افزایش می دهیم و دوره به روز رسانی را روی 1 ساعت (p=1) تنظیم می کنیم. مقدار K-ناشناس بودن 50 به عنوان ارائه تعادل بهینه بین مطلوبیت و حریم خصوصی ارزیابی شد. این مقدار برای خنثی کردن حملات اولیه ربات و حفظ حریم خصوصی متفاوت کافی است، در حالی که به اندازه کافی پایین است که API همچنان برای موارد استفاده مورد نظرش مفید باشد. |
(گزارش شده در سه ماهه قبل) forDebuggingOnly | اگر forDebuggingOnly.reportAdAuctionWin همچنان پس از 3PCD باقی بماند، ممکن است مورد سوء استفاده قرار گیرد. | ما پیشنهاد خود را در مورد چگونگی ادامه حمایت از موارد استفاده درازمدت اشکال زدایی در اینجا به اشتراک گذاشته ایم. ما از بازخورد اضافی در مورد پیشنهاد استقبال می کنیم. |
(گزارش شده در سه ماهه قبل) خط مشی همان مبدا | درخواست برای کاهش سیاست همان مبدأ برای اجازه دادن به زیر دامنهها. | این درخواست در حال بررسی است و ما در اینجا در مورد آن بحث کرده ایم. |
(گزارش شده در سه ماهه قبل) اندازه مؤلفه تبلیغاتی | تعداد اجزای تبلیغات را از 20 به 40 افزایش دهید. | ما این درخواست را در طول تماس WICG در 4 اکتبر و در این شماره GitHub مورد بحث قرار داده ایم و قصد داریم تا پایان سه ماهه اول 2024 به آن رسیدگی کنیم. |
(گزارش شده در سه ماهه قبل) ارزش کلید انقضای کلید سرور | بحث در مورد حذف کلیدهای سرور پس از منقضی شدن IGهای مربوطه. | مدیریت TTL بهتر است در خارج از TEE انجام شود تا پیچیدگی کاهش یابد، اگرچه ما از بازخورد اضافی در اینجا استقبال می کنیم. |
محرک های InterestGroup | آیا یک IG منفرد می تواند در یک حراجی واحد (مولفه) تولید چند پیشنهاد بدهد؟ | هر بار که مرورگر تابع ()genereBid یک IG را فراخوانی می کند، آن IG مجاز است یک مقدار bid را برگرداند. این امکان وجود دارد که به عنوان مثال در یک حراج چند فروشنده، یک IG چندین بار، هر بار در یکی از حراج های جزء، فراخوانی شود. برای فعال کردن/پشتیبانی از این رفتار، نیازی نیست که مالک IG به صراحت کاری انجام دهد. |
سوالات انطباق | دامنه رضایتی که از طریق مرورگر کروم کاربر جمع آوری می شود چقدر است؟ | لطفاً به "چگونه Privacy Sandbox به رعایت حریم خصوصی در Chrome نزدیک می شود؟" در سوالات متداول رعایت حریم خصوصی برای جزئیات بیشتر. |
حراج چند تگ | چگونه می توان حراج های چند تگ را در نظر گرفت؟ | ما در حال ارزیابی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
در دسترس بودن حفاظت IP | اگر حفاظت IP در تاریخ های اعلام شده آماده نباشد، چه تأثیری بر جدول زمانی ویژگی های مخاطب محافظت شده مانند اجرای چارچوب حصار و حذف یا حذف گزارش سطح رویداد دارد؟ | همانطور که در اینجا ذکر شد، ما معتقدیم جدولهای زمانی مخاطب محافظت شده باید با جدول زمانی انتشار سایر ویژگیهای حفاظت از حریم خصوصی مرتبط باشد. |
سیگنال های مدل سازی | درخواست یک فیلد جدید علاوه بر مدلسازی سیگنال هایی که فقط می توانند اطلاعات نمایش و کلیک را رمزگذاری کنند. | ما دستاوردهای مفید ارائه شده توسط این را درک می کنیم و در حال ارزیابی درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
IGهای منفی | آیا می توان به IGهای معمولی اجازه داد تا نام IG منفی را مشخص کنند؟ | در حال حاضر این امر به گفته توضیح دهنده امکان پذیر نیست، اما ما از بازخورد اکوسیستم اضافی در مورد اینکه چرا این یک الزام است استقبال می کنیم. |
استفاده از API | یک گزارش انبوه در passing سطح ()geneBid ایجاد کنید | Private Aggregation را می توان در داخل generateBid فراخوانی کرد. |
ماکروها | سیگنالها را از perBuyerSignals از طریق ماکروها در IFrames به 3Ps هدایت کنید. | ما در اینجا در حال بحث در مورد این مورد استفاده هستیم و از بازخورد اضافی استقبال می کنیم. |
استفاده از API | اگر خطای واکشی بازده سیگنالهای امتیازدهی مورداعتماد همچنان () scoreAd فراخوانی میشود؟ | اگر فراخوانی واکشی موفقیت آمیز نبود ()ScoreAd همچنان باید اجرا شود. |
استفاده از API | نوشتن metadata.shard_num در فایلهای riegeli برای فایلهای delta/snapshot. | در حال حاضر پشتیبانی از shard_num را برای رفع انسداد اضافه می کنیم. Riegeli به خوبی مانند Avro پذیرفته نشده است، اما رها نشده است. از آنجایی که TEE دارای محدودیتها و سربار بسیار بیشتری است، ما این مبادله را انجام دادیم تا عملکرد را بر تجربه کاربر اولویت دهیم. ما در حال بررسی ارائه یک سرویس gRPC برای ایجاد فایل از درخواست ها هستیم. ما همچنین ممکن است فرمت های دیگری مانند Avro را بر اساس تأثیر عملکرد آنها ارزیابی کنیم. |
تست API | چگونه PA API و Measurement API از تست افزایشی پشتیبانی میکنند؟ | Privacy Sandbox راهی برای اندازه گیری افزایش با پیش حراج خلاف واقع ندارد. میتوانید از ذخیرهسازی مشترک و تجمیع خصوصی استفاده کنید، اما خلاف واقع فقط پس از حراج خواهد بود. |
استفاده از API | آیا استفاده از biddingWasmHelperURL برای بهروزرسانیهای روزانه بر آستانه ناشناس بودن k تأثیر میگذارد؟ | از آنجایی که K-ناشناس بودن دیگر برای بهروزرسانیهای IG در نظر گرفته نمیشود ، biddingWasmHelperURL را میتوان بدون تأثیرگذاری بر آستانه بهروزرسانی کرد. |
استفاده از API | آیا می توانیم اعلان های خطا را برای PA API دریافت کنیم؟ | ما از بازخورد اکوسیستم در مورد نوع اعلان خطایی که برای عیبیابی مشکلات PA API نیاز دارند استقبال میکنیم. |
اندازه های تبلیغاتی | اندازه آگهی در حراج قابل مشاهده نیست و امکان گزارش وجود ندارد. | ما با این درخواست کشش مشکل را حل می کنیم. |
استفاده از API | اگر در این مزایده شرکت نکند، نقطه پایانی IG به روز رسانی برای IG فراخوانی می شود؟ | آره. UpdateURL برای همه IGهای یک مالک خاص فراخوانی می شود، حتی اگر در آن حراج خاص پیشنهادی ارائه نکرده باشند. تنها الزامات عبارتند از: - مالک باید در یک حراج معین گنجانده شود (یعنی به عنوان خریدار در auctionConfig گنجانده شود) - گروه علاقه مندی مالک داده شده نباید در 24 ساعت گذشته به روز شده باشد. |
Prebid در PA API | چه نسخه ای از Prebid.js برای مرحله آزمایش مورد نیاز است؟ | طبق مستندات فنی ما، نسخه باید >= 8.9.0 باشد. |
فعال سازی داده های شخص اول در PA API | چگونه می توانند داده های شخص اول خود را برای تعریف و استفاده از IGها فعال کنند؟ | برای این کار می توان از «اعمال مجوز» و «گروه های ذینفع منفی» استفاده کرد. |
PA API و برچسب گذاری سمت سرور | چگونه PA API با برچسب گذاری سمت سرور کار می کند؟ | تگ پایه در مرورگر کاربر باید تماس API را به بقیه تگ های سمت سرور هدایت کند، که به آنها امکان می دهد تماس را نیز ثبت کنند. |
آزمایش کروم (حالت a/b) | آیا انتظار می رود که SSP ها این برچسب ها را در درخواست های پیشنهادی RTB نیز پاس کنند و اگر چنین است چگونه؟ | بله، انتظار این است که برچسب ها از SSP به DSP منتقل شوند. نهادها تشویق میشوند به برچسب دسترسی داشته باشند و ارزش بدون تغییر را از طریق این برنامه افزودنی دستگاه با شرکا به اشتراک بگذارند. |
ذخیره سازی و استفاده از داده ها | آیا اطلاعات بیشتری در مورد نحوه ذخیره داده ها و محل انتقال داده ها دارید؟ | ما راهنمایی قانونی ارائه نخواهیم کرد، بلکه رویکرد/تفکر عمومی ما در مورد ذخیره سازی داده ها، حفظ و سایر مسائل مربوط به حریم خصوصی بیشتر است. سوالات متداول مربوط به رعایت حریم خصوصی را اینجا ببینید که ممکن است برای شما مفید باشد. |
ایمنی API | نگرانی در مورد کد مخرب سمت مشتری که مقدار بازگشتی تابع ()generalBid را دستکاری می کند. | ما این موضوع را در اینجا مورد بحث قرار داده ایم و برخی از بازخوردها در پیشنهاد تجمیع خصوصی گنجانده شده است. |
مقصد سفارشی | هنگام استفاده از تماسهای گزارش رویداد سفارشی مقصد، آیا میدانید مبدأ گزارش سفارشی (نه به خریدار و نه برای فروشنده) که بهعنوان بخشی از یک IG از پیش ثبتشده در allowReportingOrigins باید توسط DSP در ReportWin با استفاده از registerAdBeacon اعلام شود؟ | خیر، نیازی به ثبت مجدد آن در ReportWin نیست و میتواند مستقیماً در reportEvent همانطور که در اینجا مستند شده است استفاده شود. |
محدودیت های API | اندازه IG در هنگام ایجاد و به روز رسانی. | اندازه به روز رسانی به 1 مگابایت به روز شده است، که با سقف جدید 1 مگابایتی (از 50 کیلوبایت) برای ایجاد IG مطابقت دارد. |
محدودیت های K-anon | K-anon برای تبلیغات دارای اندازه های مختلف. | ما مقدار K-anonymity را در دسامبر 2023 منتشر کردیم که بیان می کند K-anonymity بررسی اندازه تبلیغ را «زمانی بعد از سال 2025» آغاز می کند. راهی برای حذف اندازه وجود ندارد زیرا میتواند یک بردار ردیابی متقابل باشد، همانطور که در تماس WICG 11 اکتبر توضیح داده شد. |
ایمنی API | آیا یک بازیکن مخرب می تواند "نام میزبان" یک صفحه را جعل کند؟ | API از یک کلید فرعی برای نام میزبان ناشر پشتیبانی می کند. از آنجایی که مرورگر در حال تنظیم کلید است، دور زدن این مکانیسم دشوار به نظر می رسد. |
استفاده از API | توابع ForDebuggingOnly نباید برای استفاده در تولید توصیه شوند. | ما در شرف تأیید مجدد به اکوسیستم هستیم که توابع forDebuggingOnly اصلاً برای عیبیابی post-3PCD مناسب نیستند. |
ابزارهای اشکال زدایی بیشتری مورد نیاز است | ForDebuggingOnly برای درک مسائلی که ممکن است قبل از scoreAd رخ دهد کافی نیست. | ما در حال جمع آوری بازخوردهای بیشتری در مورد این شکاف هستیم و از ورودی های اضافی در اینجا استقبال می کنیم. |
انصراف دائمی از گروه های علاقه مند | درخواست برای اجازه دادن به کاربران برای انصراف دائمی از ایجاد IGهای ویژه. | استراتژی ما این بوده است که اجازه ندهیم کاربران در سطح IG انصراف دهند زیرا معناشناسی آنطور که همه چیز برای کاربران قابل درک نیست. |
بهبود اسناد | از همان حروف بزرگ برای پارامتر renderUrls در spec و توضیح دهنده استفاده کنید. | ما از بازخورد قدردانی می کنیم و به روز رسانی اسناد را پیگیری می کنیم. |
پشتیبانی از معامله مخاطبان محافظت شده | درخواست گزینه های اضافی برای پشتیبانی از معامله مخاطب محافظت شده. | تیم Chrome در حال حاضر در حال ارزیابی است که ما میتوانیم برای پشتیبانی از 3PCD چه کاری انجام دهیم. |
ماکروها | پشتیبانی ماکرو برای نگه داشتن اندازه IGها زیر حداکثر اندازه IG مورد نیاز است. | به روز رسانی اخیر به توضیح دهنده تا حدی به این درخواست پرداخته است. |
API ReportLoss در سطح رویداد | درخواست برای API ReportLoss در سطح رویداد. | در حالی که گزارشهای ضرر در سطح رویداد خطر جدی حفظ حریم خصوصی دارند، ما معتقدیم که اهداف اساسی این درخواست را میتوان با تغییرات مناسب در API جمعآوری خصوصی برآورده کرد. ما از بازخورد اضافی در اینجا استقبال می کنیم. |
استفاده از API | روشهای forDebuggingOnly چگونه عمل میکنند اگر هیچ پیشنهادی امتیازی بالاتر از 0 نداشته باشد؟ | اگر امتیاز <= 0 باشد، این یک ضرر خودکار است. بنابراین، ReportAdAuctionloss فراخوانی خواهد شد. |
استاندارد سازی | هیچ تراز بین کاربران مقدار ورودی/خروجی تابع PA API generateBid() وجود ندارد. | ما به همه شرکا توصیه می کنیم که این (یا موارد مشابه) را در آزمایشگاه فناوری IAB مطرح کنند. این گروه به طور خاص روی استانداردهای صنعتی برای APIهایی مانند مخاطبان محافظت شده کار می کند. |
ایمنی API | گوگل چه داده هایی را از IGهای ما می تواند ببیند؟ | K-anonymity برای جلوگیری از افشای اطلاعات حساس کاربر به هر طرف، از جمله Google، به حفاظت از حریم خصوصی قوی متکی است. گوگل همچنین در حال توسعه یک پیاده سازی شخص ثالث (Fastly) از این لایه است تا این خطر را به حداقل برساند. |
آزمایش کروم (حالت a/b) | آیا کاربران محدود شده "k-anon" را می توان از آزمایش حذف کرد؟ | همانطور که در اینجا توضیح داده شده است، ما وضعیت k-ناشناس بودن را در گزارش نشان می دهیم. |
ایمنی برند | از مواردی که تبلیغات بسته به لیست سایت های مسدود شده یا کلمات کلیدی ارائه نمی شود، از ایمنی برند پشتیبانی کنید. | چنین موارد استفاده ایمنی نام تجاری باید از قبل با API PA امکان پذیر باشد. برای اینکه یک کمپین تبلیغاتی مجموعه ای از دامنه ها را به طور منفی هدف قرار دهد، آنها می توانند فهرست بلاک دامنه را در خود IG ذخیره کنند، شاید اگر فهرست کردن هر کدام فضای زیادی را اشغال کند، از فیلتر Bloom استفاده کنند. یا می توانند با استفاده از یک UDF که پاسخ را بر اساس ترکیب کلیدی که کمپین تبلیغاتی را شناسایی می کند و نام دامنه ای که در درخواست ارزش کلیدی گنجانده شده است، به دنبال تصمیم گیری مجاز یا رد را از سرور ارزش کلیدی خود بازگردانند. Protected Audience API همچنین به SSP و DSP اجازه می دهد تا هر گونه اطلاعاتی را در مورد زمینه صفحه به حراج منتقل کنند. این میتواند شامل فهرستی از موضوعات حساس یا کلمات کلیدی در صفحه باشد. منطق مناقصه DSP می تواند این اطلاعات را با هر اطلاعات ذخیره شده در مورد جایی که تبلیغ نباید نمایش داده شود مقایسه کند و در صورت لزوم پیشنهاد ندادن را انتخاب کند. ما از بازخورد اکوسیستم در مورد موارد استفاده خاص که آنها معتقدند امکان پذیر نیست استقبال می کنیم. |
تفویض مجوز | تفویض مجوز چگونه کار می کند؟ | ما اسناد مربوط به تفویض مجوز را در اینجا به اشتراک گذاشته ایم. |
درخواست های دسته ای | از درخواست POST برای برخی از URL های API PA به منظور پشتیبانی از درخواست دسته ای استفاده کنید. | ما از پیشنهاد استقبال می کنیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
بهبود API | فیلدهایی که احتمالاً نباید استفاده شوند (مانند X-fledge-bidding-signals-format-version). | ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
بهبود API | درخواست برای گذراندن رضایت GDPR به فروشنده خدمات و اندازهگیری آگهی شخص ثالث. | این عملکرد با استفاده از API جایگزین ماکرو قدیمی ReplaceInURN پشتیبانی می شود، همانطور که در اینجا توضیح داده شده است. |
بهینه سازی خلاقانه پویا | چگونه مخاطب محافظت شده از بهینه سازی خلاقانه پویا پشتیبانی می کند؟ | ما در حال بحث در مورد این مورد استفاده و راه حل های بالقوه در اینجا هستیم. |
بهبود API | درخواست برای نشانی اینترنتی ارائه آگهی شخص ثالث که بتواند زمینه IG را عمدتاً نام IG مطابق با IG برنده حراج دریافت کند. | چنین درخواست هایی ممکن است خطر ردیابی را برای کاربران افزایش دهد. ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
ایمنی API | نگرانی از اینکه اندازه "IG blob" اطلاعات مربوط به IGهای انتخاب شده را درز کند. | همانطور که در بخش ملاحظات حریم خصوصی توضیحدهنده Chrome B&A API ذکر شد، اندازه حباب به هیچ یک از ورودیهای navigator.getInterestGroupAdAuctionData بستگی ندارد. این فقط تمام IGها را روی دستگاه بسته بندی می کند. این تضمین می کند که اندازه حباب در یک صفحه نسبتاً ثابت است و توانایی درز اطلاعات بین سایت را محدود می کند. ما دقیقا به همین دلیل آن را به این شکل طراحی کردیم. |
آزمایش کروم (حالت a/b) | موضع سایر SSP ها در مورد از دست دادن اولین بار در رابطه با تنظیم کوکی ها و آزمایش با تسهیل کروم چیست؟ | ما هیچ نگرانی قابل توجهی نشنیدهایم (اگرچه دیگران این وضعیت را تایید کردهاند)، اما اگر این موضوع مهم باشد، از بازخورد اکوسیستم استقبال میکنیم. |
پشتیبانی از تست A/B | درخواست پشتیبانی برای تست PA API A/B. | ما این درخواست را در جلسه نوامبر WICG مورد بحث قرار دادیم و از بازخورد اضافی در اینجا استقبال کردیم. |
اندازه های تبلیغاتی | چه کسی اندازه حراج مخاطب محافظت شده را انتخاب می کند؟ | این سوال در این پرسش متداول پاسخ داده شده است. |
بهبود API | درخواست پیکربندی سرویس کلید-مقدار برای پذیرش مسیر /bidding-signals/v1/getvalues. | ما پیشوندهای مسیر پشتیبانی را در این درخواست کشش اضافه کرده ایم. |
استفاده از API | چگونه یک ناشر می تواند IG را با کد خود ایجاد کند، اگر قرار است در پایگاه آگهی دهنده باشد، تا تبلیغ کننده بتواند بر روی آنها پیشنهاد دهد؟ | پاسخها باید از طرف برخی از شرکای فناوری تبلیغات باشد - یک DSP یا SSP که میخواهد در حراجهای مخاطب محافظتشده شرکت کند و راهی برای آن مخاطبان ایجاد میکند که از یک منبع خارجی بیایند. ما این موضوع را در این شماره GitHub بیشتر مورد بحث قرار داده ایم. |
بهبود API | درخواست امکان پیوند IGهای منفی به تبلیغات در "گروه های علاقه مثبت". | ما در حال بررسی این درخواست هستیم و یک پیشنهاد احتمالی در مورد نحوه پشتیبانی از آن را در اینجا به اشتراک گذاشتیم. |
تعداد خرده ها | درخواست پشتیبانی برای ارسال "حمایت از shard_num" در ابرداده. | به دنبال این بازخورد، ما پشتیبانی از shard_num را اضافه کردهایم . |
استفاده از API | درخواست تخمین سربار کلیدها در سرور K/V. | ما نظرات خود را به اشتراک گذاشته ایم و از بازخورد اضافی در اینجا استقبال می کنیم. |
K-ناشناس بودن | درخواست برای شفاف سازی و افزایش دانه بندی ضد K-Anonymity. | ما در اینجا توضیحاتی را در مورد K-Anonymity counter granularity ارائه کرده ایم. |
اشکال زدایی | درخواست بهبود قابلیتهای اشکالزدایی PA API به دنبال تغییرات پیشنهادی اخیر در forDebuggingOnly. | ما در حال بحث در مورد درخواست در اینجا هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
اندازه آگهی | درخواست اندازه اسلات آگهی به عنوان سیگنال BTS اضافی. | ما پیشنهادی برای حمایت از این درخواست به اشتراک گذاشتهایم و از بازخورد اضافی در اینجا استقبال میکنیم. |
ایمنی API | آیا می توان استفاده از "runAdAuction()" را بر اساس مبدا محدود کرد؟ | ما پاسخ مفصلی را در اینجا به اشتراک گذاشته ایم. |
طول عمر IG | درخواست افزایش طول عمر IGها از 30 به 90 روز. | ما در حال بررسی درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
استفاده از API | آیا امکان اجرای حراج مخاطب محافظت شده به موازات Header Bidding و تماس سرور آگهی ناشر وجود دارد؟ | ما در حال بحث در مورد این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
اشکال زدایی | درخواست برای پشتیبانی بهتر از برنامههای افزودنی اشکالزدایی API Chrome PA که با DevTools صحبت میکنند. | ما از ارائه ابزارهای بیشتر برای رفع اشکال حمایت می کنیم و از پیشنهادات اضافی در اینجا استقبال می کنیم. |
استفاده از API | در صورتی که هیچ پیشنهادی از طرف فروشندگان جزء به فروشنده برتر نرسد، اعلانهای ضرر فعال نمیشوند. | ما در اینجا دلیل این امر را توضیح داده ایم. |
بهبود API | درخواست پشتیبانی از TextEncoder در کارنامه مناقصه مخاطبین محافظت شده. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
استفاده از API | تماسهای شبکه و منطق در حال اجرا در کلاینت میتواند موضوع اصلی را مسدود کند و باعث چالشهایی در اجرای JS شود که میتواند بر SEO تأثیر بگذارد. | ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
استفاده از API | آیا ممکن است DSPها از قیف پیشنهادی سمت سرور فعلی خود برای ارزیابی و ارسال آگهیها به عنوان بخشی از perBuyerSignal برای استفاده در مزایدههای روی دستگاه استفاده کنند؟ | ما در حال بحث در مورد این سوال هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
دادههای فرصت پیشنهادی را گسترش دهید | درخواست گسترش دادههای فرصت پیشنهاد ارسال شده توسط مرورگر به SSP با فهرستی از دامنههای مبدا منحصر به فرد IGهای فعال در مرورگر. | ما در حال بحث در مورد این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
ORTB | درخواست دو قلاب جدید برای auctionConfig و انطباق پاسخ GenerBid در ORTB. | ما در حال بررسی این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
برد قبلی | درخواست برای IG که یک prevWinsTransformer را تعریف می کند، که بردهای قبلی IG را می گیرد و یک چیز قابل سریال سازی را خروجی می دهد. | ما در حال بررسی این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
انواع محتوا | استراتژی برای تکامل انواع محتوا، به عنوان مثال JSON به چیزی مانند CBOR. | ما در حال بررسی این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
Prebid در Protected Audience API | درخواست یک صفحه ناشر نمونه که از prebid برای اجرای یک جریان سرتاسر برای حراج مخاطب محافظت شده استفاده می کند. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم در مورد اینکه چرا باید این مورد اولویت بندی شود، استقبال می کنیم . همچنین شرکتکنندگان اکوسیستم را دیدهایم که صفحات ناشر نمونهای را تولید میکنند که برای سایرین در اکوسیستم به صورت نمایشی در دسترس است. |
خدمات حراج محافظت شده
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
محیط های اجرایی مورد اعتماد (TEEs) | اجرای «محیطهای اجرای معتمد» در ابرهای عمومی در مقایسه با مراکز داده فناوری تبلیغات داخلی، گرانتر است؟ | مدل امنیتی TEE فعلی ما از شیوههای پیادهسازی ابر عمومی سود میبرد. به طور خاص، TEE های مبتنی بر سخت افزار فعلی در برابر همه حملات فیزیکی دفاع نمی کنند. ارائه دهندگان ابر عمومی پشتیبانی شده فعلی ما، AWS و GCP، اقدامات کاهشی را برای خطرات دسترسی فیزیکی، از جمله کارمندان، طراحی و اجرا کردند. جزئیات بیشتر در مورد پشتیبانی داخلی را در زیر مشاهده کنید. فناوری های تبلیغاتی به ما اشاره کرده اند که اجرای سرویس های ابری گران تر از مراکز داده فناوری تبلیغات داخلی است. در حالی که ما در موقعیتی نیستیم که این اظهارات را ارزیابی کنیم، از بازخورد اضافی در مورد هزینه ها استقبال می کنیم و به ارزیابی گزینه ها برای گسترش پشتیبانی TEE خود ادامه می دهیم. |
(گزارش شده در سه ماهه قبل) TEE در محل | شرایط لازم برای تبدیل شدن به یک ارائه دهنده TEE چیست؟ | پاسخ ما مشابه فصل های قبل است: "در حالی که ما به بررسی پشتیبانی از گزینههای فراتر از راهحلهای مبتنی بر ابر عمومی، از جمله در نظر گرفتن اینکه کدام استقرار از منظر امنیتی قابل قبول است، ادامه میدهیم، هیچ برنامهای برای پشتیبانی از TEEهای داخلی نداریم. در این مرحله، با توجه به الزامات امنیتی Privacy Sandbox و چالشهای مهمی که توسط استقرار در محل ارائه میشود، ما معتقدیم که ادامه گسترش و بهبود استقرار مبتنی بر ابر برای اکوسیستم سودمندترین است. محدودیت های امنیتی." |
محدودیت های سرور کلید/مقدار | محدودیت کلیدها در هر حراج برای هر سرور | ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
محدودیت های K-anon | تأییدیه که ناشناس بودن K در آینده روی کلیدهای K/V اعمال نخواهد شد. | ما هیچ برنامهای برای اعمال k-anon روی کلیدهای درخواستهای سرور K/V نداریم، زیرا قصد داریم در آینده سرورهای K/V را به TEE منتقل کنیم. |
خدمات K/V ساختمان | آیا گوگل مصنوعات از پیش ساخته شده برای سرویس K/V در دسترس دارد؟ | ما در حال حاضر هیچ مصنوع از پیش ساخته شده ای برای سرور کلید/ارزش مخاطب محافظت شده نداریم، اگرچه اگر تقاضای زیادی برای آن از سوی اکوسیستم بشنویم، ممکن است آن را ارائه کنیم. |
پشتیبانی EgId در B&A | درخواست پشتیبانی از ExperimentGroupId میدانی در کد مناقصه و مزایده و درخواست سرویس KeyValue از BuyerFrontEnd | B&A در حال حاضر از ExperimentGroupId پشتیبانی نمی کند، اما قصد دارد این را تا نسخه بتا 2 (در حال حاضر برای فوریه 2024 برنامه ریزی شده) عرضه کند. ما اطلاعات اضافی را در اینجا به اشتراک گذاشته ایم. |
استفاده از API | ادغام درخواست در HTTP می تواند به محافظت در برابر مهاجمان در مسیر کمک کند، اما اپراتور TEE اندازه ها را یاد می گیرد. | ما در حال بحث در مورد این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
بهبود اسناد | مشخصات مشخص نیست که سرور kv چگونه آدرسدهی میشود. | ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
استفاده از API | هدف از "Ad-Auction-Result" و adAuctionHeaders چیست؟ | ما در اینجا در حال بحث در مورد این موضوع هستیم و از بازخوردهای اضافی استقبال می کنیم. |
بهبود اسناد | مشخص نیست که آیا طراحی v2 در FLEDGE.md منتشر شده است یا خیر. | FLEDGE.md در مورد نحوه ارسال درخواستهای Chrome به BYOS-KV صحبت میکند. طراحی پروتکل v2 فقط به TEE-KV محدود شده است و در حال حاضر توسط Chrome پشتیبانی نمی شود. |
اندازه گیری تبلیغات دیجیتال
گزارش انتساب (و سایر APIها)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
اندازه گیری متقابل محیطی | Chrome چگونه برنامهای برای پشتیبانی از اندازهگیری متقابل محیطی در مرحله میانی دارد، جایی که 3 رایانه شخصی از دستگاه همراه Chrome حذف شده است، اما جعبه ایمنی حریم خصوصی برای Android هنوز در دسترس نیست؟ | از طرف Android، ما در حال کار بر روی گسترش پوشش PSB/ARA هستیم - API گزارش Attribution (ARA) در Android 13 و 14 در دسترس است، و ما قصد داریم تا اواخر سال جاری به Android 11 و 12 گسترش دهیم، اگرچه این موضوع مشروط به تغییر دادن. ما نمیتوانیم آن را به اندروید 10 یا بالاتر گسترش دهیم، اما انتظار داریم درصد دستگاههای اندرویدی هنوز در اندروید 10 یا پایینتر در 3PCD کمتر باشد و طبیعتاً با گذشت زمان با ارتقای کاربران کاهش یابد. ما از بازخورد اضافی از اکوسیستم در مورد این درخواست استقبال می کنیم. |
فیلتر کردن | فیلتر کردن "تبدیل ها" از اسکن خلاق. | ما برای درک بهتر درخواست آنها با این ذینفع تماس گرفتیم و از بازخورد اضافی اکوسیستم در مورد این موضوع استقبال می کنیم. |
سرورهای تبلیغاتی شخص ثالث | PA API و ARA چگونه با برچسبهای سرور تبلیغاتی شخص ثالث کار خواهند کرد؟ | مشابه نحوه عملکرد پیکسلها با برچسبهای نمایش و کلیک امروزه، یک سرور تبلیغات میتواند به تنهایی ثبتهای منبع و راهاندازی را برای ARA تنظیم کند (از جمله حراجهای مخاطب محافظتشده)، یا میتواند تغییرمسیر را برای عبور و پذیرش ثبت منبع و راهاندازی تنظیم کند. آرا. |
DCM | پشتیبانی از attributionsrc توسط DCM و سایر سرورهای تبلیغاتی شخص ثالث. | این یک مشکل مربوط به DCM است و توسط تیم DCM در این شماره GitHub به آن پرداخته شده است. |
کلید تجمع سلسله مراتبی | آیا لازم است تمام بودجه مشارکت به همه این کلیدهای سلسله مراتبی تقسیم شود؟ | ما بحث کرده ایم و به این ذینفع پاسخ داده ایم. هنگام استفاده از ساختار کلید سلسله مراتبی، فناوری تبلیغاتی باید در نظر داشته باشد که بودجه مشارکت در همه خروجیهای کلید برای یک نمایش به اشتراک گذاشته میشود. |
از زیر دامنه های مختلف استفاده کنید | آیا گزارش انتساب با منابع و محرک های ثبت شده در زیر دامنه های مختلف اما eTLD+1 یکسان کار می کند؟ | ما این سوال را با ذینفعان بحث کرده و راه حل های زیر را پیشنهاد کرده ایم. آنها میتوانند تنظیمات URL خود را تغییر دهند تا مبدا و منبع گزارش یکسانی داشته باشد، یا قبل از انجام ثبت نام، از URL فعلی خود به یک URL مشترک هدایت شوند. اگر راهحلهای پیشنهادی برای مورد استفادهشان کار نکنند، آماده دریافت بازخورد اکوسیستم اضافی هستیم. |
(در فصل های گذشته نیز گزارش شده است) پشتیبانی تولید | چه سطوحی از خدمات برای پشتیبانی از شرکای استفاده از ARA در دسترس است؟ | پاسخ ما نسبت به فصل های گذشته بدون تغییر است: "Google مجموعهای از کانالها را فراهم میکند تا به فناوریهای تبلیغاتی اجازه دهد مشکلات فنی را گزارش کنند و هرگونه تشدید لازم را برای حل چنین مشکلاتی فعال کنند. علاوه بر این، Chrome انتظار دارد فرآیندی را برای حل مشکلات فنی و تشدیدهایی که بر سلامت اکوسیستم تأثیر میگذارد ایجاد و مقیاسبندی کند. Chrome متعهد است که منابع لازم برای این تلاش را تضمین کند. لطفاً برای اطلاعات بیشتر در مورد انجمنهای عمومی و خصوصی برای بازخورد و تشدید، پست توسعهدهنده ما را ببینید." |
(در فصل های گذشته نیز گزارش شده است) جدول زمانی | آیا Google تا آغاز آزمایش کمی CMA، «فاز 2 کامل رویداد انعطافپذیر» را آماده خواهد کرد؟ | انتظار میرود سطح رویداد کامل انعطافپذیر فاز 2 در سه ماهه اول 2024 در Chrome در دسترس باشد. میتوانید وضعیت را در اینجا پیگیری کنید. |
(در فصل های گذشته نیز گزارش شده است) قیف تبدیل | چندین دامنه را گزارش کنید که در تبدیل استفاده شده است. | این مورد استفاده از زمان اضافه شدن چندین مقصد امکان پذیر است. ما از بازخورد اضافی استقبال می کنیم. |
گزارش برچسب های تست | آیا قابلیتهای گزارشدهی به آزمایشکنندگان اجازه میدهد گزارش دهند که کاربر (مرورگر کروم) در کدام گروه است (حالت A/B)؟ | ما در حال کار بر روی انتشار یک راهنمای آزمایش برای گرفتن برچسبهای آزمایش کروم در ARA هستیم. |
مستندات | در مستندات Attribution-Reporting-Register-Source آمده است که انقضا به نزدیکترین روز گرد می شود، چگونه گرد می شود؟ | گرد کردن به نزدیکترین روز به این معنی است که 1.5 روز به 2 روز تبدیل می شود. |
از زیر دامنه های مختلف استفاده کنید | درخواست دریافت گزارش های Attribution Reporting API در یک زیردامنه دیگر به عنوان منبع و شروع ثبت نام. | ممکن نیست. تغییر مسیرهای HTTP را می توان اعمال کرد، اما هیچ تنظیمی برای این کار وجود ندارد. ما از بازخورد اضافی از اکوسیستم در مورد اینکه چرا این درخواست مفید است استقبال می کنیم. |
تأخیر گزارش دهی در سطح رویداد | پنجره اسناد و گزارش 7 روزه، اما به دلیل تاخیر در گزارش سطح رویداد، ممکن است بیش از 8 روز طول بکشد تا همه گزارش ها ارائه شوند. | ما بازخورد را تأیید میکنیم و از ورودیهای اضافی اکوسیستم در مورد اینکه آیا این تأخیر در گزارشدهی در سطح رویداد یک مشکل است یا خیر، استقبال میکنیم، بهویژه با تغییر پنجرههای گزارش رویداد ثابت به انعطافپذیر. |
محرک های تبدیل | محرکهای تبدیلی که بین پایان اولین رویداد_report_window (1 ساعت) و زمان انقضا (1 روز) اتفاق میافتد، گزارش تولید نمیکند. | ما پیکربندی انعطافپذیر در سطح رویداد را معرفی کردهایم که از پنجرههای گزارش رویداد ثابت به انعطافپذیر حرکت میکند. |
سر و صدا | آیا گزارشهای سطح رویداد همانطور که در توضیحگر GitHub توضیح داده شده، تبدیل جعلی پر سر و صدا هستند؟ | بله، نویز برای گزارشهای سطح رویداد اعمال میشود و نشاندهنده همه حالتهای خروجی ممکن است، از جمله trigger_data مختلف، اصلاً چیزی را گزارش نمیکند زمانی که یک ماشه واقعاً رخ داده است، یا به طور بالقوه گزارشهای جعلی متعدد را برای رویداد گزارش میکند. % نویز منبع باز است و میتوان آن را از طریق تنظیمات سطح رویداد انعطافپذیر ساخت. |
فیلتر کردن | استفاده از فیلتر کردن با Attribution Reporting API همچنان بودجه مشارکت را مصرف میکند، حتی اگر کلید تجمیع را ثبت نمیکند. | این همانطور که در نظر گرفته شده است کار می کند زیرا aggregatable_trigger_data فقط از فیلتر کردن روی خود قطعات کلید ماشه پشتیبانی می کند، نه روی مقادیر/کلیدها. فیلترهای سطح بالا میتوانند از فیلتر کردن کلیدها پشتیبانی کنند، اما این مورد توسط رویداد + مجموع به اشتراک گذاشته میشود، بنابراین در اینجا قابل اجرا نیست. اگر فیلتر کردن کلیدها ضروری باشد، از بازخورد اضافی از اکوسیستم در اینجا استقبال می کنیم. |
محدودیت ذخیره سازی | درخواست برای معرفی محدودیت ذخیره سازی که منشاء گزارش را نیز در نظر می گیرد. | افزایش از 1024 به 4096 این حد از M120 موثر خواهد بود و ما از بازخورد اضافی از اکوسیستم در اینجا استقبال می کنیم. |
اسناد مستقیم | چگونه میتوان معیارهایی را برای موقعیتهایی دریافت کرد که در آن کاربر مستقیماً بدون مراجعه به ناشر از تبلیغکننده بازدید میکند، زیرا فرآیند استاندارد گزارش اسناد این سناریو را پوشش نمیدهد؟ | ARA فقط برای بازیابی اطلاعات بین سایتی (یعنی پیوستن اطلاعات در سایت های ناشر/تبلیغ کننده) طراحی شده است. اگر اطلاعات متقابل سایت مورد نیاز نباشد، ARA به شما کمک نخواهد کرد. ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
زمان گزارش | به جای استفاده از زمان محلی ماشین، زمان scheduled_report_time را از سرور زمان دریافت کنید. | ما در حال حاضر هیچ برنامه ای برای استفاده از سرور زمان نداریم و تقاضای زیادی از Ad Tech برای آن نشنیده ایم. ما علاقه مند به شنیدن بازخورد اضافی از اکوسیستم در مورد اینکه آیا این یک ویژگی مفید است یا خیر، خواهیم بود. |
سرویس تجمع
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(در فصل های گذشته نیز گزارش شده است) راه حل در محل | آیا سرویس Aggregation را می توان در مراکز داده داخلی مستقر کرد؟ | در حالی که ما در حال بررسی گزینههای پشتیبانی بالقوه فراتر از راهحلهای مبتنی بر ابر هستیم، در حال حاضر پشتیبانی از TEEهای داخلی با توجه به محدودیتهای امنیتی درون محل که نیاز به ارزیابی زمانبر برای Privacy Sandbox دارد، امکانپذیر نیست. با توجه به الزامات امنیتی Privacy Sandbox و چالشهای قابل توجهی که توسط استقرارهای داخلی ارائه میشود، ما معتقدیم که ادامه گسترش و بهبود استقرارهای مبتنی بر ابر (مثلاً پشتیبانی از GCP علاوه بر AWS) برای اکوسیستم مفیدترین است. با این حال، در اینجا از بازخورد اضافی در مورد اینکه چرا چنین الزامی ضروری است استقبال می کنیم. |
محصور کردن | اگر Enclave بالا نباشد یا ناگهان خطا دریافت کند، Aggregation Service API چگونه با آن برخورد میکند؟ | اگر Enclave در راهاندازی و مقیاس خودکار شکست بخورد، از تلاشهای مجدد استفاده میکنیم تا اگر نمونهای ناسالم دیده شود، نمونههای جدیدی را ارائه میکنیم. Adtech ها همچنین می توانند با استفاده از لاگ ها خرابی ها را بررسی کنند. برای رفع اشکال خرابیهای enclave در AWS، متخصصان تبلیغات میتوانند وضعیت نمونه EC2 خود را با وارد شدن به مدیریت کنسول AWS خود بررسی کنند. فنآوران تبلیغات همچنین میتوانند به نمونه میزبان Nitro Enclave وارد شوند و وضعیت enclave را با ابزار nitro-cli بررسی کنند. در صورت وجود هر گونه خطا/شکست، آنها می توانند از رابط خط فرمان AWS برای مشاهده گزارش ها و بررسی بیشتر استفاده کنند. برای رفع اشکال خرابیهای enclave در GCP، adtechها میتوانند وضعیت نمونه خود را از طریق Cloud Console بررسی کنند. آنها همچنین می توانند خطاها را با استفاده از دستور list-errors-command بررسی کنند. |
از زیر دامنه های مختلف استفاده کنید | درخواست ثبت چندین دامنه (زیر) برای استفاده از چندین نمونه از سرویسهای جمعآوری، هم در محیطهای توسعهدهنده و هم در محیطهای prod. | ثبتنام سایت راهاندازی شده است تا فناوریهای تبلیغاتی بتوانند چندین زیر دامنه از یک سایت را در یک حساب AWS یا پروژه GCP ثبت کنند. آنها همچنین می توانند همان دامنه را در چندین حساب AWS یا پروژه های GCP ثبت کنند. ما از بازخورد اکوسیستم استقبال می کنیم . |
بودجه حریم خصوصی | چگونه می توان مسائل مربوط به خستگی بودجه حریم خصوصی را بهتر اشکال زدایی کرد؟ | در حال حاضر ما به دنبال راه حل هایی برای ارائه جزئیات بیشتر در مورد بودجه تمام شده و همچنین بهبود اسناد خود برای ترسیم استراتژی هایی هستیم که adtech ها می توانند برای به حداقل رساندن وقوع این خطا استفاده کنند. به محض اینکه پیشنهادی داشته باشیم ، صفحه GitHub Service Aggregation را به روز می کنیم. |
ارزش اپسیلون | درخواست افزایش ارزش اپسیلون. | برای تسهیل آزمایش و بازخورد روی پارامترهای مختلف در طول 3PCD، مقدار اپسیلون سرویس Aggregation تا محدوده 64 نگهداری میشود. قبل از بهروزرسانی مقادیر محدوده اپسیلون، اطلاعیههای پیشرفتهای به اکوسیستم ارائه خواهیم کرد. |
باینری ها | مجموعه کاملتری از باینریها را برای نسخههای Aggregation Service منتشر کنید. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی استقبال می کنیم . |
استفاده از API | به اشتراک گذاری داده ها با هماهنگ کننده ها، با توجه به شرایط خدمات هماهنگ کننده. | ما به دنبال توضیح در مورد این موضوع هستیم و از بازخورد اضافی استقبال می کنیم . |
Private Aggregation API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
اشکال زدایی | گزینه های اضافی را برای اشکال زدایی در طول آزمایش حالت B فعال کنید. | همانطور که در این شماره Github به اشتراک گذاشته شد، ما با اجازه دادن به حالت اشکال زدایی در حالت B جلو می رویم. این واجد شرایط بودن در M121 Beta در 50٪ از ترافیک حالت B که از 1/31 شروع می شود، تغییر می کند. قبل از اینکه به استیبل بروید، اطلاعیهای ارائه میکنیم. |
ردیابی پنهان را محدود کنید
کاهش نماینده کاربر/ نکات مشتری عامل کاربر
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
ChromeOS | از راهنمایی های کاربر-عامل مشتری برای کمیت سیستم عامل کروم پشتیبانی کنید. | ما پاسخی به این درخواست را در اینجا به اشتراک گذاشته ایم. |
حفاظت از IP (Gnatcatcher سابق)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
سو استفاده کردن | ممکن است Google بتواند دادههای مرور کاربر را از طریق IP Protection مشاهده کند. | ترافیک تونل های IP از طریق دو پروکسی (یکی توسط Google ، یکی توسط یک شرکت دیگر) ترافیک. این تضمین می کند که Google نمی تواند داده های مرور را ببیند. تمام ترافیک بین Chrome و Proxies رمزگذاری شده است ، بنابراین Proxy Google هیچ اطلاعاتی در مورد مرور وب سایت ها ندارد. علاوه بر این ، این سیستم از نشانه های احراز هویت نابینا برای به حداقل رساندن دسترسی به شناسه های کاربر در پروکسی ها استفاده می کند. تمام پروکسی های Google می بینند که یک مشتری ناشناخته در یک IP خاص از سیستم پروکسی استفاده می کند. هیچ اطلاعاتی در مورد وب سایت های بازدید شده یا تبلیغات بارگذاری شده در دسترس نیست. |
پشتیبانی از حالت بدون سر | چگونه رباتها با استفاده از افزونه ها و حالت بدون سر مدیریت می شوند؟ | کاهش سوءاستفاده از محافظت از IP اولویت اصلی تیم است. ما این سناریوها را با دقت در نظر گرفته ایم (در میان بسیاری از تهدیدات احتمالی دیگر) و در حال کار بر روی گزینه هایی هستیم که به کاهش احتمال سوءاستفاده یا کلاهبرداری کمک می کند. در حالی که ما در حال حاضر نمی توانیم جزئیات بیشتری را ارائه دهیم ، انتظار داریم در آینده نزدیک آنها را ارائه دهیم و مشتاقانه منتظر ادامه بحث هستیم. |
پروکسی های موجود | حفاظت IP چگونه با تنظیمات پروکسی موجود در Chrome کار خواهد کرد؟ | تنظیمات پروکسی موجود پشتیبانی خواهد شد. کاربران قادر خواهند بود مانند گذشته پروکسی های سفارشی خود را پیکربندی کنند. |
گزارش سوءاستفاده | گزارش سوء استفاده چگونه انجام می شود؟ | ما جزئیات بیشتری برای به اشتراک گذاشتن در آینده نزدیک خواهیم داشت ، اما ما قصد داریم مکانیسمی برای سازمانها و کاربران داشته باشیم تا گزارش ها و شواهد سوء استفاده را به اشتراک بگذارند. |
آئین نامه | محافظت از IP چگونه از قوانین و مقررات محلی پیروی می کند؟ | گوگل متعهد به رعایت قوانین و مقررات محلی است و دور زدن چنین بلوک های سطح کشور ممکن است مجاز نباشد. این ویژگی برای دور زدن در نظر گرفته نشده است. |
محدود کردن قابلیت ها | آیا محافظت از IP پاسخ سایبری ما را مسدود می کند؟ | ما در تلاش هستیم تا تعادل بین محافظت از کاربران در وب بر اساس آدرس های IP آنها و ضمن به حداقل رساندن اختلال در عملکردهای عادی سرورها ، از جمله استفاده از آدرس های IP برای ضد سوء استفاده ، تعادل برقرار کنیم. در حالی که ما در حال حاضر نمی توانیم جزئیات بیشتری را ارائه دهیم ، انتظار داریم در آینده نزدیک آنها را ارائه دهیم و مشتاقانه منتظر ادامه بحث هستیم. |
جدول زمانی | اگر این کار قبل از پایان سال 2024 اجرا شود ، آماده سازی برای آن تقریباً غیرممکن خواهد بود. | Chrome در ابتدا محافظت از IP را به عنوان یک تنظیم انتخابی برای کاربران در مناطق خاص راه اندازی می کند ، و می داند که این می تواند تغییر مهمی برای نحوه اعتماد برخی از شرکت ها به آدرس های IP باشد و به دنبال به حداقل رساندن اختلال در هنگام تنظیم اکوسیستم است. محافظت از IP در اواخر سال 2025 به طور پیش فرض منتقل می شود. |
استفاده از API | آیا به کاربر انتخاب می شود که اولین بار که Chrome را باز می کند ، حفاظت IP را تغییر دهد؟ | ما قصد داریم انتخاب کنیم که آیا آنها می خواهند از IP محافظت کنند یا خیر. مکانیک ارائه این گزینه به کاربران هنوز در حال توسعه است. |
استفاده از API | چه مقدار داده وارد شده است و برای چه مدت آن داده ها حفظ می شود؟ | ما جزئیات بیشتری برای به اشتراک گذاشتن در آینده خواهیم داشت ، اما ما قصد داریم حداقل مقادیر داده را وارد کنیم. |
بازخورد منفی | در صورت تمایل به استفاده از آنها ، کاربران می توانند از VPN استفاده کنند. نیازی به API های PS نیست. | هدف محافظت از IP جلوگیری از استفاده از آدرس های IP به منظور ردیابی متقابل سایت است ، در نظر گرفته نشده است که یک سرویس VPN باشد. |
ایمنی API | چگونه می توان از طریق پارامتر هدر ، به آدرس IP و اطلاعات مربوط به طرف اول دسترسی پیدا کرد؟ | ما در ابتدا روی اشخاص ثالث تمرکز می کنیم زیرا می بینیم که بیشترین تأثیر را دارد. ما همچنان به نظارت بر اکوسیستم ادامه خواهیم داد تا مشخص کنیم که آیا برای جلوگیری از دور زدن مقیاس ، باید رویکرد خود را تکامل دهیم. |
استفاده از API | در صورت صحیح بودن درک استفاده از API ، تأیید لازم است. | IP Protection از یک رویکرد مبتنی بر لیست استفاده می کند تا مشخص شود که ترافیک شخص ثالث از طریق پروکسی ها عبور می کند. منشأی که در این لیست قرار دارند اما در یک زمینه شخص اول قابل دسترسی هستند از طریق این سرویس برای آن اتصالات مجهز نمی شوند. به عنوان مثال ، اگر یک شرکت Analytics در لیست دامنه ها قرار داشته باشد و کاربر مستقیماً به سایت منتقل شود ، آن سایت همچنان می تواند آدرس IP کاربر را به جای آدرس IP پروکسی مشاهده کند. با این حال ، اگر این دامنه در لیست درخواست شبکه را در یک زمینه شخص ثالث ایجاد کند ، اتصال به شما امکان پذیر می شود و آدرس IP اصلی کاربر برای سایت قابل مشاهده نخواهد بود. هدف نهایی ما جلوگیری از ردیابی متقابل سایت کاربران در وب است. ما قبل از به اشتراک گذاشتن اطلاعات بیشتر در مورد کدام حوزه های شخص ثالث که قصد داریم در ابتدا روی آن تمرکز کنیم ، در حال کار با جزئیات هستیم. |
VPN | نگرانی از اینکه پیشنهاد Google می تواند برای سایر ارائه دهندگان VPN نامطلوب باشد. | هدف محافظت از IP جلوگیری از استفاده از آدرس های IP به منظور ردیابی متقابل سایت است ، در نظر گرفته نشده است که یک سرویس VPN باشد. |
جدول زمانی | جدول زمانی محافظت IP چیست؟ | محافظت IP در ابتدا انتخاب خواهد شد. این امر به اطمینان از کنترل کاربر بر تصمیمات حریم خصوصی کمک می کند و Google می تواند رفتارها را در حجم پایین تر نظارت کند. محافظت از IP به صورت مرحله ای از بین می رود و زودتر از سال 2025 به طور پیش فرض به صورت پیش فرض منتقل می شود. مانند همه پیشنهادات حریم خصوصی ما ، ما می خواهیم اطمینان حاصل کنیم که یاد می گیریم که می رویم و می دانیم که ممکن است ملاحظات منطقه ای نیز برای ارزیابی وجود داشته باشد. ما از یک رویکرد مبتنی بر لیست استفاده می کنیم و فقط دامنه های موجود در لیست در یک متن شخص ثالث تحت تأثیر قرار می گیرند. ما آگاه هستیم که این پیشنهادات ممکن است باعث ایجاد اختلال ناخواسته برای موارد استفاده قانونی شود و بنابراین ما فقط روی اسکریپت ها و دامنه هایی متمرکز شده ایم که به عنوان ردیابی کاربران در نظر گرفته می شوند. |
محدود کردن قابلیت ها | آدرس های IP کاربر دیگر نمی توانند در Whois مورد بررسی قرار گیرند. | موقعیت ما این است که آدرس IP یک شناسه پایدار است که استفاده از آن می تواند پیامدهای حریم خصوصی برای کاربران داشته باشد ، از جمله استفاده از ابرداده مرتبط با آن مانند ASN. با محافظت از IP ، ما در تلاش هستیم تا تعادل مناسب بین حریم خصوصی و پشتیبانی از یک تجربه مفید کاربر در وب ، به عنوان مثال با رویکرد ما به جغرافیایی IP. اگر این ابرداده برای مورد استفاده شما کافی نباشد ، ما برای بحث در مورد این موضوع باز هستیم. |
ارجاع HTTP | آیا ارجاع اصلی HTTP حفظ خواهد شد؟ | همانطور که در اینجا بحث شده است ، هیچ برنامه ای برای تغییر عنوان مراجعه کننده به عنوان بخشی از محافظت از IP وجود ندارد. |
متن باز | آیا کدهای منبع حفاظت IP منبع باز خواهد بود؟ | اکثر نرم افزارها در اینجا به عنوان بخشی از پروژه های کروم و نماینده پروکسی ، منبع باز هستند ، اما برخی از مؤلفه ها همانطور که در اینجا توضیح داده شده است ، منبع بسته هستند. |
کاهش ردیابی گزاف گویی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
حذف ذخیره سازی | آیا کاهش ردیابی Bounce (BTM) ذخیره سازی ذخیره سازی مشترک و ذخیره سازی را حذف می کند؟ | ما قصد نداشتیم BTM را برای حذف ذخیره سازی API Sandbox Privacy (ARA ، PA API ، ذخیره سازی مشترک ، جمع آوری خصوصی ، مباحث) حذف کنیم. BTM فقط باید انواع ذخیره سازی را که در صورت دسترسی در یک زمینه شخص ثالث ، خطرات حریم خصوصی را حذف کنند ، حذف کند. رفع اشکال در حال انجام است. |
استفاده از API | کدام نسخه Chrome BTM فعال خواهد شد؟ آیا ردیابی تغییر مسیر/گزاف گویی پس از 10 ثانیه به عنوان ردیابی گزاف گویی توسط BTM در نظر گرفته می شود یا خیر؟ | در M116 ، BTM به 100 ٪ از کاربران با 3 قطعه مسدود شده رسید. در حال حاضر یک تغییر مسیر پس از 10 ثانیه ، گزاف گویی محسوب نمی شود. |
در مورد استفاده کنید | به طور خودکار همگام سازی/حفظ وضعیت ورود به سیستم در چندین حوزه ، بدون اینکه مجازات رفتاری مانند ردیابی باشد؟ | ما در اینجا در مورد این درخواست بحث می کنیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
سفر کاربر | در حال حاضر BTM منجر به سفرهای پیچیده کاربر می شود. | ما در مورد این موضوع بحث می کنیم و در اینجا افکار خود را در این باره به اشتراک گذاشتیم. |
Storage Access API | BTM در Chromium کمک های مالی 3pc را از API دسترسی به ذخیره سازی (SAA) افتخار می کند. | ما این موضوع را با شرکت کنندگان در اکوسیستم در TPAC 2023 مورد بحث قرار داده ایم و از بازخورد اضافی در اینجا استقبال می کنیم. |
تأثیر در گزارش تبلیغات | کاهش ردیابی گزاف گویی ممکن است منجر به شرکت های کوچکتر در اکوسیستم با تکیه بر سایر API های ماسه ای حریم خصوصی مانند ARA برای انجام موارد استفاده از تبلیغات شود. | کاهش ردیابی گزاف گویی برای جلوگیری از دور زدن 3 قطعه در نظر گرفته شده است. ARA یکی از بسیاری از راه حل های اندازه گیری جایگزین است که شرکت ها پس از 3pcd در دسترس خواهند بود ، اما هیچ شرکتی برای استفاده از آن لازم نیست. |
بودجه حریم خصوصی
هیچ بازخوردی در این سه ماه ارائه نشده است.
مرزهای حفظ حریم خصوصی سایت را تقویت کنید
مجموعه های وب سایت مرتبط (مجموعه های شخص اول)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(در فصل های گذشته نیز گزارش شده است) محدوده دامنه مجموعه وب سایت (RWS) | درخواست گسترش تعداد دامنه های مرتبط. | در حال حاضر ، ما انتظار نداریم حد عددی را افزایش دهیم. این حد بر اساس ملاحظات مربوط به حریم خصوصی کاربر ، بازخورد ذینفعان اکوسیستم در W3C و در نظر گرفتن پیاده سازی های قابل مقایسه در سایر مرورگرها ایجاد شده است. برای کسب اطلاعات بیشتر ، لطفاً به پست های وبلاگ ما مراجعه کنید ( 1 ، 2 ). توصیه می کنیم موارد استفاده را که نیاز به دسترسی به کوکی های متقابل در سایت فراتر از حد عددی دارند ، بررسی کنید و از راهنمایی های ما برای استفاده از هویت ، تعبیه های معتبر و موارد استفاده تبلیغاتی استفاده کنید. |
دامنه دسترسی کوکی | این نگرانی که همه حوزه های RWS به خواندن و نوشتن همه کوکی ها از همه حوزه ها دسترسی پیدا کرده اند. | عضویت در RWS باعث نمی شود اعضا بتوانند به کوکی های یکدیگر دسترسی پیدا کنند. در عوض ، این امر به اعضا امکان می دهد تا هنگام تعبیه در سایر سایتهای SOH-RWS (پس از یک دعوت API دسترسی به ذخیره سازی) ، به کوکی های خود دسترسی پیدا کنند. |
(در فصل های گذشته نیز گزارش شده است) ادغام RWS + تراشه ها | درخواست ادغام RWS + Chips به منظور پشتیبانی از موارد استفاده مانند آزمایش A/B | ما در اینجا به درخواست موارد و درخواست های استفاده از این ویژگی ادامه می دهیم. در حال حاضر ، ما نیاز به این ویژگی را در برابر خطرات قابلیت همکاری مرورگر متقاطع داریم. |
استفاده از API | اگر کاربر به صورت دستی سایت ها را از تنظیمات Chrome به صورت محلی خارج کند ، چه می شود؟ | ما در حال حاضر راهی برای کاربر برای حذف دستی یک سایت از یک گروه نداریم. در عوض کاربر می تواند ویژگی "سایتهای مرتبط" را با استفاده از ضامن زیر "بلوک کوکی های شخص ثالث" خاموش کند. یا "مسدود کردن همه کوکی های شخص ثالث" در صفحه جدید تنظیمات حفاظت از ردیابی. |
ارتباط متقابل دامنه | آیا RWS اجازه ارتباط متقابل دامنه را می دهد؟ | ما در حال حاضر یک آزمایش اصلی را برای گسترش دسترسی به برخی از انواع ذخیره سازی نشده (از جمله LocalStorage و کانال پخش) از طریق API دسترسی به ذخیره سازی که این ارتباط را فعال می کند ، انجام می دهیم. این قابلیت در کلیه تنظیمات پشتیبانی شده API دسترسی به ذخیره سازی ، در همان RWS و همچنین در سایت های غیر RWS موجود است. این پست وبلاگ دارای اطلاعات اضافی است. |
درخواست storageaccessfor | آیا document.requeststorageaccessfor (Origin) می تواند وعده ای را که با کوکی های متقابل سایت Origin برطرف می شود ، بازگرداند؟ | ممکن نیست. از آنجا که دعوت از منشأ سطح بالا (که با منشأ تصویب شده به عنوان استدلال متفاوت است) اتفاق می افتد ، انجام این کار باعث نقض همان سیاست مبدا می شود. |
قاب های حصارکشی API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(در فصل های گذشته نیز گزارش شده است) تبلیغات بومی | پشتیبانی قاب حصارکشی برای تبلیغات بومی. | ما قبلاً اظهار داشتیم که برخی از فن آوری های Sandbox حریم خصوصی در آینده برای تقویت بیشتر حمایت های حریم خصوصی مورد نیاز خواهند بود. به عنوان مثال ، برای مخاطبان محافظت شده ، ما نیاز به استفاده از فریم های حصارکشی برای ارائه تبلیغات و انتقال از گزارش در سطح رویداد ، زودتر از سال 2026 داریم. بنابراین صنعت در مورد تکامل در نظر گرفته شده API وضوح دارد. زمان اضافی به ما این امکان را می دهد تا با صنعت برای طراحی و اجرای پشتیبانی از طیف گسترده تری از موارد استفاده مهم ، به کار خود ادامه دهیم. به عنوان مثال ، ما برای حفظ پشتیبانی از تبلیغات ویدیویی و بومی با API مخاطبان محافظت شده ، فریم های حصارکشی را پیش از نیاز آنها در سال 2026+ تکامل خواهیم کرد. طبق تعهدات ما ، CMA در مورد چنین تغییراتی مشورت خواهد شد ، و ما پیش از اجرای الزامات "زودتر از" ، با بازخورد اکوسیستم ادامه خواهیم داد. |
اختلاف اندازه در سکوها | گزارش می دهد که اندازه محتوای نمایش داده شده در قاب حصیری بین دسک تاپ و تلفن های هوشمند متفاوت به نظر می رسد. | ما در حال بررسی این مسئله هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
adcomponent | کدهای نمونه ای را در مورد چگونگی ارائه adcomponsent در قاب حصار ارائه دهید؟ | ما به دنبال ارائه مستنداتی در مورد نحوه استفاده از navigator.adauctioncomponents (numComponents) در داخل قاب حصارکشی خواهیم بود تا تبلیغی را تشکیل دهد که از چندین قطعه تشکیل شده است. |
API را بهبود بخشید | سیگنال های بیشتری را به حصارکشی ارائه دهید (به عنوان مثال ایمنی برند). | ما از این پیشنهاد استقبال می کنیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
API ذخیره سازی مشترک
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
مورد استفاده ضد سوء استفاده / ضد کلاهبرداری | پتانسیل استفاده از ذخیره مشترک برای کلاهبرداری یا تشخیص ناهنجاری. | ما در اینجا درباره این احتمال بحث کردیم و از بازخورد اضافی استقبال کردیم. |
پوشش فرکانس | راهی برای پوشش فرکانس متقابل در خارج از API PA فراهم کنید. | ما از بازخوردی که پوشش فرکانس متقابل سایت در خارج از API PA یک مورد استفاده ارزشمند است ، قدردانی می کنیم. در این زمان ، حریم خصوصی Sandbox روی مجموعه فعلی API های آن برای 3pcd متمرکز است. با این حال ، ما از بازخورد اضافی از اکوسیستم در مورد این مورد استفاده در اینجا استقبال می کنیم. |
چیپس
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
بازشو/تغییر مسیر | چگونه تراشه ها از احراز هویت تعبیه شده پشتیبانی می کنند از مواردی که شامل پاپ آپ و تغییر مسیر است؟ | ما به تازگی راهنمایی هایی را در مورد بررسی تأثیر فاز 3PC در گردش کار ورود شما به اشتراک گذاشتیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
حد پارتیشن | حد کلی در هر مکان را در هر بخش به 1 KIB کاهش دهید. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. ما همچنان به نظارت بر بازخورد ادامه خواهیم داد زیرا همچنان 3pcd را ادامه می دهیم و توسعه دهندگان تراشه ها را اتخاذ می کنند و بازخورد ارائه می دهند. |
مهاجرت کوکی | فرآیند توصیه شده برای مهاجرت یک برنامه وب برای صدور کوکی ها به عنوان پارتیشن بندی که کوکی ها/جلسات مداوم را خراب نمی کند؟ | ما یک طرح بالقوه برای مهاجرت در پاسخ خود در اینجا پیشنهاد کردیم. اما توسعه دهنده قادر به تدوین یک راه حل جایگزین است که برای پیکربندی آنها بهتر کار می کند. |
استفاده از API | آیا دسترسی به ذخیره سازی پارتیشن زمانی غیرفعال است وقتی کاربر از تنظیم API های تبلیغاتی آگهی خودداری نمی کند؟ | کوکی های ذخیره سازی و پارتیشن بندی شده (تراشه ها) حتی اگر کاربر از تنظیم API های تبلیغاتی آگهی خودداری نکند ، فعال می شوند. از آنجا که آنها امکان انتقال اطلاعات در سایت را امکان پذیر نمی کنند. به عنوان یک اصل کلی ، انتقال متقابل اطلاعات در معرض محدودیت ، چک یا انتخاب کاربر قرار خواهد گرفت. اما این در حال حاضر در مورد تراشه ها صدق نمی کند. |
استفاده از API | دلیل این امر در نهایت مسدود کردن کوکی های غیرقابل تحمل چیست ، نه اینکه مرورگر فقط "سکوت" آنها را تقسیم کند؟ | همانطور که در اینجا توضیح داده شده است ، در کوتاه مدت و میان مدت امکان پذیر نیست. |
FedCM
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
استفاده از API | قادر به ارائه "پرونده شناخته شده" در ETLD+1 در محیط توسعه نیست. | ما Chrome Canary را به روز کرده ایم تا از این موضوع که در اینجا مورد بحث قرار گرفته است ، از این امر استفاده کند. |
استفاده از API | آیا نیازهای خاص تعامل کاربر برای درخواست مجوزهای ورود به سیستم شخص ثالث یا استفاده از FEDCM وجود دارد؟ | همانطور که در اینجا بحث شده است ، هیچ الزامات خاص تعامل کاربر وجود ندارد. |
ایمنی API | آیا برنامه ای برای داشتن جریان وجود دارد که به مشتری اجازه می دهد FEDCM را آغاز کند ، اما اساساً نشانه ها از IDP به سیستم باطن RP منتقل می شوند؟ | ما در اینجا بحث می کنیم و از بازخورد اضافی استقبال می کنیم. |
انتخاب | به IDP اجازه دهید تا شناسه مشتری RP را دریافت کند ، بنابراین کاربران می توانند تصمیم بگیرند که آیا به IDP اعتماد دارند یا خیر. | ما در مورد این درخواست بحث می کنیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
استفاده از API | درخواست مستندات بیشتر در FEDCM. | ما این بازخورد را تأیید می کنیم و همچنان که همچنان به توسعه این API ادامه می دهیم ، به بهبود اسناد ادامه خواهیم داد. |
با هرزنامه و کلاهبرداری مبارزه کنید
API Token State Private (و سایر API)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
مستندات | برای کمک به آزمایش ، یک راهنمای توسعه دهنده دقیق در مورد نشانه های ایالت خصوصی درخواست کنید. | ما یک راهنمای توسعه دهنده برای نشانه های دولتی خصوصی را در Q4 2023 منتشر کرده ایم. |
سن/تأیید جنسیت | تأیید "سن و جنسیت" تأیید مخاطبان پس از 3pcd. | توکن های ایالتی خصوصی در حال حاضر برای تأیید سن و جنس طراحی نشده است. ما به دنبال این هستیم که پرونده استفاده را بهتر درک کنیم ، و چگونه این کار امروز انجام می شود و از بازخورد اضافی استقبال می کنیم. |