گزارش فصلی برای سه ماهه اول 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 به بازخورد از پرسشهای متداول منتشر شده، پاسخهای واقعی به مسائل مطرحشده توسط ذینفعان و تعیین موقعیت بهویژه برای اهداف این گزارش گزارش عمومی ایجاد شده است. با توجه به تمرکز فعلی توسعه و آزمایش، سؤالات و بازخوردها به ویژه در رابطه با موضوعات، FLEDGE و APIهای گزارش انتساب دریافت شد.
بازخورد دریافت شده پس از پایان دوره گزارش فعلی ممکن است هنوز پاسخی در نظر گرفته شده برای Chrome نداشته باشد.
واژه نامه کلمات اختصاری
- چیپس
- کوکی هایی که دارای حالت تقسیم شده مستقل هستند
- DSP
- پلتفرم سمت تقاضا
- FedCM
- مدیریت اعتبار فدرال
- FPS
- مجموعه های مهمانی اول
- IAB
- دفتر تبلیغات تعاملی
- بیجاشدگان داخلی
- ارائه دهنده هویت
- IETF
- کارگروه مهندسی اینترنت
- IP
- آدرس پروتکل اینترنت
- openRTB
- مناقصه در زمان واقعی
- OT
- آزمایش مبدا
- PatCG
- گروه اجتماعی فناوری تبلیغات خصوصی
- RP
- حزب اتکا
- SSP
- پلت فرم سمت عرضه
- TEE
- محیط اجرای مورد اعتماد
- UA
- رشته عامل کاربر
- UA-CH
- نکات مشتری عامل کاربر
- W3C
- کنسرسیوم وب جهانی
- WIPB
- کوری IP ارادی
بازخورد عمومی، بدون API/فناوری خاصی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تست و آزمایش | ارتباط آزمایش برای اطلاع از ارزیابی CMA در صورتی که APIهای Sandbox Privacy تا زمان شروع آزمایش تکمیل نشده باشند. | توسعه APIهای Sandbox Privacy با سرعت در حال پیشرفت است. آنها در حال حاضر در Origin Trial برای آزمایش در دسترس هستند و به طور کلی برای 100٪ ترافیک تابستان امسال در دسترس خواهند بود. علاوه بر این، ما جدول زمانی برای ویژگیهای خاص (مانند گزارشدهی در سطح رویداد FLEDGE، رندر FLEDGE با iframes) را مشخص کردهایم که زودتر از سال 2026 تحت تأثیر قرار نخواهند گرفت. ما اکوسیستم را تشویق میکنیم تا APIها را آزمایش کند و بر اساس آنچه آزمایشکنندگان انتظار دارند پس از منسوخ شدن کوکیهای شخص ثالث به آن تکیه کنند، به CMA بازخورد ارائه کند. این می تواند به ارزیابی آنها از تأثیر احتمالی از بین رفتن کوکی های شخص ثالث کمک کند. |
کنترل های کاربر | راهنمایی واضح برای اکوسیستم در مورد پیامدهای کنترل کاربر مربوط به APIهای Privacy Sandbox | ما نمیتوانیم در مورد کنترلهای کاربر که اکوسیستم میتواند استفاده کند، مشاوره حقوقی ارائه کنیم. در همان زمان، Chrome به عنوان بخشی از تلاش مداوم ما برای بهبود فناوریهای جعبه ایمنی حریم خصوصی (Privacy Sandbox) بهعنوان بخشی از تلاشهای مداوم ما، در حال آزمایش کنترلهای کاربر بهروزرسانیشده «حریم خصوصی آگهی» («حریم خصوصی پیشرفته آگهی») به درصد بسیار کمی از کاربران است. بهروزرسانیها شامل زبان و طرحبندی واضحتر و مفیدتر است. هنگامی که Chrome این اصلاحات را ارزیابی کرد و تصمیم گرفت که آیا آنها را به جمعیت بیشتری گسترش دهد، میتواند اطلاعات بیشتری را با اکوسیستم به اشتراک بگذارد. |
نشت داده ها | در صورتی که مرورگر به خطر بیفتد، خطر نشت داده های شخص اول به Google و سایر طرف ها وجود دارد | توضیحدهنده FLEDGE ما به وضوح نشان میدهد که دادههای یک فناوری تبلیغاتی فقط با همان فناوری تبلیغاتی (چه با مجموعههای کاری یا سرورهای مورد اعتماد آنها) به اشتراک گذاشته میشود یا زمانی که به صراحت توسط آن فناوری تبلیغات به اشتراک گذاشته میشود (مانند خریدار نشانی اینترنتی آگهی را که میخواهد نمایش دهد به فروشنده نشان میدهد). تنها استثنا این است که بررسی ناشناس بودن k باید توسط یک سرور متمرکز جهانی انجام شود، که منطقه ای است که ما همچنان منابع قابل توجهی را به آن اختصاص می دهیم. برای مشاهده دقیق نحوه تفکر ما در مورد حریم خصوصی، به توضیح K-anonymity مراجعه کنید. فراتر از آن، ما آماده ارائه جزئیات بیشتر در مورد نحوه عملکرد حفاظتهای فناوری تبلیغاتی به کار رفته در طراحی سرور k-anonymity هستیم. |
انجمن اضافی برای بحث | درخواست یک انجمن اضافی به W3C برای بازیکنان اکوسیستم غیر فنی برای به اشتراک گذاشتن بازخورد | فرم بازخورد جعبه ایمنی حریم خصوصی برای نظرات عمومی و خاص، فنی و غیر فنی مناسب است. گروه تجاری بهبود وب تبلیغاتی، انجمنی برای گفتگو از طریق تماس های هفتگی و مخزن GitHub است. صفحه بازخورد جعبه ایمنی حریم خصوصی مکانیسم های دیگری را برای ارائه بازخورد و مشارکت در بحث توضیح می دهد. Chrome همچنین به برگزاری رویدادهایی مانند ساعات اداری عمومی برای تسهیل سوالات و اشتراکگذاری محتوا ادامه میدهد. علاوه بر این، Chrome در سه ماهه گذشته میزبان بیش از دوازده رویداد صنعتی بوده یا در آن شرکت کرده است. |
شفاف سازی جدول زمانی | توضیح در مورد تاریخ دقیق در دسترس بودن عمومی در سه ماهه سوم 2023 | طبق جدول زمانی منتشر شده در PrivacySandbox.com ، در دسترس بودن عمومی قرار است با انتشار نسخه 115 کروم عرضه شود. |
reCAPTCHA | تأثیر APIهای Sandbox برای موارد استفاده از تشخیص هرزنامه reCATPCHA | ما بهطور دورهای از reCAPTCHA بازخورد دریافت میکنیم تا مطمئن شویم که پیشنهادات جعبه ایمنی حریم خصوصی تأثیر قابلتوجهی بر امنیت وب یا تقلب نمیگذارد. آنها در حال توسعه طرح خود برای آماده سازی و تنظیم برای حذف کوکی های شخص ثالث هستند، بنابراین این سوال به بهترین وجه توسط آنها مطرح می شود. |
برنامه های افزودنی کروم | آیا فناوریهای جعبه ایمنی حریم خصوصی مانند اقدامات ضد ردیابی پنهان (ACT) برای برنامههای افزودنی Chrome اعمال میشوند؟ | ما هیچ اطلاعیهای در مورد اینکه آیا ACT ممکن است برای برنامههای افزودنی Chrome اعمال شود، ندادهایم. با این حال، اگر یک فناوری به طور مخفیانه اطلاعات یک کاربر را جمعآوری کند، این با اصول حفظ حریم خصوصی ما همخوانی ندارد. |
نمایش محتوا و تبلیغات مرتبط
موضوعات
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
بررسی طراحی تگ | TAG Early Design Review of Topics را منتشر کرد. | ما به موضوعات متعهد هستیم و بهروزرسانی تعهد خود را در صفحه آخرین بهروزرسانیها و در این شماره به اشتراک گذاشتهایم. ما نقطه به نقطه به بررسی TAG پاسخ دادیم و دیدگاه سطح بالاتر خود را در اینجا به اشتراک گذاشتیم. Topics API بخشی از مجموعه APIهایی خواهد بود که اکوسیستم تبلیغات باید در طول سال 2023 آزمایش کند - و ما امیدواریم که بازخورد آزمایشی که می شنویم و تجربه پیاده کننده ای که به دست می آوریم کمک های ارزشمندی در تلاش های آینده در راستای استانداردهای بین مرورگرها در این فضا باشد. ما مشتاقانه منتظر ادامه تعامل با اکوسیستم در مورد چگونگی تسهیل انتقال احتمالی هستیم که در آن Topics API می تواند استاندارد مورد توافق با سازگاری بین مرورگرها باشد. |
رویکرد به موضوعات | پشتیبانی از رویکرد باز Chrome برای توسعه Topics API | ما از این احساسات قدردانی می کنیم و مشتاقانه منتظر ادامه همکاری با گروه صنعتی برای ایجاد یک Topics API هستیم که به طور کلی برای اکوسیستم ارزش ارائه می کند. |
(همچنین در سه ماهه سوم 2022 گزارش شده است) موضوعات طبقه بندی به اندازه کافی دانه بندی نشده است | تاکسونومی موضوعات گسترده شامل موضوعات جزئی تر، از جمله منطقه خاص نیست. | به روز رسانی Q1: بهبود طبقهبندی تلاشی مداوم است و در سه ماهه دوم یک طبقهبندی بهروزرسانی شده برای Topics API اعلام خواهیم کرد. برای ایجاد این طبقهبندی جدید، با شرکتهایی از سراسر اکوسیستم همکاری نزدیک داشتیم. ما فعالانه به دنبال بازخورد در مورد طبقه بندی هستیم که برای اکوسیستم مفیدتر است. در ارزیابی اینکه آیا باید تعداد موضوعات را گسترش داد یا موضوعات جزئیتر را شامل میشود، چند ملاحظه وجود دارد، از جمله 1) پیامدهای بالقوه حریم خصوصی (موضوعات بیشتر ممکن است خطر اثر انگشت را معرفی کند) و 2) توانایی بازیابی موضوعات مشاهده شده قبلی (مانند موضوعات بیشتر، ممکن است شانس کمتری وجود داشته باشد که یک فناوری تبلیغات موضوع انتخابی را در گذشته دیده باشد). |
(همچنین در سه ماهه چهارم 2022 گزارش شده است) تاثیر بر سیگنال های شخص اول | سیگنال موضوعات ممکن است بسیار ارزشمند باشد و در نتیجه سایر سیگنالهای مبتنی بر علاقه شخص اول را کاهش دهد. | ما معتقدیم تبلیغات مبتنی بر علاقه یک مورد استفاده مهم برای وب است و Topics برای پشتیبانی از این مورد طراحی شده است. ما میدانیم که برخی از ناشران بزرگ نگران هستند که موضوعات تأثیر منفی بر استراتژیهای داده شخص اول آنها بگذارد. ما مشتاقانه منتظر آزمایش اکوسیستم هستیم که اطلاعاتی در مورد تأثیر موضوعات بر ناشران ارائه می دهد. |
موارد استفاده از موضوعات غیر مرتبط با تبلیغات | استفاده از موضوعات برای اهدافی غیر از نمایش تبلیغات مبتنی بر علاقه | موضوعات برای رسیدگی به موارد استفاده تبلیغات مبتنی بر علاقه طراحی شده است، که ما معتقدیم یک مورد استفاده حیاتی برای وب آزاد و باز است. ما در حال حاضر به دنبال بازخورد در مورد موارد استفاده دیگر هستیم و در حال ارزیابی هستیم. |
وضعیت انتخاب پیش فرض | قوانین منطقهای برای پیشفرض رضایت موضوعات تأثیر میگذارد | این موضع ما نیست که در مورد نظرات حقوقی اظهار نظر کنیم. |
(همچنین در سه ماهه سوم 2022 گزارش شده است) سایت های دسته بندی اشتباه | زمانی که موضوعات برای یک سایت مشخص به اشتباه دسته بندی می شوند، تبلیغات را هدف قرار می دهد | به روز رسانی Q1: در سه ماهه دوم یک طبقهبندی بهروزرسانی شده برای Topics API اعلام خواهیم کرد و مشتاقانه منتظر تعامل با اکوسیستم در آن هستیم. در پاسخ به بازخورد فعلی، سایتها از طریق ترکیبی از فهرست نادیده گرفته شده توسط انسان، حاوی محبوبترین سایتها و یک مدل ML روی دستگاه طبقهبندی میشوند. Chrome به ارزیابی گزینههای سایتها برای مشارکت در طبقهبندی موضوعات ادامه میدهد. هر گونه بهبود ابزار باید با خطرات حریم خصوصی و سوء استفاده سنجیده شود. برای مثال، تعدادی از خطرات عبارتند از: سایتهایی که از خود برچسبگذاری به عنوان روشی برای رمزگذاری معانی مختلف (و بالقوه حساس) در موضوعات استفاده میکنند. سایت هایی که موضوعات خود را برای منافع مالی نادرست معرفی می کنند. سایتهایی که به موضوعات حمله میکنند تا مفید بودن آن را برای دیگران کمرنگ کنند (به عنوان مثال ارسال هرزنامه به موضوعات کاربر با نویز بیمعنی). عموم می توانند این اجزا را با ابزارهای موجود از طریق chrome://topics-internals یا این colab بازرسی کنند. از طریق آزمایش، ما انتظار داریم که طبقه بندی در طول زمان بهبود یابد و از بازخورد نمونه هایی از سایت هایی که ممکن است به اشتباه طبقه بندی شوند استقبال می کنیم . |
دسته بندی موضوعات | درخواست برای بازگرداندن اطلاعات اضافی که دلایل بازگرداندن «بدون موضوع» به تماسگیرنده را برای اهداف اشکالزدایی نشان میدهد. | ما درک می کنیم و قدردانی می کنیم که ابزارهای اشکال زدایی برای توسعه دهندگان مفید هستند، زیرا آنها برای ادغام Topics API در سیستم های خود کار می کنند. با این حال، با افشای اطلاعات اضافی (مانند دلیل برگرداندن هیچ موضوعی)، ممکن است ناخواسته اطلاعاتی را به اشتراک بگذاریم که به طرفین امکان می دهد جزئیات بیشتری را کشف کنند (مثلاً اگر کاربر در حالت ناشناس است، API را غیرفعال کرده باشد، و غیره) فراتر از آنچه در نظر گرفته شده است، به حریم خصوصی کاربر آسیب می رساند. در حالی که در حال حاضر قصد نداریم ابزارهای رفع اشکال اضافی را ارائه کنیم، اما در مورد اینکه کدام ابزار ارزشمند است، بازخورد داریم. |
بازیابی اطلاعات خصوصی (PIR) | درخواست برای موضوعات API برای اتخاذ بازیابی اطلاعات خصوصی | ما قبلاً با استفاده از PIR بررسی کردهایم و مبادلات را در اینجا به اشتراک گذاشتهایم . |
جریان پیشنهاد | آیا موضوعات به طور مجزا از مخاطبان تعریف شده فروشنده در پیشنهاد قیمت نشان داده می شوند؟ | Topics API یک پیشنهاد Privacy Sandbox است که توسط Chrome ایجاد شده است که از پیشنهاد مخاطبان تعریف شده توسط فروشنده IAB Tech Lab متمایز است. ما انتظار داریم که این دو به طور مشخص در جریان مناقصه حضور داشته باشند. بیاموزید که چگونه موضوعات در درخواستهای پیشنهادی OpenRTB نشان داده میشوند. |
API مخاطب محافظت شده (FLEDGE سابق)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
در دسترس بودن ویژگی FLEDGE | روشنسازی جدولهای زمانی آزمایش و پیادهسازی ویژگیهای FLEDGE مانند اجرای Fenced Frame، K-Anonymity و غیره. | ما وضعیت را در مورد ویژگی های مختلف FLEDGE با محدوده و زمان پشتیبانی به اشتراک گذاشته ایم. با ادامه توسعه FLEDGE، از بازخورد اضافی در مورد اعلامیه استقبال می کنیم. |
محدودیت های ارائه محصول | درخواست کاهش تبلیغات شامل محدودیتهای چندتایی برای قابهای حصاردار FLEDGE | همانطور که در فوریه اعلام کردیم، استفاده از قابهای حصاردار حداقل تا سال 2026 اختیاری خواهد بود و رفتار iframes توسط urn-iframes پشتیبانی میشود. ما از بحث بیشتر در مورد این موضوع استقبال می کنیم. |
مسائل مقیاس پذیری | عملکرد FLEDGE به عنوان مقیاس های استفاده | ما فعالانه بازخوردها را دنبال میکنیم و زمینه بیشتری را درک میکنیم تا بتوانیم راهحلهای عملی را پیشنهاد کنیم. اولین قدم این بود که بازخوردها را به دو دسته تقسیم کنیم که این کار را انجام دادیم:
|
(همچنین در سه ماهه سوم 2022 گزارش شده است) قابل مشاهده بودن منطق مناقصه | نگرانی از اینکه منطق مناقصه DSP در جاوا اسکریپت نمایش داده شود | به روز رسانی Q1: ما پیشنهادی را به اشتراک گذاشتهایم که توانایی دشمنان را برای درخواست داده از سرور به روش اکتشافی (مرور اجباری) محدود میکند و از بازیکنان اکوسیستم استقبال میکنیم تا بازخورد یا حمایت خود را از این پیشنهاد به اشتراک بگذارند. |
مشکلات تست | توانایی DSPهای کوچکتر برای آزمایش صحیح FLEDGE و کاهش خطر این که تبلیغ کنندگان فقط علاقه مند به آزمایش با DSPهای بزرگتر باشند. | ما متعهد به کار با DSPهای کوچکتر هستیم و به شدت تشویق میکنیم که آزمایشهای گستردهای را در میان DSPها و تبلیغکنندگان در همه اندازهها انجام دهیم، زیرا FLEDGE به سمت دسترسی عمومی حرکت میکند. ما علاقه مندیم که بشنویم که چگونه می توانیم به بهترین وجه آنها را در آزمایش FLEDGE با دیگران در اکوسیستم کمک کنیم و از ایده ها و تلاش های صنعت برای ایجاد انگیزه در تبلیغ کنندگان برای آزمایش با DSP های کوچکتر استقبال کنیم. |
بازاریابی مجدد پویا | آیا بازاریابی مجدد پویا همچنان با منسوخ شدن کوکی های شخص ثالث پست FLEDGE امکان پذیر خواهد بود؟ | ما در حال بررسی پاسخی به این سوال هستیم و از بازیکنان اکوسیستم استقبال می کنیم تا بینش بیشتری در مورد نحوه استفاده از بازاریابی مجدد پویا به اشتراک بگذارند. |
کلاهبرداری/سوءاستفاده | چگونه اکوسیستم می تواند خطرات را کاهش دهد و بازیگران یا خریداران بد را از قرار دادن خود به عنوان یک مخاطب مطلوب باز دارد؟ | ما مشتاقانه منتظر تعامل بیشتر با بازیگران اکوسیستم در مورد کلاهبرداری و سوء استفاده هستیم و از بازخوردهای بیشتری در این زمینه استقبال می کنیم. |
تنظیمات برگزیده کاربر | فرآیند ذخیره تنظیمات برگزیده کاربر و استفاده در انتخاب آگهی | برای تبلیغات خاص، فناوری تبلیغات مربوطه، طرفی است که بهترین موقعیت را دارد تا کنترلهایی را در مورد اینکه کدام خلاقیتها نشان داده میشوند یا نحوه انتخاب آنها ارائه میکند. |
پیشنهاد تست کمی | برای اینکه تست کمی منصفانه باشد، آیا باید این آزمایش در ترافیک بدون کوکی های شخص ثالث انجام شود یا با SSP هایی که فقط از FLEDGE استفاده می کنند؟ چگونه می توان از اختلاط سیگنال های کوکی های شخص ثالث جلوگیری کرد؟ | ما از این بازخورد قدردانی میکنیم و با CMA برای طراحی آزمایشهایی کار میکنیم که تصویر قابلاعتمادی از تأثیر حذف کوکیهای شخص ثالث و معرفی پیشنهادات جعبه ایمنی حریم خصوصی بر روی اکوسیستم ارائه میدهند. ما پیشنهاد می کنیم بازخورد اضافی در مورد پیشنهاد آزمایش کمی CMA به طور مستقیم با CMA به اشتراک گذاشته شود. |
مستندات واضح تر | درخواست اسناد واضح تر در مورد پیکربندی حراج | امیدواریم در هفتههای آینده یک پست وبلاگ با مروری بیشتر در مورد گزارش حراج FLEDGE به اشتراک بگذاریم. |
موازی سازی | آیا خدمات مناقصه و مزایده (B&A) از موازی سازی پشتیبانی می کند؟ | یک فناوری تبلیغاتی با استفاده از سرورهای Bidding / Auction می تواند چندین سرور را راه اندازی کند که می توانند نتایج را به صورت موازی ارائه دهند. |
کاهش سوء استفاده | آیا سرور FLEDGE k-anonymity با استفاده از رمزهای دولتی خصوصی برای اطمینان از حریم خصوصی کاربر کافی است؟ | انگیزه برای K-ناشناس بودن کمتر بر روی هدف گذاری کوچک متمرکز است و بیشتر بر روی داشتن پشتیبان در مرحله میانی که در آن FLEDGE اجازه گزارش در سطح رویداد را می دهد متمرکز است. ما افکار بیشتری را به اشتراک گذاشته ایم و از بازخورد اضافی استقبال می کنیم . |
تضاد ماژول ES | درخواست حذف generateBid به عنوان یک تابع سراسری زیرا با ماژول ES در تضاد است | ما در حال بحث در مورد این درخواست هستیم و از بازخورد اضافی استقبال می کنیم. |
حراج قطعات | درخواست از ناشران برای کنترل بیشتر بر طرح های حراج | مناقصه و طرح حراج برای پشتیبانی از حراج مؤلفه، مانند Chrome در دستگاه. |
جدول زمانی B&A | شفافیت در جدول زمانی برای فناوری های تبلیغاتی علاقه مند به آزمایش سرورهای B&A | ما بهتازگی B&A Explainer را بهروزرسانی کردیم و بخش Timeline را بهروزرسانی کردیم تا پس از همراستایی با CMA، تعاریف واضحی از جدولهای زمانی برای مراحل مختلف آزمایش Chrome-B&A داشته باشد. |
طرح کنترل تایم اوت | بهبود طرح کنترل مهلت زمانی که در حال حاضر برای FLEDGE در دسترس است | این یک پیشنهاد جالب است. ما این را به صف پیشنهادات برای مطالعه و گزارش تحولات خود اضافه خواهیم کرد. |
جریان های پیشنهادی خلاقانه | امکان بررسی، و فیلتر کردن یک پیشنهاد برنده، بر اساس خلاقیت | این یک پیشنهاد جالب است. ما این را به صف پیشنهادات برای مطالعه و گزارش تحولات خود اضافه خواهیم کرد. |
reportWin | پیشنهاد برای ارائه اطلاعات اضافی در مورد پیشنهاد بالاترین امتیاز از مالک گروه ذینفع متفاوت غیر از برنده در تابع reportWin | این یک پیشنهاد جالب است. ما افزودن سیگنال های اضافی را در گزارش انبوه در نظر خواهیم گرفت و از بازخورد اضافی در اینجا استقبال می کنیم . |
انواع رویداد | استاندارد کردن انواع رویداد در میان APIهای اندازه گیری در صورت ادغام با FLEDGE | این یک پیشنهاد جالب است. ما این را به صف پیشنهادات برای مطالعه و گزارش تحولات خود اضافه خواهیم کرد. این امر مستلزم هماهنگی با تلاشهای گستردهتر ما در این زمینه است، زیرا بر دیگر APIهای Privacy Sandbox فراتر از FLEDGE تأثیر میگذارد. ما از بازخورد اضافی در اینجا استقبال می کنیم . |
راه حل های بلند مدت برای گزارش در سطح رویداد | علاقه به در دسترس نگه داشتن دادههای خاص مانند highestScoringOtherBid حتی پس از منسوخ شدن کوکیهای شخص ثالث | همانطور که در پست وبلاگ فوریه به اشتراک گذاشتیم، گزارش برنده حراج در سطح رویداد تا "حداقل سال 2026" پشتیبانی خواهد شد. ما در حال حاضر جزئیات بیشتری برای به اشتراک گذاشتن نداریم، اما از بازخورد اضافی در مورد اینکه چرا مهم است برخی دادهها پس از منسوخ شدن کوکی شخص ثالث در دسترس باقی بماند، استقبال میکنیم. |
محدودیت گروه های علاقه مند | محدودیت تعداد گروههای علاقهای که یک منبع میتواند یک مرورگر را به آن اضافه کند چقدر است؟ | Chrome به هر مالک حداکثر 1000 گروه علاقه و حداکثر 1000 مالک گروه علاقه را می دهد. اینها قرار است نرده های محافظ باشند، نه اینکه در عملیات منظم مورد ضربه قرار گیرند. |
سیگنال های سطح رویداد | پشتیبانی از یک پیشنهاد برای داشتن سیگنالهای سطح رویداد برای generateBid و reportWin ، که میتواند در آموزش یادگیری ماشین استفاده شود. | ما تصمیم خود را برای سیگنال های طراحی شده توسط مرورگر و سیگنال های تعریف شده با فناوری تبلیغاتی در اینجا به اشتراک گذاشته ایم و از بازخورد اضافی استقبال می کنیم. |
اسکریپت مناقصه | شناسه کاربری را در URL اسکریپت مناقصه قرار دهید. | این امکان پذیر نخواهد بود زیرا FLEDGE دارای شرایط اضافی است که چند نفر از مالک گروه علاقه مند، URL اسکریپت پیشنهادی و خلاقیت ارائه شده باید k-ناشناس باشند تا یک تبلیغ نمایش داده شود. |
اجرای K-anon | آیا ناشناس بودن k بر روی جفت (componentAd، اندازه) اعمال می شود؟ | بله، خواهد شد. رجوع به turtledove/issues/312 شود . |
الزامات مناقصه و خدمات مزایده | خدمات B&A چگونه از مشارکتکنندگان در ادغام با FLEDGE روی دستگاه و دیگران با خدمات B&A پشتیبانی میکند؟ | ما هنوز در حال نهایی کردن طراحی هستیم و از بازخورد اضافی در اینجا استقبال می کنیم . |
انتساب پس از مشاهده | آیا انتساب Post-view پشتیبانی خواهد شد؟ | در حال حاضر ما هیچ نوع تعریف استانداردی از قابلیت مشاهده نداریم و برای علامت گذاری یک رویداد مشاهده به خود خلاقیت تکیه می کنیم. رجوع به turtledove/issues/452 شود . |
هدف گذاری شبیه | آیا جعبه ایمنی حریم خصوصی می تواند از "هدف گیری شبیه به نظر" پشتیبانی کند؟ | ما در اینجا در مورد مورد استفاده بحث می کنیم و از ورودی های اضافی استقبال می کنیم. |
API نظارت در زمان واقعی | پیشنهاد برای یک رویکرد نظارت بر زمان واقعی FLEDGE | ما در حال بحث در مورد این پیشنهاد هستیم و از ورودی های اضافی در اینجا استقبال می کنیم . |
گزارش FLEDGE | reportWin و reportResult باید به ترتیب تصادفی ساخته شوند تا از گزارش دهی بیش از حد یا کمتر از آن جلوگیری شود. | reportResult() باید ابتدا توسط فروشنده قبل از reportWin() توسط خریدار اجرا شود تا سیگنالهای فروشنده از reportResult() در reportWin() گنجانده شود. برای اطلاعات بیشتر به توضیح دهنده مراجعه کنید. |
سرورهای ارزش کلید سفارشی (K/V). | آیا سرورهای سفارشی K/V در آینده پشتیبانی خواهند شد؟ | ما در اینجا در حال بحث درباره این سوال هستیم و از هرگونه ورودی اضافی استقبال می کنیم. |
حراج سطح بالا | آیا برای اجرای مکانیک های حراج سطح بالا باید سرور تبلیغات باشد؟ | FLEDGE API مشخص نمی کند که کدام طرف باید آن را فراخوانی کند. هیچ الزامی از این نظر در طراحی FLEDGE وجود ندارد. هر کسی می تواند حراج FLEDGE (از جمله حراج های چند فروشنده) را اجرا کند. همانطور که در گزارش Q4 2022 ذکر شد، FLEDGE به هر ناشر اجازه می دهد ساختار حراج را انتخاب کند، از جمله انتخاب فروشندگان سطح بالا و قطعات. |
دامنه API | آیا FLEDGE قصد دارد با داده های شخص اول کار کند؟ | ما محتوا را در سه ماهه دوم سال 2023 منتشر خواهیم کرد و روشن می کنیم که داده های شخص اول واقعاً با FLEDGE قابل استفاده هستند، 1) استفاده به عنوان منطق برای تعیین عضویت در گروه ذینفع و 2) برای تغذیه به عنوان سیگنال پیشنهاد کاربر برای استفاده در تولید منطق مناقصه بعدی. |
گروه های ذینفع بین دامنه ای | امکان ایجاد گروه های منافع متقابل | هر اطلاعاتی که در زمان افزودن مرورگر به یک گروه علاقه مند وجود دارد می تواند برای اطلاع رسانی به آن مخاطب استفاده شود. وقتی کوکیهای شخص ثالث حذف شوند، در دسترس بودن دادههای بینسایتی برای اطلاعرسانی ایجاد گروههای ذینفع محدود میشود. |
منطق مناقصه سمت مشتری | انتقال منطق پیشنهادی سمت سرور موجود به سمت مشتری | ما علاقه مندیم در مورد مناطقی که در فرآیند انتقال چالش برانگیز هستند یا در حال حاضر فاقد آن هستند اطلاعات بیشتری کسب کنیم و از هرگونه بازخورد یا بینش اضافی استقبال می کنیم . |
مقادیر سرور K/V | آیا مقادیر سرور K/V باید از نوع رشته باشند؟ | مقدار باید یک رشته باشد، اما آنها می توانند اشیاء را در JSON یا بافر پروتکل ذخیره کرده و آنها را به رشته تبدیل کنند. |
فهرست مسدودکننده آگهیدهنده | کدام سیگنال برای ارائه یک خریدار برای فهرست مسدودکننده تبلیغکننده مناسب است؟ | مکان مناسب یا در auctionSignals یا در perBuyerSignals است. |
واحد مناقصه | پشتیبانی از واحدهای مناقصه مختلف مانند CPI و CPM | مایلیم در مورد اینکه چرا این مورد با توجه به طراحی فعلی نیاز است بیشتر بدانیم و دوست داریم بازخورد بیشتری بشنویم. |
منطق حراج | آیا مرورگر یا سرور تبلیغات برنده حراج را تعیین می کند؟ | تمام انتخاب های برنده در داخل جعبه شنی اجرا می شود و تمام تصمیمات توسط کد فروشنده گرفته می شود. مرورگر به سادگی یک محیط خصوصی و مهر و موم شده را فراهم می کند که کد خریدار و فروشنده در آن اجرا می شود. |
مجوزها - سیاست | آیا پس از پایان دوره آزمایشی مبدا، سیاست مجوزهای FLEDGE فعلی همچنان اجرا می شود؟ | برای Origin Trial، لیستهای مجاز پیشفرض فعلی هر دو ویژگی موقتی هستند و تغییر خواهند کرد. ما علاقه مندیم قبل از اینکه شروع به اعمال تغییر کنیم، بشنویم که فنآوریهای تبلیغاتی چه مدت برای آماده شدن برای تغییر نیاز دارند. |
محدودیت اندازه سیگنال | درخواستهای Trusted Bidding Signals در گروههای ذینفع متعدد با همان trustedBiddingSignalsUrl ادغام میشوند. محدودیت اندازه 2 مگابایت یک محدودیت است. | این محدودیت برای تماس گیرندگان روی دستگاه وجود دارد تا از افزایش منابع روی دستگاه جلوگیری کند. تماس گیرندگان از یک سرور B&A محدودیت راحت تری خواهند داشت. |
سیگنال های گزارش | یک سیگنال اضافی، خطاهای اسکریپت، اضافه کنید تا امکان بازیابی تعداد خطاهای سمت کلاینت به ازای هر مالک گروه ذینفع و هر computeBid یا reportWin / reportResult فراهم شود. | ما در حال بررسی نگرانیهای بالقوه حریم خصوصی در مورد این پیشنهاد هستیم و از بازیکنان اکوسیستم استقبال میکنیم تا بینشهای بیشتری در مورد اینکه چرا این مورد نیاز است به اشتراک بگذارند. |
اندازه پنجره K-Anon | اندازه پنجره K-Anon را از محدودیت 7 روزه فعلی افزایش دهید. | این در حال بررسی است و ما در حال حاضر منتظر (و استقبال) ورودی اضافی از اکوسیستم هستیم. |
عملکرد دستگاه | اگر کاربر در تعداد زیادی از گروههای علاقهمند باشد، FLEDGE چگونه عملکرد دستگاه را کنترل میکند؟ | FLEDGE چندین گزینه زمانبندی، اولویتبندی و محدودیت را در بین SSPها و DSPها ارائه میدهد که در شرایطی که عملکرد دستگاه ممکن است یکی از دلایل محدود کردن مشارکت در حراج باشد، وقتی دستگاه در تعداد زیادی از گروههای علاقهمند است، به فناوری تبلیغات کنترل دقیقی میدهد. |
تست خدمات B&A | درخواست از بازیکنان اکوسیستم برای استفاده از سرور خود در مرحله آزمایش به منظور داشتن گزارشهای بیشتر برای اشکالزدایی | B&A به کاربران اجازه می دهد تا سرورها را از ارائه دهندگان ابری تایید شده راه اندازی و مقیاس کنند. برای حفظ حریم خصوصی کاربر، اجرا را مجبور میکنیم که در یک محیط اجرای قابل اعتماد (TEE) انجام شود. ما به زودی توضیحی در مورد اشکال زدایی B&A TEE منتشر می کنیم و در حال توسعه ویژگی هایی برای پشتیبانی از آن هستیم. ما به دنبال بازخورد اضافی در مورد موضوع هستیم. |
الزامات نظارتی | آیا FLEDGE با ارائه دهندگان ابر در کشورهای مختلف برای حمایت از انطباق با الزامات قانونی محلی کار خواهد کرد؟ | ما همیشه آماده پیشنهادات برای سایر ارائه دهندگان ابری هستیم، اما در حال حاضر در حال برنامه ریزی حداقل برای پشتیبانی از GCP و AWS در زمانی که منسوخ شدن کوکی های شخص ثالث اعمال می شود، هستیم. برای اطلاعات بیشتر به این توضیح دهنده مراجعه کنید. |
اندازه گیری تبلیغات دیجیتال
گزارش انتساب (و سایر APIها)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تجزیه و تحلیل داده های تاثیر نویز | راهنمایی در مورد نحوه انجام تجزیه و تحلیل داده ها در مورد تأثیر نویز | ما اسناد اضافی در مورد نویز و نویز و تصمیمات طراحی را به اشتراک گذاشته ایم که می توان از آنها برای تغییر تأثیر نویز بر داده های فناوری تبلیغات استفاده کرد. راهنمای دقیق تری نیز موجود است. |
گزارش تهی | شفافیت در اجرای گزارش های پوچ | ما در حال حاضر روی پیشنهادی برای اجرای گزارش های پوچ کار می کنیم و به زودی جزئیات بیشتری برای به اشتراک گذاشتن خواهیم داشت. اجرای گزارشهای پوچ به ما امکان میدهد تا تاخیرهای گزارش را بدون به خطر انداختن حریم خصوصی کاهش دهیم . |
سطح نویز | تنظیم سطح نویز بر اساس طول پنجره انتساب | ما از این پیشنهاد استقبال می کنیم و به دنبال اضافه کردن آن به مشخصات هستیم. ما از بازخورد اضافی در اینجا استقبال می کنیم. |
اندازه داده را فعال کنید | چرا اندازه داده های ماشه به 3 بیت محدود شده است؟ | اندازه به 3 بیت و 8 مقدار متمایز محدود شده است تا اطمینان حاصل شود که مقدار اطلاعات متقابل سایت/متن در مورد کاربر محدود است. ما از بازیکنان اکوسیستم استقبال می کنیم تا بازخورد خود را در مورد اینکه آیا پارامترسازی فعلی برای گزارش در سطح رویداد منطقی است یا خیر ارائه دهند . |
محرک های گزارش دهی در سطح رویداد | امکان اولویت بندی در یک کلید حذف مجدد | ما در حال بررسی راه حل هایی برای این مشکل هستیم و از ورودی های اضافی استقبال می کنیم. |
پشتیبانی از اشکال زدایی | وضوح اشکال زدایی پس از منسوخ شدن کوکی های شخص ثالث | ما میخواهیم از اشکالزدایی پس از منسوخ شدن کوکیهای شخص ثالث پشتیبانی کنیم و در حال بررسی گزینهها هستیم. ما به دنبال بازخورد و ایده های اضافی هستیم. |
از طریق گزینه های تبدیل کلیک کنید | درخواست راهنمایی بیشتر در مورد گزینه های جایگزین برای تبدیل کلیک کنید | ما اکوسیستم را تشویق میکنیم تا از API گزارش اسناد بهعنوان یک سیستم اندازهگیری خصوصی بادوام برای موارد استفاده اندازهگیری تبدیل قابل اجرا استفاده کند. جایگزین های دیگری نیز وجود دارد و ارائه دهندگان فناوری تبلیغات باید راه حل مناسبی را بر اساس حریم خصوصی و نیازهای کاربردی مورد نظر خود انتخاب کنند. |
موارد استفاده از صورتحساب | شفافیت در مورد میزان گزارش اسناد از موارد استفاده از صورتحساب مبتنی بر تبدیل پشتیبانی میکند | ما در حال کار بر روی پست کردن عمومی هستیم تا محدوده API گزارش انتساب برای صورتحساب را روشن کنیم. Attribution Reporting API در ابتدا به گونهای طراحی نشده بود که مستقیماً از صورتحساب CPA پشتیبانی کند. از صورتحساب CPC و CPM پشتیبانی میکند، که ساختار صورتحساب است که اکثر فناوریهای تبلیغاتی از آن استفاده میکنند. این چیزی است که اگر بازخورد اکوسیستم اضافی وجود داشته باشد، ممکن است در آینده از آن حمایت کنیم. |
از پشتیبانی کیس استفاده کنید | از مستندات موردی برای API اندازه گیری استفاده کنید | ما در حال کار بر روی شفافسازی اسناد برای تمام سطوح گزارشدهی جعبه ایمنی حریم خصوصی هستیم. |
کیفیت کلیک کنید | درخواست اضافه کردن سیگنال برای تشخیص کلیک های عمدی و غیرعمدی روی یک تبلیغ | ما در حال بحث در مورد درخواست هستیم و از ورودی های اضافی استقبال می کنیم. |
راه حل اندازه گیری | پشتیبانی از راه حل های اندازه گیری در چندین DSP | API گزارش Attribution می تواند توسط ارائه دهندگان اندازه گیری برای حذف بین چندین DSP استفاده شود. بهعلاوه، ما برای فهرستی از URLها در attributionsrc پشتیبانی پیشنهاد میکنیم که پشتیبانی از درخواستهای API Attribution Reporting ارائهدهنده اندازهگیری را برای DSPها آسانتر میکند. ما از هرگونه بازخورد اضافی در مورد پیشنهاد فوق استقبال می کنیم. |
گزارش در سطح رویداد | درخواست کنید که تعداد روزهای قبل از ارسال گزارش به طور مستقیم در دسترس باشد | این درخواست را میتوان با استفاده از اطلاعات موجود در حال حاضر توسط فناوریهای تبلیغاتی محاسبه کرد. ما هیچ بازخورد اکوسیستم دیگری در رابطه با این درخواست نشنیده ایم، اما آماده بازخورد در مورد آن هستیم. |
source_registration_time | source_registration_time در گزارش Attribution در سطح رویداد اضافه کنید. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی در مورد اینکه آیا بازیکنان اکوسیستم آن را یک ویژگی مفید میدانند، استقبال میکنیم. |
حالت ناشناس | آیا زمانی که کاربر در حالت ناشناس است راه حل های اندازه گیری در دسترس خواهد بود؟ | خیر، وقتی کاربر در حالت ناشناس باشد، راه حل های اندازه گیری در دسترس نخواهند بود. کوکی های شخص ثالث به طور پیش فرض در حالت ناشناس خاموش هستند. |
اتاق تمیز داده ها | آیا API های Measurement با اتاق های تمیز سازگار خواهند بود؟ | اتاق تمیز داده معمولی محیطی است که در آن دادههای شناسایی فردی از منابع مختلف در پایگاه داده آپلود میشوند تا تجزیه و تحلیلهای مبتنی بر ادغام آن دادههای اساسی را اجرا کنند. دو چارچوب اندازهگیری برای APIهای Privacy Sandbox، گزارشهای سطح رویداد و گزارشهای خلاصه هستند. گزارشهای سطح رویداد حاوی شناسه رویداد ارائهشده با فناوری تبلیغاتی است که میتواند در اتاق تمیز داده استفاده شود، اما اطلاعات مربوط به سمت تبدیل محدود و پر سر و صدا خواهد بود. گزارشهای جمعآوریشده رمزگذاریشده را نمیتوان مستقیماً در اتاق تمیز استفاده کرد، اما نتایج خلاصه ارائهشده توسط سرویس تجمع میتواند به عنوان ورودی برای تجزیه و تحلیلهایی که انجام میدهید یا بهعنوان اطلاعات تکمیلی استفاده شود. |
سرویس تجمع
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در سه ماهه چهارم 2022 گزارش شده است) گزارش تاخیر | تاخیر گزارش مورد انتظار چقدر است؟ | به روز رسانی Q1 2023: پس از بازخورد شریک، ما پیشنهاداتی را برای کاهش تاخیر و کاهش تاثیر تاخیر به اشتراک گذاشته ایم. هر دو پیشنهاد در طول فراخوان های WICG توسط فناوری های تبلیغاتی پشتیبانی شده اند. |
بدون قانون تکراری | اگر گزارشهای انبوهی که دارای شناسه مشترک یکسانی هستند، قبلاً پردازش شده باشند، چگونه با یک "گزارش انباشته با تاخیر" برخورد میکنید؟ | ما پیشنهادی در مورد اضافه کردن تاخیر گزارش اضافی به اطلاعات مشترک گزارشهای جمعآوریشده و تعریف شناسه مشترک برای سرویس Aggregation به اشتراک گذاشتهایم تا به طور جزئی به تأثیر از دست دادن تأخیر بر API کل رسیدگی شود. ما از هرگونه بازخورد در مورد پیشنهاد استقبال می کنیم. |
پردازش داده ها | با استفاده از Privacy Budget، درخواست فعال کردن پشتیبانی از چندین پاس داده با رعایت حریم خصوصی متفاوت | ما در حال بحث در مورد امکان استفاده از روشی انعطاف پذیرتر برای مصرف بودجه حریم خصوصی برای فعال کردن این مورد استفاده و استقبال از بازخورد اضافی هستیم. |
(همچنین در سه ماهه دوم 2022 گزارش شده است) ارگونومی پرس و جو | فعال کردن پرس و جو کل کلیدها. | به روز رسانی Q1 2023: درخواست ویژگی هنوز در حال بررسی است، اما در حال حاضر هیچ پیشنهادی برای اشتراکگذاری نداریم. |
محدودیت های Origin Trial | محدوده خدمات جمعآوری مانند «قاعده عدم وجود موارد تکراری» را که در حال حاضر در آزمایش اولیه اعمال نمیشود، روشن کنید. | ما به دنبال بهروزرسانی اسناد خود هستیم تا مشخص کنیم چه چیزی در نسخه آزمایشی مبدأ در مقابل GA در دسترس خواهد بود. |
Private Aggregation API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
بودجه مشارکت خصوصی | بودجه کمک L1 بسیار محدود کننده است. | هر تماس با Private Aggregation API یک مشارکت نامیده می شود. برای محافظت از حریم خصوصی کاربر، تعداد مشارکتهایی که میتوان از یک فرد جمعآوری کرد محدود است. وقتی همه مقادیر قابل جمع را در همه کلیدهای تجمیع جمع می کنید، مجموع باید کمتر از بودجه مشارکت باشد. تحت طراحی فعلی، ما محدودیتی را برای مشارکت برای یک منبع گزارش خاص در ~24 ساعت گذشته (به عنوان یک پنجره متحرک) تعیین کردیم. این بودجه کمک L1 است که در بازخورد ذکر شده است. ما پیشنهاد می کنیم که توسعه دهندگان مقادیر مورد نظر خود را بر اساس حجم مورد انتظار (یعنی فقط با استفاده از مقدار 1) مقیاس می کنند. بنابراین ، ممکن است استفاده از یک ارزش کوچکتر برای وقایع رایج تر برای جلوگیری از خسته شدن بودجه ، منطقی باشد. ما در حال حاضر به دنبال بازخورد در مورد بودجه سهم API جمع آوری خصوصی در هر دو تعداد عددی و دامنه هستیم. ما در نظر داریم دامنه را از هر منظر به هر سایت منتقل کنیم و محدوده موجود را به یک پنجره ده دقیقه ای با یک محدوده روزانه بزرگتر منتقل کنیم. |
ردیابی پنهانی را محدود کنید
کاهش کاربر-عامل/مشتری عامل کاربر عامل
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تصویب UA-R | از 10،000 سایت برتر انگلیس ، تنها 1 ٪ از سایت هایی که از تبلیغات برنامه ای استفاده می کنند ، نکات مشتری HTTP را ارسال می کنند. DSP هایی که مهاجرت نکرده اند ممکن است در قابلیت های ضد کلاهبرداری تأثیر بگذارد. | پس از اجرای یک تجزیه و تحلیل در همان مجموعه داده ها ، دریافتیم که اگر شما با استفاده از برچسب HTML <Meta> و API های JavaScript ، استفاده از UA-Ch را در نظر بگیرید ، تعداد سایتهایی که از UA-CH استفاده می کنند به طور قابل توجهی بالاتر از شکل 1 ٪ ارائه شده در بازخورد است. بر این اساس ، و سایر حقایق از جمله بازخورد اکوسیستم ، ما با اطمینان از حرکت تدریجی فاز 6 کاهش UA ، مطابق با جدول زمانی منتشر شده ، در حالی که CMA را آگاه می کند ، به جلو حرکت می کنیم. توجه داشته باشیم که سایت ها تقریباً دو سال از زمان سرب برای آماده سازی برای انتقال داشته اند و یک آزمایش استهلاک هنوز برای سایتهایی که احساس می کنند آماده نیستند ، در دسترس است. |
نکات مربوط به فاکتورهای شکل اضافی | درخواست UA-Ch برای ارائه فاکتورهای فرم اضافی مانند تلویزیون ، VR | ما از این پیشنهاد استقبال می کنیم و به دنبال ترکیب آن در طراحی هستیم. ما از بازخورد اضافی استقبال می کنیم. |
تست خودکار | قبل از ارسال فاز 6 UAR ، درخواست حل اشکال UA-CH را در کروم بدون سر درخواست کنید | اشکال مورد نظر برطرف شده است. |
پشتیبانی ua-ch در iOS | سایتی که به اطلاعات مربوط به UA برای تبلیغات متکی است ، از مواردی استفاده می کند که از آن استفاده می کند که Chrome در iOS پشتیبانی نمی شود. | برای مرورگرهای IOS غیر Safari (از جمله Chrome در iOS) ، پروژه WebKit قبل از فعال شدن باید پشتیبانی از UA-CH را اضافه کند (زیرا آنها کنترل پشته شبکه را کنترل می کنند). |
محافظت از IP (قبلاً Gnatcatcher)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در Q4 گزارش شده است) موارد استفاده از جغرافیایی | محافظت از IP ممکن است مانع از کار با استفاده از جغرافیایی قانونی در آینده شود ، مانند شخصی سازی محتوا بر اساس جغرافیایی. | پاسخ ما از Q4 2022 بدون تغییر است: "ما در حال همکاری با ذینفعان هستیم تا اطمینان حاصل کنیم که Chrome همچنان از موارد استفاده قانونی برای آدرس های IP پشتیبانی می کند. ما به دنبال بازخورد اکوسیستم در مورد دانه جغرافیایی IP هستیم." |
انطباق با مقررات | اگر یک منطقه زیر 1 میلیون نفر جمعیت داشته باشد ، آستانه فعلی 1M برای محافظت از IP باعث می شود وب سایت ها از آدرس های IP برای انطباق نظارتی استفاده کنند. | ما در حال کار با ذینفعان هستیم تا اطمینان حاصل کنیم که Chrome همچنان از موارد استفاده قانونی برای آدرس های IP پشتیبانی می کند. ما به دنبال بازخورد اکوسیستم در مورد انطباق نظارتی در محافظت از IP هستیم. |
کاهش | احزاب می توانند با به اشتراک گذاشتن آدرس های IP غیرمترقبه به دیگران ، از IP محافظت کنند. | ما از این خطر آگاه هستیم که پیشنهاد فعلی محافظت از IP ممکن است از لحاظ فنی مانع از اشتراک گذاری آدرس های IP با دیگران نباشد. ما در حال کار بر روی کاهش هستیم که از این خطر سوء استفاده جلوگیری می کند. همانطور که در مورد این پیشنهاد تکرار می کنیم ، بازخورد و بحث بیشتر را تشویق می کنیم. به طور خاص ، ما می خواهیم از موارد استفاده آگاهی داشته باشیم که طرفین معتقدند که آنها باید آدرس های IP غیرمترقبه را با سایر احزاب به اشتراک بگذارند. |
مسدود کننده شبکه | احزاب می توانند با استفاده از پروکسی های محافظت از IP ، مسدود کردن شبکه را دور بزنند. | موجودی که بلوک را انجام می دهد ، باید برای این سناریو محافظت IP را غیرفعال کند. ما به این مسئله پاسخ داده ایم و از بازخورد اضافی استقبال کرده ایم. |
لیست بلوک های آدرس IP تحت تأثیر پیشنهاد محافظت از IP | بسیاری از شرکت های فناوری تبلیغاتی از لیست بلوک های اساسی آدرس های IP ، مانند لیست IP Datacenter Tag ، برای جلوگیری از مناقصه موجودی تبلیغاتی که به احتمال زیاد کلاهبرداری (یا حداقل قابل استفاده نیست) استفاده می کنند. در صورتی که یک فناوری تبلیغی نیز ردیاب باشد و می تواند مشمول پیشنهاد محافظت از IP باشد ، این شرکت ممکن است قبل از خرید موجودی تبلیغاتی ، توانایی انجام یک چک اساسی را در برابر تبلیغات از دست بدهد. | ما بازخورد و بحث بیشتر در مورد پیشنهاد محافظت از IP در مورد موضوعات و راه حل های احتمالی را تشویق می کنیم. یکی از گزینه ها استفاده از لیست های مشابه برای محافظت از IP است ، به گونه ای که ما مشتریانی را که از آدرس های IP پرچم دار قبلاً پرچم گذاری شده اند ، پروکسی نمی کنیم. |
مرزهای حفظ حریم خصوصی سایت را تقویت کنید
ست های شخص اول
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در Q4 گزارش شده است) حد دامنه | درخواست گسترش تعداد حوزه های مرتبط | پاسخ ما از Q4 2022 بدون تغییر است: " ما در تماس های WICG توضیح داده ایم که Chrome متعهد به ارائه یک راه حل قابل استفاده است که منافع حریم خصوصی کاربران را نیز در نظر می گیرد. در این راستا ، ما از بازخورد جامعه در مورد موارد استفاده خاص که ممکن است تحت تأثیر محدودیت دامنه باشد ، قدردانی می کنیم ، به طوری که تیم می تواند راه هایی برای پرداختن به این موارد استفاده در ضمن ادامه محافظت از حریم شخصی کاربر را در نظر بگیرد. " |
ارسال FPS جایگزین | پیشنهادی برای روش جایگزین برای ارسال لیست های جهانی برای FPS | در این زمان ، ما در حال آماده سازی برای ارسال مجموعه های شخص اول (FPS) در Chrome هستیم و یک مخزن متمرکز GitHub را برای پذیرش ارسال های مجموعه تنظیم کرده ایم. از آنجا که ما امیدواریم که FPS در آماده سازی برای استهلاک کوکی های شخص ثالث ، شکافی را با راه حل های پلت فرم وب موجود پر کند ، انتظار داریم از آنها یاد بگیریم که چگونه FPS توسط نویسندگان سایت استفاده می شود. از آنجا که لیست مجموعه ها با گذشت زمان رشد می کنند و اکوسیستم با دنیای کوکی های شخص ثالث پس از آن سازگار می شود ، ما همچنین می توانیم این روند را تا جایی که می توانیم طرح های غیر متمرکز جایگزین مانند طرح پیشنهادی را در نظر بگیریم ، بالغ کنیم. با روند فعلی ، ما انتظار داریم که Lifetimes Set را ایجاد کنیم ، که به ما امکان می دهد روند مصرف را با گذشت زمان تکامل دهیم. ما می توانیم پس از بالغ شدن روند ارسال ، این ایده را دوباره بررسی کنیم. |
اعتدال دوباره | برای جلوگیری از سوءاستفاده ، اعتدال جامعه از repo ارسال FPS را تصویب کنید. بازیگران بد می توانند به راحتی فرآیند استفاده از منشأ مشعل را برای پیشنهاد مجموعه ها تحت الشعاع قرار دهند ، و یک حجم بیش از حد درخواست ها ممکن است بر عملکردهای پیشنهادی مجموعه واقعی تأثیر بگذارد. | ما در تلاش هستیم تا با تکیه بر بررسی های اعتبار سنجی فنی ، چک ها را تا حد امکان عینی انجام دهیم. ما فکر می کنیم این مقیاس پذیرترین رویکرد برای فرآیند ارسال است. با توجه به این هدف ، ما همچنین هدف ما اطمینان از روند انعطاف پذیری در مورد ارسال های هرزنامه / مشعل خواهیم بود. |
زیر مجموعه های مرتبط | آیا FPS قادر به پشتیبانی از موارد استفاده از فروشنده شخص ثالث/SaaS از طریق زیر مجموعه های مرتبط خواهد بود؟ | جریان فروشنده / SaaS شخص ثالث مورد استفاده ای نیست که در حال حاضر در محدوده مجموعه های شخص اول در نظر گرفته شده است. ما از بازخورد اضافی در مورد نحوه استفاده کوکی های سایت متقاطع برای این موارد استفاده استقبال می کنیم. |
ادغام FPS + تراشه ها | درخواست ادغام FPS + تراشه ها به منظور پشتیبانی از موارد استفاده مانند آزمایش A/B | ما در حال بحث در مورد این مورد استفاده هستیم و همچنین در حال بحث در مورد این موضوع در یک تماس WICG هستیم و از ورودی اضافی در اینجا استقبال می کنیم. |
GDPR | پیشنهادی برای زیر مجموعه FPS جدید پس از مفاهیم GDPR مدل سازی می شود | ما در مورد این پیشنهاد در داخل بحث کردیم و آن را در برابر سایر بازخورد دریافت شده و همچنین اهداف حریم خصوصی خود وزن کردیم. ما پاسخی را ارائه داده ایم که توضیح می دهد که چرا در حال حاضر این پیشنهاد را دنبال نمی کنیم. |
حافظه | تغییر انتظار می رود در اندازه حافظه مرورگر وقتی لیست FPS درج شده است | موارد قبلی برای مرورگرها وجود داشته است تا بتوانند این نوع لیست ها را با حداقل تأثیر حافظه ، مانند لیست حفاظت از ردیابی قطع ارتباط ، ذخیره کنند. در حالی که لیست مجموعه های شخص اول به صورت محلی در هر مشتری Chrome کپی می شود ، ما همچنان به اندازه پرونده نظارت خواهیم کرد و اطمینان داریم که می توانیم ردپای حافظه را بهینه کنیم. |
Fenced Frames API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
محدودیت های قاب های حصارکشی | وضوح در مورد محدودیت های تحمیل شده توسط فریم های حصارکشی | در ماه مارس ، ما توضیح دهنده خود را در مورد فریم های حصارکشی به روز کردیم که اطلاعاتی در مورد قابلیت های آن ارائه می دهد و از هرگونه بازخورد اضافی استقبال می کنیم. |
اطلاعات دسترسی را گسترش دهید | درخواست گسترش دسترسی به اطلاعات اطراف قاب های همسایه | ما به دنبال این هستیم که بیشتر بفهمیم که چرا این یک الزام از اکوسیستم است و از هرگونه بازخورد اضافی استقبال می کنیم. |
قاب های حصارکشی و Iframes | سوالات مربوط به برابری ویژگی بین قاب های حصارکشی و Iframes | کلیه API ها و گزارش های Sandbox Privacy در دسترس برای Iframes و برای حصارکشی به همان روش در دسترس خواهند بود. |
اندازه گیری مجدد قاب های حصارکشی | محدود کردن تغییرات اندازه قاب بر موارد استفاده خاصی تأثیر می گذارد. | ما علاقه مند به یادگیری بیشتر در مورد انواع موارد استفاده ای هستیم که تحت تأثیر محدودیت قرار دارند و از بازخورد اضافی استقبال می کنیم. |
API ذخیره سازی مشترک
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
کارگاه های شخص ثالث | آیا اشخاص ثالث می توانند برای ذخیره سازی مشترک ، تقسیم شده توسط مبدا بنویسند؟ یا برای اندازه گیری شخص ثالث با کارگاه های دیگر تماس بگیرید؟ | منشأ زمینه مرور که در آن کد اجرا می شود ، تعیین می کند که ذخیره مشترک آن داده ها برای آنها نوشته شده است. هنگامی که کد شخص ثالث به یک صفحه اضافه می شود ، کد شخص ثالث را می توان به عنوان یک IFRAME با زمینه مرور خود تعبیه کرد ، که به کد شخص ثالث اجازه می دهد تا با منشأ خود بنویسد. کد شخص ثالث همچنین می تواند به جای یک Iframe به عنوان یک اسکریپت تعبیه شود ، که زمینه مرور را تغییر نمی دهد و شخص ثالث می تواند به ذخیره مشترک تعبیه کننده بنویسد. توجه داشته باشید که فقط صاحب آن ذخیره سازی مشترک می تواند از آن ذخیره سازی مشترک بخواند. |
کپی برداری | Deduplication برای تعامل خارج از اکوسیستم Chrome امکان پذیر نخواهد بود. | ذخیره سازی مشترک به منظور ارائه خروجی های منحصر به فرد مبتنی بر مرورگر کروم در کروم است. ما علاقه مند به همکاری با فناوری های تبلیغاتی هستیم تا درک کنیم که چگونه می توان از این خروجی ها به عنوان بخشی از مدل های دسترسی گسترده تر آنها استفاده کرد. ما می دانیم که خود خروجی ها فقط می توانند بخشی از تعامل را به خود اختصاص دهند و علاقه مند به کار با فناوری های تبلیغاتی برای کشف روشهای مدل سازی اضافی هستند که می توانند در بالا لایه بندی شوند. |
پنجره نگاه برگشت | برای دیدن تغییرات در تبدیل به مرور زمان ، یک پنجره نگاه برای نرخ تبدیل داشته باشید | این امر می تواند با پردازش مسیرهای مختلف تبدیل در سمت مشتری با استفاده از ذخیره سازی مشترک ، که انعطاف پذیری دیگری را برای تجزیه و تحلیل پیشرفته نسبت به ذخیره سازی مرورگر ایمن ایمن فراهم می کند ، اجرا شود. |
پنجره انقضا | درخواست گسترش پنجره انقضا تا 90 روز | خط مشی حفظ داده ها در نوامبر 2022 به روز شد و بیان می کند که هر کلید پس از سی روز آخرین نوشتن پاک می شود. ما از بازخوردهای اضافی استقبال می کنیم تا بفهمیم آیا سیاست جدید برای اکوسیستم کار خواهد کرد یا خیر. |
چرخش خلاقانه | موارد استفاده از چرخش خلاق منعکس کننده اقدامات واقعی پس از حراج نیست. | ما علاقه مندیم از شرکتهای تبلیغاتی بیشتر طرف خرید در مورد اینکه آیا مستندات چرخش خلاق دقیق است یا خیر ، بشنویم. |
تراشه
هیچ بازخوردی در این سه ماه دریافت نکرد.
فدستان
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
نقطه پایانی ادعای هویت | صریحاً درخواست های دلخواه را به نقطه پایانی ادعای هویت اجازه دهید. | ما در این درخواست کشش با موزیلا همکاری کرده ایم تا توانایی وب سایت ها را در ایجاد درخواست های معتبر متقاطع به صورت سکوت بدون ایجاد دلخوری کاربر محدود کنیم و به بررسی و پرداختن به سایر بازخورد ها نیز ادامه خواهیم داد. |
هویت قبل از جمعیت | آیا می توان از FEDCM استفاده کرد تا از پیش جمع شده در فرم هایی با ارائه دهنده هویت از لیست FEDCM استفاده کند؟ | نگرانی از این مورد استفاده این است که ممکن است منجر به نشت اطلاعات شود وقتی سایتی که با کاربر درگیر نشده باشد قادر به پرس و جو از آخرین IDP است که توسط کاربر استفاده می شود. ما در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم. |
انتخاب حساب متنی | پیشنهاد اضافه کردن سیگنال های متنی در UI انتخاب حساب | ما در حال بررسی این پیشنهاد هستیم و از بحث های اضافی استقبال می کنیم. |
با هرزنامه و کلاهبرداری مبارزه کنید
API Token State Private (و سایر API)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
بررسی جمع آوری قابلیت ها | در اوایل Q1 ، ما جمع آوری نتایج نظرسنجی خود را به پایان رساندیم که برای موارد مختلف استفاده از ضد کلاهبرداری مورد نیاز است و آنها را به صورت عمومی به اشتراک گذاشتیم ( دقیقه ، نتایج ) | ما قصد داریم این بازخورد را گنجانیم ، زیرا پیشنهادات و نمونه های جدید را برای API های هدفمند و حفظ حریم خصوصی برای قابلیت های ضد کلاهبرداری تهیه می کنیم. ما انتظار داریم که در جایی که نیاز کافی وجود داشته باشد ، توسعه را در اولویت قرار دهیم و فناوری موجود وجود دارد که می توانیم در ضمن حفظ حریم شخصی کاربر ، توانایی را برای معرفی وب ایجاد کنیم. به عنوان مثال ، یکپارچگی دستگاه و بوت بسیار رتبه بندی شده است و بسیاری از سیستم عامل ها دارای API های موجود هستند که با اطمینان ارزیابی یکپارچگی دستگاه را به اشتراک می گذارند ، بنابراین کاندیدای خوبی برای دنبال کردن اکتشافات در گروه های جامعه است. |
PST قصد ارسال بازخورد | به عنوان بخشی از قصد حمل و نقل ، ما با توجه به اینکه از یک نسخه قدیمی تر از حریم خصوصی عبور می کنیم ، نگرانی خود را دریافت کردیم. ما همچنین بازخورد دریافت کردیم که مشخصات در بخش های خاصی مشخص نیست و برای تسهیل سازگاری مرورگر باید بهبود یابد. | ما قصد داریم قبل از حمل و نقل به GA ، و همچنین چند تغییر API ، بسیاری از تغییرات مشخصات پیشنهادی را پیاده سازی کنیم. بازخورد درست در پایان Q1 به وجود آمد ، بنابراین ما با جزئیات خاص و به روزرسانی برنامه راه اندازی خود (در حال انجام ، از زمان انتشار این گزارش بازخورد) در مورد مسائل GitHub پیگیری می کنیم. برای تغییرات بزرگتر در API ، ما برای در نظر گرفتن آنها باز هستیم ، اما احساس می کنیم بهترین راه پیش رو شروع به کار در دسترس بودن عمومی و بازخورد دست از توسعه دهندگان بیشتر است. امیدواریم این بحث را ادامه دهیم و استاندارد سازی مرورگر را دنبال کنیم. اگر و هنگامی که یک استاندارد جدید پدیدار شود ، ما در نظر خواهیم گرفت که اتخاذ و تدوین برنامه ای را برای انتقال دقیق به آن انجام دهیم. |