گزارش فصلی برای سه ماهه چهارم سال 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 متعهد شده است که پیشنهادات جعبه ایمنی حریم خصوصی را به گونهای طراحی و اجرا کند که با ترجیح دادن خود به کسبوکار Google، رقابت را مخدوش نکند و تأثیر آن را بر رقابت در تبلیغات دیجیتال و ناشران و تبلیغکنندگان، صرف نظر از ما به همکاری نزدیک با CMA ادامه می دهیم تا اطمینان حاصل کنیم که کار ما با این تعهدات مطابقت دارد. با پیشرفت تست Privacy Sandbox، یکی از سوالات کلیدی که ما ارزیابی خواهیم کرد این است که فناوری های جدید چگونه برای انواع مختلف ذینفعان عمل می کنند. بازخورد از این نظر بسیار مهم است، به ویژه بازخوردهای خاص و عملی که می تواند به ما در بهبود بیشتر طرح های فنی کمک کند. ما با CMA کار کردهایم تا رویکرد خود را برای آزمایشهای کمی توسعه دهیم و از انتشار یادداشتی در مورد طراحی آزمایش توسط CMA حمایت میکنیم تا اطلاعات بیشتری را به شرکتکنندگان بازار و فرصتی برای اظهار نظر در مورد رویکردهای پیشنهادی ارائه کنیم." |
(همچنین در سه ماهه سوم گزارش شده است) درخواست های اسناد و مدارک | درخواست برای منابع بیشتر در مورد نحوه مدیریت تست، تجزیه و تحلیل و پیاده سازی | به روز رسانی Q4: ما قدردانی میکنیم که توسعهدهندگان مطالب فعلی ما را مفید دانستهاند و همچنان متعهد به ارائه مطالب بیشتر هستند تا توسعهدهندگان بتوانند بفهمند فناوریهای جدید چگونه میتوانند برای آنها کار کنند. در سه ماهه گذشته، بخش «اخبار و بهروزرسانیها» را به privacysandbox.com اضافه کردهایم و بررسی گستردهای درباره اینکه چگونه جعبه ایمنی حریم خصوصی میتواند به افزایش ارتباط آگهی در آینده کمک کند، منتشر کردیم. ما همچنین جلسات ساعات اداری برنامهنویس عمومی را برای به اشتراک گذاشتن بهترین شیوهها و نمایشهای نمایشی، همراه با جلسات پرسش و پاسخ با محصولات و سرنخهای مهندسی برگزار کردهایم تا امکان بحث/سوالات زنده را فراهم کنیم. |
Core Web Vitals | چگونه تأخیر Privacy Sandbox API بر Core Web Vitals تأثیر می گذارد؟ | حفظ تأخیر به حداقل یک هدف کلیدی طراحی APIهای Privacy Sandbox است. انتظارات فعلی ما این است که تأخیر API حداقل تأثیری بر Core Web Vitals یک سایت داشته باشد، زیرا اکثر API ها پس از رندر اولیه وب سایت فراخوانی می شوند. ما همچنان به نظارت و بهبودهایی برای کاهش بیشتر تأخیر برای هر یک از APIها ادامه میدهیم و آزمایشها و بازخوردهای مداوم را تشویق میکنیم. تأخیر در فرآیند مناقصه زمان واقعی در بخش FLEDGE در بخش "عملکرد مزایده های FLEDGE" بررسی می شود. |
قابلیت همکاری | نگرانی در مورد قابلیت همکاری با سایر راه حل های بالقوه | هدف Privacy Sandbox محافظت از کاربران در برابر ردیابی بین سایتی و در عین حال پشتیبانی از نیازهای اکوسیستم وب است. ما به دنبال این هستیم که با دور شدن از فناوریهای مرورگر قدیمی که چنین ردیابی بینسایتی مانند کوکیهای شخص ثالث را امکانپذیر میکنند، به انجام برسانیم و در جای خود فناوریهای جدیدی را که برای پشتیبانی از موارد استفاده خاص ساخته شدهاند، انجام دهیم. پیشنهادات جعبه ایمنی حریم خصوصی با محدود کردن دادههایی که از دستگاه کاربر خارج میشود، حریم خصوصی را بهبود میبخشد. این پیشنهادها محدودیتهای فنی برای توانایی وبسایت برای اشتراکگذاری یا پردازش دادههای جمعآوریشده از مرورگر ایجاد نمیکنند. بنابراین، فناوریها مانع از ورود شرکتها به قراردادهای «مدیریت داده» یا هر رابطه قراردادی مشابه دیگری نمیشوند. به همین ترتیب، آنها توانایی کاربران را برای رضایت به اشتراک گذاری داده های خود از طریق روش های دیگر محدود نمی کنند. برای وضوح، Google متعهد شده است که فناوریهای جعبه ایمنی حریم خصوصی را به یک روش برای همه وبسایتها، از جمله محصولات و خدمات Google، اعمال کند. پس از پایان پشتیبانی Chrome از کوکیهای شخص ثالث، تعهدات همچنین مشخص میکند که Google از سایر دادههای شخصی، مانند سابقه همگامسازی مرور کروم کاربران، برای ردیابی کاربران برای هدفیابی یا اندازهگیری تبلیغات دیجیتال استفاده نخواهد کرد. |
نمایش محتوا و تبلیغات مرتبط
موضوعات
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تاثیر بر رتبه بندی جستجوی گوگل | پرس و جو در مورد اینکه آیا پشتیبانی از Topics API یک وب سایت به عنوان یک سیگنال بالقوه برای رتبه بندی نتایج جستجوی Google استفاده می شود یا خیر | برخی از وبسایتها ممکن است انتخاب کنند که از موضوعات API انصراف دهند. تیم Privacy Sandbox هماهنگی نکرده یا از سازمان جستجو درخواست نکرده است که از رتبه بندی صفحه به عنوان انگیزه ای برای وب سایت ها برای استفاده از Topics API استفاده کند. Google به CMA تأیید کرده است که جستجوی Google از تصمیم سایت برای انصراف از Topics API به عنوان سیگنال رتبه بندی استفاده نمی کند. |
طبقه بندی موضوعات | URL و محتوای صفحه را علاوه بر نام میزبان برای تعیین موضوع صفحه وب به منظور بهبود سودمندی برای سهامداران مختلف اضافه کنید. | تاریخچه مرور کاربر در حال حاضر با استفاده از نام میزبان وب سایت طبقه بندی می شود. Chrome به ارزیابی گزینهها برای در نظر گرفتن فراداده سطح صفحه (مانند همه یا برخی از اجزای URL صفحه و/یا محتوا) در طبقهبندی موضوعات ادامه میدهد. هر گونه بهبود ابزار باید با خطرات حریم خصوصی و سوء استفاده سنجیده شود. به عنوان مثال، با توجه به فراداده به طور خاص، تعدادی از خطرات عبارتند از: - سایت هایی که ابرداده های سطح صفحه را به عنوان روشی برای رمزگذاری معانی مختلف (و بالقوه حساس) در موضوعات تغییر می دهند. - سایتهایی که ابردادههای سطح صفحه را تغییر میدهند تا موضوعات خود را برای سود مالی نادرست معرفی کنند. - سایت هایی که ابرداده های سطح صفحه را به صورت پویا به عنوان روشی برای ردیابی بین سایتی تغییر می دهند |
(همچنین در سه ماهه سوم گزارش شده است) تاثیر بر سیگنال های شخص اول | سیگنال موضوعات ممکن است بسیار ارزشمند باشد و در نتیجه سایر سیگنالهای مبتنی بر علاقه شخص اول را کاهش دهد. | پاسخ ما نسبت به Q3 بدون تغییر است: "ما معتقدیم تبلیغات مبتنی بر علاقه یک مورد استفاده مهم برای وب است، و Topics برای پشتیبانی از این مورد طراحی شده است. همانطور که [در گزارش سه ماهه سوم ما] توضیح داده شد، سایر ذینفعان اکوسیستم ابراز نگرانی کرده اند مبنی بر اینکه Topics ممکن است به اندازه کافی برای ارائه مفید نباشد. ارزش. در همه موارد، بهبود طبقه بندی یک تلاش مداوم است و ما انتظار داریم که طبقه بندی با آزمایش و ورودی اکوسیستم تکامل یابد." |
به روز رسانی طبقه بندی | لیست طبقه بندی چگونه به روز می شود؟ | ما فعالانه به دنبال بازخورد در مورد طبقه بندی هستیم که برای اکوسیستم مفیدتر است. طبقه بندی موجود در پیشنهاد اولیه Topics API برای فعال کردن تست عملکردی طراحی شده است. کروم به طور فعال چندین رویکرد را برای به روز رسانی طبقه بندی در نظر می گیرد. به عنوان مثال، Chrome ممکن است از مفهوم ارزش تجاری برای هر موضوع استفاده کند تا مشخص کند کدام دسته را در تکرارهای بعدی قرار دهد. |
موضوعات عملکرد طبقه بندی کننده منطقه ای | طبقهبندیکننده موضوعات در حوزههای منطقهای ضعیف عمل میکند | بهبود طبقه بندی کننده یک تلاش مداوم است. بر اساس بازخوردی که دریافت کردهایم، یکی از امکانهای مورد بررسی گسترش فهرست لغو موضوعات است، که تحلیل ما نشان میدهد که پوشش جهانی را افزایش میدهد و دقت را بهبود میبخشد. برای توضیح، طبقهبندی Topics API دارای دو مؤلفه مرتبط است: (1) فهرست لغو شامل 10 هزار سایت برتر و موضوعات آنها، و (2) یک مدل ML روی دستگاه که نامهای میزبان را به موضوعات طبقهبندی میکند. با گسترش فهرست لغو (1)، میتوانیم عملکرد طبقهبندی را برای مناطقی که طبقهبندیکننده در آنها ضعیف عمل میکند، بهبود بخشیم. |
دوره یک هفته ای | دوره یک هفته ای برای کاربرانی که به دنبال تصمیم گیری کوتاه مدت هستند بسیار طولانی است. | ما فعالانه به دنبال این هستیم که طول دوره مناسب چقدر باید باشد و از بازخورد بیشتر در مورد اینکه چه دوره ای برای اکوسیستم بهتر است استقبال می کنیم. |
بازیابی هدر HTTP | نگرانی از اینکه اطلاعات کافی در مورد بازیابی هدر HTTP موضوعات وجود ندارد | کار برای هدرها و fetch() در حال انجام است. ما همچنین اطلاعاتی را در اینجا در دسترس داریم. ما همچنین اطلاعات skipObservation را به توضیح دهنده اضافه کرده ایم . |
هدف موضوعات فقط کمک به تبلیغکنندگان است، نه کاربران | به نظر می رسد جعبه ایمنی موضوعات/حریم خصوصی یک رویکرد متمرکز بر صنعت باشد. سود برای کاربران به اندازه سود برای صنعت روشن نیست. | ما معتقدیم که مزیت برای کاربران این است که Topics از تبلیغات مبتنی بر علاقه پشتیبانی می کند که وب را آزاد و باز نگه می دارد، و همچنین معتقدیم که حریم خصوصی را به طور قابل توجهی در مقایسه با کوکی های شخص ثالث بهبود می بخشد . حذف کوکیهای شخص ثالث بدون جایگزینهای مناسب ممکن است بر ناشران تأثیر منفی بگذارد و به رویکردهای بدتر منجر شود. که کمتر خصوصی هستند، شفاف نیستند و به طور واقعی توسط کاربران قابل تنظیم مجدد یا کنترل نیستند. بسیاری از شرکتها بهطور فعال موضوعات و APIهای Sandbox را آزمایش میکنند، و ما متعهد به ارائه ابزارهایی برای ارتقای حریم خصوصی و پشتیبانی از وب هستیم. گروه معماری فنی W3C اخیراً دیدگاه اولیه خود را در مورد Topics API منتشر کرده است که ما به صورت عمومی به آن پاسخ خواهیم داد. در این مرحله، از آنجایی که گوگل از اکوسیستم سؤالاتی در مورد آنچه که این بررسی ممکن است برای توسعه و راهاندازی Topics API داشته باشد، دریافت کرده است، مایلیم برنامه خود را برای در دسترس قرار دادن آن در Chrome Stable در سال جاری مجدداً تأیید کنیم. در حالی که Googles از ورودی گروه معماری فنی W3C قدردانی می کند، ادامه تلاش ها برای توسعه و آزمایش موضوعات را با مشورت CMA و اکوسیستم بسیار مهم می داند. |
نشت داده ها | نگرانی از اینکه موضوعات ممکن است بدون اجازه به سایت های دیگر درز کند | طراحی Topics API باعث میشود که اطلاعات یک ناشر (و حتی گروه کوچکتری از ناشران) به هیچ وجه به بیرون درز نکند. وبسایتهای ناشر نیز بر روی Topics API کنترل کامل دارند و میتوانند از طریق خطمشی مجوز، دسترسی به این API را ممنوع کنند. |
عدم وجود تبلیغ کننده برای آزمایش | ناشران نگران هستند که در حال حاضر نمی توانند ارزش موضوعات را به تبلیغ کنندگان نشان دهند. | در نیمه دوم سال 2023، ما قصد داریم تمام API های مرتبط با تبلیغات را برای آزمایش یکپارچه سازی در دسترس داشته باشیم و تجزیه و تحلیل اکوسیستم ارزش موضوعات را برای تبلیغ کنندگان فعال کنیم. آزمایش و انتشار نتایج توسط CMA نظارت خواهد شد که داده ها، تجزیه و تحلیل و روش شناسی را بررسی خواهد کرد. اکوسیستم تشویق می شود تا بازخورد خود را با Google و CMA به اشتراک بگذارد. |
موضوعات و FLEDGE | برای اطلاعات بیشتر در مورد نحوه استفاده از موضوعات در منطق مناقصه FLEDGE درخواست کنید | امکان استفاده از موضوعات در منطق مناقصه FLEDGE وجود دارد . راهنمای ادغام نیز در حال انجام است و شامل جزئیات بیشتری در مورد پیاده سازی خواهد بود. |
رتبه بندی سفارشی برای موضوعات تماس گیرنده | اجازه دهید رتبه بندی توسط تماس گیرنده تنظیم شود | چالش با رتبه بندی موضوع یا مقادیر سفارشی برای هر فناوری تبلیغاتی این است که این می تواند به مکانیزمی تبدیل شود که از طریق آن یک فناوری تبلیغاتی می تواند بر موضوعاتی که برگردانده می شوند تأثیر بگذارد، بنابراین بردار اثر انگشت. |
موضوعات لیست اولویت تماس گیرنده | به تماسگیرندگان اجازه دهید فهرست اولویتبندیشدهای از موضوعاتی که Topics API بر اساس واجد شرایط بودن آنها را برمیگرداند، ارائه دهند. | ما در حال حاضر در حال بحث بیشتر درباره این ایده هستیم و از ورودی های اضافی استقبال می کنیم. |
FLEDGE
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
Google Ad Manager | نگرانی از اینکه Google Ad Manager تصمیمگیرنده نهایی حراجهای FLEDGE است و به نفع Google Publisher Tags و Google Ad Manager است. | FLEDGE به هر ناشر اجازه می دهد تا ساختار حراج را انتخاب کند، از جمله انتخاب فروشندگان سطح بالا و قطعات. هر خریدار و فروشنده در حراج قطعات میداند فروشنده سطح بالا کیست و میتواند انتخاب کند که پیشنهاد دهد یا نه. |
شرکت کنندگان کافی در حال آزمایش FLEDGE نیستند | درخواست تشویق شرکتهای بیشتری برای آزمایش FLEDGE، برای مثال با بهبود عملکرد API و ممانعت از جایگزینهای مزاحم حریم خصوصی مانند اثر انگشت | جعبه ایمنی حریم خصوصی در مراحلی با همکاری نزدیک با راهنمایی CMA و ICO پیش می رود و آزمایش عملکردی FLEDGE پایداری و قابلیت لازم را نشان داده است. Google همچنان به تشویق اکوسیستم برای آزمایش Sandbox API ها ادامه میدهد و اخیراً اسناد « به حداکثر رساندن ارتباط آگهی » خود را منتشر کرده است تا نشان دهد چگونه FLEDGE و سایر APIها میتوانند به پشتیبانی از موارد استفاده حیاتی برای صنعت تبلیغات پس از منسوخ شدن کوکیهای شخص ثالث کمک کنند. سایر بخشهای جعبه ایمنی حریم خصوصی در حال حاضر از اقدامات کاهشی برای پوشش ردیابی پشتیبانی میکنند (به UA-CH، حفاظت IP، و کاهشهای ردیابی جهشی مراجعه کنید) و در طول زمان بهبود خواهند یافت. هدف Google این نیست که FLEDGE را به تنها راهحل هدفیابی بادوام تبدیل کند، بلکه در عوض متعهد به همکاری با صنعت و قانونگذاران برای هدایت بهترین فناوریهای تبلیغاتی حفظ حریم خصوصی در مرورگر کروم است. |
موارد استفاده از یادگیری ماشین | راهنمایی بیشتر در مورد نحوه استفاده از موارد یادگیری ماشین برای آموزش الگوریتمهای پیشنهاد مزایده در FLEDGE و Attribution Reporting پشتیبانی میشود. | ما نیاز به کمک به آزمایشکنندگان را میدانیم تا مفیدترین روشها را برای استفاده از فناوریهای جعبه ایمنی حریم خصوصی پیدا کنند. ما شروع به انتشار راهنماییهایی کردهایم که بهطور خاص مربوط به استفاده از جنبههای مختلف APIهای جعبه ایمنی حریم خصوصی بهعنوان ورودیهای یادگیری ماشینی است. جدیدترین قطعه، " به حداکثر رساندن ارتباط تبلیغات "، به این موضوع میپردازد که چگونه صنعت تبلیغات میتواند از این سیگنالها برای یادگیری ماشین استفاده کند، و ما قصد داریم به انتشار چنین راهنماییهایی در آینده ادامه دهیم. |
پرس و جو FLEDGE ارزش کلید (K/V) سرور | چرا سرور K/V به صورت عمومی قابل استعلام است؟ | هدف سرور K/V ارائه سیگنالهای بلادرنگ به حراجهای FLEDGE است. به این ترتیب، سرور K/V باید از جایی که مزایدههای FLEDGE اجرا میشوند، که در دستگاههای کاربر است، قابل دسترسی باشد و نیاز است که در دسترس عموم قرار گیرد. مقدار ذخیره شده در سرور K/V را فقط می توان توسط طرفی که از قبل کلید خود را دارد بازیابی کرد - بنابراین اگر یک فناوری تبلیغاتی کلیدها را فقط به مرورگرهایی که در گروه علاقه هستند بدهد و از کلیدهایی که به طور تصادفی قابل حدس زدن هستند استفاده نکند. ، فقط مرورگرهایی که برای اجرای حراج خود به مقدار نیاز دارند می توانند آن را بازیابی کنند. |
چگونه هدف گذاری تاریخ/زمان را انجام دهیم؟ | پشتیبانی از اشیاء تاریخ در تابع منطق مناقصه. | راه های متعددی برای این کار وجود دارد. خریداران می توانند از فروشنده خود بخواهند که تاریخ و زمان فعلی را ارائه کند و ارائه این اطلاعات به همه خریداران برای فروشندگان باید آسان باشد. خریداران همچنین میتوانند تاریخ و زمان را در پاسخ ارزش کلیدی خود در زمان واقعی ارائه دهند. در نهایت، خریداران میتوانند تاریخ و زمان را بهعنوان بخشی از پاسخ متنی خود در سیگنالهای هر خریدار ارائه کنند، که فروشنده میتواند آن را به اسکریپت GenerBid خریدار منتقل کند. |
تنظیمات برگزیده کاربر | امکان انتخاب کاربران برای مسدود کردن خلاقیتها توسط تبلیغکننده هنگام ارائه از طریق FLEDGE یا راهحلهای جایگزین. | کاربران میتوانند از APIهای تبلیغاتی در کروم انصراف دهند. برای تبلیغات خاص، فناوری تبلیغات مربوطه، طرفی است که بهترین موقعیت را دارد تا کنترلهایی را در مورد اینکه کدام خلاقیتها نشان داده میشوند یا نحوه انتخاب آنها ارائه میکند. |
جدول زمانی واضح تر | برای اطلاعات بیشتر در مورد در دسترس بودن حفاظت های حریم خصوصی در FLEDGE، مانند نیاز به قاب های حصاردار، درخواست کنید. | ما قصد داریم تا جدول زمانی دقیق تری را در سه ماهه اول منتشر کنیم. |
گزارش سردرگمی | برای وضوح بیشتر در مورد نحوه کار گزارش FLEDGE با سایر APIها مانند Fenced Frames و Private Aggregation API درخواست کنید. | ما قصد داریم توضیحی در مورد تعامل بین API جمعآوری خصوصی، FLEDGE و فریمهای حصاردار در هفتههای آینده منتشر کنیم. |
مناقصه در زمان واقعی و FLEDGE | راهنمایی در مورد نحوه ادغام FLEDGE با مناقصه بلادرنگ استاندارد. | دو مورد اصلی که توانایی یک فناوری تبلیغاتی را برای انجام مناقصه بلادرنگ پیچیده میکند، دسترسی به دادههای سطح رویداد و ادغام آسانتر در ARA است. ما در حال برنامه ریزی برای ارسال به روز رسانی و توضیح در مورد هر دوی این موارد در Q1 هستیم. |
اجرای حراج های FLEDGE | گزارش از آزمایش کنندگان مبنی بر اینکه حراج های FLEDGE تاخیر بالایی دارند | ما از گزارشهای آزمایشکنندگان که نتایج و موارد استفاده خود را به اشتراک میگذارند قدردانی میکنیم و پیشنهاداتی را در مورد چگونگی بهبود عملکرد FLEDGE به اشتراک گذاشتهایم. به موازات آن، ما ابزارهایی را به مرورگر اضافه کردهایم که به توسعهدهندگان اجازه میدهد بهتر تشخیص دهند که چه چیزی باعث کندی حراجها میشود ، و به طور سیستماتیک به منابع اولیه تأخیر مشاهدهشده پرداختهایم. پیشرفتهای اخیر شامل مهلت زمانی برای حراجهای آهسته ، تکنیک فیلتر سریع پیشنهاددهنده ، روشی برای استفاده مجدد از Workletهای FLEDGE برای جلوگیری از پرداخت هزینههای راهاندازی ، و کار مداوم برای اجازه دادن به درخواست آگهی متنی برای اجرا موازی با زمان راهاندازی FLEDGE و واکشیهای شبکه است. ما انتظار داریم که بهینهسازی تأخیر بهعنوان یک مکالمه مداوم بین توسعهدهندگان Chrome و آزمایشکنندگان FLEDGE بر اساس تجربه دنیای واقعی آنها با استفاده از API ادامه یابد. |
محدودیت حافظه اندازه گروه علاقه | درخواست افزایش محدودیت اندازه یک گروه ذینفع از 50 کیلوبایت. | ما فعالانه درخواست را بررسی می کنیم و به دنبال بازخوردی در مورد اینکه چه مقدار محدودی کار می کند هستیم. |
ترکیب داده های ارائه شده FLEDGE با کوکی شخص اول | آیا FLEDGE از ادغام با داده های شخص اول تبلیغ کننده پشتیبانی می کند؟ | FLEDGE برای پشتیبانی از تبلیغات با استفاده از دادههای شخص اولی که یک تبلیغکننده از قبل دارد ساخته شده است. با این حال، FLEDGE قصد ندارد از تبلیغ کننده ای پشتیبانی کند که رفتار مرور یک شخص را در هیچ وب سایتی غیر از سایت خود تبلیغ کننده یاد می گیرد. ضمیمه کردن رفتار مرور خارج از سایت به داده های شخص اول مغایر با اهداف Privacy Sandbox است. ما در حال برنامه ریزی برای به اشتراک گذاشتن راهنماهای یکپارچه سازی با جزئیات بیشتر در مورد نحوه پشتیبانی FLEDGE از ادغام با داده های شخص اول در هفته های آینده هستیم. |
ارزش ناشناس بودن K | مقدار "K" به "k-anon" چگونه تعیین می شود و آیا منتشر می شود؟ | مقدار "K" هنوز در حال نهایی شدن است و با توسعه برنامه هایمان اطلاعات بیشتری را به اشتراک خواهیم گذاشت. ما علاقه مندیم در مورد اینکه چگونه یک مقدار k ناشناخته ممکن است مانع آمادگی FLEDGE و آموزش مدل ML شود، بیشتر بیاموزیم و از بازخورد اضافی در مورد این موضوع استقبال می کنیم. |
پشتیبانی از چندین SSP | چگونه چندین SSP در FLEDGE پشتیبانی خواهند شد؟ | همانطور که در این پیشنهاد ذکر شده است، FLEDGE از حراج های چند فروشنده پشتیبانی می کند. |
قابل مشاهده بودن منطق مناقصه | نگرانی از اینکه منطق مناقصه DSP در جاوا اسکریپت نمایش داده شود | با منطق مناقصه طراحی فعلی، جاوا اسکریپت می تواند توسط دیگران قابل دسترسی باشد، اما ما از بازخورد بیشتری در مورد اینکه چرا این می تواند منبع نگرانی برای DSP ها باشد استقبال می کنیم. |
prebid.js | جدول زمانی پشتیبانی از prebid.js در FLEDGE چیست؟ | فقط نسخههای 7.14 و جدیدتر Prebid.js از ماژول FLEDGE پشتیبانی میکنند. هر ناشر علاقه مند به آزمایش باید ماژول FLEDGE را اضافه کند و نمونه Prebid خود را ارتقا دهد. |
توابع تعریف شده توسط کاربر در FLEDGE | چگونه توابع تعریف شده کاربر (UDF) در FLEDGE پشتیبانی می شوند؟ اینها توابعی هستند که می توانند توسط کاربران نهایی برای گسترش عملکرد API برنامه ریزی شوند. | توضیح دهنده در اینجا موجود است. این هنوز در حال تکمیل است، بنابراین ما از بازخورد اضافی در مورد موارد استفاده استقبال می کنیم. |
کاهش محدودیت منبع مشابه در منابع گروه بهره | برای فعال کردن موارد استفاده از فناوری تبلیغاتی خاص، درخواست کاهش محدودیتهای همان مبدأ در منابع گروه علاقهمندی کنید | در اجرای فعلی FLEDGE، biddingLogicUrl ، biddingWasmHelperUrl ، dailyUpdateUrl و trustedBiddingSignalsUrl باید منشأ یکسانی با مالک گروه ذینفع داشته باشند.محدودیت برای جلوگیری از سوء استفاده های خاص توسط مهاجمان وجود دارد، همانطور که در اینجا توضیح داده شده است. |
مالکیت interestGroup | درخواست برای محدود کردن اینکه آیا یک فناوری تبلیغات میتواند از joinInterestGroup برای گروههای علاقه یکسان در سراسر سایتها استفاده کند یا خیر. | تمرکز ما بر نحوه استفاده از مخاطبان است نه نحوه ساخت آنها. ما در اینجا درباره رویکردهای بالقوه بحث می کنیم و از ورودی های اضافی استقبال می کنیم. |
ارزش کلید انقضای کلید سرور | بحث در مورد حذف کلیدهای سرور پس از انقضای گروه های ذینفع مربوطه | ما در حال بررسی راه هایی برای رسیدگی به انقضای کلید هستیم و در اینجا به دنبال بازخورد هستیم. |
اندازه گیری تبلیغات دیجیتال
گزارش انتساب (و سایر APIها)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
ترافیک آزمایشی مبدا | ترافیک فعلی Origin Trial برای انجام آزمایش ابزار کافی نیست. | Origin Trials کنونی برای بازیکنان اکوسیستم طراحی شده است تا آزمایشات عملکردی را انجام دهند تا اطمینان حاصل شود که API همانطور که در نظر گرفته شده است کار می کند. ما میدانیم که وقتی توسعه API مختلف Privacy Sandbox بالغتر شد، برای انجام تست ابزار به حجم بیشتری از ترافیک نیاز است. جدول زمانی آزمایش فعلی پیشبینی میکند که این امر در دسترسپذیری عمومی (یعنی زمانی که فناوریهای موارد استفاده راهاندازی میشوند و برای 100٪ ترافیک Chrome در دسترس هستند) در سه ماهه سوم 2023 رخ میدهد ( خط زمانی بهروز ما را در privacysandbox.com ببینید) ما از هرگونه بازخورد اضافی در مورد آزمایش مورد استفاده که به ترافیک اضافی نیاز دارد استقبال می کنیم. |
همپوشانی در عملکرد API های مختلف اندازه گیری Privacy Sandbox | نگرانی در مورد همپوشانی چندین رویکرد اندازهگیری از طریق Privacy Sandbox، پیچیدگی را افزایش میدهد، بهعنوان مثال، Attribution Reporting API و Private Aggregation API. | ما در حال کار بر روی اسناد بهتر برای روشن کردن موارد استفاده مختلف برای APIها هستیم و از بازخوردهای اضافی در مورد مواردی که توضیحی ندارند استقبال می کنیم . به عنوان مثال، Attribution Reporting API به طور خاص برای پشتیبانی از اندازهگیری تبدیل در نظر گرفته شده است، در حالی که API جمعآوری خصوصی و ذخیرهسازی مشترک APIهای همه منظوره هستند که برای پشتیبانی از طیف وسیعتری از موارد استفاده اندازهگیری بین سایتی در نظر گرفته شدهاند. |
درخواست گزارش ناموفق را دوباره امتحان کنید | توضیح در مورد اینکه چند بار درخواست گزارش در صورت عدم موفقیت درخواست شده است. | ما راهنمایی در این مورد منتشر کرده ایم. به طور خلاصه، گزارشها فقط زمانی ارسال میشوند که مرورگر در حال اجرا/آنلاین باشد. پس از اولین عدم ارسال، گزارش پس از 5 دقیقه دوباره امتحان می شود. پس از شکست دوم، گزارش پس از 15 دقیقه دوباره امتحان می شود. پس از آن گزارش ارسال نمی شود. |
تاخیر گزارش | تاخیر گزارش مورد انتظار چقدر است؟ | ما به دنبال شنیدن بازخورد بیشتری از اکوسیستم در مورد تأخیرهای گزارش دهی آنها هستیم زیرا داده هایی را برای ارزیابی بیشتر این تاخیرها به صورت موازی جمع آوری می کنیم. |
صفحات پیش اجرا | آیا ارجاع ARA در صفحات پیش اجرا کار خواهد کرد؟ | ثبت نام در صفحات پیش اجرا تا زمان فعال سازی (کلیک یا مشاهده واقعی) به تعویق می افتد. این بدان معناست که پینگ درخواست «attributionsrc» را به تعویق می اندازیم. |
اندازه گیری بالابر تبدیل | نحوه اندازه گیری افزایش تبدیل با آزمایش AB در همان دامنه | وبسایتها میتوانند افزایش تبدیل را با آزمایش A/B در همان دامنه از طریق گزارش اسناد اندازهگیری کنند. آنها میتوانند پارامترهای A/B خود را بهعنوان کلید با استفاده از API کل رمزگذاری کنند و سپس گزارشهای خلاصهای را برای مقادیر تبدیل توسط آن سطلهای کلید دریافت کنند. |
(همچنین در Q3 گزارش شده است) تبدیل های بین دامنه ای | نحوه ردیابی تبدیل هایی که متقاطع دامنه هستند، مانند 2 یا چند مقصد | به روز رسانی Q4: ما پیشنهادی برای حذف محدودیت مقصد صفحه فرود منتشر کردهایم که امکان ردیابی مکالمات بین دامنهای را فراهم میکند. این پیشنهاد اجرایی شده است. |
(همچنین در سه ماهه سوم گزارش شده است) تنظیم انقضا در گزارش تبدیل | درخواست برای پشتیبانی از فیلتر گزارش / انقضا برای کمتر از 24 ساعت | به روز رسانی Q4: ما این درخواست کشش را به اشتراک گذاشتهایم که پنجرههای انقضا و گزارش را از هم جدا میکند تا مبادله تاخیر گزارش در مقابل انقضای تبدیل را کاهش دهد. این در حال حاضر در M110 راه اندازی شده است. |
تقلب و سوء استفاده | درخواستهایی از تبلیغکنندگان و بازاریابها برای اینکه بتوانند دادهها را بر اساس سایتهای ناشری که در آن آگهیهایشان ارائه میشود، برش داده و جمعآوری کنند، که همچنین بینش بیشتری در مورد شیوههای تبلیغات تقلبی احتمالی میدهد. | این بازخورد به طور فعال در اینجا مورد بحث قرار می گیرد و ما از ورودی های اضافی استقبال می کنیم. |
(همچنین در Q3 گزارش شد) تاخیر گزارش سطح رویداد | تاخیر 2 تا 30 روزه در گزارش سطح رویداد ممکن است برای موارد استفاده خاص بسیار طولانی باشد. | گزارش سطح رویداد دارای پنجره های گزارش پیش فرض 2، 7 و 30 روزه است. این را می توان با استفاده از پارامتر "expiry" تغییر داد. Ad-tech ها می توانند انقضا را با حداقل 1 روز پیکربندی کنند تا گزارش های احتمالی را در کمتر از 2 روز دریافت کنند. بهعنوان مکانیزم حفاظت از حریم خصوصی، جزئیات انقضاها را به ۱ روز محدود میکنیم، زیرا گزارشهای دقیقتر میتواند منجر به حملات زمانبندی شود. علاوه بر این، ما اجازه می دهیم پارامترهای مستقل "انقضا" را برای سطح رویداد و گزارش های انبوه تنظیم کنیم. اینجا را ببین . بهعلاوه، Google Ads پنجرههای گزارشگیری خاصی را که سایر فناوریهای تبلیغاتی از طریق Attribution Reporting API دریافت نمیکنند، دریافت نخواهد کرد. |
همان نیاز مبدا گزارش دهی | درخواست حذف الزام برای یکسان بودن مبدا ثبت منبع با مبدا ثبت تبدیل | ما پیشنهاد می کنیم از تغییر مسیرهای HTTP برای واگذاری ثبت نام برای حل این مورد استفاده استفاده کنیم. از هرگونه بازخورد اضافی در مورد راهنمایی جدید استقبال می کنیم. |
ردیابی تبدیل | باید متمایز شود که آیا تبدیل قبل یا بعد از ساعات مشخصی که توسط تبلیغکننده تعیین میشود اتفاق افتاده است یا خیر | Attribution Reporting API از تنظیم یک پنجره انقضا و اولویت برای انتساب منبع پشتیبانی می کند. با استفاده از هر دو، از نظر فنی میتوان تبدیلی را که در پنجره X روز اتفاق افتاد جدا از تبدیلی که بعد از X اتفاق افتاد نسبت داد. |
شبیه سازی نویز | درخواست برای شبیهسازی حجم مختلف تبدیلها در هر سطل، برای درک تأثیر بر تبلیغکنندگان با تبدیل کمتر | ما به دنبال اضافه کردن راه هایی برای شبیه سازی این موضوع در نسخه های بعدی Noise Lab هستیم. ما از هرگونه بازخورد اضافی استقبال می کنیم. |
گزارش در موبایل | آیا وقتی Chrome در پسزمینه در تلفن همراه اجرا میشود، گزارش همچنان ارسال میشود؟ | در حال حاضر، حتی در تلفن همراه، وقتی کروم در پسزمینه است، گزارش ارسال نمیشود. زمانی که API با Android Privacy Sandbox ادغام میشود، این احتمالاً تغییر میکند. اینجا را ببین . توجه داشته باشید که Android Privacy Sandbox بخشی از تعهدات پذیرفته شده توسط CMA نیست. |
در دسترس بودن داده ها | نگرانیهایی که Google از طریق APIهای Privacy Sandbox به دادهها دسترسی بیشتری خواهد داشت | اول، Google Ads هیچ گونه دسترسی ترجیحی به دادهها از API گزارش Attribution یا سایر APIهای Privacy Sandbox دریافت نمیکند. این موضوع همچنین در بخش بازخورد عمومی در بخش "تعامل پذیری" که شامل جزئیات بیشتری در مورد تعهدات Google است، پرداخته شده است. دوم، در مورد تفاوت بین سایت های بزرگتر و کوچکتر، گوگل تشخیص می دهد که حفاظت از حریم خصوصی مبتنی بر نویز ممکن است تأثیر بیشتری بر بخش های داده کوچکتر داشته باشد. با این حال، برخی کاهشهای احتمالی وجود دارد: برای مثال، روشهایی مانند تجمیع در دورههای زمانی طولانیتر این مشکل را حل میکند. با این حال، مشخص نیست که آیا نتیجهگیری بر اساس برشهای داده بسیار کوچک (مانند یک یا دو خرید) اصلاً برای تبلیغکنندگان معنادار است یا خیر. در طول آزمایش اولیه، Google آزمایشکنندگان را تشویق کرده است تا از توانایی آزمایش طیف گستردهای از پارامترهای حریم خصوصی و نویز استفاده کنند تا بتوانند بازخورد خاصتری درباره این موضوع ارائه دهند. |
ردیابی پنهان را محدود کنید
کاهش عامل کاربر
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تا زمانی که اکوسیستم وب آماده تر شود، کاهش عامل کاربر را به تاخیر بیندازید | زمان کافی برای انطباق با تغییرات آتی کاهش عامل کاربر وجود ندارد. | ما این بازخورد را در گزارش کامل در زیر "نگرانی های ذینفعان" در بخش با عنوان "تعامل Google با CMA" بررسی می کنیم. |
تا زمانی که اکوسیستم وب آماده تر شود، کاهش عامل کاربر را به تاخیر بیندازید | درخواست به تأخیر انداختن عرضه کاهش عامل کاربر تا زمانی که SUA مستقر شود | تیم Google Ads افزودن ساختار یافته کاربر-عامل (به مشخصات را ببینید) در اکتبر 2021 به OpenRTB پیشنهاد کرد و در بهروزرسانی مشخصات 2.6 که در آوریل 2022 منتشر شد، گنجانده شد. ما شواهدی داریم که نشان میدهد SUA امروزه مستقر و در دسترس است، همانطور که در پست وبلاگ Scientia Mobile نشان داده شده است که نحوه استفاده از UA-CH و WURFL API برای ایجاد یک SUA را نشان میدهد. |
###
نکات مشتری عامل کاربر
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
UA-CH را با سایر تکنیک های ردیابی ضد پنهان آزمایش کنید | راهنمایی در مورد نحوه آزمایش همه APIهای Sandbox Privacy و تکنیکهای اثرانگشت ارائه شده با هم در یک رویکرد جامع | طرح آزمایشی ما بهمنظور منعکسکردن جدولهای زمانی ناهمزمان برای توسعه برخی از اقدامات ضد اثرانگشت بر خلاف بقیه پیشنهادات Sandbox طراحی شده است. به این واقعیت می پردازد که برخی از اقدامات ضد اثرانگشت (به عنوان مثال بودجه حریم خصوصی، حفاظت از IP و کاهش ردیابی پرش) به طور کامل توسعه یافته و تنها پس از منسوخ شدن کوکی های شخص ثالث برای دسترسی عمومی آماده می شوند. در حالی که این اقدامات ضد اثرانگشت در آزمایشهای کمی گنجانده نمیشوند، اما بر اساس حقایق موجود در زمان Standstill، مشمول ارزیابی کیفی خواهند بود. |
(همچنین در سه ماهه دوم گزارش شده است) کارایی | نگرانی در مورد تأخیر دریافت راهنمایی از طریق Critical-CH (در بارگذاری صفحه اول) | بخش اختصاصی UA-CH را در زیر ببینید |
بازخورد ناکافی | بازخورد اکوسیستم در مورد تغییر UA-CH ممکن است کافی نباشد، که منجر به نگرانی در مورد عدم آگاهی از اکوسیستم می شود. | ما به طور فعال برنامههای خود را به اشتراک گذاشتهایم تا از عرضه دقیقی که اختلال را به حداقل میرساند اطمینان حاصل کنیم. طرحهای کاهش عامل کاربر و UA-CH API در 18 مارس 2022 به گروه جامعه ضد کلاهبرداری W3C و در 20 ژانویه 2022 به گروه پرداخت وب و گروه سود امنیت پرداخت وب ارائه شد. نگرانی های قابل توجهی در طول یا بعد از ارائه ها مطرح شد. گوگل به طور فعال با بیش از 100 اپراتور سایت برای دریافت بازخورد درگیر شده است. علاوه بر این، گوگل همچنین از کانالهای Blink-Dev برای برقراری ارتباط عمومی کاهش عامل کاربر بر اساس بازخورد سهامداران اکوسیستم استفاده کرده است. |
زمان سنجی | نگرانی های مطرح شده در مورد زمان عرضه و آمادگی صنعت | بخش اختصاصی UA-CH را در زیر ببینید |
وضعیت پلتفرم کروم | درخواست کرد که صفحه chromestatus برای UA-CH به روز شود | ورودی chromestatus در 19 دسامبر به "سیگنال های مختلط" به روز شد. |
حفاظت IP (Gnatcatcher سابق)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
شرکت کردن یا انصراف | آیا حریم خصوصی آدرس IP را انتخاب کنید یا انصراف دهید؟ | هدف ما ارائه حفاظت IP برای همه کاربران است. با توجه به این هدف ، ما در حال حاضر گزینه های انتخاب کاربر را برای محافظت از IP ارزیابی می کنیم. |
مورد استفاده از آدرس IP برای داده های شخص اول | آیا می توان از آدرس های IP برای دوخت سفرهای کاربر در دامنه های شخص اول حمایت از IP استفاده کرد؟ | همانطور که قبلاً منتشر شد ، محافظت IP در ابتدا روی ردیابی در متن شخص ثالث متمرکز خواهد شد ، این بدان معنی است که دامنه های شخص اول تحت تأثیر قرار نمی گیرند. |
موارد استفاده از فناوری | چگونه شرکت ها می توانند اقدامات ضد کلاهبرداری را با محافظت از IP تنظیم کنند؟ | ما اهمیت آدرس IP را به عنوان سیگنالی برای تلاش های ضد کلاهبرداری در وب امروز تشخیص می دهیم. به عنوان بخشی از تعهدات ما به CMA (بند 20) ، ما گفتیم که ما محافظت از IP را بدون تلاش های معقول برای پشتیبانی از توانایی وب سایت ها در انجام اقدامات ضد اسپم و ضد کلاهبرداری انجام نخواهیم داد. یکی از اولویت های اصلی ما این است که درک کنیم که چگونه محافظت از IP بر موارد استفاده ضد کلاهبرداری و قابلیت های تشخیص تأثیر می گذارد ، به طوری که ما می توانیم بیشتر در فن آوری های حفظ حریم خصوصی سرمایه گذاری کنیم که به شرکت ها کمک می کند تا ایمنی وب را حفظ کنند. ما بازخورد و ورودی را در مورد پیشنهادات جدید با هدف حمایت از نیازهای شرکتهای امنیتی و ضد کلاهبرداری تشویق می کنیم ، حتی اگر سیگنال ها با گذشت زمان تغییر کنند. |
کلاهبرداری و سوء استفاده | آیا محافظت از IP شامل انکار سرویس (DOS) است؟ | ما متعهد هستیم ضمن حفظ ایمن بودن وب ، حریم خصوصی را بهبود بخشیم و محافظت در برابر حملات انکار سرویس ، یک مورد مهم استفاده از ضد سوء استفاده برای طراحی است. ما امیدواریم که از طریق طراحی محافظت از IP و از طریق راه حل های جدید ضد سوء استفاده ، تأثیر را در حفاظت از DOS به حداقل برسانیم. از آنجا که در ابتدا محافظت از IP بر روی خدمات تعبیه شده شخص ثالث متمرکز شده است ، برخی از ذینفعان اعلام کرده اند که باید تأثیر محدودی در محافظت DOS برای سایت های شخص اول داشته باشد. با این حال ، ما همچنان از بازخورد عمومی برای ارزیابی ریسک برای موارد استفاده DOS ، به ویژه برای خدمات جاسوسی شخص ثالث استفاده می کنیم. به موازات ، ما در حال بررسی مکانیسم های سوءاستفاده و مسدود کردن مشتری هستیم که یک سایت یا سرویس را قادر می سازد بدون شناسایی کاربر ، یک کاربر اسپم را مسدود کند. |
فیلتر کردن محتوا | فیلتر محتوا با محافظت از IP | شرکت های مختلف با توجه به فیلتر کردن محتوا و شخصی سازی تجربه کاربر نیازهای متفاوتی دارند. بسیاری از موارد استفاده در حال حاضر به آدرس های IP متکی نیستند و بنابراین باید تحت تأثیر محافظت IP قرار بگیرند. به عنوان مثال ، ناشر که به دنبال تنظیم محتوای خود و رانندگی بیشتر درگیری است ، ممکن است از کوکی های شخص اول یا کوکی های پارتیشن شخص ثالث (تراشه) برای درک علایق کاربر و تعامل قبلی با ناشر استفاده کند. یا یک شریک AD Tech با تمرکز بر ارائه تبلیغ مناسب به کاربر مناسب ، می تواند Fledge و موضوعات را در بر بگیرد ، به عنوان مثال ، برای ارائه نتایج AD مشابه همانطور که امروز با کوکی های شخص ثالث یا سایر فن آوری های ردیابی متقابل انجام می شود. ما همچنین در حال بررسی ایجاد قابلیت های جدید برای حفظ حریم خصوصی در محافظت از IP ، مانند جغرافیایی درشت ، برای پشتیبانی بیشتر از فیلتر محتوا در جایی که مکانیسم های موجود ممکن است کافی نباشد. ما از بازخورد اضافی در مورد موارد استفاده از فیلتر محتوا که ممکن است تحت تأثیر محافظت IP باشد استقبال می کنیم. |
(همچنین در Q3 گزارش شده است) موارد استفاده از جغرافیا | محافظت از IP ممکن است مانع از کار با استفاده از جغرافیایی قانونی در آینده شود ، مانند شخصی سازی محتوا بر اساس جغرافیایی. | به روزرسانی Q4: ما با ذینفعان همکاری می کنیم تا اطمینان حاصل کنیم که Chrome همچنان به پشتیبانی از موارد قانونی برای آدرس های IP ادامه می دهد. ما در اینجا به دنبال بازخورد اکوسیستم در مورد دانه جغرافیایی IP هستیم. |
بودجه حریم خصوصی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
مستندات واضح تر | مثالهای بیشتر بنابراین ذینفعان می توانند پس از اجرای بودجه حریم خصوصی ، چگونگی محدودیت امور را پیش بینی کنند | پیشنهاد بودجه حریم خصوصی هنوز تحت بحث فعال است و توسط هیچ مرورگری اجرا نشده است. اولین تاریخ در دسترس بودن مقیاس نشان دهنده اولین تاریخ است که می توان بودجه حریم خصوصی را اجرا کرد. این اتفاق قبل از حذف کوکی های شخص ثالث در سال 2024 رخ نخواهد داد. ما در حال حاضر هیچ اسناد اضافی برای اشتراک گذاری نداریم. ما وقتی نهایی می شود ، جزئیات اضافی را در مورد این پیشنهاد به اشتراک خواهیم گذاشت. در ضمن ، ما از ذینفعان استقبال می کنیم تا هرگونه بازخوردی را که در تهیه پیشنهاد کمک می کند به اشتراک بگذارند . |
مرزهای حفظ حریم خصوصی سایت را تقویت کنید
مجموعه های شخص اول
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در Q3 گزارش شده است) حد دامنه | درخواست گسترش تعداد حوزه های مرتبط | به روزرسانی Q4: ما FPS را برای آزمایش های محلی منتشر کرده ایم ، از جمله یک فرآیند ارسال مجموعه مسخره در GitHub و یک پرچم برای آزمایش RSA و RSAFOR به صورت محلی. ما همچنین دو جلسه باز برای توسعه دهندگان در FPS برگزار کرده ایم تا همچنان به سؤالات مربوط به موارد استفاده برای زیر مجموعه های مرتبط بپردازیم. ما توسعه دهندگان را ترغیب می کنیم تا عملکرد FPS را آزمایش کنند تا بازخوردی در مورد چگونگی تأثیر دامنه برای زیر مجموعه مرتبط بر قابلیت استفاده از FPS برای موارد استفاده آنها تأثیر بگذارند. ما در تماس های WICG توضیح داده ایم که Chrome متعهد به ارائه یک راه حل قابل استفاده است که منافع حریم خصوصی کاربران را نیز در نظر می گیرد. در این راستا ، ما از بازخورد جامعه در مورد موارد استفاده خاص که ممکن است تحت تأثیر محدودیت دامنه باشد ، قدردانی می کنیم ، به طوری که این تیم می تواند راه های پرداختن به این موارد استفاده را در حالی که همچنان به حفظ حریم خصوصی کاربر است ، در نظر بگیرد. |
درخواست اطلاعات بیشتر در مورد اقدامات کاهش سوءاستفاده | چه اتفاقی می افتد اگر دامنه ای به مجموعه ای اضافه شود که آنها رضایت نداشته باشند؟ | ما دستورالعمل های ارسال برای مجموعه های شخص اول را در 2 دسامبر 2022 منتشر کرده ایم. همانطور که در دستورالعمل های ارسال توضیح داده شده است ، هر مدیریت تغییر مجموعه ای پیروی می کند و یک فرآیند اعتبار سنجی در مورد GitHub ، از جمله اعتبار در مالکیت ، که باید این خطر را کاهش دهد ، احترام می گذارد. |
کاهش | نگرانی از این که از سازندهای تعیین شده شخص اول قابل بهره برداری باشد | ما به دنبال راه هایی برای گسترش چک های فنی برای انواع زیر مجموعه هستیم و به طور فعال به دنبال ورودی اضافی از جامعه در اینجا هستیم. |
تبلیغات از موارد استفاده می کند | سؤالاتی در مورد اینکه آیا از مجموعه های شخص اول برای پشتیبانی از هدف گذاری تبلیغ استفاده می شود | ما در تلاش نیستیم تا از تبلیغات هدفمند استفاده از موارد استفاده برای مجموعه های شخص اول پشتیبانی کنیم و توصیه می کنیم از API های ADS موجود برای چنین مواردی استفاده کنید. |
(همچنین در Q3 گزارش شده است) سیاست | این نگرانی که FPS با تعهدات CMA در مورد "قانون حمایت از داده های قابل اجرا" سازگار نیست ، بر این اساس که GDPR محدودیتی را برای تعداد سایت ها در یک مجموعه تحمیل نمی کند در حالی که FPS محدودیت 3 را پیش بینی می کند | پاسخ ما از Q3 بدون تغییر است: "Google همچنان به CMA متعهد می شود تا پیشنهادات Sandbox را به طراحی و اجرای پیشنهادات Sandbox حریم خصوصی به گونه ای طراحی کند که با پیشگیری از تجارت خود Google ، رقابت را تحریف نکند و تأثیر خود را در رقابت در تبلیغات دیجیتال ، ناشران و تبلیغ کنندگان در نظر بگیرد. به عنوان تأثیر بر نتایج حریم خصوصی و انطباق با اصول حفاظت از داده ها که در قانون حفاظت از داده های قابل اجرا آمده است. نگرانی بیان شده هیچ ناسازگاری با GDPR را فاش نمی کند. ما همچنان با CMA همکاری می کنیم تا اطمینان حاصل کنیم که کار ما با این تعهدات مطابقت دارد. " |
پیشنهاد جایگزین | مجموعه های معتبر GDPR | علاوه بر بازخورد ارائه شده توسط اکوسیستم در مورد پیشنهاد اتخاذ "مجموعه های معتبر GDPR" ، Chrome نگرانی در مورد محدودیت های زیر این پیشنهاد جایگزین دارد:
از آنجا که این گزینه جایگزین شد ، Chrome پیشنهاد مجموعه های شخص اول را به روز کرده و دستورالعمل های ارسال را برای ایجاد مجموعه های جدید منتشر کرده است. |
قاب های حصارکشی API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
محدودیت های قاب های حصارکشی در طول OT | محدودیت های فعلی در مورد فریم های حصارکشی برای دوره آزمایشی مبدا چیست؟ | ما در حال کار بر روی مستندات در مورد محدودیت ها و وضعیت اجرای هستیم و قصد داریم آن را در طول Q1 2023 به اشتراک بگذاریم. |
چندین تبلیغ در یک قاب حصار | درخواست نمایش چندین تبلیغ در یک قاب حصار در یک حراج | در حال حاضر ، این درخواست به طور فعال توسعه نمی یابد ، اما اگر بازیکنان اکوسیستم ویژگی را مهم بدانند ، از بازخورد اضافی استقبال می کنیم. |
بسته های وب | الزامات و پشتیبانی برنامه ریزی شده برای بسته های وب با قاب های حصارکشی چیست؟ | ما در حال حاضر به روزرسانی در مورد اینکه آیا این الزام در آینده خواهد بود ، نداریم. هرگونه تغییر از قبل اعلام می شود و قبل از استهلاک کوکی شخص ثالث اجرا نمی شود. لطفاً برای وضعیت فعلی این توضیح دهنده را ببینید. |
API ذخیره سازی مشترک
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
ذخیره سازی مشترک برای فناوری تبلیغاتی | عدم اطمینان پیرامون استفاده از ذخیره مشترک برای موارد استفاده از فناوری تبلیغاتی | ذخیره سازی مشترک و API جمع آوری خصوصی می تواند برای انواع مختلفی از اهداف اندازه گیری که نیاز به اندازه گیری ذخیره سازی در سایت دارند استفاده شود. برخی از نمونه ها در اینجا ذکر شده است. ما در حال پیش بینی DSP و ارائه دهندگان راه حل اندازه گیری هستیم تا یکپارچه ساز اصلی موارد استفاده از تبلیغات باشد. |
چیپس
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در Q3 گزارش شده است) نیاز تقسیم شده | نیاز به رفتار صریح را برای ویژگی "تقسیم بندی شده" در کوکی های شخص اول اضافه کنید. | به روزرسانی Q4: پس از بحث و گفتگو در مورد تماس های GitHub و PrivacyCG ، رفتاری که ما روی آن تراز کرده ایم این است که کوکی های تقسیم شده روی کوکی های شخص اول که از یک کلید پارتیشن (A ، A) استفاده می کنند ، در جایی که "A" سایت سطح بالا است. ما این رفتار را در مورد توضیحات و مشخصات مستند خواهیم کرد. |
مدیریت کوکی ها | آیا ابزاری برای مدیریت/حاکمیت کوکی های شخص اول یا شخص ثالث وجود دارد؟ | Devtools Chrome و NetLog می توانند برای آزمایش سایت هایی با مسدود کردن کوکی شخص ثالث فعال شوند. هر دو ابزار گزارش می دهند که کوکی ها به دلیل پیکربندی کاربر مسدود می شوند. ما از بازخورد در مورد نوع وب سایت های حسابرسی اضافی که دوست دارند ببینند استقبال می کنیم. |
فدستان
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
IDP برای اجازه یک جلسه به دانش RP نیاز دارد | هنگامی که یک کاربر در تلاش است از دو RP های مختلف وارد Feide IDP شود | ما در اینجا در مورد راه حل های بالقوه برای این موضوع بحث می کنیم. |
قابلیت همکاری | نگرانی در مورد تأثیر FEDCM در رابطه بین کاربران و وب سایتهایی که آنها با استفاده از FEDCM و "قابلیت همکاری" بین وب سایت ها وارد می شوند | FEDCM قصد دارد به حمایت از خدمات هویتی فدرال که در حال حاضر به کوکی های شخص ثالث متکی هستند ، پس از حذف کوکی های شخص ثالث از Chrome ، ادامه دهد. ما انتظار داریم که FEDCM فقط یک گزینه در دسترس چنین خدماتی باشد. ارائه دهندگان هویت (IDP) و احزاب با تکیه (RP) برای استفاده از سایر فن آوری هایی که ممکن است متناسب با نیاز آنها باشد ، آزاد هستند. به نظر می رسد که نگرانی های مربوط به رابطه کاربر RP و "قابلیت همکاری" مدیون سوء تفاهم از پیشنهاد FEDCM است. FEDCM آن را به آوارگان واگذار می کند تا تصمیم بگیرد که چه اطلاعاتی را با RP به اشتراک بگذارد ، و به چه شکلی ، هنگامی که کاربر تصمیم به ورود به سایت RP گرفت. FEDCM نیازی به IDP ندارد تا "یک شناسه نامطلوب منحصر به فرد برای هر [RP] ایجاد کند که کاربر با آن تأیید می کند." در عوض ، FEDCM برای هر IDP باز است تا بتواند شناسه واقعی کاربر را به اشتراک بگذارد ، یک نسخه در هر سایت از آن شناسه یا نسخه دیگری از این اطلاعات. . مرورگر.) FEDCM همچنین در حال حاضر انتخاب کاربر را با توجه به هویت فراهم می کند. به عنوان مثال ، اگر کاربر دارای چندین هویت با همان IDP باشد (به عنوان مثال ، یک پروفایل کار و یک پروفایل شخصی) ، FEDCM راهی را برای کاربر فراهم می کند تا کدام یک را که می خواهد برای ورود به سایت RP استفاده کند انتخاب کند. فراتر از آن ، هر RP برای خود تصمیم می گیرد که IDP ها از سایت خود پشتیبانی کنند. یکی از جنبه های این تصمیم در نظر گرفتن مکانیسمی است که یک IDP به آن متکی است ، خواه FEDCM باشد یا یک فناوری متفاوت. باز هم ، مرورگر این گزینه ها را برای RPS یا IDP ها دیکته نمی کند. |
با هرزنامه و کلاهبرداری مبارزه کنید
API Token State Private
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
دست زدن به رباتها | چه اتفاقی می افتد اگر صادرکننده کشف کند که نشانه های دولتی خصوصی به رباتها صادر شده است؟ | برای جلوگیری از توکن های صادر شده برای باقیمانده در اکوسیستم برای مدت طولانی ، صادرکنندگان باید کلیدهایی را که استفاده می کنند برای امضای نشانه ها به طور مرتب بچرخانند ، به گونه ای که نشانه های قدیمی صادر شده تحت منطق صدور بالقوه شکسته منقضی می شوند و سایت ها با منطق صدور به روز شده ، نشانه های جدیدتر را بازخرید می کنند. |
ارسال فرم همان سایت | آیا می توان از نشانه های ایالتی خصوصی برای ارسال های فرم همان سایت استفاده کرد که شامل ناوبری تمام صفحه (IE محتوا-نوع: Application/X-ww-form-urlencoded) به جای درخواست API های Fetch/XMLHTTPREQUEST است؟ | این در حال حاضر در نسخه اول نشانه های دولتی خصوصی پشتیبانی نمی شود. اگر تقاضای شدیدی برای این مورد استفاده شود ، از بازخورد اکوسیستم استقبال می کنیم. |
تایید سمت سرور | سؤالاتی در مورد اینکه آیا نشانه های حالت خصوصی می توانند سمت سرور تأیید شوند | توکن ها در برابر صادرکننده بازخرید می شوند ، و سپس صادرکننده سابقه بازخرید را ایجاد می کند که می تواند شامل خود نشانه یا مقداری امضا شده حاصل از نشانه باشد ، سرورها می توانند از آن سوابق بازخرید برای تأیید صحت این نشانه استفاده کنند ، و ما انتظار داریم اکوسیستم های مختلف صادرکننده های مختلف استانداردهای مختلفی برای چگونگی تفسیر سوابق رستگاری آنها ارائه می شود. |