گزارش فصلی برای سه ماهه سوم سال 2023، خلاصه بازخورد اکوسیستم دریافت شده در مورد پیشنهادات جعبه ایمنی حریم خصوصی و پاسخ Chrome.
بهعنوان بخشی از تعهدات خود به CMA، Google موافقت کرده است که گزارشهای فصلی فرآیند تعامل با ذینفعان را برای پیشنهادات جعبه ایمنی حریم خصوصی خود به صورت عمومی ارائه کند (به پاراگرافهای 12 و 17(c)(ii) تعهدات مراجعه کنید). این گزارشهای خلاصه بازخورد Sandbox حریم خصوصی با جمعآوری بازخوردهای دریافتی توسط Chrome از منابع مختلف که در نمای کلی بازخورد فهرست شده است، ایجاد میشوند، از جمله اما نه محدود به: مشکلات GitHub، فرم بازخورد موجود در privacysandbox.com ، جلسات با سهامداران صنعت، و انجمنهای استانداردهای وب. Chrome از بازخوردهای دریافتی از اکوسیستم استقبال می کند و به طور فعال در حال بررسی راه هایی برای ادغام آموخته ها در تصمیمات طراحی است.
مضامین بازخورد بر اساس شیوع در هر API رتبهبندی میشوند. این کار با جمعآوری مقدار بازخوردی که تیم Chrome در مورد یک موضوع خاص دریافت کرده و به ترتیب نزولی از نظر سازماندهی انجام میشود. مضامین رایج بازخورد با بررسی موضوعات بحث از جلسات عمومی (W3C، PatCG، IETF)، بازخورد مستقیم، GitHub و سوالات متداول مطرح شده از طریق تیمهای داخلی Google و فرمهای عمومی شناسایی شدند.
به طور خاص، صورتجلسات جلسات بدنه استاندارد وب بررسی شد و برای بازخورد مستقیم، سوابق Google از جلسات 1:1 ذینفعان، ایمیلهای دریافتی توسط مهندسان فردی، فهرست پستی API و فرم بازخورد عمومی در نظر گرفته شد. سپس گوگل بین تیمهای درگیر در این فعالیتهای ارتباطی مختلف هماهنگ کرد تا شیوع نسبی موضوعات در حال ظهور در رابطه با هر API را تعیین کند.
توضیحات پاسخهای Chrome به بازخورد از پرسشهای متداول منتشر شده، پاسخهای واقعی به مسائل مطرحشده توسط ذینفعان و تعیین موقعیت بهویژه برای اهداف این گزارش گزارش عمومی ایجاد شده است. با توجه به تمرکز فعلی توسعه و آزمایش، سؤالات و بازخوردها به ویژه در رابطه با موضوعات، مخاطبین محافظت شده و APIهای گزارش اسناد دریافت شد.
بازخورد دریافت شده پس از پایان دوره گزارش فعلی ممکن است هنوز پاسخی در نظر گرفته شده برای Chrome نداشته باشد.
واژه نامه کلمات اختصاری
- چیپس
- کوکی هایی که دارای حالت تقسیم شده مستقل هستند
- DSP
- پلتفرم سمت تقاضا
- FedCM
- مدیریت اعتبار فدرال
- FPS
- مجموعه های مهمانی اول
- IAB
- دفتر تبلیغات تعاملی
- بیجاشدگان داخلی
- ارائه دهنده هویت
- IETF
- کارگروه مهندسی اینترنت
- IP
- آدرس پروتکل اینترنت
- openRTB
- مناقصه در زمان واقعی
- OT
- آزمایش مبدا
- PatCG
- گروه اجتماعی فناوری تبلیغات خصوصی
- RP
- حزب اتکا
- SSP
- پلت فرم سمت عرضه
- TEE
- محیط اجرای مورد اعتماد
- UA
- رشته عامل کاربر
- UA-CH
- نکات مشتری عامل کاربر
- W3C
- کنسرسیوم وب جهانی
- WIPB
- کوری IP ارادی
بازخورد عمومی، بدون API یا فناوری خاص
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
آمادگی اکوسیستم | SSP ها نگرانی از آماده نبودن ناشران و انجام ندادن کار استقرار مورد نیاز را برجسته کردند. | Privacy Sandbox به طور خاص بر آموزش ناشران متمرکز شده است، که شامل وبینارها و جلسات اختصاصی با ناشران و SSPهای حاضر برای پیشبرد کار استقرار است. |
منسوخ شدن کوکی های شخص ثالث | نگرانی ها در مورد از بین رفتن کوکی های شخص ثالث (3PCD) در سه ماهه چهارم 2023 به دلیل خاموشی فناوری صنعت افزایش یافت. | جدول زمانی برای Sandbox حریم خصوصی با CMA مورد بحث قرار گرفته است و توالی به نیمه دوم سال 2024 آماده می شود. Privacy Sandbox اطلاعات دقیق تری در مورد توالی افزایش 3PCD منتشر خواهد کرد. بر اساس تعهدات، 3PCD منوط به رسیدگی به نگرانی های رقابتی CMA است. |
Google Ad Manager | Google Ad Manager از افشای سطح API که آزمایش را دشوار می کند خودداری می کند. | پاسخ ارائه شده توسط Google Ad Manager: به دلایلی که در این پاسخ توسط Google Ad Manager توضیح داده شده است، برنامههای Google Ad Manager برای یکپارچهسازی API مخاطبان محافظت شده آن شامل پشتیبانی از سرور تبلیغات ناشر Google بدون کنترل حراج سطح بالا نمیشود. |
Google Ad Manager | Google Ad Manager یک قیمت طبقه مخفی دارد که فقط در معرض AdX یا Open Bidding SSPs قرار دارد. | اسناد عمومی Google Ad Manager میگوید که برنده حراج متنی به منطق امتیازدهی سطح بالا منتقل میشود و نه به حراجی جزء، از جمله AdX یا Open Bidding. علاوه بر این، این مستندات در مورد منطق امتیازدهی سطح بالا میگوید: «Ad Manager پیشنهاد برنده هر حراج مؤلفه، از جمله حراج مؤلفه خود Ad Manager را برای پیشنهادهای گروهی علاقهمند به خریدارانش، و همچنین بهترین آگهی متنی (که از طریق تخصیص پویا انتخاب میشود) مقایسه میکند و آگهی را با بالاترین پیشنهاد ارائه میکند. |
Google Ad Manager | محصولات Google Ads باید مشمول قوانین مشابه محصولات تبلیغاتی شخص ثالث باشند. | محصولات Google Ads در حال حاضر تحت قوانینی مشابه اشخاص ثالث قرار دارند. |
آزمایش با استفاده از کروم | برای مرورگرهایی که در A یا B نیستند برچسب اضافه کنید. | ما در حال حاضر به انجام این کار فکر نمی کنیم، زیرا تحقیقات ما نشان داده است که افزودن برچسب های غیر آزمایشی ممکن است نگرانی های مربوط به حریم خصوصی در مورد ترافیک در حالت ناشناس را پیچیده کند. |
آژانس تبلیغاتی | آیا آژانسها یا شرکتهای بدون جاوا اسکریپت در وبسایتها میتوانند از Privacy Sandbox API استفاده کنند؟ | هر کسی میتواند با APIهای Privacy Sandbox تماس بگیرد. اگر یک آژانس یا هر شخص دیگری بخواهد فناوریهایی را مستقیماً روی APIها ایجاد کند، میتواند. APIهای سمت کلاینت به ادغام با مشتری نیاز دارند، درست مانند کوکی ها. بسیاری از APIها، مانند کوکی ها، دارای یک رابط هدر HTTP نیز هستند. ما قبلاً یک چارچوب صنعت تبلیغات، Prebid را دیدهایم که ادغام سمت مشتری با APIها ایجاد میکند. سازمان های دیگر نیز می توانند همین کار را انجام دهند. |
راه حل های سمت مشتری | چرا Google راه حل های سمت مشتری را برای Privacy Sandbox اتخاذ می کند در حالی که یک مهندس قبلاً در سال 2012 نسبت به مقیاس پذیری چنین راه حل هایی ابراز نگرانی کرده است؟ | فناوری افزایش حریم خصوصی (PET) به عنوان یک رشته تحصیلی از سال 2012 به طور قابل توجهی تکامل یافته است و همراه با آن، برنامه های کاربردی تجاری قابل دوام است. در هسته Sandbox حریم خصوصی ترکیبی از PET وجود دارد که بیش از یک دهه پیش امکان پذیر نبود. علاوه بر این، قدرت محاسبات شخصی افزایش یافته است، همانطور که انتظارات مصرف کنندگان از مرورگرها و انتظارات نظارتی از حریم خصوصی افزایش یافته است. |
یادگیری ماشینی | استفاده برنامه ریزی شده Google از جعبه ایمنی حریم خصوصی برای اهداف یادگیری ماشینی چیست؟ | امروزه بیشتر اکوسیستم فناوری تبلیغات از یادگیری ماشینی استفاده می کند و ما انتظار نداریم که تغییر کند. جعبه ایمنی حریم خصوصی مانع از ادامه استفاده شرکتهای فناوری تبلیغات یا هر شخص دیگری از یادگیری ماشینی نمیشود. همچنین Privacy Sandbox ایجاب نمی کند که شرکت هایی که با API های آن ادغام می شوند از یادگیری ماشینی استفاده کنند. منطقی است انتظار داشته باشیم که شرکتها به ساخت محصولات و خدمات به روشهایی ادامه دهند که نیازهای مشتریانشان را برآورده کند، خواه این شامل یادگیری ماشین باشد یا خیر. هر گونه یادگیری ماشینی که ادغامکنندههای Privacy Sandbox ایجاد میکنند، بدیهی است که برای آنها شناخته شده است و بنابراین برای آنها پنهان نمیماند. |
تایید داده ها | چگونه شرکتها میتوانند تأیید کنند که دادههایی که از استفاده از جعبه ایمنی حریم خصوصی دریافت میکنند دقیق است و آیا Google مایل است از طریق نهادی مانند شورای رتبهبندی رسانه (MRC) بررسی شود؟ | APIهای Sandbox Privacy در پلتفرم منبع باز ساخته شدهاند که Chrome را تقویت میکند. بخشهایی از APIهایی که قرار است در محیطهای اجرایی مورد اعتماد اجرا شوند نیز منبع باز و قابل ممیزی هستند. هر کسی که بخواهد کد را بازرسی کند می تواند، از جمله MRC. |
(همچنین در سه ماهه قبلی گزارش شده است) پشتیبانی تولید | فرآیند Chrome برای پشتیبانی از مشکلات فنی و تشدیدهایی که اکوسیستم را تحت تأثیر قرار میدهند Privacy Sandbox چیست؟ | Google مجموعهای از کانالها را فراهم میکند تا به فنآوران تبلیغات اجازه دهد مشکلات فنی را گزارش کنند و هرگونه تشدید لازم را برای حل چنین مشکلاتی فعال کنند. علاوه بر این، کروم انتظار دارد فرآیندی را برای حل مشکلات فنی و تشدیدهایی که بر سلامت اکوسیستم تأثیر میگذارند، بسازد و مقیاسبندی کند. Chrome متعهد است که منابع لازم برای این تلاش را تضمین کند. لطفاً برای بازخورد و تشدید به انجمنهای عمومی و خصوصی ما مراجعه کنید. |
حالتهای آزمایش با تسهیل کروم | اطلاعات بیشتر در مورد جدول زمانی و اجرای دقیق حالتهای آزمایشی با تسهیل Chrome. | ما یک پست وبلاگ در مورد حالت های آزمایشی به اشتراک گذاشته ایم و در تلاش هستیم تا اطلاعات بیشتری را به زودی به اشتراک بگذاریم. ما از پیشنهادهایی برای اندازه برچسب های حالت تست استقبال می کنیم . |
ادغام با سایر استانداردهای صنعتی | آیا APIهای Privacy Sandbox به یکی یا هر دو نسخه TCF v2.* و Consent Mode متصل خواهند شد؟ | ما برنامهای برای ادغام APIهای Privacy Sandbox به طور مستقیم با TCF v2 یا Consent Mode نداریم. با این حال، شرکتها و گروههای تجاری صنعتی میتوانند محصولات و چارچوبهای خود را برای کار در ارتباط با APIهای Privacy Sandbox تطبیق دهند. برای مثال، در چارچوبهایی مانند TCF، هر شرکتکننده باید رویکرد انطباق خود را بر اساس سیگنال TCF که دریافت میکند و خطمشیهای TCF مرتبط تعیین کند. ما از شرکتها انتظار داریم زمان و نحوه استفاده از عملکردهای مختلف بلوکهای ساختمانی جعبه ایمنی حریم خصوصی را تعیین کنند. |
ثبت نام و تاییدیه
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
محدودیت | فرآیند ثبتنام به این معناست که Google میتواند تصمیم بگیرد که کدام شرکت در اکوسیستم مجاز به استفاده از APIهای Privacy Sandbox است. | فرآیند ثبت نام و تأیید اساساً مستلزم تأیید نهاد است (به عنوان مثال، نهاد دارای شماره DUNs است، می تواند پیوندی به خط مشی حفظ حریم خصوصی ارائه دهد، و غیره) و تأیید عمومی را برای فراخوانی APIها الزامی می کند. نهادهایی که می توانند با موفقیت شرایط ثبت نام را برآورده کنند، اعتبارسنجی خواهند شد. برای شرکتهایی که DUN ندارند، ما یک فرآیند تسریعشده و رایگان را با Dun & Bradstreet برای به دست آوردن آن ارائه میکنیم. هدف افزایش حفاظت از حریم خصوصی APIها (با اقداماتی که قبلا ذکر شد) و همچنین افزودن یک لایه شفافیت به APIهای Privacy Sandbox است، بنابراین افراد علاقه مند بتوانند بهتر بفهمند چه کسی از کدام API استفاده می کند و چه گواهی هایی را ارائه می کند. ما آماده بازخورد بیشتر صنعت در مورد این موضوع هستیم، که قبلاً برای شکل دادن به فرآیند استفاده شده است. |
سربار ثبت نام مجدد | پرونده گواهینامه هر 12 ماه یکبار منقضی می شود و وب سایت ها را ملزم به ثبت نام مجدد می کند. | ما بازخوردهای اکوسیستم را شنیده ایم و رویکرد خود را بر این اساس اصلاح کرده ایم. این بدان معناست که فایلها پس از 12 ماه یا هر دوره زمانی مشخصی منقضی نمیشوند. ما در حال به روز رسانی راهنمای برنامه نویس ثبت نام خود با زمینه های اضافی هستیم. |
فایل تصدیق | چگونه از فایل تصدیق استفاده می شود؟ | همه شرکتهایی که APIهای مرتبط و اندازهگیری را فراخوانی میکنند، در مهلت اجرایی ملزم خواهند بود تا فایل گواهی را در سایت خود آپلود کنند و تا زمانی که شما قصد دارید به فراخوانی APIها ادامه دهید، آن را برای عموم نگه دارند. وبسایتها میتوانند تقریباً یک درخواست در ساعت از Privacy Sandbox انتظار داشته باشند و سایر نهادهای بالقوه نیز ممکن است درخواست کنند. این کار از طریق مکانیسم خود سیستم ثبت نام برای پرس و جو از سرورهای نهادهای ثبت شده و اطمینان از معتبر بودن فایل گواهی انجام می شود. گواهینامه ها در گزارش های شفافیت گنجانده شده و برای عموم قابل مشاهده خواهد بود. ما از شرکت ها انتظار داریم که مطابق با گواهینامه های اعلام شده خود عمل کنند، همانطور که سایر اکوسیستم ها و نهادهای نظارتی مربوطه این کار را انجام می دهند. |
ثبت نام | ثبت نام در هر سایت است یا هر مبدا؟ | ثبت نام در سطح سایت می باشد. |
نمایش محتوا و تبلیغات مرتبط
موضوعات
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
عملکرد | نگرانیهای عملکرد در مورد تأثیر نرخ انتخاب موضوعات در منطقه اقتصادی اروپا. | ما به ذینفعان مربوطه پیشنهاد می کنیم که در مورد این موضوع با مرجع حفاظت از داده های مربوطه خود تماس بگیرند. آنها بهترین موقعیت را برای رسیدگی به چنین نگرانیهایی دارند و تأثیر میگذارند که آیا برنامههای فنآوریهای تقویتکننده حریم خصوصی توسط قوانین تشویق میشوند یا در عوض مانند ردیابی رفتار میشوند که نیازمند رویکردهای مشابه برای رضایت است. مورد دوم ممکن است باعث شود APIهایی مانند آنهایی که در Privacy Sandbox وجود دارد، اغلب در دسترس نباشند. |
ثبت نام | آیا پیشنهاد دهندگان پایین دستی برای استفاده از سیگنال های Topics از SSP های بالادستی باید در Topics API ثبت نام کنند؟ | گیرنده های پایین دستی موضوعاتی فراتر از تماس گیرنده اولیه Topics API نیازی به ثبت نام ندارند، اگرچه بسیاری از آنها احتمالاً برای استفاده های دیگر API ثبت نام می کنند. فهرستی از ثبتنامشدگان Privacy Sandbox بهعنوان بخشی از تلاشهای شفافسازی برنامه، بهصورت برنامهریزی ارائه میشود، که به تماسگیرنده علاقهمند به Topics API اجازه میدهد بررسی کند که آیا گیرندهای که موضوعی را برایش ارسال میکند، ثبت نام کرده است یا خیر. |
فیلتر کردن موضوعات | درخواست اعمال فیلتر تماس گیرنده دیگر برای موضوعاتی که آنها در صفحه بازیابی می کنند، به منظور به اشتراک گذاشتن تنها مواردی که خریداران واجد شرایط بازیابی هستند. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
حذف سایت | وب سایت ها را از مشارکت در موضوعات کاربر مستثنی کنید. | موضوعات به طور پیش فرض فراخوانی نمی شوند. توجه به این نکته مهم است که هنگام انتخاب موضوعات هیچ محتوای صفحه در نظر گرفته نمی شود و همه موضوعات برای اطمینان از حساس نبودن آنها تنظیم شده است. یک وب سایت همچنین می تواند سایت خود را از لحاظ کردن موضوع در محاسبه موضوع از طریق سربرگ خط مشی مجوز زیر محدود کند: Permissions-Policy: browsing-topics=() |
مشاهده موضوعات | به ناشران اجازه دهید تا به Chrome اجازه دهند تا موضوعات را بر اساس محتوای صفحه (مثلاً سر یا بدن) طبقه بندی کند. | ما قبلاً ارائه عملکردی برای طبقهبندی سایتها به موضوعات بر اساس محتوای صفحه در نظر گرفتیم و تصمیم گرفتیم بر اساس نگرانیهای مربوط به حفظ حریم خصوصی و امنیتی به جلو حرکت نکنیم. این پیشنهاد ممکن است برخی از این نگرانی ها را کاهش دهد، اما مشخص نیست که تا چه حد. با توجه به دوره آزمایش CMA آتی، انتظار نداریم این تغییر قبل از 3PCD رخ دهد. ما از بازخورد اضافی در اینجا استقبال می کنیم . |
مشاهده موضوعات | خطمشیهای مجوز دقیقتری را برای ناشران ارائه دهید. | ارائه خطمشیهای مجوز دقیقتر برای ناشران، سایتهای ناشر را قادر میسازد تا بر کاربرد Topics API برای کل اکوسیستم تأثیر منفی بگذارند، بدون اینکه تأثیر منفی بر کاربرد Topics API برای خود سایت بگذارد. برای پشتیبانی از مجوزهای جداگانه برای بازیابی و مشاهده مشکل GitHub برای بحث دقیق تر در مورد موضوع، به خط مشی مجوزهای به روز رسانی مراجعه کنید. |
موضوعات پزشکی و بهداشتی | چرا تاکسونومی موضوعات موضوعاتی را در دسته بندی های پزشکی یا بهداشت پوشش نمی دهد؟ | مقوله های پزشکی و بهداشتی موضوعات حساسی در نظر گرفته می شوند و بنابراین از طبقه بندی موضوعات حذف می شوند. |
بازیابی موضوعات | روشی سریعتر برای DSPها برای دریافت موضوعات بدون واکشی با استفاده از سرصفحه. | متدهای هدر نسبت به ایجاد یک iframe متقاطع و برقراری فراخوانی document.browsingTopics() از آن کارایی بیشتری دارند و هزینه کمتری دارند. (یک iframe متقاطع باید برای تماس استفاده شود، زیرا زمینه سطح بالا برای مشاهده یک موضوع باید با زمینه ای که از آن به موضوعات دسترسی پیدا می شود مطابقت داشته باشد.) این در اینجا به تفصیل مورد بحث قرار گرفت. |
بازیابی موضوعات | درخواستهایی برای پشتیبانی از ارسال موضوعات از طریق هدر در درخواستهای برچسب اسکریپت متقابل. | از منظر امنیتی، این امکان پذیر نیست. هر سند و محیط اجرای آن با یک مبدأ واحد مرتبط است - منبع سند. منابع فرعی شخص ثالث بارگیری و اجرا شده در همان محیط، متعلق به مبدأ سند در نظر گرفته می شود. این برای جلوگیری از نشت داده های بدون رضایت از یک منبع به منبع دیگر است. یک جایگزین، ارائه ویژگی browsingTopics در تگهای <script> است. این باید از منظر امنیتی تمیز باشد و تاخیر اضافی اضافه نکند. ما آماده بازخورد از طرف های علاقه مند هستیم. |
آگاهی | آگاهی عمومی از Topics API و نحوه استفاده از API را بهبود بخشید. | ما با ذینفعی که این بازخورد را ارائه کرده بود درگیر شدیم و این مشکل در GitHub حل شد. در آینده، ما به حمایت از درک اکوسیستم از API ادامه خواهیم داد و مشتاقانه منتظر شنیدن نظرات ذینفعان هستیم. در عین حال، به سهامدارانی که میخواهند درباره موضوعات API بیشتر بدانند، پیشنهاد میکنیم که با مستندات راهنمای برنامهنویس Chrome آشنا شوند. |
اطلاع رسانی | اعلان برای هشدار به کاربر هنگامی که موضوعات آنها توسط یک وب سایت مشاهده می شود. | ما به این بازخورد در GitHub پرداختیم . کاربران میتوانند درباره کنترلهای موضوعات در مرکز راهنمای Chrome اطلاعات بیشتری کسب کنند. |
یادگیری ماشینی | چگونه می توان از ML برای استنباط موضوعات کاربر استفاده کرد؟ | ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی استقبال می کنیم . |
سودمندی برای انواع مختلف ذینفعان | شرکتهای فناوری تبلیغاتی کوچکتر ممکن است نتوانند موضوعات را به دلیل نحوه محاسبه مرورگرها مشاهده کنند. | فقط فناوری های تبلیغاتی که مشاهده کرده اند کاربر از صفحه ای در مورد موضوع مورد نظر در سه هفته گذشته بازدید کرده است، موضوعی را دریافت می کنند. اگر فناوری تبلیغات در سه هفته گذشته برای آن کاربر در سایتی در مورد آن موضوع، API را فراخوانی نکرده باشد، مقدار برگشتی خالی خواهد بود. این ویژگی به این معنی است که فناوری های تبلیغاتی که خدمات آنها توسط تعداد بیشتری از صاحبان سایت استفاده می شود و بنابراین فرصت بیشتری برای مشاهده بازدید از سایت توسط یک کاربر خاص دارند، ممکن است موضوعات بیشتری را نسبت به سایر فناوری های تبلیغاتی دریافت کنند. این ویژگی برای حفاظت از حریم خصوصی API ضروری است زیرا در دسترس بودن اطلاعات مربوط به یک کاربر را فقط به طرف هایی محدود می کند که قبلاً می توانند همان اطلاعات اساسی را مشاهده کنند (در حال حاضر از طریق کوکی های شخص ثالث). |
درخواست XHR | چه زمانی گنجاندن موضوعات در درخواستهای XMLHttpRequest (XHR) منسوخ میشود؟ | همانطور که کروم در آگوست 2023 اعلام کرد ، کروم هنگام انتقال از Origin Trial به General Availability، پشتیبانی از XHR را منسوخ کرد. با پیشرفت افزایش موضوعات، پشتیبانی XHR فقط برای کاربرانی که ویژگیهای OT برایشان فعال بود، در نظر گرفته شد و با ادغام گروههای آزمایشی OT منسوخ شد. اگر از Topics با XHR استفاده می کردید، سایت های شما خراب نمی شوند. موضوعات به عنوان درخواست XHR شما اضافه نمی شوند. توصیه میکنیم یا به fetch برای درخواست خود انتقال دهید، از ویژگی iframe استفاده کنید یا از JavaScript API برای بازیابی موضوعات استفاده کنید. Fetch توسط همه مرورگرهای مدرن پشتیبانی می شود، اما اینترنت اکسپلورر یا اپرا مینی پشتیبانی نمی شود. |
فرآیند به روز رسانی طبقه بندی و طبقه بندی | اطلاعات بیشتر در مورد تاکسونومی موضوعات و سرعت انتشار طبقهبندیکننده و نحوه آماده شدن شرکتها برای چنین بهروزرسانیهایی. | پاسخ ما نسبت به Q2 بدون تغییر باقی می ماند: همانطور که در پست وبلاگ اخیر به اشتراک گذاشته شد، ما انتظار داریم که طبقه بندی در طول زمان تکامل یابد، و در نهایت مدیریت طبقه بندی به یک حزب خارجی که نماینده سهامداران از سراسر صنعت است، تبدیل شود. ما همچنین طرح رمپ آپ را در گروه اعلام موضوعات به اشتراک گذاشتیم. |
سوء استفاده | حمله بالقوه از طریق زنجیره تغییر مسیر. | ما در حال بررسی این موضوع هستیم و از بازخورد اضافی استقبال می کنیم. |
انواع موجودی ناشر | آزمایش مخاطبین و موضوعات محافظت شده از چه نوع موجودی ناشر پشتیبانی می کند؟ | نه مخاطب محافظت شده و نه موضوعات ذاتاً از نظر انواع موجودی که میتوانند در آن استفاده شوند محدودکننده نیستند. |
زمان افزایش سرعت | برای رسیدن به 100% طبقه بندی های جدید، زمان افزایش را توصیه نکنید. | به دنبال این درخواست بازخورد از اکوسیستم و بحث در طول جلسات PATCG، ما برنامه خود را برای عرضه طبقه بندی جدید اعلام کرده ایم. |
API مخاطب محافظت شده (FLEDGE سابق)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
مزایده های سطح بالا | امکان استفاده از سرور تبلیغات ناشر Google بدون اینکه به Google Ad Manager کنترل حراج سطح بالای Protected Audience API را بدهد. | پاسخ ارائه شده توسط Google Ad Manager: برنامههای Google Ad Manager برای API مخاطبان محافظتشده شامل پشتیبانی از سرور تبلیغات ناشر Google بدون کنترل حراج مخاطب محافظتشده سطح بالا، به دلایل زیر نیست. برای ارائه خدمات مناسب به مشتریان خود در بازار ارائه تبلیغات ناشر، سرور تبلیغات ناشر Google باید کنترل حراج مخاطب محافظت شده سطح بالا را حفظ کند. به عنوان یک سرور تبلیغات ناشر، نقش ما این است که پیشبینی ناشران را ارائه دهیم تا بتوانند در مورد کمپینهای فروش مستقیم بدون رزرو بیش از حد مذاکره کنند و رزروهای مستقیم خود را بهطور بهینه انجام دهند. انجام این کار مستلزم اجرای حراج نهایی برای مقایسه تمام تقاضاهای واجد شرایط مستقیم و غیرمستقیم است. پیش بینی و سرعت عملکردهای اصلی هستند که ناشران از یک سرور تبلیغات انتظار دارند. بدون پیش بینی دقیق، ناشران ممکن است در نهایت موجودی خود را بیش از حد بفروشند، که شهرت تجاری آنها را به خطر می اندازد. سرعتگیری نیز بسیار مهم است، زیرا ناتوانی در انجام قراردادهای رزرو با تبلیغکنندگان نیز به رابطه مستقیم ناشر-آگهیدهنده آسیب وارد میکند، که میتواند تأثیر قابلتوجهی بر تجارت ناشران داشته باشد. بنابراین، به طور خلاصه، فعالیت سرور تبلیغات ناشر در اجرای حراج مخاطب محافظت شده سطح بالا را متمایز از سایر فعالیت های سرور تبلیغات ناشر نمی دانیم. |
directFrom | directFrom به Google Ad Manager اجازه می دهد تا ناشر را از دیدن قیمت حراج متنی خود جلوگیری کند. | پاسخ کروم: اطلاعات ارسال شده به runAdAuction() معلوم نیست که از فروشنده می آید مگر اینکه فروشنده runAdAuction() از iframe خودش فراخوانی کند. در یک حراج چند فروشنده، غیر ممکن است که همه فروشندگان فریمی را ایجاد کنند که runAdAuction() فراخوانی می کند. directFromSellerSignals با بارگیری محتوا از یک بسته منبع فرعی که از مبدا فروشنده بارگیری شده بود به این مشکل پرداخت. این تضمین می کند که صحت و یکپارچگی اطلاعات ارسال شده به حراجی از پیکربندی های فروشنده-حراج قابل دستکاری نیست. اگر ناشران بخواهند از API مخاطبان محافظتشده برای درک هر یک از اطلاعاتی که ارائهدهندگان فناوری آنها به حراجهای مخاطب محافظتشده منتقل میکنند استفاده کنند، میتوانند این قابلیت را از آن ارائهدهندگان فناوری بخواهند.پاسخ ارائه شده توسط Google Ad Manager: ما برای سالها تمرکز شدیدی بر عادلانه بودن حراج داشتهایم، از جمله قول دادهایم که هیچ قیمتی از منابع تبلیغاتی تضمیننشده ناشر، از جمله قیمتهای اقلام خطی غیر تضمینی، با خریدار دیگری قبل از پیشنهاد در حراج به اشتراک گذاشته نمیشود، که بعداً در تعهدات خود به سازمان رقابت فرانسه مجدداً تأیید کردیم. برای حراجهای مخاطب محافظتشده، ما قصد داریم با استفاده از directFromSellerSignals به قول خود عمل کنیم و قبل از تکمیل حراج در حراجهای چند فروشنده، پیشنهاد هیچ شرکتکننده حراج را با هیچ شرکتکننده دیگری در حراج به اشتراک نگذاریم. برای روشن بودن، همانطور که در بهروزرسانی دینامیک حراج سطح بالا توضیح داده شد، قیمت حراج متنی را با حراج اجزای خودمان نیز به اشتراک نمیگذاریم. |
قرار گرفتن در معرض اطلاعات | منطق تجاری حساس و جزئیات قرارداد ممکن است توسط مرورگر افشا شود. | شخصی که از یک مرورگر وب استفاده می کند می تواند همه چیزهایی که در مرورگر اتفاق می افتد را ببیند. وقتی یک مزایده تبلیغاتی در داخل مرورگر اتفاق میافتد، این درست است که شخصی که مرورگرش است میتواند برگزاری آن حراج را تماشا کند، از جمله اینکه ببیند طرفهای مختلف چقدر برای پیشنهاد پیشنهاد میکنند. از آنجایی که یک مرورگر نماینده کاربر است، فکر نمیکنیم که امکان یا مطلوبی برای تغییر آن وجود داشته باشد. با این حال، فقط شخصی که از مرورگر استفاده می کند، امکان مشاهده این عملیات را دارد. حراج روی دستگاهی که با استفاده از Protected Audience API اجرا میشود، برای هیچ سروری از جمله سرور Google قابل مشاهده نیست. |
PerBuyerExperiment | محدوده ارزش فعلی ازPerBuyerExperiment می تواند به خریداران اجازه دهد که داده های متنی را با درخواست سرور مورد اعتماد مرتبط کنند. | استفاده از API مخاطب محافظت شده به این روش با تأیید اجباری Privacy Sandbox که کاربران API سعی در دور زدن محافظتهای Privacy Sandbox ندارند، مطابقت ندارد. در آینده، این الزام که سرورهای کلید-مقدار در محیطهای اجرایی قابل اعتماد (TEE) اجرا شوند، حفاظت فنی در برابر این حمله را فراهم میکند. |
خط مشی همان مبدا | برای اجازه دادن به زیر دامنهها، سیاست همان مبدأ را کاهش دهید. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
نسخه API | درخواست نسخهسازی و یادداشتهای انتشار برای تغییرات در Protected Audience API. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
مزایده های چند SSP | به سیگنالهای حراج سطح بالا اجازه دهید ادغامهای JSON را با auctionSignals سیگنال مؤلفه انجام دهند. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
حد پیشنهاد | محدودیت تعداد مؤلفههای تبلیغاتی را که وارد پیشنهاد قیمت میشوند از 20 به 40 افزایش دهید. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم در مورد اینکه چرا این امر مفید است استقبال می کنیم. |
(در فصل های گذشته نیز گزارش شده است) اجرای حراج مخاطبان حفاظت شده | گزارش از آزمایشکنندگان مبنی بر اینکه حراجهای مخاطب محافظتشده تأخیر بالایی دارند. | در مورد سؤالات تأخیر، API مخاطب محافظت شده عموماً از الگوی استاندارد موجود در کنترلهای ساختمان پیروی میکند که به فروشندگان اجازه میدهد تصمیم بگیرند که مناقصهدهندگان چقدر زمان و منابع میتوانند مصرف کنند، و ابزارهایی ایجاد میکند که به خریداران اجازه میدهد تصمیم بگیرند چگونه از منابع در دسترس خود به بهترین شکل استفاده کنند. این کنترل ها و ابزارها به طور کلی امروزه در دسترس هستند، اما سود کامل آنها تنها پس از پذیرش توسط خریداران و فروشندگان محقق می شود. علاوه بر این، Chrome به کار بر روی انواع بهبودهای زیرساختی برای سرعت حراج ( crrev.com/1190815 , crrev.com/1199839 , crrev.com/1201837 , crrev.com/1198339 , crrev.com/1197323 ) ادامه می دهد. ما از هر دو نیمه این تلاش تأخیر بازخورد میخواهیم: ابزارهای جدیدی که خریداران و فروشندگان مفید میدانند، و گزارشهایی از تنگناهای مشاهدهشده که مهندسان Chrome باید بررسی کنند. |
فیلتر سمت خرید | بر اساس گروههای علاقه، پشتیبانی از فیلتر سمت خرید را اضافه کنید. | ما چندین روش را پیشنهاد کردهایم که SSPها و DSPها میتوانند طرحهای خود را برای مدیریت این موضوع تغییر دهند:
|
کنترل گروه علاقه ناشر | پشتیبانی از ناشرانی که به دنبال واگذاری استفاده از گروههای علاقه ایجاد شده توسط ناشر هستند. | ما با بسیاری از طرف ها در مورد این درخواست مذاکره کرده ایم. ما بر این باوریم که همه موارد استفاده از این دست که در «تفویض» گروههای ذینفع ایجاد شده توسط ناشر دخیل هستند، اکنون قابل پذیرش هستند، و علاوه بر این، باید پشتیبانی بیشتری ایجاد کنیم تا برخی از موارد استفاده در آینده روانتر شوند. |
(همچنین در Q2 گزارش شده است) محیط های اجرایی مورد اعتماد | پشتیبانی از Trusted Execution Environments (TEE) در محیط های ابری غیر عمومی. | پاسخ ما مشابه فصل های قبل است: در حالی که ما به بررسی پشتیبانی از گزینههای فراتر از راهحلهای مبتنی بر ابر عمومی ادامه میدهیم، هیچ برنامهای برای پشتیبانی از TEEهای داخلی نداریم. در این مرحله، با توجه به الزامات امنیتی Privacy Sandbox و چالشهای قابل توجهی که توسط استقرارهای داخلی ارائه میشود، ما معتقدیم که ادامه گسترش و بهبود استقرارهای مبتنی بر ابر (به عنوان مثال، پشتیبانی از Google Cloud علاوه بر AWS) بیشترین سود را برای اکوسیستم دارد. با این حال، ما از بازخورد اضافی در مورد اینکه چرا چنین الزامی با توجه به محدودیتهای حریم خصوصی و امنیتی ضروری و امکانپذیر است، استقبال میکنیم. |
محیط اجرای مورد اعتماد | اجزای موجود در مسیر سرویس دهی TEE، مانند متعادل کننده بار، می توانند تمام ترافیک را مشاهده کنند و اطلاعات آدرس IP هر درخواست را داشته باشند. | در حال حاضر آدرس IP به عنوان یک فراداده در سرصفحههای درخواست به سرویس تبلیغاتی فروشنده نامعتبر در مورد مزایدههای مزایده و مزایده و حراج مخاطب محافظت شده روی دستگاه ارسال میشود. برای اطلاعات بیشتر به ارسال ابرداده مراجعه کنید. در درازمدت، ما قصد داریم ترافیک فناوری تبلیغات و ردیابی را از طریق یک IP Proxy ردیابی کنیم، که از مشاهده تمام ترافیک در مسیر سرویس توسط اجزا جلوگیری میکند. |
زمان برای زندگی (TTL) | آیا زمان حیات (TTL) قبل از اینکه سرویس ها باید کلیدهای جدید را درخواست کنند تنظیم می شود یا قرار است انعطاف پذیر (یا پویا) باشد؟ | TTL به طور کلی ثابت است. در حال حاضر، TTL برای عموم 8 روز است، و چرخش هر 7 روز اتفاق می افتد. TTL همچنین برای کلیدهای خصوصی در مورد سرویس تجمع یکسان است. در مورد خدمات Bidding و Auction، کلیدهای خصوصی و عمومی هر N ساعت یک بار در مسیر غیر درخواستی واکشی می شوند و در حافظه پنهان ذخیره می شوند، به طوری که بین چرخش کلیدها و دریافت این کلیدها توسط سرورها بیش از N ساعت تاخیر وجود ندارد. بافر 1 روزه بین چرخش کلید و انقضا برای اطمینان از این است که حتی اگر تولید کلید شکست بخورد، خدمات می توانند به کار خود ادامه دهند. ما در حال بررسی گسترش TTL برای انعطاف پذیری بیشتر در برابر قطع هستیم. در صورت نشت کلید، ما قصد داریم به صورت دستی تولید کلید را اجباری کنیم و کلیدها را زودتر باطل کنیم. توجه داشته باشید که کلیدهای عمومی در حال حاضر به مدت 24 ساعت دوباره روی مشتریان ذخیره می شوند تا اطمینان حاصل شود که در صورت قطع هماهنگ کننده، سرویس ها همچنان می توانند کار کنند. |
شکل دهی ترافیک | پشتیبانی از شکل دهی ترافیک برای خدمات مناقصه و مزایده. | خریداران میتوانند بر اساس دادههای شخص اول ناشر یا دادههای متنی، تقاضا برای حراجهای مخاطب محافظت شده را نشان دهند. فروشندگان میتوانند تصمیمات مشابهی را در سرور تبلیغات فروشنده یا سرور Ad Exchange نیز انجام دهند. این مدلها را میتوان بر روی دادههای 1P و هرگونه گزارش انبوه از حراجهای مخاطب محافظتشده آموزش داد. فروشندگان می توانند از این اطلاعات برای جلوگیری از ارسال درخواست به سرورهای Bidding و Auction در زمانی که هیچ تقاضایی برای حراج مخاطب محافظت شده وجود ندارد استفاده کنند. ما معتقدیم که این می تواند راهی موثر برای شکل دادن به ترافیک باشد. |
حراج قطعات | کدام سیگنالهای حراج سطح بالا با فروشندگان کامپوننت به اشتراک گذاشته میشوند؟ | خریداران در حراج قطعات فقط سیگنال هایی را از فروشنده قطعات دریافت می کنند. ما به دنبال به اشتراک گذاشتن اسناد در مورد توالی کلی یک حراج ترکیبی با پیشنهاد سرصفحه و حراج مخاطب محافظت شده هستیم. |
رندر ویدیو | پشتیبانی از رندر ویدیو با استفاده از مخاطبان محافظت شده و فریم های حصاردار. | Protected Audience API از رندر ویدیو با استفاده از مکانیزمی که به iframe متکی است پشتیبانی می کند. با این حال، ما هنوز راهحلی را طراحی نکردهایم که با فریمهای حصاردار سازگار باشد، و این یکی از دلایلی است که تصمیم گرفتیم اجرای فریمهای حصاردار را تا سال 2026 عقب بیندازیم. این بدان معناست که اگر شریکی تصمیم بگیرد اکنون فریمهای حصاردار را اجرا کند، پشتیبانی از ویدیو برای آن شریک وجود ندارد. |
محدودیت فرکانس | (در فصل های گذشته نیز گزارش شده است) کنترل فرکانس برای هر کاربر در یک کمپین و گروه تبلیغاتی. | پاسخ ما نسبت به گزارش های قبلی تغییری نکرده است: مخاطب محافظتشده از محدودیت فرکانس برای حراجهای روی دستگاه و کمپینهای متنی و نام تجاری نیز پشتیبانی میکند. ذخیرهسازی مشترک و سرپوشهای مخصوص سایت نیز میتوانند برای کنترلهای درپوش فرکانس اضافی استفاده شوند. |
تنظیمات برگزیده تبلیغات | آیا مخاطب محافظت شده راهی برای انصراف یا مسدود کردن فهرست توسط سایتهای تبلیغکننده یا راهی برای خروج از همه گروههای ذینفع از یک مالک ارائه میکند؟ | راههای مختلفی برای کاربران وجود دارد که میتوانند دسترسی به API مخاطب محافظت شده و سایر ویژگیهای Privacy Sandbox را مسدود کنند . |
خط مشی مبدأ یکسان برای URL منبع اسکریپت های مناقصه و حراج | این الزام را کاهش دهید که همه فیلدهایی که نشانیهای اینترنتی را برای بارگیری اسکریپتها یا JSON مشخص میکنند، باید با مالک یک منبع باشند. | ما در حال حاضر در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم . |
forDebuggingOnly | پتانسیل برای forDebuggingOnly که در صورت باقی ماندن در پست 3PCD مورد سوء استفاده قرار گیرد. | در طول سالهای گذشته، پس از منسوخ شدن کوکیهای شخص ثالث، بازخوردی را از اکوسیستم در رابطه با شکافهای عملکردی در مخاطبین محافظتشده دریافت کردهایم، و در تلاش هستیم تا طرحی را برای پشتیبانی از آنها در پست 3PCD بدون به خطر انداختن اهداف Privacy Sandbox تدوین کنیم. ما از هرگونه پیشنهاد و بازخورد اضافی در مورد عملکردی که اکوسیستم مایل به مشاهده آن است استقبال می کنیم. |
گروه های علاقه مند متعدد | از چندین گروه ذینفع در یک پیشنهاد استفاده کنید. | این مورد امروزه در Protected Audience API پشتیبانی نمیشود، زیرا منجر به تغییر مدل حریم خصوصی اساسی میشود. ما از بحث بیشتر در اینجا استقبال می کنیم. |
حراج های روی دستگاه | آیا Chrome در Android از حراجهای مخاطب محافظت شده روی دستگاه پشتیبانی میکند؟ | بله، حراجهای روی دستگاه در Chrome در Android پشتیبانی میشوند . |
(گزارش شده در سه ماهه دوم 2023) داده های مربوط به کلیک | داده های مربوط به کلیک را به مرورگر Signals اضافه کنید. | ما همچنان به ارزیابی این درخواست ویژگی ادامه میدهیم و از بازخورد اضافی در مورد اینکه چرا باید این درخواست اولویتبندی شود، استقبال میکنیم. |
ارائه دهندگان محیط اجرایی مورد اعتماد | آیا تفاوتهای مادی در ارائههای Trusted Execution Environment ارائهدهندگان مختلف ابری وجود دارد؟ | ما از هیچ تفاوت عمده ای آگاه نیستیم، اما توصیه می کنیم اکوسیستم راهنمای استقرار عمومی را بررسی کند تا ببیند کدام راه حل مناسب نیازهای آنها است. Google Cloud . AWS . |
(گزارش شده در سه ماهه قبل) پشتیبانی از هدف گذاری گروهی با علاقه منفی | یک API برای پشتیبانی از هدفگیری گروههای علاقه منفی: نمایش تبلیغات تنها در صورتی که کاربر به یک گروه علاقهمند تعلق نداشته باشد. | ما به دنبال اجرای این ویژگی هستیم و در حال بحث در مورد درخواست هستیم. |
نقض محتوا | از ویژگیهایی پشتیبانی میکند که به کاربران امکان میدهد آگهیهای بد ارائه شده توسط Protected Audience API در فریمهای حصاردار را گزارش کنند. | ما معتقدیم که مکانیسم گزارشدهی تبلیغات قاب حصاردار موجود، گزینههای خوبی را برای فناوریهای تبلیغاتی ارائه میدهد که میخواهند یک جریان گزارشدهی «تبلیغات بد» تولید شده توسط کاربر داشته باشند. این امر باعث می شود تا تبلیغات بد به گونه ای اساساً بدون تغییر نسبت به استانداردهای صنعت امروز گزارش شود. در صورت باقی ماندن شکاف، از درخواستهای ویژگی اضافی استقبال میکنیم، از جمله در طول زمان پس از حذف کوکی شخص ثالث، اما قبل از فراگیر شدن رندر قاب حصاردار. |
گزارش API جمع آوری خصوصی | چگونه می توانیم زمانی را که کاربر در آن گروه علاقه سپری کرده است محاسبه کنیم؟ | در Chrome M116+ شما باید بتوانید از تازگی مطابق تعریف pull/639 استفاده کنید. |
سرور K-Anonymity | اطلاعات بیشتر در مورد سرور K-Anonymity. | ما اطلاعات بیشتری را در مورد سرورهای K-Anonymity در اینجا به اشتراک گذاشتیم و از بازخوردهای اضافی استقبال می کنیم. |
URL های خلاقانه پویا | پشتیبانی از URL های خلاقانه بدون اعلام قبلی در حالی که همچنان به K-ناشناس بودن احترام می گذارد. | ما در حال بحث در مورد این درخواست ویژگی هستیم و از بازخورد اضافی در مورد اینکه چرا باید این مورد اولویت بندی شود، استقبال می کنیم. |
الزام K-ناشناس بودن | آیا الزام ناشناس بودن k در بهروزرسانیهای Interest Group مجدداً معرفی میشود؟ | ما تغییراتی را در موقعیت بیان شده در این پست GitHub پیش بینی نمی کنیم. همانطور که در آن پست اعلام شد، ما تصمیم گرفتیم که الزام ناشناس بودن k را در بهروزرسانیهای گروه علاقهمند مخاطب محافظتشده حذف کنیم، که تأثیر قابلتوجهی بر حفاظتهای حریم خصوصی کلی API ندارد، و ما قصد داریم در تاریخ بعد، زمانی که فناوریهای مرتبط توسعه، استقرار و به کار گرفته میشوند، سایر حفاظتهای بالقوه مستقیمتر (مانند حریم خصوصی آدرس IP یا سرور بهروزرسانی قابل اعتماد) را در نظر بگیریم. |
تست بتا خدمات مناقصه و مزایده | آزمایش بتا خدمات مزایده و مزایده چه زمانی آغاز می شود؟ | همانطور که در جدول زمانی و نقشه راه گفته شد ، مرحله اول آزمایش خدمات مناقصه و حراج در نوامبر 2023 آغاز می شود. |
سد سازی جاده | درخواست برای پشتیبانی از هماهنگی خلاق برای شبکه های تبلیغاتی (SSP و DSP در یک شرکت یا خصوصیات مشابه هستند). | ما از بازخورد این مورد استفاده قدردانی می کنیم و به دنبال این هستیم که بدانیم آیا فناوری های تبلیغاتی بیشتری علاقه مند به دیدن این پشتیبانی هستند یا خیر. ما از بازخورد اضافی استقبال می کنیم . |
تبلیغات بومی | پشتیبانی قاب حصارکشی برای تبلیغات بومی. | ما در حال بررسی حمایت از پرونده استفاده هستیم و در مورد راه حل ها و راه حل های احتمالی بحث می کنیم. |
ناشناس بودن k | چگونه می توانم تبلیغات گروه علاقه ای را که آستانه K-Anon را برآورده می کنند ، به حداکثر برسانم؟ | ما راهنمایی های تاکتیکی در مورد این موضوع به اشتراک گذاشته ایم. |
پشتیبانی پست | پشتیبانی از ارسال داده های حراج از طریق درخواست های پست. | ما در حال ارزیابی این درخواست ویژگی هستیم و از ارسال های اضافی شماره GitHub در مورد اینکه چرا این امر باید در اولویت قرار گیرد استقبال می کنیم. |
دانه بندی گزارش | دانه بندی گزارش دهنده گزارش تبلیغات قاب حصارکشی با تبلیغات متشکل از چند قطعه چیست؟ | طراحی فعلی اجازه ضبط شناسه یا موقعیت محصول را نمی دهد زیرا این ممکن است حریم شخصی کاربر را به خطر بیاندازد. فقط قابل استفاده reserved.top_navigation قابل استفاده است ، که در صورت فعال سازی کاربر (مانند کلیک) در قاب حصیری مؤلفه تبلیغاتی ارسال می شود ، که منجر به یک ناوبری سطح بالا می شود. |
حراج تبلیغات | آیا یک SSP که در یک حراج مؤلفه شرکت می کند ، می تواند حراج مؤلفه دیگری را ایجاد کند؟ | یک componentSeller هم نمی تواند شامل componentAuctions باشد.حراج چند فروش فقط دو سطح دارد: 1. حراج های مؤلفه به طور موازی. 2. حراج سطح بالا (جایی که تبلیغ برنده از هر componentAuction رقابت می کند). |
در دسترس بودن خدمات مناقصه و حراج | آیا مناقصه و حراج در مرحله آزمایش تسهیل شده Chrome در دسترس خواهد بود؟ | سرور مناقصه و حراج در مرحله آزمایش تسهیل شده Chrome در دسترس نخواهد بود. |
سیگنال های مناقصه | به مرورگرها اجازه دهید سیگنال های مناقصه را درخواست و حذف کنند. | ما در مورد این درخواست بحث می کنیم و از بازخورد اضافی در مورد اینکه چرا باید این امر در اولویت قرار گیرد استقبال می کنیم . |
generateBid() | امکان به روزرسانی userBiddingSignals Usergroup از طریق updateURL . | ما این پیشنهاد را در نظر می گیریم و از بازخورد و بحث اضافی استقبال می کنیم . |
انواع موجودی ناشر | چه نوع موجودی ناشر توسط مخاطبان محافظت شده و آزمایش مباحث پشتیبانی می شود؟ | نه مخاطبان محافظت شده و نه مباحث از نظر انواع موجودی که می توان از آنها استفاده کرد ، ذاتاً محدود کننده نیستند. |
ادغام سرور به سرور | آیا ادغام مستقیم بین SSP و DSP برای مخاطبان محافظت شده لازم است؟ | اگر DSP نیازی به پردازش سیگنال های متنی در سرور خود نباشد ، ادغام مستقیم بین SSP و DSP لازم نیست تا بتواند اطلاعات پردازش شده را به عملکرد مناقصه در دستگاه خود منتقل کند. |
یک قسمت bid_currency در B&A | پشتیبانی از قسمت bid_currency در سرویس مناقصه و حراج. | B&A هنوز از bid_currency پشتیبانی نمی کند ، اگرچه ما قصد داریم تا پایان ژانویه 2024 از آن پشتیبانی کنیم. به جدول زمانی مراجعه کنید. |
perBuyerSignals | آیا محدودیت اندازه برای perBuyerSignals وجود دارد؟ | هیچ محدودیتی در تعداد سیگنال های هر خریدار وجود ندارد ، اما ارسال داده های بیش از حد ممکن است اثرات مضر بر عملکرد مرورگر داشته باشد. |
موارد استفاده متقاطع | آیا می توانیم از گروه های علاقه مند API مخاطبان محافظت شده در چندین وب سایت استفاده کنیم؟ | مخاطبان محافظت شده برای چنین مواردی طراحی نشده اند ، همانطور که در Turtledove/شماره ها/282 توضیح داده شده است. |
درخواست های گروه علاقه HTTP | شامل حباب گروه علاقه در هدرهای HTTP شوید. | ما در حال بررسی این درخواست هستیم و از این درخواست بازخورد بیشتری استقبال می کنیم . |
کنترل کیفیت تبلیغات | از دست دادن کنترل کیفیت آگهی مربوط به اطلاعات متقابل. | ما در حال بررسی این بازخورد هستیم و از بازخورد اضافی استقبال می کنیم . |
Chrome DevTools | درخواست های شبکه محافظت شده مخاطبان در حال خروج باید در برگه شبکه Tools Developer Crome قابل مشاهده باشد. | ما در حال کار بر روی فعال کردن این قابلیت در برگه شبکه هستیم و از بازخورد اضافی در مورد اینکه چرا باید این امر در اولویت قرار گیرد استقبال می کنیم . |
محیط اجرای مورد اعتماد | چه موقع جزئیات مربوط به معیارها تأثیر حریم خصوصی (و مدرک آنها) به توضیح دهنده در مورد نظارت بر محیط زیست قابل اعتماد اضافه می شود؟ | ما در حال به روزرسانی توضیح دهنده با این اطلاعات هستیم. توضیح دهنده به روز شده تا نوامبر 2023 در دسترس خواهد بود. |
directFrom | چرا directFrom است directFrom به عنوان یک بسته وب بسته بندی نشده اند؟ | ما در اینجا دلیل این تصمیم را برای این تصمیم به اشتراک گذاشتیم. |
نمایندگی | آیا روش قابل دوام برای انجام نمایندگی در جایی که نتیجه یک گروه علاقه در حال انتخاب است ، یک اقدام هدفمند دیگر وجود دارد؟ | حراج های متعدد تو در تو به دو دلیل با اهداف حریم خصوصی ما سازگار نیستند. اول ، هنگامی که برنده حراج در داخل یک قاب حصارکشی قرار می گیرد ، اهداف حریم خصوصی ما برای مخاطبان محافظت شده شامل ارائه خلاقانه حاصل بدون اطلاع از متن است: URL صفحه یا کوکی شخص اول یک نقض حریم خصوصی است. در آن محیط ، حراج تو در تو قابل استفاده نیست. دوم ، مدل مخاطبان محافظت شده می گوید که برنده هر حراج باید فقط براساس داده های یک سایت اضافی باشد. حراج های تو در تو راهی برای ترکیب این امر خواهد بود که در نتیجه امکان انتخاب تبلیغات بر اساس مشخصات سایت های مختلف ایجاد می شود. |
داده ها در معیار استراحت | داده های موجود در معیار REST را در مدل اعتماد Key/Value Service توضیح دهید. | داده های موجود در سرویس ارزش کلیدی در حافظه بارگذاری می شوند و به جای انجام هرگونه ذخیره سازی خوانده شده ، از آنجا سرو می شوند. |
سیگنال داده خریدار | آیا برای سیگنال های buyer_data که از DSP دریافت می شود ، محدودیت اندازه مشخصی وجود دارد؟ | در حال حاضر هیچ محدودیت تحمیل شده مرورگر برای سیگنال های buyer_data دریافت شده از DSP ها وجود ندارد. |
اندازه گیری تبلیغات دیجیتال
گزارش انتساب (و سایر APIها)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
متقابل دستگاه | برنامه ای برای پشتیبانی متقابل از دستگاه برای API گزارش انتساب. | دستگاه متقابل چالش های جدید حریم خصوصی را در بالای 3 قطعه ارائه می دهد و همچنین با توجه به طیف وسیعی از دستگاه ها و سیستم عامل هایی که کاربر ممکن است از آن استفاده کند ، چالش های توزیع فناوری را اضافه می کند. ما در حال بررسی راه حل های بالقوه هستیم ، اما ما بر روی موارد مهم استفاده شده که در حال حاضر توسط گزارش انتساب پشتیبانی می شوند متمرکز شده ایم و برنامه ای برای معرفی پشتیبانی متقابل قبل از حذف کوکی های شخص ثالث نداریم. |
(همچنین در سه ماهه قبلی گزارش شده است) اندازه داده های ماشه | چرا اندازه داده های ماشه به 3 بیت محدود شده است؟ | اندازه آن به 3 بیت و 8 مقدار مجزا محدود می شود تا اطمینان حاصل شود که میزان اطلاعات متقابل و اطلاعات متقاطع در مورد کاربر محدود است. ما از بازیکنان اکوسیستم استقبال می کنیم تا در مورد اینکه آیا پارامتر شدن فعلی برای گزارش در سطح رویداد کافی است ، بازخورد ارائه دهند . |
قیف تبدیل | چندین دامنه را که در تبدیل استفاده شده اند گزارش دهید. | این مورد استفاده از زمان افزودن مقصد متعدد امکان پذیر است. ما از بازخورد اضافی استقبال می کنیم. |
همان دامنه در حمایت از کشور مختلف | آیا گزارش انتساب با وب سایتهایی که دارای یک دامنه یکسان هستند اما TLD های مختلف کشور هستند ، کار می کند؟ | این موضوع با ذینفعان که این سؤال را مطرح کرده است مورد بحث و حل و فصل شده است. اگر یک فناوری تبلیغی نیاز به استفاده از TLD های مختلف کشور داشته باشد ، آنها نیاز به ثبت نام های متعدد دارند ، با یکی برای هر کشور TLD. |
مخاطبان محافظت شده و گزارش انتساب | آیا فناوری های تبلیغاتی می توانند به هر دو تبدیل از طریق نمایشگاه برای حراجی های محافظت شده مخاطبان و همچنین تبدیل های کلیک برای گزارش انتساب دسترسی پیدا کنند؟ | بله ، Sandbox حریم خصوصی باید از VTC و CTC در مخاطبان محافظت شده پشتیبانی کند. |
تأخیر در گزارش AgageGregatable | تأخیر در گزارش قابل جمع کردن بیشتر را کاهش دهید. | ما بازخورد اخیر در مورد این را شنیده ایم و ایده های مشترک را در اینجا به اشتراک گذاشته ایم. ما از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
تأخیر در گزارش AgageGregatable | کاهش تأخیرها از طریق معرفی واسطه سرور. | ما در حال بررسی این پیشنهاد هستیم و از بازخورد اضافی استقبال می کنیم . |
تأخیر در گزارش سطح رویداد | تأخیرهای گزارش سطح رویداد را کاهش دهید. | پیشنهاد کامل در سطح رویداد ، که در تنظیمات انعطاف پذیر در سطح رویداد شرح داده شده است ، می تواند تاخیر گزارش در سطح رویداد را با یک تجارت سر و صدا کاهش دهد. |
منشأ گزارش منبع در هر منبع | محدودیت منشأ گزارش منبع حداکثر در هر سایت گزارش منبع ، مانع از ثبت نام منابع از منشأ گزارش های مختلف برای منشأ ناشر واحد می شود. | این مورد با ذینفعان مورد بحث قرار گرفته است که این مسئله را مطرح کرده است و یک راه حل بالقوه استفاده از 1 گزارش گزارش در هر سایت گزارش منبع قبل از تلاش دیگر راه حل های بالقوه مربوط به تغییر مسیر مورد آزمایش قرار می گیرد. ما در مورد هر بازخورد اکوسیستم اضافی نیز در مورد این حد باز هستیم. |
گزارش مسئله | چگونه می توانیم خطاها یا مسائل مربوط به API گزارش انتساب را به Chrome گزارش دهیم؟ | در حال حاضر ما توصیه می کنیم که Techs Ad هرگونه خطای API گزارش دهنده را که ممکن است به عنوان موضوعی در GitHub با آنها روبرو شوند ، گزارش دهند. اگر آنها با یک مسئله مرتبط با کروم روبرو هستند ، توصیه می کنیم یک اشکال کروم ایجاد کنید. پیوندهایی برای چگونگی و از کجا پرچم گذاری هر مشکلی را می توان در زمینه بازخورد درگیر و به اشتراک گذاشت . |
کپی برداری | چگونه می توانیم تبدیل ها را در خطوط لوله و دستگاه های مختلف اختصاص دهیم؟ | Dedupplic در بین دستگاه ها و خطوط لوله اندازه گیری یک چالش شناخته شده و فعلی است که امروزه فناوری های تبلیغاتی نیز با 3 قطعه با آن روبرو هستند. با استفاده از API گزارش انتساب ، فناوری های تبلیغاتی می توانند تصمیم بگیرند که چه زمانی تبدیل های خاص را ثبت کنند و ابرداده خاصی را اضافه کنند تا نشان دهند کدام خط لوله های اندازه گیری از آنها برای ردیابی تبدیل ها استفاده کرده اند (به عبارت دیگر ، بخشی از کلید جمع آوری) ، که می تواند در برابر سایر خطوط لوله اندازه گیری مقایسه شود. ما در مورد این بازخورد اکوسیستم اضافی باز هستیم. |
فداکاری و اولویت | درخواست اولویت اول قبل از deduplication. | ما در حال بررسی این درخواست هستیم و از بازخورد اضافی استقبال می کنیم . |
ضد تقلب | خطر استفاده از کاربر مخرب داده های سطح رویداد. | تأیید گزارش به دلایلی که در مورد این گزارش های سطح رویداد پشتیبانی نمی کند ، برای گزارش در سطح رویداد کار نمی کند؟ . |
نوع تبدیل | چگونه می توانیم بین نمای از طریق و ناوبری در گزارش انتساب تمایز قائل شویم؟ | ما گزینه فیلتر داخلی زیر را داریم: source_type . جزئیات اضافی در اینجا موجود است . |
سرویس تجمع
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
بهبود بودجه | برخی از تکنیک های تبلیغاتی در مواردی که خرابی ، خطاها یا حذف گزارش های آنها وجود دارد ، می توانند گزارش ها را دوباره پردازش کنند. | این تیم در حال بررسی راه های پرداختن به این موضوع به روشی برای حفظ حریم خصوصی است. |
ثبت نام در سایت | چندین فن آوری تبلیغاتی درخواست پشتیبانی برای پردازش چندین منشاء در همان حساب را برای موارد استفاده مانند تقسیم داده های GEO ، تبلیغ کننده درخواست کرده اند. این رفتار همچنین با توجه به اینکه ثبت نام API مشتری اکنون مبتنی بر سایت است (و نه مبتنی بر مبدا) انتظار می رود. مهاجرت از مبدا به ثبت نام سایت ، روند تبلیغات را از طریق سازگاری با فرآیند ثبت نام مشتری ، ساده تر می کند. | ما به زودی مهاجرت را از ثبت نام Origin به ثبت نام در سایت برای ثبت نام در سایت آغاز خواهیم کرد و از بازخورد اکوسیستم استقبال می کنیم. |
برنامه آزادی و استهلاک | برنامه انتشار و استهلاک برای ویژگی های خدمات جمع آوری و تکه های منتشر شده. هدف از این طرح این است که به تکنیک های تبلیغاتی در سیاست های انتشار ما مراجعه کنیم تا بتوانند آنها را برای انتشار نسخه های آینده و استهلاک آماده کنند و اطمینان حاصل کنند که آنها نسخه های پایدار و ایمن خدمات را اجرا می کنند. | ما اخیراً پیشنهادی را برای برنامه انتشار و برنامه استهلاک خدمات جمع آوری منتشر کرده ایم و از بازخورد اضافی استقبال می کنیم. |
هماهنگ کننده ها | چه اتفاقی می افتد اگر هماهنگ کنندگان در خدمات جمع آوری پایین بیایند؟ | هر دو هماهنگ کننده برای عملکرد صحیح سیستم باید کاملاً در دسترس باشند. عدم دسترسی کوتاه با ترمیم ها در کتابخانه های مشتری ما جای می گیرد. عدم دسترسی طولانی تر هر یک از این دو هماهنگ ، مشاغل جمع آوری شکست خواهد خورد. در صورت عدم مصرف بودجه حریم خصوصی ، می توان مشاغل را مجدداً مورد استفاده قرار داد. در صورتی که هرگونه عدم موفقیت خدمات منجر به مصرف بودجه بدون گزارش خلاصه ای برای ذخیره سازی فناوری تبلیغاتی شود ، در حال حاضر توصیه می کنیم آنها از گزارش های اشکال زدایی برای بازیابی نتایج با استفاده از ابزار تست محلی استفاده کنند. ما همچنین در حال کار بر روی ویژگی هایی هستیم تا در صورت بروز خرابی امکان بهبودی بودجه را فراهم کنیم تا تکنیک های تبلیغاتی بتوانند شغل خود را دوباره انجام دهند. |
Private Aggregation API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
پرچم | درخواست پشتیبانی از URL حباب در ذخیره سازی مشترک. | پشتیبانی از URL حباب در Chrome M116 اضافه شده است. |
ردیابی پنهانی را محدود کنید
کاهش عامل کاربر و مشتری عامل کاربر اشاره می کند
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
JavaScript API | در دسترس بودن مشتری عامل کاربر به API JavaScript اشاره می کند. | هیچ برنامه ای برای از بین بردن این قابلیت وجود ندارد زیرا این راه حل اصلی ما برای شرکای خود است که می خواهند به طور فعال به داده های آنتروپی بالا فراتر از آنچه که به طور پیش فرض در UA یخ زده و کاهش یافته دسترسی دارند ، دسترسی پیدا کنند. |
اطلاعات عامل دستگاه و فرم | توانایی وب سایت ها برای درک ورودی ، خروجی و سایر اطلاعاتی که دستگاه بازدید از وب سایت می تواند از آن پشتیبانی کند. | ما به دنبال بازخورد از اکوسیستم ، پشتیبانی از این درخواست را اضافه کرده ایم. |
محافظت از IP (قبلاً Gnatcatcher)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
ترافیک شخص ثالث واجد شرایط | "ترافیک واجد شرایط شخص ثالث" در توضیح دهنده چیست؟ | ما اهمیت این سؤال را درک می کنیم و به طور جدی در تلاش هستیم تا مشخص شود که ترافیک شخص ثالث واجد شرایط خواهد بود و کدام یک نخواهد بود. ما از بازخورد در مورد این موضوع استقبال می کنیم. |
حسابرسی ترافیک شبکه | پشتیبانی از شرکت ها برای انجام ممیزی ترافیک شبکه برای شبکه های خود. | فقط ترافیک شخص ثالث تعبیه شده در سایت های شخص اول تحت تأثیر قرار می گیرد که باید میزان ترافیکی که نیاز به فیلتر دارد را محدود کند. علاوه بر این ، ما قصد داریم به کاربران این گزینه را بدهیم که آیا از محافظت از IP استفاده می کنند یا نه ، و برای Chrome تحت کنترل شرکت ، سیاست های سازمانی برای غیرفعال کردن محافظت از IP وجود خواهد داشت. سرانجام ، ما در حال بررسی اینکه کنترل ها (در صورت وجود) برای غیرفعال کردن محافظت از IP به اپراتورهای شبکه ارائه می شود. ما از بازخورد در مورد این موضوع استقبال می کنیم. |
کنترل دسترسی | محافظت از IP ممکن است بر خدمات وب که از آدرس های IP برای کنترل دسترسی استفاده می کنند ، تأثیر بگذارد. | ما اهمیت موارد استفاده ضد کلاهبرداری و تأثیر احتمالی آن موارد استفاده را درک می کنیم. ما به دنبال بازخورد اکوسیستم هستیم که چگونه می توانیم از مواردی که به طور معمول به آدرس های IP اعتماد کرده اند ، از موارد استفاده ضد کلاهبرداری بهتر پشتیبانی کنیم. |
ارتباط بین پروکسی های 2-HOP | چگونه می توان اطمینان حاصل کرد که هیچ اطلاعاتی بین پروکسی ها وجود ندارد. | ما در حال طراحی تعامل پروکسی هستیم. هدف ما به حداقل رساندن شانس برای به اشتراک گذاری اطلاعات از طریق تجارت ، فرآیند و وسایل فنی است. |
احراز هویت غیر Google | پشتیبانی از احراز هویت غیر Google. | ما قصد داریم در آینده جزئیات بیشتری درباره تأیید اعتبار حساب منتشر کنیم ، اگرچه برخی ملاحظات اولیه را به اشتراک گذاشته ایم. |
طبقه بندی ردیاب | چگونه محافظت از IP تعیین می کند که چه چیزی یک ردیاب و انواع آن را تشکیل می دهد؟ | ما اهمیت این سؤال را درک می کنیم و به طور جدی در تلاش هستیم تا مشخص شود که ترافیک شخص ثالث واجد شرایط خواهد بود و کدام یک نخواهد بود. ما از بازخورد در مورد این موضوع استقبال می کنیم. |
تجزیه و تحلیل | محافظت از IP ممکن است بر صحت خدمات تحلیلی تأثیر بگذارد. | ما به دنبال درک تأثیر محافظت از IP هستیم و از بازخورد و نمونه های اضافی از اکوسیستم استقبال می کنیم. |
پروکسی | اگر کاربر از پروکسی استفاده می کند یا یک پروکسی را به صورت دستی تعریف کرده است ، ماسک IP در این حالت چگونه کار خواهد کرد؟ | ما به دنبال درک تأثیر محافظت از IP در سایر پروکسی ها هستیم. ما در حال حاضر هیچ برنامه ای برای اشتراک گذاری نداریم. ما از بازخورد در مورد این موضوع استقبال می کنیم. |
پیشنهاد حق بیمه | آیا محافظت از IP یک ویژگی پولی خواهد بود؟ | محافظت IP به عنوان بخشی از تجربه اصلی مرورگر در دسترس کاربران Chrome خواهد بود. این یک ویژگی پولی نخواهد بود. |
سرور پروکسی | آیا در جلسات کاربر از همان سرورهای پروکسی استفاده می شود؟ | یک اتصال HTTP/S از یک جفت پروکسی واحد استفاده می کند و یک آدرس IP ماسک شده را به مبدا ارائه می دهد. فراتر از آن ، هیچ محدودیت سختی در اتصالات مختلف HTTP/S وجود ندارد که از سرورهای مشابه استفاده کنند. |
پشتیبانی از پلتفرم | محافظت از IP در کدام پلتفرم پشتیبانی می شود؟ | حفاظت IP در ابتدا برای Android و Desktop در Chrome در دسترس خواهد بود. ما همچنان به ارزیابی نحوه گسترش محافظت از سیستم عامل های دیگر می پردازیم. |
انصراف دهید | آیا کاربران قادر به محافظت از IP هستند؟ | ما قصد داریم انتخاب کنیم که آیا آنها می خواهند از IP محافظت کنند یا خیر. |
ناشناس سازی | چه نوع درخواست هایی تحت حمایت IP ناشناس می شوند؟ | درخواست های HTTP/S و DNS به دامنه های شخص ثالث واجد شرایط از طریق پروکسی های حریم خصوصی ناشناس می شوند. ما جزئیات بیشتری را در یک توضیح دهنده آینده در مورد چگونگی تعیین اینکه کدام دامنه ها گنجانده شده است ارائه خواهیم داد. بقیه ترافیک (به عنوان مثال ، بقیه درخواست های DNS یا سایر ترافیک HTTP/S) بی تأثیر است. |
مشاهده داده ها | آدرس های شبکه ممکن است در اولین هاپ در محافظت از IP قابل دسترسی باشد. | در مدل پروکسی دو هاپ ، اولین هاپ (کنترل شده توسط Google) فقط IP مشتری منبع و درخواست اتصال به هاپ دوم را می بیند ، در حالی که هاپ دوم (کنترل شده توسط یک CDN خارجی) فقط یک تپل را در اولین هاپ اول (پورت IP + Proxy) و IP مقصد می بیند. برای پاسخ از مبدأ ، هاپ دوم قادر است پاسخ را به اولین پورت پروکسی+هاپ مرتبط با درخواست ارسال کند و نیازی به یادگیری چیزی در مورد IP مشتری اصلی ندارد (و اولین هاپ فقط بدون یادگیری چیزی در مورد IP مقصد ، پاسخ را به مشتری باز می گرداند). به این ترتیب ، هاپ اول فقط IP مشتری و هاپ دوم را می آموزد ، در حالی که هاپ دوم فقط IP مقصد را می آموزد. |
WebView | آیا محافظت IP در آینده در دسترس Android WebView خواهد بود؟ | ما در حال حاضر هیچ برنامه ای برای اشتراک گذاری نداریم ، اما چشم انداز ما این است که این محافظت را تا حد امکان ارائه دهیم. |
کاهش ردیابی گزاف گویی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
ردیابی تعامل | تعامل کاربر چگونه ردیابی می شود؟ | ردیابی ردیابی دو نوع تعامل کاربر را ردیابی می کند:
این فعل و انفعالات با سایت سطح بالا در صفحاتی که در آن رخ می دهد همراه است. به عنوان مثال ، اگر کاربر در Iframe تعبیه شده کلیک کند ، تعامل با سایت سطح بالا همراه است و نه سایت تعبیه شده. فعل و انفعالات در یک پایگاه داده حاوی ETLD بدون طرح و زمان تعامل ذخیره می شود. فعل و انفعالات از دامنه مرتبط با حذف حالت کاهش ردیابی به مدت 45 روز محافظت می کند. |
معافیت های لیست شده | آیا می توان دامنه ها را معاف کرد؟ | ما این درخواست را در نظر می گیریم و از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
بودجه حریم خصوصی
هیچ بازخوردی در این سه ماه دریافت نکرد.
مرزهای حفظ حریم خصوصی سایت را تقویت کنید
مجموعه های وب سایت مرتبط (مجموعه های شخص اول)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
رویکرد متمرکز | نگرانی از رویکرد مخزن متمرکز برای مدیریت مجموعه های وب سایت مرتبط. | یک مخزن عمومی و به راحتی در دسترس برای طراحی RWS مهم است زیرا مسئولیت ارسال را برای ارسال ها فراهم می کند. عملکرد کوکی شخص ثالث در نهایت با استفاده از API دسترسی به ذخیره سازی یا API RSAFOR ارائه می شود ، با عضویت RWS دسترسی به اعطای خودکار (بر خلاف اعلان ها با API دسترسی به ذخیره سازی). ما معتقدیم که رویکردی مانند فرآیند ارسال RWS یک نیاز مناسب برای دسترسی به کوکی شخص ثالث با اعطای خودکار است. |
تغییر نام پرونده JSON | آیا با تغییر در نام API ، آیا نام پرونده JSON میزبان نیاز به تغییر دارد؟ | بله ، دستورالعمل های ارسال تغییر یافته است ، و دامنه اصلی باید یک پرونده JSON را در /.well-known/related-website-set.json ارائه دهد.مجموعه های موجود در لیست RWS نیازی به تغییر ندارند ، اما اگر تغییراتی در مجموعه های موجود ارائه شود ، پرونده JSON باید تغییر یابد. |
(همچنین در سه ماهه قبلی گزارش شده است) حد دامنه | درخواست گسترش تعداد حوزه های مرتبط | همانطور که در یک وبلاگ در تاریخ 31 آگوست اعلام شد ، ما به دنبال بازخورد اکوسیستم ، محدوده دامنه مرتبط را به پنج حوزه افزایش داده ایم. ما تصمیم گرفتیم که محدوده دامنه مرتبط را به پنج حوزه (به علاوه یک دامنه اصلی) افزایش دهیم که به بهترین وجه با مقایسه ترین اجرای ارائه شده توسط یک مرورگر اصلی دیگر مطابقت دارد. |
کوکی های شخص ثالث | آیا مجموعه وب سایت های مرتبط فقط با کوکی های شخص ثالث غیرفعال می شوند؟ | مجموعه های وب سایت مرتبط حتی در شرایطی که کاربر کوکی های شخص ثالث را مسدود نکرده باشد کار خواهد کرد. اما هیچ تأثیر قابل توجهی وجود نخواهد داشت زیرا کوکی های مربوطه بدون نیاز به مجموعه های وب سایت مرتبط و API دسترسی به ذخیره سازی در دسترس هستند. |
ویرایش های قانونی | چگونه مجموعه وب سایت مربوطه مخزن مانع از تغییر مجموعه های غیر مالکین می شود؟ | در مورد راهنماهای ارسال ، هر کسی می تواند PR را در GitHub ارسال کند تا پرونده first_party_sets.JSON را ویرایش کند. با این حال ، اگر روابط عمومی تصویب شود (از اعتبار فنی عبور می کند ، و غیره) ، آن را به صورت دستی در دسته ها به لیست FPS متعارف یک بار در هفته (سه شنبه ها در ساعت 12 بعد از ظهر شرقی) توسط Google ادغام می شود.اگر یک بازیگر بد سعی کند مجموعه ای را که متعلق به آنها نیست اصلاح کند ، نباید مشکلی ایجاد کند زیرا آنها قادر به تغییر پرونده های .well-known نیستند و بنابراین اعتبارسنجی ها شکست می خورند. |
ربودن دامنه | ربودن دامنه ممکن است داده های دامنه مرتبط را در معرض احزاب غیرمجاز قرار دهد. | این امکان پذیر نیست ، همانطور که در این موضوع محافظت شده مخاطبان GitHub بحث شده است. |
Fenced Frames API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تخلف | به کاربران اجازه دهید تبلیغات مشکوک را گزارش دهند. | گزارش تبلیغات مشکوک توسط قاب های حصارکشی پیشگیری نمی شود. کاربران هنوز هم می توانند با آگهی ارتباط برقرار کرده و تبلیغات مشکوک را به روش معمول به فناوری تبلیغاتی گزارش دهند. |
تعامل با سایت های اطراف | تعامل با وب سایت اطراف یا سطح بالا را فراهم کنید. | ما به دنبال این هستیم که درک کنیم که چرا این درخواست ضروری است و از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
تبلیغات بومی | پشتیبانی قاب حصارکشی برای تبلیغات بومی. | ما در حال بررسی حمایت از پرونده استفاده هستیم و در مورد راه حل ها و راه حل های احتمالی بحث می کنیم. |
API ذخیره سازی مشترک
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
حوزه متقاطع | اجازه ارتباط در حوزه ها را برای ذخیره سازی محلی. | این مورد استفاده در حال حاضر مطابق با دروازه های خروجی حفظ حریم خصوصی ذخیره سازی نیست ، اما ما از متن دیگری استقبال می کنیم زیرا پیشنهادات مربوط به ذخیره سازی غیر مشارکت را تحول می دهیم. |
پرچم | درخواست پشتیبانی از URL حباب در ذخیره سازی مشترک. | پشتیبانی از URL حباب در Chrome M116 اضافه شده است. |
تراشه
هیچ بازخوردی در این سه ماه دریافت نکرد.
FedCM
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
کوکی های شخص ثالث | آیا FEDCM در حال حاضر غیرفعال است اگر کاربران "بلوک کوکی های شخص ثالث" را در تنظیمات Chrome فعال کنند؟ | بله ، FEDCM در حال حاضر غیرفعال است. برای آزمایش ، توصیه می کنیم علاوه بر این chrome://flags/#fedcm- .ما در آینده به دنبال پشتیبانی از FEDCM بدون کوکی های شخص ثالث هستیم. |
با هرزنامه و کلاهبرداری مبارزه کنید
API Token State Private (و سایر API)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
انقضای توکن | پس از حذف Google Chrome ، آیا نشانه از بین می رود یا ذخیره می شود؟ | اگر کاربر Google Chrome را حذف کند ، این نشانه از بین می رود. |
اطلاعات توکن | چگونه صادرکنندگان می توانند اطلاعات صادر شده را در امور خصوصی خصوصی حفظ کنند؟ | اطلاعات همیشه در نشانه ها خصوصی نگه داشته می شوند و توسط احزاب خارجی که کلیدها ندارند ، نمی توانند رمزگذاری شوند. |
خطا در نسخه ی نمایشی | خطا هنگام تلاش برای اجرای نسخه ی نمایشی Token State. | ما نسخه ی نمایشی را به روز کرده ایم و اکنون باید به درستی کار کند. |