گزارش فصلی برای سه ماهه اول 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 است. صفحه بازخورد جعبه ایمنی حریم خصوصی در developer.chrome.com مکانیسم های دیگری را برای ارائه بازخورد و مشارکت در بحث توضیح می دهد. 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) مقیاسبندی کنند. بنابراین، ممکن است منطقی باشد که از مقدار کمتری برای رویدادهای رایج تر استفاده کنیم تا از اتمام بودجه جلوگیری کنیم. ما در حال حاضر به دنبال بازخوردی در مورد بودجه مشارکت Private Aggregation API در هر دو محدوده عددی و محدوده هستیم. ما در حال بررسی انتقال دامنه از مبدا به هر سایت و انتقال کران موجود به یک پنجره ده دقیقه ای با کران روزانه بزرگتر هستیم. |
ردیابی پنهان را محدود کنید
راهنمای کاربر-کاهش/کاربر-عامل مشتری-نکات
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
پذیرش UA-R | از 10000 سایت برتر در بریتانیا، تنها 1٪ از سایت هایی که از تبلیغات برنامه ای استفاده می کنند، نکات مشتری HTTP را ارسال می کنند. DSPهایی که مهاجرت نکردهاند ممکن است بر قابلیتهای ضد کلاهبرداری تأثیر بگذارند. | پس از اجرای تجزیه و تحلیل بر روی همان مجموعه داده، متوجه شدیم که اگر استفاده از UA-CH را از طریق تگ HTML <meta> و APIهای جاوا اسکریپت در نظر بگیرید، تعداد سایت هایی که از UA-CH استفاده می کنند به طور قابل توجهی بیشتر از رقم 1٪ است. در بازخورد ارائه شده است. بر اساس این، و سایر حقایق از جمله بازخورد اکوسیستم، ما احساس اطمینان می کنیم که با عرضه تدریجی فاز 6 کاهش UA، مطابق با جدول زمانی منتشر شده ، و در عین حال CMA را در جریان قرار می دهیم. توجه داشتهایم که سایتها نزدیک به دو سال زمان لازم برای آمادهسازی برای انتقال داشتهاند و آزمایشی منسوخ برای سایتهایی که احساس میکنند آماده نیستند هنوز در دسترس است. |
نکاتی برای فاکتورهای فرم اضافی | درخواست UA-CH برای ارائه فاکتورهای فرم اضافی مانند TV، VR | ما از این پیشنهاد استقبال می کنیم و به دنبال گنجاندن آن در طراحی هستیم. ما از بازخورد اضافی استقبال می کنیم. |
تست خودکار | قبل از ارسال فاز 6 UAR، درخواست رفع اشکال UA-CH در کروم بدون سر | باگ مورد نظر رفع شده است. |
پشتیبانی از UA-CH در iOS | سایتی که برای تبلیغات به اطلاعات UA تکیه دارد، از موارد استفاده میکند که Chrome در iOS پشتیبانی نمیشود. | برای مرورگرهای iOS غیر Safari (از جمله Chrome در iOS)، پروژه WebKit باید قبل از فعال شدن از UA-CH پشتیبانی اضافه کند (زیرا پشته شبکه را کنترل می کنند). |
حفاظت IP (Gnatcatcher سابق)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در Q4 گزارش شده است) موارد استفاده از موقعیت جغرافیایی | حفاظت IP ممکن است از کارکرد موارد استفاده مشروع از موقعیت جغرافیایی در آینده جلوگیری کند، مانند شخصیسازی محتوا بر اساس موقعیت جغرافیایی. | پاسخ ما نسبت به سه ماهه چهارم 2022 بدون تغییر است: "ما در حال کار با سهامداران هستیم تا اطمینان حاصل کنیم که Chrome همچنان از موارد استفاده قانونی برای آدرسهای IP پشتیبانی میکند. ما به دنبال بازخورد اکوسیستم در مورد جزئیات موقعیت مکانی IP هستیم." |
انطباق با مقررات | اگر منطقه ای کمتر از 1 میلیون جمعیت داشته باشد، آستانه فعلی 1M برای حفاظت از IP مانع از استفاده وب سایت ها از آدرس های IP برای انطباق با مقررات می شود. | ما در حال کار با سهامداران هستیم تا اطمینان حاصل کنیم که Chrome همچنان از موارد استفاده قانونی برای آدرسهای IP پشتیبانی میکند. ما به دنبال بازخورد اکوسیستم در مورد انطباق مقررات در حفاظت IP هستیم. |
کاهش سوء استفاده | طرفین می توانند با به اشتراک گذاشتن آدرس های IP بدون نقاب با دیگران، حفاظت IP را دور بزنند. | ما از این خطر آگاه هستیم که پیشنهاد فعلی حفاظت از IP ممکن است از نظر فنی مانع از اشتراک گذاری آدرس های IP بدون نقاب با دیگران توسط طرفین نشود. ما در حال کار بر روی اقدامات کاهشی هستیم که از این خطر سوء استفاده جلوگیری می کند. همانطور که ما در مورد پیشنهاد تکرار می کنیم، بازخورد و بحث بیشتری را تشویق می کنیم. به طور خاص، ما میخواهیم موارد استفادهای را بدانیم که طرفین معتقدند باید آدرسهای IP بدون نقاب را با سایر طرفها به اشتراک بگذارند. |
مسدود کردن شبکه | احزاب می توانند با استفاده از پروکسی های حفاظت از IP، مسدود شدن شبکه را دور بزنند. | نهادی که بلوک را انجام می دهد باید IP Protection را برای این سناریو غیرفعال کند. ما به این موضوع پاسخ دادهایم و از بازخورد اضافی استقبال میکنیم. |
لیست های بلوک آدرس IP تحت تأثیر پیشنهاد حفاظت IP قرار گرفته است | بسیاری از شرکتهای فناوری تبلیغات از یک لیست بلوک اصلی از آدرسهای IP، مانند فهرست IP مرکز داده TAG ، استفاده میکنند تا از مناقصه برای موجودی آگهیهایی که به احتمال زیاد تقلبی هستند (یا حداقل غیرقابل کسب درآمد) جلوگیری کنند. در صورتی که یک فناوری تبلیغاتی نیز یک ردیاب باشد و ممکن است مشمول پیشنهاد حفاظت از IP باشد، آن شرکت ممکن است توانایی بررسی اولیه تبلیغات را قبل از خرید موجودی تبلیغاتی از دست بدهد. | ما بازخورد و بحث بیشتر در مورد پیشنهاد حفاظت از IP در مورد مسائل و راه حل های بالقوه را تشویق می کنیم. یکی از گزینهها اعمال چنین لیستهایی برای حفاظت از IP است، به طوری که ما کلاینتهایی را که از آدرسهای IP قبلی پرچمگذاری شدهاند، پروکسی نمیکنیم. |
مرزهای حریم خصوصی بین سایتی را تقویت کنید
مجموعه های شخص اول
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در Q4 گزارش شده است) محدودیت دامنه | درخواست گسترش تعداد دامنه های مرتبط | پاسخ ما نسبت به سه ماهه چهارم 2022 بدون تغییر است: "ما در تماسهای WICG توضیح دادهایم که Chrome متعهد به ارائه راهحلی قابل استفاده است که منافع حریم خصوصی کاربران را نیز در نظر میگیرد. در این راستا، ما از بازخورد انجمن در مورد موارد استفاده خاص که ممکن است تحت تأثیر محدودیت دامنه قرار بگیرند، قدردانی میکنیم. که تیم میتواند راههایی را برای رسیدگی به این موارد استفاده و در عین حال حفظ حریم خصوصی کاربر در نظر بگیرد. " |
ارسال FPS جایگزین | پیشنهاد راه جایگزین برای ارسال لیست های جهانی برای FPS | در حال حاضر، ما در حال آمادهسازی برای ارسال مجموعههای شخص اول (FPS) در کروم هستیم و یک مخزن متمرکز GitHub برای پذیرش ارسالهای مجموعه راهاندازی کردهایم. از آنجایی که امیدواریم FPS در آماده سازی برای از بین رفتن کوکی های شخص ثالث، شکافی را با راه حل های پلتفرم وب موجود پر کند، انتظار داریم از آنها یاد بگیریم که چگونه FPS توسط نویسندگان سایت مورد استفاده قرار می گیرد. از آنجایی که فهرست مجموعهها در طول زمان رشد میکند و اکوسیستم با دنیای کوکیهای شخص ثالث سازگار میشود، میتوانیم فرآیند را تا حدی توسعه دهیم که بتوانیم طرحهای غیرمتمرکز جایگزینی مانند طرح پیشنهادی را در نظر بگیریم. با روند فعلی، ما انتظار داریم که طول عمرهای مشخصی را ایجاد کنیم، که به ما امکان می دهد فرآیند مصرف را در طول زمان تکامل دهیم. زمانی که فرآیند ارسال به بلوغ رسید، میتوانیم این ایده را دوباره بررسی کنیم. |
اعتدال ریپو | برای جلوگیری از سوء استفاده، نظارت انجمن را برای مخزن ارسال FPS اعمال کنید. بازیگران بد میتوانند به راحتی فرآیند را تحت تأثیر قرار دهند و از مبداهای مشعل برای پیشنهاد مجموعهها استفاده کنند، و حجم عظیمی از درخواستها ممکن است بر عملیات پیشنهادهای مجموعه واقعی تأثیر بگذارد. | ما در تلاش هستیم تا با تکیه بر بررسی های تایید فنی، بررسی ها را تا حد امکان عینی کنیم. ما فکر می کنیم این مقیاس پذیرترین رویکرد برای فرآیند ارسال است. با توجه به این هدف، ما همچنین میخواهیم اطمینان حاصل کنیم که فرآیند در برابر ارسالهای هرزنامه/رایتر مقاوم است. |
زیر مجموعه های مرتبط | آیا FPS قادر به پشتیبانی از موارد استفاده جریان فروشنده/SaaS شخص ثالث از طریق زیر مجموعههای مرتبط است؟ | جریان های فروشنده شخص ثالث / SaaS یک مورد استفاده نیست که در حال حاضر در محدوده مجموعه های شخص اول در نظر گرفته می شود. ما از بازخورد اضافی در مورد نحوه استفاده از کوکی های متقاطع سایت برای این موارد استفاده استقبال می کنیم. |
ادغام FPS + CHIPS | درخواست ادغام FPS + CHIPS به منظور پشتیبانی از موارد استفاده مانند تست A/B | ما در حال بحث در مورد این مورد استفاده هستیم و همچنین در حال بررسی این موضوع در یک تماس WICG هستیم و از ورودی اضافی در اینجا استقبال می کنیم. |
GDPR | پیشنهاد برای یک زیرمجموعه جدید FPS که بر اساس مفاهیم GDPR مدل شود | ما این پیشنهاد را در داخل مورد بحث قرار دادیم و آن را با سایر بازخوردهای دریافتی و همچنین اهداف حفظ حریم خصوصی خود مقایسه کردیم. ما پاسخی ارائه کردهایم که توضیح میدهد چرا در حال حاضر این پیشنهاد را دنبال نمیکنیم. |
حافظه | هنگامی که لیست FPS گنجانده شده است، اندازه حافظه مرورگر مورد انتظار تغییر است | پیشینه هایی برای مرورگرها وجود داشته است که این نوع لیست ها را با کمترین تأثیر حافظه ذخیره می کنند، مانند فهرست حفاظت از ردیابی قطع ارتباط. در حالی که لیست مجموعه های شخص اول به صورت محلی برای هر مشتری Chrome کپی می شود، ما به نظارت بر اندازه فایل ادامه می دهیم و مطمئن هستیم که می توانیم ردپای حافظه را بهینه کنیم. |
Fenced Frames API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
محدودیت های قاب های حصاردار | وضوح پیرامون محدودیت های تحمیل شده توسط قاب های حصاردار | در ماه مارس، توضیحدهنده خود را در مورد قابهای حصاردار بهروزرسانی کردیم که اطلاعاتی درباره قابلیتهای آن ارائه میدهد و از هرگونه بازخورد اضافی استقبال میکنیم. |
اطلاعات دسترسی را گسترش دهید | درخواست گسترش دسترسی به اطلاعات پیرامون فریم های مجاور | ما به دنبال درک بیشتر این موضوع هستیم که چرا این یک الزام از سوی اکوسیستم است و از هرگونه بازخورد اضافی استقبال می کنیم. |
قاب ها و آیفریم های حصاردار | سوالاتی در مورد برابری ویژگی بین قاب های حصاردار و iframe | همه APIها و گزارشهای Privacy Sandbox موجود برای iframes و برای FencedFrames به همین ترتیب در دسترس خواهند بود. |
تغییر اندازه قاب های حصاردار | محدود کردن تغییرات اندازه فریم بر موارد استفاده خاص تأثیر می گذارد. | ما علاقه مندیم در مورد انواع موارد استفاده که تحت تأثیر محدودیت قرار می گیرند بیشتر بیاموزیم و از بازخورد اضافی استقبال می کنیم. |
API ذخیره سازی مشترک
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
ورکلت های شخص ثالث | آیا اشخاص ثالث می توانند به ذخیره سازی مشترک که بر اساس مبدا پارتیشن بندی شده اند، بنویسند؟ یا برای اندازه گیری شخص ثالث با سایر Worklet ها تماس بگیرید؟ | مبدأ زمینه مرور محل اجرای کد تعیین میکند که آن داده در چه کسی ذخیرهسازی مشترک نوشته شده است. وقتی کد شخص ثالث به یک صفحه اضافه می شود، کد شخص ثالث را می توان به عنوان یک iframe با زمینه مرور خاص خود جاسازی کرد، که به کد شخص ثالث اجازه می دهد تا در مبدا خود بنویسد. کد شخص ثالث همچنین میتواند بهجای iframe بهعنوان یک اسکریپت جاسازی شود، که زمینه مرور را تغییر نمیدهد، و شخص ثالث میتواند در فضای ذخیرهسازی مشترک جاسازیکننده بنویسد. توجه داشته باشید که فقط مالک آن فضای ذخیرهسازی مشترک میتواند از آن فضای ذخیرهسازی مشترک بخواند. |
کپی برداری | برای تعاملات خارج از اکوسیستم کروم امکان حذف مجدد وجود ندارد. | فضای ذخیرهسازی مشترک برای ارائه خروجیهای دسترسی منحصربهفرد مبتنی بر مرورگر Chrome در Chrome است. ما علاقه مند به کار با فناوری های تبلیغاتی هستیم تا بفهمیم چگونه می توان از این خروجی ها به عنوان بخشی از مدل های دسترسی گسترده تر آنها استفاده کرد. ما میدانیم که خود خروجیها ممکن است تنها بخشی از تعاملات را به خود اختصاص دهند و علاقهمند به کار با فناوریهای تبلیغاتی برای کشف روشهای مدلسازی اضافی هستند که میتوانند در بالا قرار بگیرند. |
پنجره نگاه به تبدیل | برای مشاهده تغییرات در تبدیل در طول زمان، یک پنجره بازبینی برای نرخ تبدیل درخواست کنید | این را می توان با پردازش مسیرهای تبدیل مختلف در سمت سرویس گیرنده با استفاده از ذخیره سازی مشترک، که انعطاف پذیری بیشتری را برای تجزیه و تحلیل پیشرفته نسبت به ذخیره سازی امن مرورگر بدون پارتیشن فراهم می کند، پیاده سازی کرد. |
پنجره انقضای آیتم | درخواست تمدید دوره انقضا تا 90 روز | خط مشی حفظ داده ها در نوامبر 2022 به روز شد و بیان می کند که هر کلید پس از سی روز از آخرین نوشتن پاک می شود. ما از بازخورد اضافی استقبال می کنیم تا بفهمیم آیا سیاست جدید برای اکوسیستم کارآمد است یا خیر. |
چرخش خلاقانه | موارد استفاده از چرخش خلاق، اقدامات واقعی پس از حراج را منعکس نمی کند. | ما علاقهمندیم از شرکتهای فناوری تبلیغاتی بیشتری در مورد اینکه آیا مستندات چرخش خلاقانه دقیق هستند یا خیر، بشنویم. |
چیپس
هیچ بازخوردی در این سه ماهه دریافت نشد.
FedCM
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
نقطه پایانی ادعای هویت | به صراحت درخواستهای دلخواه را به نقطه پایانی تأیید هویت اجازه دهید. | ما در این درخواست کششی با موزیلا همکاری کردهایم تا توانایی وبسایتها را برای ایجاد درخواستهای اعتباری متقاطع بهطور بیصدا و بدون ایجاد مزاحمت برای کاربر محدود کنیم و به بررسی و رسیدگی به سایر بازخوردها نیز ادامه خواهیم داد. |
هویت از قبل جمعیت | آیا می توان از FedCM برای پر کردن فرم ها با یک ارائه دهنده هویت از لیست FedCM استفاده کرد؟ | نگرانی برای این مورد استفاده این است که زمانی که سایتی که با کاربر درگیر نشده است بتواند آخرین IDP استفاده شده توسط کاربر را پرس و جو کند، ممکن است منجر به درز اطلاعات شود. ما در حال بحث بیشتر در مورد این موضوع هستیم و از بازخوردهای اضافی استقبال می کنیم. |
انتخاب حساب متنی | پیشنهاد اضافه کردن سیگنال های متنی در رابط کاربری انتخاب حساب | ما در حال بررسی این پیشنهاد هستیم و از بحث های بیشتر استقبال می کنیم. |
با اسپم و کلاهبرداری مبارزه کنید
Private State Token API (و سایر APIها)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
بررسی جمع آوری قابلیت ها | در اوایل سه ماهه اول، جمعآوری نتایج نظرسنجی خود را که برای موارد مختلف استفاده از تقلب به قابلیتهایی نیاز است، به پایان رساندیم و آنها را به صورت عمومی به اشتراک گذاشتیم ( دقایق ، نتایج ) | ما قصد داریم این بازخورد را همزمان با توسعه پیشنهادات و نمونههای اولیه برای APIهای ساختهشده و حفظ حریم خصوصی برای قابلیتهای ضد کلاهبرداری به کار ببریم. ما انتظار داریم که توسعه را در جایی که نیاز کافی وجود دارد و فناوری موجودی وجود دارد که میتوانیم با حفظ حریم خصوصی کاربر بر روی آن برای معرفی این قابلیت به وب ایجاد کنیم، اولویت بندی کنیم. برای مثال، یکپارچگی دستگاه و بوت رتبه بالایی داشت و بسیاری از پلتفرمها دارای APIهای موجود هستند که به طور ایمن ارزیابی یکپارچگی دستگاه را به اشتراک میگذارند، بنابراین کاندیدای خوبی برای پیگیری کاوش در گروههای اجتماعی است. |
PST قصد ارسال بازخورد | بهعنوان بخشی از قصد ارسال، با توجه به اینکه از نسخه قدیمیتر Privacy Pass استفاده میکنیم، نگرانی در ادامه دریافت کردیم. همچنین بازخورد دریافت کردیم مبنی بر اینکه مشخصات در بخشهای خاصی مشخص نیست و باید برای تسهیل سازگاری مرورگر بهبود یابد. | ما قصد داریم بسیاری از تغییرات مشخصات پیشنهادی را قبل از ارسال به GA و همچنین چند تغییر API را اجرا کنیم. بازخورد درست در پایان سه ماهه اول منتشر شد، بنابراین ما در حال پیگیری مسائل github با جزئیات خاص و بهروزرسانی برنامه راهاندازی خود هستیم (در حال انجام، از زمان انتشار این گزارش بازخورد). برای تغییرات بزرگتر در API، ما آماده در نظر گرفتن آنها هستیم، اما فکر می کنیم بهترین راه پیش رو این است که راه اندازی را تا دسترسی عمومی ادامه دهیم و بازخورد عملی از توسعه دهندگان بیشتری دریافت کنیم. امیدواریم این بحث را ادامه دهیم و استانداردسازی مرورگر را دنبال کنیم. اگر و زمانی که استاندارد جدیدی پدیدار شود، ما اتخاذ و توسعه طرحی را برای انتقال دقیق به آن در نظر خواهیم گرفت. |