گزارش فصلی برای سه ماهه سوم سال 2022، خلاصه بازخورد اکوسیستم دریافت شده در مورد پیشنهادات جعبه ایمنی حریم خصوصی و پاسخ 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/فناوری خاصی
موضوع بازخورد | خلاصه | پاسخ کروم |
(همچنین در سه ماهه دوم گزارش شده است) سودمندی برای انواع مختلف ذینفعان | نگرانی از این که فناوریهای جعبه ایمنی حریم خصوصی به نفع توسعهدهندگان بزرگتر هستند و سایتهای خاص (کوچکتر) بیشتر از سایتهای عمومی (بزرگتر) مشارکت دارند. | به روز رسانی Q3: Google به CMA متعهد شده است که پیشنهادات جعبه ایمنی حریم خصوصی را به گونهای طراحی و اجرا کند که رقابت را با ترجیح دادن به کسبوکار خود گوگل مخدوش نکند و تأثیر آن را بر رقابت در تبلیغات دیجیتال و ناشران و تبلیغکنندگان، صرف نظر از آنها، در نظر بگیرد. اندازه. ما به همکاری نزدیک با CMA ادامه می دهیم تا اطمینان حاصل کنیم که کار ما با این تعهدات مطابقت دارد. با پیشرفت تست Privacy Sandbox، یکی از سوالات کلیدی که ما ارزیابی خواهیم کرد این است که فناوری های جدید چگونه برای انواع مختلف ذینفعان عمل می کنند. بازخورد از این نظر بسیار مهم است، به ویژه بازخوردهای خاص و عملی که می تواند به ما در بهبود بیشتر طرح های فنی کمک کند. ما با CMA کار کردهایم تا رویکرد خود را برای آزمایشهای کمی توسعه دهیم و از انتشار یادداشتی در مورد طراحی آزمایش توسط CMA حمایت میکنیم تا اطلاعات بیشتری را به شرکتکنندگان بازار و فرصتی برای اظهار نظر در مورد رویکردهای پیشنهادی ارائه کنیم. |
(همچنین در سه ماهه دوم گزارش شده است) درخواست های اسناد و مدارک | درخواست برای منابع بیشتر در مورد نحوه مدیریت تست، تجزیه و تحلیل و پیاده سازی | به روز رسانی Q3: ما قدردانی میکنیم که توسعهدهندگان مطالب فعلی ما را مفید دانستهاند و متعهد به ارائه مطالب بیشتر در هفتهها و ماههای آینده هستند تا توسعهدهندگان بتوانند به درک اینکه چگونه فناوریهای جدید میتوانند برای آنها کار کنند، ادامه دهند. ما همچنین جلسات ساعات اداری برنامهنویس عمومی را برای به اشتراک گذاشتن بهترین شیوهها و نمایشهای نمایشی، همراه با جلسات پرسش و پاسخ با محصولات و سرنخهای مهندسی برگزار کردهایم تا امکان بحث/سوالات زنده را فراهم کنیم. |
پشتیبانی از مرورگرهای متقابل | سایر فروشندگان مرورگر که از APIهای Privacy Sandbox استفاده می کنند. | سایر فروشندگان مرورگر، مانند اپل، موزیلا و مایکروسافت، شرکت کنندگان فعالی در تالارهای گفتمان عمومی هستند که در آن اصول حفظ حریم خصوصی و رویکردهای مبتنی بر مرورگر مورد بحث قرار می گیرد. ما از بحث های مشترک در انجمن هایی مانند نشست اخیر TPAC سالانه W3C و انجمن های W3C PATCG در حال انجام که در آن نشانه هایی از همگرایی را می بینیم، تشویق می شویم. |
تفاوت پلت فرم | برای کمک به کاهش منابع مورد نیاز برای انتقال، تا آنجا که ممکن است، مجموعههای ویژگیها را در سراسر وب و Android درخواست کنید. | ما سخت کار می کنیم تا رویکردهای خود را در سراسر Chrome و Android هماهنگ کنیم تا از ایجاد سردرگمی/تجزیه در صنعت جلوگیری کنیم. هر گونه تفاوت در رویکرد ما تا حد زیادی به دلیل تفاوت های فنی ضروری بین وب و پلت فرم های برنامه تلفن همراه است که توسعه دهندگان از قبل در نظر گرفته اند. |
منابعی برای تست Privacy Sandbox API | مشکلات تخصیص کافی منابعی برای آزمایش APIهای Sandbox Privacy با توجه به شرایط اقتصادی فعلی. | Google به طور مداوم در حال بهبود اسناد و پشتیبانی موجود برای آزمایشگران است تا پیچیدگی را کاهش دهد و به پذیرش APIها کمک کند. این تلاشها عبارتند از: فهرستهای پستی مخصوص API، ساعات کاری باز، و بهروزرسانیهای مداوم در developers.chrome.com . |
Sandbox API Opt-out Signal | درخواست ارائه سیگنال «کاربر از Sandbox API ها انصراف داده است» که فناوری تبلیغات و وبسایتها میتوانند از آن استفاده کنند. | موارد تاریخی زیادی را دیدهایم که در آن وبسایتها به انتخابهای کاربر مانند «خاموش کردن کوکیهای شخص ثالث» با فشار دادن به کاربر برای تغییر تنظیمات خود واکنش نشان میدهند، که گاهی شامل مسدود کردن دسترسی به وبسایت میشود مگر اینکه انجام دهند. همچنین ممکن است از سیگنال انصراف به عنوان سیگنال اضافی برای انگشت نگاری استفاده شود. در این مقطع زمانی، گوگل قصد ندارد سیگنال انصراف ارائه دهد |
(همچنین در سه ماهه دوم گزارش شده است) جدول زمانی واضح تر | برنامههای انتشار واضحتر و دقیقتر | به روز رسانی Q3: همانطور که در بخش تغییرات در پاسخ به بازخورد زیر توضیح داده شد، Google جدول زمانی Privacy Sandbox را در ژوئیه بهروزرسانی کرد تا به بازار زمان بیشتری برای آزمایش اولیه و بازخورد بدهد، همچنین زمان بیشتری برای آزمایش پس از راهاندازی کامل APIهای Privacy Sandbox قبل از سوم کوکی های مهمانی منسوخ شده اند. |
(همچنین در سه ماهه دوم گزارش شده است) جدولهای زمانی منسوخ شدن کوکیهای شخص ثالث | درخواست برای جلوگیری از تاخیر بیشتر برای منسوخ شدن کوکی شخص ثالث | به روز رسانی Q3: در ماه ژوئیه، Chrome جدول زمانی بهروزرسانیشدهای را برای لغو کوکیهای شخص ثالث اعلام کرد که نشاندهنده تعهد ما به رفتار مسئولانه با توجه به پیچیدگی فناوریها و اهمیت آنها برای اکوسیستم است. قبل از این تغییر، بازخورد تنظیمکنندهها و صنعت مورد توجه قرار گرفت و ما به همکاری نزدیک با همه ذینفعان ادامه میدهیم. |
کوکی های شخص اول | آیا محدودیت هایی برای کوکی های شخص اول نیز پیشنهاد می شود؟ اگر چنین است، نگرانیها در مورد پایداری طولانیمدت، خطر تغییرات غیرقابل پیشبینی بیشتر مرورگر، و در نتیجه تلاشهای مهندسی اکنون به هدر رفته است. | ما هیچ محدودیتی برای کوکی شخص اول در نظر نگرفته ایم. تمرکز Privacy Sandbox روی منسوخ کردن کوکیهای شخص ثالث است. |
نمایش محتوا و تبلیغات مرتبط
موضوعات
موضوع بازخورد | خلاصه | پاسخ کروم |
(همچنین در سه ماهه دوم گزارش شده است) سودمندی برای انواع مختلف ذینفعان | نگرانی هایی در مورد سودمندی سایت ها بسته به سطح ترافیک یا تخصصی بودن محتوای آنها مطرح شده است. | به روز رسانی Q3: سودمندی API از طریق آزمایش بررسی خواهد شد. همانطور که طبق بند 17.c.ii تعهدات لازم است، Google نتایج چنین آزمایشهایی را با CMA به اشتراک میگذارد. کروم انتظار دارد طبقه بندی و سایر پارامترها بر اساس نتایج آزمایش تکامل یابد. تکامل طبقه بندی یا پارامترها ممکن است نیازی به تغییرات ناسازگار با عقب نداشته باشد. علاوه بر این، Chrome انتظار دارد بازخورد همچنان بر تکامل Topics API پس از منسوخ شدن کوکی های شخص ثالث تأثیر بگذارد. |
سیاست حفظ حریم خصوصی | درخواست حذف نیاز به فیلتر موضوع برای هر تماس گیرنده. | بر اساس بازخورد KOFs حریم خصوصی، مدافعان حریم خصوصی، کارشناسان امنیتی، گروههای حقوق دیجیتال و سایرین در اکوسیستم، Chrome این طرح را انتخاب کرد تا فقط به افرادی که در غیر این صورت چنین دسترسی داشتند، به اطلاعات دسترسی داشته باشند. دلایل این امر شامل، اما محدود به محدود نبودن، محدود کردن نشت اطلاعات متقابل افزایشی بود. تضمین شفافیت و توضیح پذیری؛ اتخاذ رویکردی که پیاده سازی و توصیف آن ساده باشد. و خطر انگشت نگاری را محدود می کند. ناشران و اشخاص ثالثی که Topics را دریافت میکنند، میتوانند خودشان تصمیم بگیرند که چه اطلاعاتی را در سایت خود با اشخاص به اشتراک بگذارند. اگر اشخاص ثالث این اطلاعات را به اشتراک بگذارند، Chrome قویاً آنها را تشویق میکند که در مورد چنین اشتراکگذاریهایی برای کاربران شفاف باشند و کنترلهایی را به آنها ارائه دهند. |
سایت های دسته بندی اشتباه | سایت ها به اشتباه در موضوع اشتباه دسته بندی می شوند که ممکن است منجر به هدف گذاری تبلیغات نادرست شود. | سایتها از طریق ترکیبی از فهرست نادیده گرفته شده توسط انسان، شامل محبوبترین سایتها و یک مدل ML روی دستگاه طبقهبندی میشوند. Chrome به ارزیابی گزینههای سایتها برای مشارکت در طبقهبندی موضوعات ادامه میدهد. هر گونه بهبود ابزار باید با خطرات حریم خصوصی و سوء استفاده سنجیده شود. به عنوان مثال، چند مورد از خطرات عبارتند از:
عموم می توانند این اجزا را با ابزار موجود از طریق chrome://topics-internals یا این colab بازرسی کنند. از طریق آزمایش، ما انتظار داریم که طبقه بندی در طول زمان بهبود یابد و از بازخورد نمونه هایی از سایت هایی که ممکن است به اشتباه طبقه بندی شوند استقبال می کنیم . |
الزامات دسترسی | الزامات فعلی موضوعات موجود برای موجودیت DOM در صفحه به عنوان یک اسکریپت یا iframe برای دسترسی ممکن است منجر به رفتارهای نامطلوب بازیکنان در اکوسیستم تبلیغات شود. | ما تغییری را در توضیح دهنده Github ادغام کرده ایم. ما قصد داریم از موضوعات در هدرهای HTTP پشتیبانی کنیم. |
موضوعات طبقه بندی به اندازه کافی دانه بندی نشده است | طبقه بندی موضوعات کنونی بسیار گسترده است و موضوعات جزئی تری مانند موضوعات منطقه ای را شامل نمی شود. | بهبود طبقه بندی یک تلاش مداوم است و ما انتظار داریم که طبقه بندی با آزمایش و ورودی اکوسیستم تکامل یابد. ما فعالانه به دنبال بازخورد در مورد طبقه بندی هستیم که برای اکوسیستم مفیدتر است. در ارزیابی اینکه آیا باید تعداد موضوعات را گسترش داد یا موضوعات جزئیتری را شامل شد، چند ملاحظات وجود دارد از جمله 1) پیامدهای بالقوه حفظ حریم خصوصی (مثلاً موضوعات بیشتر ممکن است خطر انگشت نگاری را معرفی کند) و 2) توانایی بازیابی موضوعات قبلاً مشاهده شده (مثلاً با موضوعات بیشتر، ممکن است شانس کمتری وجود داشته باشد که یک فناوری تبلیغاتی موضوع انتخاب شده را در گذشته دیده باشد). با گسترش شماره 2، گوگل به دنبال به حداکثر رساندن توانایی تماس گیرندگان برای بازیابی موضوعات مشاهده شده قبلی، در چارچوب نیاز فیلترینگ موجود، با هدف دستیابی به ابزار و حریم خصوصی است. |
محدودیت موضوعات | سه موضوع در هر وبسایت، اطلاعات بسیار کمی برای تبلیغکنندگان برای ارائه تبلیغات است. | بازخورد از اکوسیستم، به ویژه نتایج آزمایش از Origin Trials ما، همچنان بر تکامل API تأثیر خواهد گذاشت. شایان ذکر است که از Topics انتظار می رود سیگنال های دیگری مانند متنی را تکمیل کند تا به یافتن یک تبلیغ مناسب برای بازدید کننده کمک کند. بنابراین، میتواند اطلاعات بیشتری فراتر از موضوعات در اختیار تبلیغکننده قرار دهد. |
(همچنین در سه ماهه دوم گزارش شده است) کنترل و ایمنی کاربر | برخی موضوعات ممکن است پروکسی برای گروه های حساس باشند و کاربران برای جلوگیری از نتایج منفی به کنترل های بیشتری نیاز دارند. | به روز رسانی Q3: موضوعات نشان دهنده یک گام به جلو برای کنترل و شفافیت کاربر است. کاربران میتوانند از موضوعات انصراف دهند، موضوعاتی را که به آنها اختصاص داده شده را مرور کنند، موضوعات را حذف کنند و بفهمند که کدام شرکتها با موضوعات خود در صفحه معین تعامل دارند. علاوه بر این، کاربران همچنین می توانند موضوعات خود را با حذف تاریخچه مرور خود، که موضوعات از آن مشتق شده اند، پاک کنند. این کنترلها در حال حاضر در مرورگر کروم در سطح دستگاه اجرا میشوند. ما از ادامه بحث در مورد کنترلهای پیشرفتهتر کاربر، مانند موارد پیشنهادی توسط توسعهدهندگان استقبال میکنیم. با این حال، ما باید مطمئن شویم که افزودههای جدید برای رفع نگرانیهای مطرحشده به خوبی کالیبره شدهاند و منجر به ایجاد تغییرات جزئی نمیشوند. |
تاثیر بر سئو | ناشرینی که نام میزبان وب سایت خود را برای انعکاس بهتر موضوعات تنظیم می کنند، ممکن است بر سئو تأثیر منفی بگذارد. | ما به سایتها هشدار میدهیم که نام میزبان خود را صرفاً به خاطر موضوعات تغییر ندهند. درست است که یک سایت ممکن است از این طریق بتواند بر موضوعات اختصاص داده شده خود تأثیر بگذارد. اما مزایای انجام این کار برای ناشران در بهترین حالت نامشخص است و اگر سایتها سعی کنند مدل طبقهبندی را «بازی» کنند، ارزش موضوعات برای کل اکوسیستم را تضعیف میکند. تکالیف موضوع نیز ثابت نیست. ما انتظار داریم که طبقه بندی با آزمایش و ورودی به تکامل خود ادامه دهد. در ارتباط با این آزمایش، بازخورد را تشویق میکنیم ، از جمله نمونههایی از سایتهایی که ممکن است به اشتباه دستهبندی شوند. |
تقلب و سوء استفاده | راهی برای طرف خرید داشته باشید تا تأیید کند موضوعی که می بیند واقعاً توسط مرورگر ایجاد شده است. | ما از پیشنهاد برای حمایت از مکانیزمی برای خریداران فناوری تبلیغات برای تأیید موضوعات ارسال شده توسط فروشندگان در حراجهای تبلیغاتی برنامهریزی قدردانی میکنیم. ما اکوسیستم را تشویق می کنیم تا در بحث فعال در اینجا مشارکت کند. در حالی که ما در حال حاضر بر روی پیشرفتهای دیگر با اولویت بالاتر تمرکز کردهایم، میدانیم که این میتواند افزوده مهمی در آینده به طراحی باشد. |
تقلب و سوء استفاده | امکان بازبینی عمومی طرفهایی که کاربران قانونی دادههای Topics هستند، از طریق همان نوع پستگذاری و بازبینی عمومی که مجموعه شخص اول در معرض آن قرار میگیرد. | ما از این پیشنهاد قدردانی می کنیم و موافقیم که پاسخگویی عمومی ابزار مهمی برای کمک به دستیابی به اهداف جعبه ایمنی حریم خصوصی است. فراخوانیهای API موضوعات ذاتاً عمومی هستند، زیرا هر کسی میتواند از یک سایت بازدید کند و تماسهای دامنه به JavaScript API را مشاهده کند. بنابراین افراد و سازمانها میتوانند فعالیت مربوطه را مشاهده کنند و ارزیابی کنند که کدام سایتها و چگونه از موضوعات استفاده میکنند. ما معتقدیم که این رویکرد بهتری نسبت به ارزیابی "مشروعیت" یک سایت از عملکرد خود Topics API است. |
تاثیر بر سیگنال های شخص اول | سیگنال موضوعات ممکن است بسیار ارزشمند باشد و در نتیجه سایر سیگنالهای مبتنی بر علاقه شخص اول را کاهش دهد. | ما معتقدیم تبلیغات مبتنی بر علاقه یک مورد استفاده مهم برای وب است و Topics برای پشتیبانی از این مورد طراحی شده است. همانطور که در بالا توضیح داده شد، سایر ذینفعان اکوسیستم ابراز نگرانی کرده اند که موضوعات ممکن است به اندازه کافی برای ارائه ارزش مفید نباشند. در همه موارد، بهبود طبقه بندی یک تلاش مداوم است و ما انتظار داریم که طبقه بندی با آزمایش و ورودی اکوسیستم تکامل یابد. |
FLEDGE
موضوع بازخورد | خلاصه | پاسخ کروم |
حراج FLEDGE | چگونه SSP ها می توانند داده های ارسال شده به Google Ads را برای پیشنهاد مزایده FLEDGE قالب بندی کنند. | شرکتهایی که در آزمایش شرکت میکنند تشویق میشوند تا اسناد مربوط به برنامههای آزمایشی خود را منتشر کنند و در صورت لزوم با یکدیگر همکاری کنند. ما با CMA کار کردهایم تا رویکرد خود را برای آزمایشهای کمی توسعه دهیم و از انتشار یادداشتی در مورد طراحی آزمایش توسط CMA حمایت میکنیم تا اطلاعات بیشتری را برای شرکتکنندگان در بازار که قصد دارند با آزمایشها درگیر شوند و فرصتی برای اظهار نظر در مورد رویکردهای پیشنهادی ارائه کند. تیم Ad Manager اسنادی را برای فروشندگانی که علاقه مند به آزمایش FLEDGE با ناشرانی هستند که از Ad Manager به عنوان سرور تبلیغات خود استفاده می کنند، در اینجا پست کرده است. در اینجا جزئیات فنی بیشتری وجود دارد. |
FLEDGE در قاب های حصاردار تو در تو | قابهای حصاردار امکان تستهای محدودتر را فراهم میکنند، در حالی که در آیندهای نامشخص محدودتر میشوند. این جدول زمانی ناشناخته چالشی را برای اکوسیستم ایجاد می کند. | شرکتها میتوانند امروز FLEDGE را با فریمهای حصاردار آزمایش کنند. برای ارائه یک گزینه آسان تر نصب، شرکت ها می توانند ابتدا FLEDGE را پیاده سازی کنند. پس از اجرای FLEDGE، می توانند فریم های حصاردار را با طراحی FLEDGE خود تست کنند. |
سیاست رسیدگی به داده ها | سیاست رسیدگی به داده ها برای گروه های ذینفع / FLEDGE چیست؟ | در طراحی FLEDGE، تمام دادههای ذخیره شده در گروههای ذینفع، یا در مورد اینکه افراد در چه گروههایی هستند، روی دستگاه باقی میمانند. هیچ یک از این داده ها به سرور Google ارسال نمی شود. برخی از محافظتهای حریم خصوصی که Chrome برای FLEDGE برنامهریزی میکند شامل تعامل با یک سرور K-Anonymity توسط Google است. این تعامل با دقت طراحی شده است تا از اشتراک گذاری اطلاعات در مورد کاربران جلوگیری کند، و در یک محیط اجرای قابل اعتماد (TEE) اجرا شود تا از برابری اطلاعات در سراسر اکوسیستم تبلیغات اطمینان حاصل شود. \ Google به CMA متعهد شده است که پیشنهادات جعبه ایمنی حریم خصوصی را به گونهای طراحی و اجرا کند که با ترجیح دادن خود به کسبوکار Google، رقابت را مخدوش نکند و تأثیر آن بر رقابت در تبلیغات دیجیتال و ناشران و تبلیغکنندگان را در نظر بگیرد. ما به همکاری نزدیک با CMA ادامه می دهیم تا اطمینان حاصل کنیم که کار ما با این تعهدات مطابقت دارد. |
سیاست های سنی | Chrome چگونه تضمین میکند که مخاطبان ایجاد شده توسط FLEDGE از محدودیتهای سنی پیروی میکنند؟ | ناشران و تبلیغکنندگان بهترین موقعیت را دارند تا ارزیابی کنند که آیا مخاطبانی که با استفاده از FLEDGE ایجاد میکنند با قوانین قابل اجرا مطابقت دارند یا خیر. برای محافظت بیشتر از کاربران، اگر سن مرتبط با حسابشان کمتر از 18 سال باشد، حتی در طول دوره آزمایش، APIهای جعبه ایمنی حریم خصوصی برای هیچ یک از کاربرانی که وارد Chrome شدهاند فعال نخواهد بود. (برای کاربران خارج از سیستم، Chrome سیگنالهای نمایه را جمعآوری نمیکند که به مرورگر اجازه دهد سن کاربر را استنباط کند.) |
خدمات کلید/ارزش FLEDGE | وضوح بیشتر در مورد خدمات FLEDGE Key/Value، مانند تعداد کلیدها و تعداد دفعات به روز رسانی آنها. | شرکتهایی که از FLEDGE استفاده میکنند، میتوانند به همان اندازه که در RAM قرار میگیرند، کلید داشته باشند. برای جزئیات بیشتر، لطفاً به توضیح دهنده اینجا مراجعه کنید. ما به دنبال ارائه مسیری سریعتر برای اصلاح دادهها و استقبال از پیشنهادات برای هر الزامی هستیم. |
آزمایش کردن | آزمایش FLEDGE با تبلیغات گوگل سخت است | در مورد نحوه بهترین شرکت و آزمایش در آزمایش اولیه، به اسناد ورودی Google Ads مراجعه کنید. |
Bidding and Auction Services API | جهت Google برای Bidding and Auction Services API چیست؟ آیا در مزایدههای دستگاهها در بالا یا پایین مرورگر Chrome FLEDGE اولویتبندی میشود؟ | ما به طرح پیشنهادی فعلی FLEDGE روی دستگاه متعهد هستیم. خدمات مناقصه و مزایده برای بررسی راه حل های ممکن برای پشتیبانی از زیرمجموعه ای از موارد استفاده که در آن قدرت محاسباتی یا سرعت شبکه دستگاه ممکن است محدود باشد، پیشنهاد شده است. |
گزارش انبوه | درخواست برای پشتیبانی از گزارش های انبوه بر اساس تمام سیگنال های موجود برای تولید Bid. | ما قصد داریم به زودی موارد بیشتری را در این مورد به اشتراک بگذاریم. |
تبلیغات متنی | ارائه تبلیغات متنی با FLEDGE. | ما این گزینه را در نظر گرفتهایم و به دلایلی که در این بحث توضیح داده شد، در حال حاضر استفاده از FLEDGE را برای تبلیغات متنی توصیه نمیکنیم. |
تست در دنیای واقعی | راهنمای نحوه جداسازی FLEDGE از کوکی های شخص ثالث برای آزمایش در دنیای واقعی. | ما در حال بررسی راه هایی برای ارائه جمعیت های آزمایشی هستیم. ما با CMA کار کردهایم تا رویکرد خود را برای آزمایشهای کمی توسعه دهیم و از انتشار یادداشتی در مورد طراحی آزمایش توسط CMA حمایت میکنیم تا اطلاعات بیشتری برای فعالان بازار و فرصتی برای اظهار نظر در مورد رویکردهای پیشنهادی فراهم کند. |
تست FLEDGE و Attribution Reporting API | بهترین راه برای پیاده سازی Attribution Reporting API با FLEDGE چیست؟ آیا جدا کردن FLEDGE و Attribution یا آزمایش با هم ایده خوبی است؟ | ما در نهایت از آزمایش هر دو FLEDGE و Attribution Reporting API به عنوان یک راه حل یکپارچه پشتیبانی خواهیم کرد، اما توسعه دهندگان را تشویق می کنیم ابتدا API گزارش انتساب را به طور مستقل آزمایش کنند و پس از تکمیل ادغام با FLEDGE. |
مشاهده قیمت پیشنهادی | درخواست مبهم کردن قیمت های پیشنهادی | برای دسترسی به مقادیر پیشنهاد از DevTools، میتوان نقاط شکست را در «generateBid()» یا «scoreAd()» تنظیم کرد. تیم Chrome بردار حمله باریکی را که در این بازخورد در FLEDGE مطرح شده است در نظر گرفته است. با این حال، مدلهای امنیتی و حریم خصوصی Chrome، کاربران را قابل اعتماد میدانند که هر کاری را که میخواهند با اطلاعات روی دستگاه خود انجام دهند، و در نتیجه هیچ راه عملی برای پنهان کردن دادههای پیشنهادی طبق درخواست وجود ندارد. |
درخواست های اسناد و مدارک | مستندات و نمونه هایی برای آزمایش در یک اکوسیستم زنده. | ما قدردانی میکنیم که توسعهدهندگان مطالب فعلی ما را مفید دانستهاند و متعهد به ارائه مطالب بیشتر در هفتهها و ماههای آینده هستند تا توسعهدهندگان بتوانند به درک اینکه چگونه فناوریهای جدید میتوانند برای آنها کار کنند، ادامه دهند. ما همچنین ساعات اداری عمومی توسعهدهنده خارجی را برگزار کردهایم تا بهترین شیوهها و نمایشهای نمایشی را همراه با جلسات پرسش و پاسخ با محصولات و سرنخهای مهندسی به اشتراک بگذاریم تا امکان بحث/سوالات زنده وجود داشته باشد. |
Private Aggregation API | برای اطلاعات بیشتر در مورد API جمع آوری خصوصی درخواست می کنید؟ | یک توضیح عمومی با آخرین اطلاعاتی که در حال حاضر می توانیم به اشتراک بگذاریم در دسترس است. با توسعه این API و تعریف موارد استفاده، مستندات بیشتری ارائه خواهد شد. |
تأخیر داده ها | آیا بازیابی اطلاعات سرور FLEDGE Key/Value در زمان واقعی خواهد بود؟ | همانطور که در یک شماره باز GitHub توضیح داده شده است، ممکن است قبل از بازگرداندن داده های به روز شده توسط سرور برای پرس و جوها، مقدار کمی کهنگی به ترتیب چند دقیقه و نه ساعت پیش بینی شود. ما همچنین به دنبال بازخورد توسعه دهندگان هستیم. |
خدمات مناقصه و مزایده | آیا در صورت استفاده از خدمات مناقصه و مزایده (B&A) قیمت های پیشنهادی از کاربر پنهان می شود؟ | برای رویکرد B&A سمت سرور، قیمت پیشنهادی فردی برای کاربر قابل مشاهده نیست، زیرا درخواست پیشنهاد از سرویس حراج SSP مستقیماً به سرویس مزایده DSP ارسال می شود و بنابراین دیگر در مرورگر موجود نیست. با این حال، قیمت پیشنهادی برنده همچنان برای مرورگر قابل مشاهده خواهد بود (در مورد درخواستها برای مبهم کردن قیمتهای پیشنهادی، با جزئیات بیشتر در بالا بحث شد). |
خدمات مناقصه و مزایده | چگونه می توانیم خدمات مناقصه و مزایده تعادل را بارگیری کنیم؟ | ما در حال حاضر هیچ راهنمایی در مورد تعادل بار نداریم، اما این یک نگرانی مهم از منظر عملکرد و حفظ حریم خصوصی است. در آینده جزئیات بیشتری ارائه خواهیم کرد. |
محدودیت های FLEDGE | درخواست افزایش سقف مدت joinAdInterestGroup از 30 روز به 90 روز. | ما احساس میکنیم بازه زمانی 30 روزه حفظ دادهها با دیگر APIهای تبلیغاتی Privacy Sandbox، مانند محدودیت 30 روزه در گزارش Attribution و نگاهی 3 هفتهای به عقب در Topics، مطابقت دارد. این بازه زمانی هم نیازهای فناوری تبلیغات و هم انتظارات حریم خصوصی کاربران را برطرف می کند. با این حال، همچنان که به بحث در مورد این موضوع در اینجا ادامه می دهیم، از بازخورد بیشتر استقبال می کنیم. |
فضای ذخیره سازی مشترک در FLEDGE | آیا امکان استفاده از Shared Storage API در FLEDGE وجود دارد؟ | ما قصد داریم در آینده از Shared Storage API در FLEDGE پشتیبانی کنیم و در تلاش هستیم تا در Origin Trial آتی آن را در دسترس قرار دهیم. |
کنترل فرکانس با کلیک | آیا محدودیت فرکانس با کلیک (نه برنده) در FLEDGE امکان پذیر است؟ | FLEDGE مشخص میکند که یک Fenced Frame میتواند navigator.leaveAdInterestGroup() (بدون پارامتر) را فراخوانی کند تا از گروه علاقهای که باعث نمایش آگهی شده است، خارج شود. این تماس را میتوان برای اولین بار انجام داد که یک کلیک دریافت میشود تا از مناقصه آینده جلوگیری شود، به عنوان نوعی محدودیت فرکانس. در حال حاضر، این راه حل برای دربندی پس از بیش از یک کلیک کار نمی کند. |
FLEDGE در قاب های حصاردار تو در تو. | اگر کلیکها روی یک قاب حصاردار تو در تو رخ دهند، نمیتوان کلیکها را از طریق گزارشدهی تبلیغات قاب حصاردار گزارش کرد. | ما پیشنهادی را برای رفع مشکل در اینجا منتشر کرده ایم. |
اندازه گیری | در مورد نحوه جمعآوری دادههای تأخیر در مناقصهدهندگان در حراج FLEDGE به راهنمایی نیاز دارید. | ما در تلاش هستیم تا به زودی سند سنجش عملکرد را منتشر کنیم. |
گزارش نویسی | گزارش FLEDGE چگونه مدیریت خواهد شد؟ | گزارش FLEDGE در مورد پیروزی، نتیجه مزایده، رویداد به عنوان مثال کلیک ها از طریق APIهای FLEDGE مانند reportResult() در دسترس خواهد بود. در گزارشدهی با تبدیل آگهی، ادغام با Attribution Reporting API مستقل از FLEDGE خواهد بود، اما بحثهای مداومی با اکوسیستم در مورد رویکردهای احتمالی وجود دارد. Private Aggregation API همچنین می تواند برای گزارش نتایج حراج از داخل محیط های اجرای ایزوله استفاده شود. توضیح دهنده را اینجا ببینید. |
اندازه گروه علاقه | آیا راهی وجود دارد که ad-tech اندازه یک گروه علاقه مند (یعنی تعداد کاربران در گروه) را بررسی کند؟ | عضویت در گروه علاقهمندی توسط مرورگر، در دستگاه کاربر ذخیره میشود و با فروشنده مرورگر یا شخص دیگری به اشتراک گذاشته نمیشود. با این حال، مالک گروه ذینفع از نظر تئوری میتواند هر تماس با navigator.joininterestgroup(...) را ردیابی کند. ردیابی این تماس اندازه دقیق یک IG را تضمین نمیکند (زیرا کاربران میتوانند هر زمان که بخواهند گروه را ترک کنند)، اما به مالک یک حد بالا و اندازه تقریبی میدهد. |
کارایی | آیا کد Bidding JS/WebAssembly در هر حراجی کامپایل می شود؟ | کد JS/WebAssembly پیشنهادی یک بار در طول هر حراج کامپایل می شود. |
کارایی | محدوده biddingDurationMsec چیست؟ | biddingDurationMsec شامل زمان کامپایل اسکریپت است. این شامل زمان دانلود، زمان کامپایل wasm، زمان شبکه نمی شود. واکشی زمان از سرور ارزش کلیدی یا هر چیزی قبل از کامپایل JS. |
سفارشی سازی | آیا می توان adComponent را به گونه ای به روز کرد که برای کاربر سفارشی شود؟ | وقتی تماسگیرنده هنگام تماس با joinInterestGroup یا زمانی که Chrome با dailyUpdateURL تماس میگیرد، گروههای علاقه بهروزرسانی میشوند، adComponent را میتوان بهروزرسانی کرد. این به تماس گیرنده اجازه می دهد تا adComponent را بر اساس دانش کاربر از سایت فعلی یا بر اساس اطلاعات k-ناشناس به روز کند. معیارهای اصلی برای مورد استفاده توصیه. |
گروه علاقه مندی | آیا یک مالک گروه ذینفع ممکن است کاربران خاصی را به صورت مشروط حذف کند؟ | عضویت در گروه علاقهمندی فقط در مرورگر کاربر ذخیره میشود و فقط در سمت کاربر قابل حذف است (مثلاً با پاک کردن دادههای سایت). با این حال، اگر کاربر به صفحهای برگردد که تحت کنترل مالک گروه علاقهمند است، ممکن است مالک گروه علاقهمندی () navigator.leaveAdInterestGroup را (با یک منطق شرطی در اطراف آن) فراخوانی کند. |
کارایی | چگونه می توان عملکرد GenerBid را اندازه گیری کرد؟ | زمان کامپایل و اجرا را می توان با biddingDurationMsec اندازه گیری کرد. زمان دانلود را می توان با chrome://net-export اندازه گیری کرد. در نسخههای اخیر کروم، زمان کامپایل و اجرا در تب DevTools Performance نمایش داده میشود. |
فراوانی به روز رسانی گروه های علاقه مند | دفعات به روز رسانی گروه مورد علاقه از مرورگرها چقدر خواهد بود؟ | برای گروههای علاقهمندی که در 24 ساعت گذشته بهروزرسانی نشدهاند، Chrome سعی میکند زمانی که navigator.updateAdInterestGroups() فراخوانی میشود یا زمانی که فرصت شرکت در یک حراجی را داشتهاند، آنها را بهروزرسانی کند. برای جزئیات بیشتر به توضیح اینجا مراجعه کنید. |
ارائه دهندگان خدمات جمع آوری | چه زمانی سایر ارائه دهندگان ابر در سرویس Aggregation پشتیبانی می شوند؟ | ما در حال حاضر هیچ به روز رسانی در زمان های خاص نداریم، اما به محض انجام، موارد بیشتری را به اشتراک خواهیم گذاشت. در حال حاضر فقط AWS الزامات امنیتی سرویس تجمیع را برآورده می کند. |
جدول زمانی تست FLEDGE | چه مدت FLEDGE در BYOS آزمایش می شود؟ آیا زمان کافی برای تغییر از مدل BYOS به مدل مبتنی بر TEE وجود خواهد داشت؟ | برای اطمینان از اینکه اکوسیستم زمان کافی برای آزمایش دارد، انتظار نداریم تا زمانی پس از منسوخ شدن کوکی های شخص ثالث، به استفاده از TEE ها نیاز داشته باشیم. ما اخطار قابل توجهی را برای توسعه دهندگان ارائه خواهیم داد تا قبل از انجام این انتقال، آزمایش و پذیرش را آغاز کنند. ما در حال حاضر هیچ به روز رسانی بیشتری نداریم، اما به محض انجام، موارد بیشتری را به اشتراک خواهیم گذاشت. لطفا آخرین اطلاعات را اینجا بیابید. |
محدودیت اندازه داده | محدودیت اندازه داده برای wam در تابع مناقصه چقدر است. | این الزام وجود دارد که بهروزرسانیهای گروه علاقهمندی نتوانند منجر به گروه علاقهای بیش از 50 کیلوبایت شوند، همانطور که در اینجا بحث شد، اما محدودیت اندازه داده برای wam هنوز تعریف نشده است، بنابراین ما از اطلاعات ورودی در این موضوع قدردانی میکنیم. |
سیگنال های حراج | آیا یک ساختار داده استاندارد برای auctionSignals وجود خواهد داشت؟ | این هنوز تعریف نشده است، اما ما آماده بازخورد هستیم. |
پرس و جو از سرورهای فناوری تبلیغات | آیا امکان استعلام داده های سرور فناوری تبلیغات در زمان واقعی از یک سرور K/V وجود دارد؟ | خیر، سرور K/V در یک مدل اعتماد اجرا میشود که برای جلوگیری از افشای اطلاعات کاربر، «بدون شبکه، دسترسی به دیسک، تایمر یا گزارشگیری» را اجرا میکند. لطفاً توضیح مدل اعتماد را در اینجا برای جزئیات بیشتر ببینید. |
فرکانس به روز رسانی اجزای تبلیغاتی | به روز رسانی قسمت adComponents (در حال حاضر فقط در تنظیمات IG) توسط سابقه مرور کاربر در حال حاضر امکان پذیر نیست | هدف Privacy Sandbox پشتیبانی از نیازهای اکوسیستم وب بدون ردیابی بین سایتی است که به معنای جلوگیری از دسترسی به تاریخچه مرور است. توصیه می کنیم از جایگزین هایی مانند Topics استفاده کنید. |
نتایج حراج | آیا راهی وجود دارد که ad-tech ها نرخ برنده شدن حراج را بدانند؟ | نتیجه حراج با فراخوانی توابع reportResult() و reportWin() در کد حراج ارائه شده توسط فروشنده و خریدار برنده به ترتیب گزارش میشود، بنابراین هر کدام فرصتی برای ثبت گزارش و گزارش در مورد نتیجه حراج دارند. |
(همچنین در سه ماهه دوم گزارش شده است) پشتیبانی از هدف گذاری گروهی با علاقه منفی | یک API برای پشتیبانی از هدفگیری گروههای علاقه منفی: نمایش تبلیغات تنها در صورتی که کاربر به یک گروه علاقهمند تعلق نداشته باشد. | به روز رسانی Q3 : ما پیشنهاد جدیدی را به اشتراک گذاشته ایم و به دنبال بازخورد هستیم. |
اندازه گیری تبلیغات دیجیتال
گزارش انتساب (و سایر APIها)
موضوع بازخورد | خلاصه | پاسخ کروم |
الزامات OT | محدودیتهای Permission-Policy را در طول / فقط برای OT حذف کنید. | لطفاً تغییرات اعلام شده ما در Permissions-Policy را در طول آزمایش مشاهده کنید. نگرانی اصلی ذینفعان که در این تغییر به آن پرداخته شده است، این است که به DSPها اجازه می دهد API را روی مقدار بیشتری از iframe های متقاطع آزمایش کنند. در ابتدا، DSPها نیاز به هماهنگی با Publishers/SSPs داشتند تا مطمئن شوند که خط مشی مجوز مناسبی برای آزمایش API روی iframe های متقاطع تنظیم شده است، اما با این تغییر، DSP ها می توانند API را به طور پیش فرض فراخوانی کنند و SSPs/Publishers می توانند در صورت نیاز در طول آزمایش اولیه، API را غیرفعال کنید. |
سر و صدا | بازخوردی مبنی بر اینکه سطح نویز خیلی زیاد است و بر سودمندی گزارشدهی تأثیر میگذارد. | ما از بازخورد در مورد نویز استقبال می کنیم ، که از آن برای تعیین نحوه تنظیم پارامترهای خاص مربوط به نویز استفاده خواهیم کرد. همچنین به دنبال انتشار منابع، ابزارها و سایر اسناد بیشتر برای کمک به آزمایشکنندگان در این زمینه هستیم. |
تبدیل های بین دامنه ای | چگونه می توان تبدیل هایی را که متقابل دامنه هستند، مانند 2 یا چند مقصد، ردیابی کرد؟ | ما در حال حاضر در مورد این سوال بحث می کنیم و به دنبال بازخورد هستیم . |
الزامات اشکال زدایی | درخواست اجازه به توسعه دهندگان برای بررسی بودجه حفظ حریم خصوصی باقیمانده هنگام استقرار / آزمایش برای گزارش خلاصه دارید؟ | شما می توانید این درخواست ویژگی را در اینجا پیگیری کنید. |
سیاست های استفاده از API | بازخورد خطمشیهایی را برای افرادی که میتوانند از یک API معین بر اساس محدودیتهایی مانند اثر انگشت استفاده کنند، پیشنهاد میکند | این یک ایده بسیار جالب است و ما خوشحال خواهیم شد که با سایر ارائه دهندگان مرورگر و اکوسیستم وب گسترده تر در آن مشارکت کنیم. |
تنظیم انقضا در گزارش تبدیل | درخواست برای پشتیبانی از فیلتر گزارش / انقضا برای کمتر از 24 ساعت. | انقضای سطح ساعت منبع نگرانی در مورد حفظ حریم خصوصی است، زیرا به فناوری تبلیغاتی امکان میدهد دقیقاً بداند کاربر در چه ساعتی از سایت تبلیغکننده بازدید میکند. انقضای سطح روز به فناوری تبلیغات اجازه میدهد تا نمایشهای نامعتبر را بدون تعیین ساعت بازدید کاربر از سایت فیلتر کند. |
انقضای توکن OT | درخواست افزایش اعتبار نشانه های OT موجود برای کاهش سربار عملیاتی. | ما می دانیم که نشانه ها باید تمدید شوند و در تلاشند تا توسعه دهندگان را آسانتر کنند و اعلامیه دیگری ارائه دهند. |
حمایت منطقه ای | سرویس جمع آوری در حال حاضر از همه مناطق پشتیبانی نمی کند. | این یک محدودیت فعلی برای بتا است. ما انتظار داریم از مناطق اضافی با پیشرفت آزمایش پشتیبانی کنیم ، اما هنوز یک جدول زمانی مشخص برای این کار وجود ندارد. |
تأخیر گزارش سطح رویداد | تأخیر 2-30 روز در گزارش سطح رویداد ممکن است برای موارد استفاده خاص خیلی طولانی باشد. | ما در اینجا پیشنهادی را به اشتراک گذاشته ایم تا بتوانیم در هنگام ارسال گزارش های سطح رویداد از طریق انقضا ، تکنیک های تبلیغاتی را کنترل کنند. پیش فرض 30 روز است ، اما می توان آن را کوتاه تر کرد. |
(همچنین در Q2 گزارش شده است) انتساب چند لمسی | اجازه دهید انتساب چند لمسی مانند دستگاه های متقاطع یا برنامه های متقابل. | به روزرسانی Q3: روشهای فعلی انتساب چند لمسی مستلزم اتصال قطعی است تا برداشت های کاربر (و بنابراین هویت) را در وب سایت های مختلف به هم وصل کند. در نتیجه ، این عملکرد به شکل فعلی خود با اهداف Sandbox Privacy ، که هدف آن پشتیبانی از موارد اصلی استفاده از موارد بدون ردیابی متقابل در سایت است ، هماهنگ نیست. |
جدول زمانی ادغام گزارش و انتساب | جدول زمانی برای ادغام API API گزارش دهنده و انتساب چیست؟ | ما در حال حاضر هیچ به روزرسانی برای به اشتراک گذاشتن نداریم ، اما هنگامی که قادر به تعهد به یک جدول زمانی خاص هستیم ، اطلاعات بیشتری را ارائه می دهیم. |
انواع مختلف ماشه | درخواست انعطاف پذیری بیشتر در ثبت نام ماشه. | ما یک سیستم deduplication را برای API کل پیشنهاد کرده ایم که به تکنیک های تبلیغاتی در نحوه کنترل گزارش های سطح و قابل جمع شدن انعطاف پذیری بیشتری می دهد. |
اندازه گیری | درخواست دریافت داده های اندازه گیری در مورد عملکرد موجودی موجودی. | ما از بازخورد قدردانی می کنیم و به دنبال وضوح بیشتری در مورد استفاده (های) استفاده برای این درخواست هستیم. |
انقضاء | به جای فقط برچسب منبع ، درخواست پشتیبانی از انقضاء تبدیل در برچسب ماشه را کنید. | ما از بازخورد قدردانی می کنیم و به دنبال وضوح بیشتری در مورد استفاده (های) استفاده برای این درخواست هستیم. |
گزارش دسته | درخواست اندازه گیری بیشتر در گزارش دسته. | ما از بازخورد قدردانی می کنیم زیرا همچنان در مورد تأثیر خدمات جمع آوری فکر می کنیم. ما علاقه مندیم که بشنویم که چگونه AD Tech در مورد گزارش های دسته بندی و فرکانس مورد انتظار آنها و همچنین بازخورد در مورد چگونگی تغییر استراتژی دسته بندی در طول سال فکر می کند. |
اپسیلون | چه زمانی ارزش اپسیلون مشخص می شود؟ | ما به طور فعال با آزمایش کنندگان اکوسیستم برای نهایی کردن ارزش Epsilon و نحوه اجرای آن در GA کار می کنیم. این ارزش در ملاء عام قابل مشاهده خواهد بود ، همراه با بحثی که منجر به تصمیم ارزش شد. اگر بازخورد دارید ، لطفاً آن را در این شماره GH ارسال کنید. |
ردیابی پنهانی را محدود کنید
کاهش عامل کاربر
موضوع بازخورد | خلاصه | پاسخ کروم |
وابستگی های استقرار | پرداختن به وابستگی های استقرار کاربر ساخت یافته (SUA). | ما در نسخه های 101 و بالاتر ، "فاز 4" ، کاهش نسخه جزئی را به 100 ٪ از کاربران Chrome کاهش داده ایم. به روزرسانی را در اینجا مشاهده کنید. |
آزمایش کردن | درخواست برای گسترش آزمایش مبدأ کاهش کاربر و عامل از متا. | ما آزمایش مبدا را گسترش دادیم و مجوز حذف محدودیت های ترافیکی را برای اسکان در سایت های بزرگتر به دست آوردیم . محدوده ترافیک آرام در مورد هر مکان ، بزرگ یا کوچک اعمال می شود. |
اشاره مشتری عامل کاربر
موضوع بازخورد | خلاصه | پاسخ کروم |
(همچنین در Q2 گزارش شده است) نگرانی های ضد کلاهبرداری / ضد سوء استفاده | ویژگی های خاصی که ممکن است از طریق UA-CH از بین بروند: روی Redirect Tracker و کلیک های کلاهبرداری کلیک کنید. | به روزرسانی Q3 : ما از شرکتهایی که گزارش می دهند هیچ گونه عوارض جانبی در خطوط لوله ضد کلاهبرداری خود مشاهده نکرده اند ، بازخورد مثبتی دریافت کرده ایم (نتایج اینجا و اینجا ). این تیم در حال بررسی این مسائل احتمالی با ذینفعان ضد کلاهبرداری و اندازه گیری است. |
اجازه | آیا مجوز سیاست ذخیره شده است؟ | همانطور که در این موضوع GitHub توضیح داده شده است ، اجازه داده شده ذخیره نمی شود. |
gnatcatcher (WIP)
موضوع بازخورد | خلاصه | پاسخ کروم |
موارد استفاده از جغرافیا | Gnatcatcher ممکن است از کار با استفاده از جغرافیایی قانونی در آینده جلوگیری کند ، مانند شخصی سازی محتوا بر اساس جغرافیایی. | ما در حال همکاری با ذینفعان هستیم تا اطمینان حاصل کنیم که Chrome همچنان به پشتیبانی از موارد قانونی از آدرس های IP ادامه می دهد. |
مرزهای حفظ حریم خصوصی سایت را تقویت کنید
ست های شخص اول
موضوع بازخورد | خلاصه | پاسخ کروم |
خط مشی | این نگرانی که FPS با مقررات تعهدات CMA در مورد "قانون حمایت از داده های قابل اجرا" سازگار نیست ، بر این اساس که GDPR محدودیتی را برای تعداد سایت ها در یک مجموعه تحمیل نمی کند در حالی که FPS محدودیت 3 را پیش بینی می کند. | گوگل متعهد شده است كه CMA پیشنهادات Sandbox حریم خصوصی را به گونه ای طراحی و پیاده سازی كند كه رقابت را با پیشگیری از تجارت خود Google تحریف نمی كند و تأثیر خود را بر رقابت در تبلیغات دیجیتال ، ناشران و تبلیغات و همچنین تأثیرگذاری بر روی آن در نظر می گیرد. نتایج حفظ حریم خصوصی و رعایت اصول حفاظت از داده ها مطابق قانون قابل استفاده در قانون حفاظت از داده ها. نگرانی بیان شده هیچ ناسازگاری با GDPR را فاش نمی کند. ما همچنان با CMA همکاری نزدیکی داریم تا اطمینان حاصل کنیم که کار ما با این تعهدات مطابقت دارد. جزئیات بیشتر در بخش "تغییرات در پاسخ به بازخورد" در زیر گنجانده شده است. |
مستندات | درخواست نمونه های اضافی و به روزرسانی توضیح دهندگان موجود. | مثالهای موجود در توضیح دهندگان ما در حال بررسی است و در صورت لزوم هرگونه را روشن یا حذف می کند. |
اشتراک اول | پیشنهاد برای ایجاد ترجیحات در همان مجموعه های حزب. | ما از بازخورد استقبال می کنیم و در اینجا به طور جدی در مورد ایده بحث می کنیم. |
اجرا | فرآیندهای اجرایی شفاف خطر سوءاستفاده توسط بازیگران بد را دارند. | ما از بازخورد قدردانی می کنیم و به طور جدی درگیر گفتگو با ذینفعان در مورد GitHub هستیم (با توجه به نکات مطرح شده در این شماره و به دنبال ارائه پیشنهادات مطرح شده در این شماره ) و سایر انجمن ها برای ارزیابی این خطر و شناسایی کاهش احتمالی. |
مالکیت مشترک | پیشنهاد اعلامیه قابل خواندن با ماشین برای مالکیت مشترک. | ورودی به پیشنهاد ما مورد استقبال و تشویق قرار می گیرد. |
مالکیت زیر دامنه | آیا زیر دامنه های مختلف با کنترل کننده های مختلف داده ، سیاست های مختلف حفظ حریم خصوصی یا توسط اشخاص مختلف اداره می شود و بخشی از همان مجموعه شخص اول است؟ | بر اساس بازخورد ، ما قصد داریم مورد استفاده مشترک ETLD را حذف کنیم. |
کاهش | درخواست جزئیات بیشتر در مورد اقدامات کاهش سوءاستفاده. | مدیریت این فرآیند در حال بررسی است و جزئیات بیشتری در ماه های آینده به اشتراک گذاشته می شود. |
بردار حمله بالقوه | یک مجموعه مرتبط با فریبنده برای صفحات به راحتی قابل استفاده می تواند برای هدایت ترافیک به صفحات دیگر که فریبنده به عنوان مستقل ارائه می شوند ، استفاده شود. | ما به طور فعال در حال جمع آوری ورودی های عمومی و بررسی روش های بالقوه برای پرداختن به این مسئله هستیم. |
اعتبار سنجی | اعتبار سنجی مجموعه از طریق سیاست های مشترک رضایت بخش. | اعضای مختلف جامعه استاندارد وب و اکوسیستم گسترده تر اظهار داشتند که امکان پذیر نیست . |
حد حوزه | درخواست گسترش تعداد دامنه های مرتبط. | ما به طور جدی در مورد حد دامنه در FPS بحث می کنیم و از بازخورد بیشتر جامعه در مورد تعداد حوزه های مرتبط که برای موارد استفاده خود نیاز دارند قدردانی می کنیم. |
تعامل خدمات زیرمجموعه | نگرانی در مورد خدمات و تعامل زیر مجموعه مرتبط. | ما از بازخورد قدردانی می کنیم و به بررسی صریح تر در مشخصات آینده خواهیم پرداخت. |
(همچنین در Q2 گزارش شده است) بهبود حریم خصوصی | بسیاری از سایت های موجود در همان مجموعه می توانند منجر به نتایج مشابه کوکی های شخص ثالث شوند. | به روزرسانی Q3: آخرین پیشنهاد ، محدودیت سه حوزه برای زیر مجموعه "مرتبط" را نشان می دهد (که شامل CCTLDS و حوزه های خدمات نیست). Chrome به طور فعال با اکوسیستم درگیر است تا مشخص کند آیا این حد مناسب است یا خیر. |
(همچنین در Q2 گزارش شده است) الزام سیاست حفظ حریم خصوصی مشترک | حفظ یک خط مشی رازداری مشترک در تمام محصولات و حوزه های قضایی که باید بخشی از همان مجموعه باشند ، غیرقابل تحمل است. | به روزرسانی Q3: یک خط مشی رازداری مشترک دیگر الزامی برای بخشی از همان مجموعه نیست. |
قاب های حصارکشی API
موضوع بازخورد | خلاصه | پاسخ کروم |
چرا یک عنصر جدید به جای ویژگی های Iframes؟ | سوال در مورد پیشنهاد قاب آزاد شده به جای پیشنهادات موجود Iframe. | ما از بازخورد استقبال می کنیم و برای ایده هایی در مورد چگونگی همگرایی وضعیت فعلی چیزهایی که در اینجا بحث شده است ، باز هستیم. |
ناظر تقاطع در قاب های حصارکشی | سؤالات مربوط به مشاهده اطلاعات در یک قاب حصارکشی. | این در بحث فعال و در دوره اظهار نظر در این سند و در GitHub است. ما از شرکای خود استقبال می کنیم تا موارد استفاده را با خود به اشتراک بگذارند تا نحوه پشتیبانی بهتر را درک کنند. |
از موجودی ویدئویی و بومی پشتیبانی کنید | آیا قاب های حصارکشی از موجودی ویدیویی و بومی پشتیبانی می کنند؟ | از نظر قابلیت های پخش ویدیویی ، فریم های حصارکشی با Iframes متفاوت نیستند و به همین دلیل در هیچ اسناد عمومی به صراحت فراخوانی نمی شود. اگر مشکلی در مورد تبلیغات ویدیویی دیده می شود ، ارائه بازخورد برای ما مفید خواهد بود تا ما بتوانیم بیشتر تحقیق کنیم. |
بسته های وب | آیا سرو / ارائه تبلیغات توسط بسته های وب با Fleedge Frame X حصارکشی به یک نیاز در آینده تبدیل می شود؟ | هدف بلند مدت پشتیبانی از بسته های وب برای ارائه محتوای تبلیغاتی در یک قاب حصیری است. با این حال ، اجرای فعلی Fleedge از این امر پشتیبانی نمی کند ، و نیاز به ارائه یک منبع HTML گرفته شده از Renderurl دارد. |
ابعاد دارایی | درخواست Render_URL برای پشتیبانی از یک کلان برای ارتفاع و عرض شکاف به گونه ای که بتوانیم با یک خلاق مناسب و مناسب پاسخ دهیم | این به طور فعال در اینجا مورد بحث قرار می گیرد. |
API ذخیره سازی مشترک
موضوع بازخورد | خلاصه | پاسخ کروم |
یکپارچه سازی | ذخیره سازی و Fledge مشترک چگونه یکپارچه خواهد شد؟ | در حالی که ما در حال حاضر این موضوع را دنبال نمی کنیم ، اگر بتوانیم از حفظ حمایت از حریم خصوصی اطمینان حاصل کنیم ، علاقه مند به بررسی این ایده هستیم. ما طرفین علاقه مند را ترغیب می كنیم كه برای موارد استفاده بالقوه پیشنهاداتی را ارائه دهند كه این پیشنهاد می تواند در مخزن GitHub ذخیره سازی مشترک یا مخزن GitHub Fledge پشتیبانی كند. . |
نگهداری داده ها | پاکسازی ذخیره سازی مشترک باعث کاهش ابزار می شود. آیا پسوند به دوره احتباس یا توانایی حذف کلید/مقادیر فردی به عنوان گزینه های دیگر در نظر گرفته شده است؟ | ما همیشه به دنبال تعادل حفظ حریم خصوصی کاربر و تجارت ابزار هستیم. ما برای بازخورد در مورد تنظیمات باز هستیم و شرکا را ترغیب می کنیم تا هنگام آزمایش ذخیره مشترک ، بازخورد و جزئیات بیشتری را ارائه دهند . |
سیگنال منفی | سیگنال منفی از موزیلا در مورد پیشنهاد ذخیره سازی مشترک. | ما از موزیلا بخاطر بررسی دقیق آنها در مورد پیشنهاد ما تشکر می کنیم. ما قصد داریم در آینده نزدیک به بازخورد آنها پاسخ دهیم. |
چیپس
موضوع بازخورد | خلاصه | پاسخ کروم |
شرط تقسیم شده | نیاز به رفتار صریح را برای ویژگی "تقسیم بندی شده" در کوکی های شخص اول اضافه کنید. | ما در مورد تماس PrivacyCG این موضوع را مورد بحث قرار داده ایم و با یادداشت ها موضوع GitHub را دنبال کرده ایم. ما در حال همکاری با مرورگرها ، توسعه دهندگان و جامعه حریم خصوصی هستیم تا بر روی یک رفتار تراز کنیم و آن را مشخص کنیم. |
جاسازی های معتبر | تراشه ها ممکن است به دلیل پارتیشن بندی های مختلف که بر تعبیه های معتبر تأثیر می گذارد ، علامت SSO فعلی را در جریان تأثیر بگذارد. | ما از مورد استفاده جاسوسی معتبر آگاه هستیم و در حال تلاش برای کشف راه حل ها هستیم. |
محدودیت پارتیشن کوکی | این نگرانی که ممکن است 10 حد فعلی کوکی برای موارد خاص استفاده کافی نباشد. | ما از محدودیتی در تعداد کوکی ها به حد حافظه 12 کیلوبایت دور می شویم. انجام این کار به ما این امکان را می دهد تا در حالی که اطمینان از عملکرد و ردپای حافظه مرورگر را تضمین می کنیم ، نگرانی های مربوط به حد کوکی را برطرف کنیم. |
جدول زمانی آزمایشی مبدأ | گسترش OT را از بین بردن نیاز محدودیت نام میزبان دنبال کنید. | ما مهلت آزمایش مبدا را پس از بازخورد از اکوسیستم تمدید کرده ایم. |
محدودیت های آزمایش در کروم | امکان آزمایش تراشه در فایرفاکس به دلیل محدودیت فعلی در کروم. | اجرای Firefox تقریباً متفاوت است ، کروم از حد کوکی پایین تر برخوردار است و تراشه ها یک مکانیسم انتخابی است ، اما Firefox به طور پیش فرض تقسیم می شود. |
(همچنین در Q2 گزارش شده است) جاسازی های معتبر | آیا وضعیت ورود به سیستم با تراشه ها حفظ شده است؟ | به روزرسانی Q3: در حال حاضر امضا شده در ایالت حفظ نشده است ، اما این مورد استفاده در نظر گرفته شده برای تراشه ها نیست. ما از مورد استفاده جاسوسی معتبر آگاه هستیم و در حال تلاش برای کشف راه حل ها هستیم. |
فدستان
موضوع بازخورد | خلاصه | پاسخ کروم |
(همچنین در Q2 گزارش شده است) بردارهای حمله بالقوه | بردارهای بالقوه حمله از طریق دکوراسیون پیوند و حملات زمان بندی. | به روزرسانی Q3: ما با موزیلا همکاری کرده ایم تا به درک مشترکی در مورد چگونگی رسیدگی به مشکل حمله زمان و جزئیات در اینجا برسیم. اکنون ما در حال نمونه سازی این تغییر معماری هستیم و انتظار داریم که در چند چهارم آینده آزمایشاتی را انجام دهیم. |
ارائه دهندگان هویت | انتخاب کننده حساب: ارائه دهنده هویت واحد. درخواست اجازه دادن به چندین ارائه دهنده هویت. | ما با فروشندگان مرورگر و FedID CG در مورد چگونگی دستیابی به ارائه دهندگان هویت متعدد کار کرده ایم و به فرمولاسیون رسیده ایم که به نظر می رسد ارزش امتحان کردن را دارد. توضیحات این پیشنهاد در اینجا است و ما انتظار داریم نمونه های اولیه را توسعه داده و آزمایشات را در چند چهارم آینده انجام دهیم. |
مسائل شناخته شده با فدراسیون | درخواست برای شماری از مواردی که فدراسیون ممکن است با استهلاک کوکی شخص ثالث دچار مشکل شود. | FEDID CG دارای یک مورد کار است که می تواند شیوه های شکستن فدراسیون در اینجا و اینجا را ذکر کند. آنها همچنین در حال ساخت ماتریس تصمیم گیری برای نقشه برداری از API های پلت فرم وب در اینجا هستند. |
پارامتر تاج | آیا پارامتر DOUNCE می تواند روی علامت در جریان تأثیر بگذارد؟ | این می تواند ردیابی بین سایت در نظر گرفته شود ، اما ما هنوز در حال جمع آوری ورودی و تجزیه و تحلیل نحوه درمان چنین مواردی هستیم. |
رضایت کاربر | پیوند دادن احزاب متکی مختلف (RP) و رضایت کاربر برای هر منشاء. | این مشخصات نمی تواند کنترل کند که منشأ در همان کوکی های سهم دامنه است. این مشخصات اجازه می دهد تا از منشأ IDP تا منشأ RP استفاده کند ، اما این وظیفه RP است که انتخاب کند که آیا علامت در وضعیت کاربر باید در یک کوکی قفل شده به آن مبدأ واحد یا یک کوکی که با منشاء در همان است ذخیره شود دامنه. |
حساب IDP قابل حمل بودن | در صورت انتخاب بین دو IDP ، گزینه کاربر برای مهاجرت از IDP ها. | این به نظر می رسد مانند کاری است که کاربر باید مستقیماً در صفحه ثبت نام از IDP جدید مورد نظر خود انجام دهد ، نه از طریق API FEDCM. |
حذف حساب | حسابداری ابطال IDP برای حذف حساب با IDP. | این درخواست ویژگی برای ورودی و تحت بررسی باز است . |
ادعای UI | ادعاهای مربوط به جنبه های رابط خاص مرورگر. | برای پرداختن به این موضوع به درخواست PULL مراجعه کنید. |
بررسی ارجاع IDP | بررسی IDP برای مراجعه کننده RP. | بررسی ارجاعگر IDP اجباری اضافه شده به مشخصات. به درخواست کشش مراجعه کنید. |
ورود به سیستم | درخواست ورود به سیستم بر اساس تنظیمات RP. | ما از این ایده استقبال می کنیم و به طور جدی در مورد آن بحث می کنیم. |
با هرزنامه و کلاهبرداری مبارزه کنید
Trust Tokens API
موضوع بازخورد | خلاصه | پاسخ کروم |
کلاهبرداری و سوء استفاده | ابزارهایی برای اطمینان از اینکه یک ربات یک صادرکننده را در دادن نشانه ای به آن فریب نداده است ، که یک ربات نشانه ای را که به یک کاربر واقعی صادر شده است و برای جلوگیری از صدور ربات ها از صداهای مخرب گرفته نشده است؟ | در حالی که ممکن است رباتها بتوانند از یک صادرکننده نشانه بگیرند ، صادرکنندگان تشویق می شوند که چند بار نشانه ها و روشهای قوی برای صدور نشانه ها و به روزرسانی منطق صدور خود را به عنوان بازیگران مخرب سعی در دور زدن آنها داشته باشند. صادرکنندگان بدون منطق کافی در صدور نشانه ها احتمالاً در اکوسیستم کمتر مورد اعتماد قرار می گیرند زیرا وب سایت ها بسته به صادرکنندگان قوی تر اولویت بندی می کنند. |
کلاهبرداری و سوء استفاده | آیا راهی وجود دارد که یک رستاخیز Trust Token بتواند مشخص کند که آنها فقط نشانه های اعتماد از نهادهای خاص را می پذیرند؟ | بله، این امکان پذیر است. بخش رستگاری Trust Token در توضیح دهنده نحوه عملکرد این کار را توضیح می دهد. |
کلاهبرداری و سوء استفاده | آیا راهی برای صادرکننده Trust Token وجود دارد که لیستی از رستگاری ها را تعریف کند و به کسی اجازه ندهد که نشانه ها را بازخرید کند؟ | در حال حاضر نه ، اما تیم در حال بررسی این پرونده استفاده است. |
جدول زمانی | چه زمانی API Trust Token به طور کلی در دسترس خواهد بود؟ | به محض اینکه بتوانیم به یک جدول زمانی متعهد شویم ، اطلاعات بیشتری را به صورت عمومی به اشتراک خواهیم گذاشت. |
(همچنین در Q2 گزارش شده است) نگهداری بالای سر | مشخص نیست که نسخه های پروتکل چه مدت پشتیبانی می شوند. | به روزرسانی Q3: پشتیبانی اضافی در API ها برای پشتیبانی از چندین نسخه همزمان اضافه می شود تا امکان انتقال برازنده بین نسخه ها فراهم شود ، اگرچه بازه های زمانی برای پشتیبانی / استهلاک هنوز کار می شود. |