گزارش فصلی برای سه ماهه دوم سال 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/فناوری خاصی
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
جدول زمانی واضح تر | برنامههای انتشار واضحتر و دقیقتر برای فناوریهای جعبه ایمنی حریم خصوصی. | ما برنامههای فعلی خود را برای برنامه زمانبندی استقرار در privacysandbox.com تنظیم میکنیم و هر ماه آن را بهروزرسانی میکنیم. در این موارد زمان توسعه برای Chrome و توسعه دهندگان وب و همچنین بازخوردهایی که از اکوسیستم گستردهتر در زمان مورد نیاز برای آزمایش و پذیرش فناوریهای جدید دریافت کردهایم، در نظر گرفته میشود. هر فناوری از آزمایش تا انتشار (راهاندازی) مراحل متعددی را طی میکند و زمانبندی هر مرحله بر اساس آنچه در مرحله قبل یاد میگیریم و کشف میکنیم، مشخص میشود. در حالی که ما در حال حاضر نسخه های متعهد نداریم، همانطور که داریم، مطمئناً جدول زمانی عمومی خود را در privacysandbox.com به روز خواهیم کرد. |
سودمندی برای انواع مختلف ذینفعان | نگرانی از این که فناوریهای جعبه ایمنی حریم خصوصی به نفع توسعهدهندگان بزرگتر هستند و سایتهای خاص (کوچکتر) بیشتر از سایتهای عمومی (بزرگتر) مشارکت دارند. | میدانیم که برخی از توسعهدهندگان نگرانیهایی در مورد تأثیر فناوریهای جعبه ایمنی حریم خصوصی دارند. Google به CMA متعهد شده است که پیشنهادات جعبه ایمنی حریم خصوصی را به گونهای طراحی یا اجرا نکند که رقابت را با ترجیح دادن خود به کسبوکار خود Google مخدوش کند و تأثیر آن بر رقابت در تبلیغات دیجیتال و ناشران و تبلیغکنندگان و نیز تأثیرات را در نظر نگیرد. در مورد نتایج حریم خصوصی و تجربه کاربر. ما به همکاری نزدیک با CMA ادامه می دهیم تا اطمینان حاصل کنیم که کار ما با این تعهدات مطابقت دارد. با پیشرفت تست Privacy Sandbox، یکی از سوالات کلیدی که ما ارزیابی خواهیم کرد این است که فناوری های جدید چگونه برای انواع مختلف ذینفعان عمل می کنند. بازخورد از این نظر بسیار مهم است، به ویژه بازخوردهای خاص و عملی که می تواند به ما در بهبود بیشتر طرح های فنی کمک کند. |
جدولهای زمانی منسوخ شدن کوکیهای شخص ثالث | درخواست برای جلوگیری از تاخیر بیشتر برای منسوخ شدن کوکی های شخص ثالث | از برخی از ذینفعان شنیده ایم که می خواهند Chrome بدون تأخیر به لغو کوکی های شخص ثالث ادامه دهد، و از دیگران شنیده ایم که معتقدند برای آزمایش و استفاده از فناوری های جعبه ایمنی حریم خصوصی به زمان بیشتری نیاز است. ما متعهد هستیم که با توجه به پیچیدگی فناوری ها و اهمیت اکوسیستم درست کردن کارها، مسئولانه پیش برویم. بازخورد صنعت و تنظیم کننده ها برای این فرآیند بسیار مهم بوده است. |
جدولهای زمانی منسوخ شدن کوکیهای شخص ثالث | درخواست به تأخیر انداختن از بین بردن کوکی های شخص ثالث و ارائه زمان بیشتری برای آزمایش APIها. | از برخی از ذینفعان شنیده ایم که می خواهند Chrome بدون تأخیر به لغو کوکی های شخص ثالث ادامه دهد، و از دیگران شنیده ایم که معتقدند برای آزمایش و استفاده از فناوری های جعبه ایمنی حریم خصوصی به زمان بیشتری نیاز است. ما متعهد هستیم که با توجه به پیچیدگی فناوری ها و اهمیت اکوسیستم درست کردن کارها، مسئولانه پیش برویم. بازخورد صنعت و تنظیم کننده ها برای این فرآیند بسیار مهم بوده است. |
درخواست های اسناد و مدارک | درخواست برای منابع بیشتر در مورد نحوه مدیریت آزمایش، تجزیه و تحلیل و پیاده سازی. | قدردانی میکنیم که توسعهدهندگان مطالب فعلی ما را مفید دانستهاند و متعهد هستیم که مطالب بیشتری از جمله ساعات اداری برنامهنویس و مستندات فنی را در هفتهها و ماههای آینده ارائه کنیم تا توسعهدهندگان بتوانند به درک چگونگی عملکرد فناوریهای جدید برای آنها ادامه دهند. همچنین جلسات ساعات اداری توسعهدهنده خارجی عمومی را برای به اشتراک گذاشتن بهترین شیوهها و نمایشهای نمایشی همراه با جلسات پرسش و پاسخ با سرنخهای محصول و مهندسی برگزار کردهایم تا امکان بحث/سوالات زنده را فراهم کنیم. |
تخصص صنعت | تیم Chrome که با نهادهای استاندارد در ارتباط است، فاقد تخصص در اکوسیستم تبلیغاتی است که برای ایجاد تعادل مناسب بین حریم خصوصی و ابزار ضروری است. | ما می دانیم که مسئولیت بزرگی داریم و برای درست کردن این موضوع به بازخورد خاصی وابسته هستیم. ما همچنین حریم خصوصی و اثربخشی را معیارهای طراحی حیاتی و ضروری می دانیم. در سراسر تیمی که روی Privacy Sandbox برای وب کار میکنند، مجموع تعداد سالهای کار در اکوسیستم تبلیغات به صدها نفر میرسد. |
نمایش محتوا و تبلیغات مرتبط
موضوعات
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
سودمندی برای انواع مختلف ذینفعان | نگرانی هایی در مورد ارزش ایجاد شده و توزیع آن ارزش برای سایت ها بسته به سطح ترافیک آنها یا میزان تخصصی بودن محتوای آنها مطرح شده است. | سودمندی API از طریق آزمایش بررسی خواهد شد. کروم انتظار دارد طبقه بندی و سایر پارامترها بر اساس نتایج آزمایش تکامل یابد. تکامل طبقه بندی یا پارامترها ممکن است نیازی به تغییرات ناسازگار با عقب نداشته باشد. علاوه بر این، Chrome انتظار دارد بازخورد همچنان بر تکامل Topics API پس از منسوخ شدن کوکی های شخص ثالث تأثیر بگذارد. |
طبقه بندی | ذینفعان صنعت مایلند صدایی در تأثیرگذاری بر طبقه بندی داشته باشند. | کروم برای ورود به طبقه بندی باز است. کروم به بازخورد در مورد مدل حاکمیتی برای اصلاح طبقهبندی و بحث در مورد اینکه چگونه سایر نهادهای صنعت میتوانند نقش فعالتری در توسعه و حفظ طبقهبندی در بلندمدت ایفا کنند بسیار علاقهمند است. |
سابقه مرور کافی نیست | پیشنهاد برای نمایش موضوعاتی که تماسگیرنده در هفتههای گذشته دیده است، اگر کاربر سابقه مرور کافی برای ایجاد 5 موضوع برای هفته اخیر نداشته باشد. | برای طراحی فعلی ما، آنها به صورت تصادفی انتخاب می شوند. ما همبستگی را با موضوعات گذشته بررسی خواهیم کرد و بررسی خواهیم کرد که آیا امکان گنجاندن آن وجود دارد یا خیر، با این حال، همبستگی ها ممکن است ملاحظات حریم خصوصی نامطلوبی داشته باشند که باید در نظر گرفته شوند. |
تماس با موضوعات از طرف یک ناشر | آیا یک ارائه دهنده خدمات شخص ثالث می تواند موضوعات را با ناشر به اشتراک بگذارد؟ | بله، این راهی است که ما انتظار داریم از Topics استفاده شود. |
بردارهای حمله بالقوه | شناسایی موضوعات پر سر و صدا | بر اساس بازخورد بسیاری از افراد در اکوسیستم، Chrome تصمیم گرفت موضوعات را فیلتر کند و نویز را معرفی کند. این تصمیمات با در نظر گرفتن حریم خصوصی اتخاذ شد - برای محدود کردن دسترسی به اطلاعات به کسانی که در غیر این صورت به چنین اطلاعاتی دسترسی نداشتند و به ترتیب امکان انکار قابل قبولی برای کاربران ایجاد کرد. ما می دانیم که این تصمیمات دارای اشکالاتی هستند، مانند بردار حمله که در اینجا به آن اشاره شده است. با این حال، ارزیابی ما این است که مزایای حفظ حریم خصوصی بیشتر از خطرات بالقوه است. ما از بحث عمومی در مورد این تصمیم استقبال می کنیم. |
واجد شرایط بودن Origin Trial | آیا راهی برای تشخیص واجد شرایط بودن یک کاربر برای آزمایش اولیه وجود دارد؟ | یک ویژگی آزمایشی اصلی ممکن است به دلیل تنظیمات مرورگر یا عوامل دیگر در دسترس کاربر نباشد، حتی اگر از یک صفحه وب بازدید کند که یک نشانه آزمایشی معتبر ارائه می دهد و مرورگر آنها در گروهی که آزمایشی برای آن فعال است، گنجانده شده است. به همین دلیل، قبل از اقدام به استفاده از ویژگی آزمایشی، همیشه باید از تشخیص ویژگی برای بررسی اینکه آیا ویژگی آزمایشی مبدأ در دسترس است استفاده شود. |
تاثیرات عملکرد | نگرانی های سربار و تأخیر با موضوعات | ما در حال درخواست بازخورد برای رویکردهایی برای جلوگیری از iframe های گران قیمت و آهسته x-origin و برای پیشنهاد جدا کردن Topics API به گونه ای هستیم که دریافت موضوعات وضعیت مرور را تغییر ندهد. |
قابلیت Split Topics API | ارائه کنترل بیشتر بر سه جنبه مختلف API | ما مورد استفاده را درک می کنیم و یک راه ممکن برای حل این مشکل در GitHub پیشنهاد کرده ایم. ما در حال حاضر منتظر بازخورد بیشتر از اکوسیستم در مورد ساخت این قابلیت هستیم. بحث در حال انجام را اینجا ببینید. |
جدول زمانی طبقه بندی کننده و مستندات | توسعه دهندگان اطلاعات بیشتری در مورد طبقه بندی کننده درخواست کرده اند. | ما در اینجا اطلاعات بیشتری در مورد طبقه بندی کننده به صورت عمومی ارائه کرده ایم. همینطور اینجا و اینجا . |
کنترل و ایمنی کاربر | برخی موضوعات ممکن است پروکسی برای گروه های حساس باشند و کاربران برای جلوگیری از نتایج منفی به کنترل های بیشتری نیاز دارند. | موضوعات نشان دهنده یک گام به جلو برای کنترل و شفافیت کاربر است. کاربران میتوانند از موضوعات انصراف دهند، موضوعاتی را که به آنها اختصاص داده شده را مرور کنند، موضوعات را حذف کنند و بفهمند که کدام شرکتها با موضوعات خود در صفحه معین تعامل دارند. علاوه بر این، کاربران همچنین می توانند با حذف تاریخچه مرور خود بر موضوعات خود تأثیر بگذارند. ما از ادامه بحث در مورد کنترلهای پیشرفتهتر کاربر، مانند موارد پیشنهادی توسط توسعهدهندگان استقبال میکنیم. با این حال، ما باید مطمئن شویم که برای نگرانیهای مطرحشده در این باگ، در واقع خطرات را از بین میبرد (به عنوان مثال، حذف فقط موضوع «مطالعه زبان خارجی» اما نه وبسایتهایی که موضوع را از تاریخچه مرور ایجاد کردهاند، به طور کامل از کاربر محافظت نمیکند. ). |
استفاده از موضوعات در سایت های دارای prebid.js | آیا Topics API در وب سایت هایی با prebid.js قابل استفاده است؟ | پاسخ کوتاه بله است. اطلاعات بیشتر در اینجا منتشر شده است. |
استفاده از Topics API در ویجت توصیه | آیا میتوانیم از Topics API در ویجت توصیهشده استفاده کنیم (مثلاً Outbrain) | ما مورد استفاده از موضوعات بازیابی شده را پس از فراخوانی API محدود نمی کنیم (این به خط مشی داده هر توسعه دهنده بستگی دارد). |
سیاست حفظ حریم خصوصی | سوالاتی در مورد هدف فیلتر کردن پاسخها توسط تماسگیرنده اگر برخی از اشخاص ثالث موضوعات خود را با هر کسی که تماس میگیرد به اشتراک بگذارند. | بر اساس بازخورد بسیاری از افراد در اکوسیستم، کروم این طرح را برای محدود کردن دسترسی به اطلاعات به کسانی که در غیر این صورت به چنین اطلاعاتی دسترسی نداشتند، انتخاب کرد. البته، ناشران و اشخاص ثالثی که Topics را دریافت میکنند، میتوانند خودشان تصمیم بگیرند که چه اطلاعاتی را در سایت خود با اشخاص به اشتراک بگذارند. اگر آنها این نوع اشتراکگذاری را انجام دهند، Chrome قویاً آنها را تشویق میکند که در مورد چنین اشتراکگذاریهایی برای کاربران خود شفاف باشند و کنترلهایی را به آنها ارائه دهند. |
سیگنال های پر سر و صدا | ارائه یک موضوع تصادفی در 5٪ مواقع ممکن است نویز / سیگنال نادرست زیادی ایجاد کند. | نویز یک روش مهم برای محافظت از حریم خصوصی کاربر است و سطوح نویز در مقابل سودمندی موضوعات از طریق آزمایش بررسی خواهد شد. |
FLEDGE
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
هماهنگی تست | آزمایش برای تأثیر عملکرد و درآمد | عملکرد FLEDGE و اینکه چگونه میتوانیم به بهترین شکل از آزمایش اکوسیستم در طول آزمایشهای اولیه و همچنین دسترسی عمومی پشتیبانی کنیم، به طور فعال در جلسات عمومی WICG مورد بحث قرار گرفته است. |
سرور قابل اعتماد برای FLEDGE | چه زمانی سرور مورد اعتماد برای آزمایش در دسترس خواهد بود؟ | ما از این بازخورد قدردانی میکنیم و فعالانه روی طرح دقیقتری کار میکنیم که میتوانیم برای استفاده از سرورهای قابل اعتماد در FLEDGE به اشتراک بگذاریم. |
استانداردسازی پروتکل | آیا پروتکل مشترکی برای انتقال داده بین SSP و DSP وجود خواهد داشت، مانند برچسب های مشترک برای گروه های ذینفع؟ | ما از بازخورد DSP ها، SSP ها و اکوسیستم تبلیغات گسترده تر در مورد استانداردسازی بالقوه مشخصات استقبال می کنیم. برای اهداف آزمایش اولیه در این زمان، توصیه می کنیم مستقیماً با شرکای آزمایشی خود کار کنید زیرا آنها در حال آزمایش رویکردهای مختلف هستند. ما همچنین سازمانهای تجاری تبلیغاتی را تشویق میکنیم و قصد داریم به همکاری با آنها ادامه دهیم تا در صورت مفید بودن برای شرکتهای عضو، استانداردسازی ایجاد کنند. |
محدودیت فرکانس | کنترلهای فرکانس برای هر کاربر در یک کمپین و گروه تبلیغاتی. | FLEDGE از محدودیت فرکانس برای حراجهای روی دستگاه و کمپینهای متنی/برندینگ نیز پشتیبانی میکند. ذخیرهسازی مشترک و سرپوشهای مخصوص سایت نیز میتوانند برای کنترلهای درپوش فرکانس اضافی استفاده شوند. |
تاثیر FLEDGE بر عملکرد | پیشنهاد دهندگان محاسباتی فشرده در حراج FLEDGE | Chrome در حال گفتگوهای فعال با توسعه دهندگان در مورد تأثیر بالقوه بر عملکرد سایت است. Chrome از این فرصت برای کسب اطلاعات بیشتر در طول آزمایش استقبال می کند. |
تست FLEDGE با ویژگی های دیگر | چگونه گزارشهای سطح رویداد از Attribution Reporting API و FLEDGE با هم تطبیق میکنند؟ | این موضوع در یک تماس اخیر WICG/conversion-Measurement-Api با پیوندی به دقیقههای دقیق اینجا مورد بحث قرار گرفت. خلاصهای از جلسه این است که طراحی فعلی برای گزارش آگهی فریمهای حصاردار امکان مرتبط ساختن شناسه تولید شده در داخل قاب حصاردار را با اطلاعات متنی فراهم میکند. بنابراین گزارشهای سطح رویداد که در داخل فریم حصاردار تولید میشوند، میتوانند به همان اطلاعات متنی روی سرور متصل شوند (با استفاده از 2 اتصال سمت سرور به جای 1). |
شمارش برداشت | کدام روش شمارش تأثیر باید یا می تواند بین خریداران و فروشندگان استفاده شود | API FLEDGE در حال حاضر از همسویی بر اساس روش بین فروشنده و خریدار در طول حراج پشتیبانی می کند. ما پیشنهاداتی در مورد پیاده سازی های جایگزین دریافت کرده ایم بدون بازخورد در مورد اینکه چرا طراحی فعلی ما نمی تواند برای اکوسیستم کار کند. |
نمایش تبلیغات چندگانه | اینکه آیا میتوان چندین آگهی را در یک حراج در یک قاب حصاردار نشان داد یا خیر | این در حال حاضر از طریق تبلیغات مؤلفه امکان پذیر است (با حراج مؤلفه اشتباه نشود). برای انجام این کار، همه تبلیغات باید در یک گروه علاقه مند باشند. |
مشخصات "مخاطبان تعریف شده فروشنده (SDA)" و FLEDGE | آیا FLEDGE می تواند به مکانیزمی تبدیل شود که خریداران را از ایجاد پروفایل از SDA در درخواست های تبلیغاتی باز دارد؟ | FLEDGE برای جلوگیری از نشت اطلاعاتی طراحی شده است که زمانی که ناشر از قبل میداند بازدیدکنندگانش در چه SDAهایی هستند و هدف آن همان سایت است، مرتبط نیست. اگر حمایت از خرید در SDAها در تمام حفاظتهای تعبیهشده در FLEDGE مهم است، یک راهحل ممکن است این باشد که فروشنده برچسبهای SDA را به حراج روی دستگاه منتقل کند و فناوری تبلیغات سمت خرید برای ایجاد گروه مورد علاقه خود. منطق پیشنهادیاش میگوید «میخواهم مخاطب X بخرم». |
پشتیبانی از ارزهای غیر از USD | پشتیبانی از آزمایش FLEDGE با ارزهای فراتر از USD | ما از این فراخوان قدردانی میکنیم و برای پشتیبانی از ارزهای دیگر در مجموعه درخواستهای ویژگیهای عقب مانده خود، ساختمانی را اضافه کردهایم. ما امیدواریم که این خیلی زود در دسترس قرار گیرد. |
پشتیبانی از هدف گذاری گروهی با علاقه منفی | یک API برای پشتیبانی از هدف گذاری منفی IG: نمایش تبلیغات تنها در صورتی که کاربر به یک IG تعلق نداشته باشد. | بحث در حال انجام، از جمله برخی از گزینه های پیشنهادی برای پشتیبانی، در موضوع github . |
چندین SSP در FLEDGE | خطر طرفداری از Google هنگام اجرای حراج های چند سطحی در FLEDGE | پشتیبانی از چندین SSP در FLEDGE اضافه شد تا زمینه بازی منصفانه و عادلانه فراهم شود. Google تحت تعهدات متعهد شده است که پیشنهادات جعبه ایمنی حریم خصوصی را به گونهای طراحی، توسعه یا اجرا نکند که رقابت را با ترجیح دادن به محصولات و خدمات تبلیغاتی خود مخدوش کند. گوگل این موضوع را جدی می گیرد و برای بحث در مورد هر گونه نگرانی که ذینفعان ممکن است در مورد جنبه های خاص این فناوری داشته باشند، بسیار آماده است. برای اطلاعات، Chrome مکانیسم حراج مؤلفه را به صورت عمومی در اینجا مستند کرده است. |
اندازه گیری تبلیغات دیجیتال
گزارش انتساب (و سایر APIها)
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
انتساب چند لمسی | ناشران درخواست پشتیبانی برای اسناد چند لمسی | روشهای فعلی ارجاع چند لمسی مستلزم گره زدن قطعی برداشتهای کاربر (و بنابراین هویت) در وبسایتهای مختلف است. در نتیجه، این عملکرد به شکل فعلیاش با اهداف «جعبه ایمنی حریم خصوصی» که هدف آن پشتیبانی از موارد استفاده از تبلیغات کلیدی بدون ردیابی بین سایتی است، همسو نیست. در برخی موارد، تقریب تخصیص اعتبار (مثلاً با استفاده از اولویتهای وزنی و تصادفی) بدون ردیابی تک تک کاربران امکانپذیر است. |
تولید نویز | سوالات مربوط به سطوح نویز در گزارش ها | آزمایش اولیه ما به توسعه دهندگان اجازه می دهد تا مقدار اپسیلون خود را تعیین کنند تا بتوانند نحوه تغییر گزارش ها را بر اساس سطح نویز تجربه کنند. در حال حاضر، توسعه دهندگان می توانند مقدار epsilon را تا 64=epsilon انتخاب کنند. ما این کار را به طور خاص انجام دادهایم تا توسعهدهندگان بتوانند APIها را آسانتر آزمایش کنند و در مورد مقادیر اپسیلون مناسب بازخورد ارائه کنند. ما همچنین درخواست عمومی برای چنین بازخوردی کردهایم. |
هماهنگی تست | آیا می توان از ابزار تست محلی برای OT استفاده کرد؟ | بله، ابزار تست محلی را می توان برای مدت زمان OT استفاده کرد. تا زمانی که کوکیهای شخص ثالث در دسترس هستند، میتوان از ابزار تست محلی با گزارشهای اشکالزدایی استفاده کرد. |
پرس و جو ارگونومی | فعال کردن پرس و جو کل کلیدها | ما موافقیم که به نظر می رسد این ارگونومی API را با هزینه اندک یا بدون هزینه حفظ حریم خصوصی بهبود می بخشد. ما پیشنهادی ارائه خواهیم کرد و خواهیم دید که آیا اجماع گسترده ای وجود دارد که ارزش حمایت از آن را دارد یا خیر. |
داده های کمتر دقیق برای سایت های کوچک | سایت ها یا کمپین های کوچکتر ممکن است داده های دقیق تری دریافت کنند. | Chrome تشخیص میدهد که حفاظتهای حریم خصوصی مبتنی بر نویز تأثیر بیشتری بر بخشهای داده کوچکتر دارند. با این حال، ممکن است روشهایی مانند تجمیع در دورههای زمانی طولانیتر این مشکل را حل کند. همچنین مشخص نیست که آیا نتیجهگیری بر اساس دادههای بسیار کوچک (مانند یک یا دو خرید) برای تبلیغکنندگان معنادار است یا خیر. در طول آزمایش اولیه، Chrome آزمایشکنندگان را تشویق میکند تا از توانایی آزمایش طیف گستردهای از پارامترهای حریم خصوصی و نویز استفاده کنند تا بتوانند بازخورد خاصتری درباره این موضوع ارائه دهند. |
ردیابی پنهان را محدود کنید
کاهش عامل کاربر
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
حفاظت از ربات | تاثیر UA-R بر حفاظت از ربات | ما از این بازخورد قدردانی میکنیم و در حال جمعآوری اطلاعات در مورد رویکردهای محافظت از رباتها برای اطلاع از طرحهای آینده خود هستیم. |
وابستگی های استقرار | پرداختن به وابستگی های استقرار عامل کاربر ساختاریافته (SUA). | ما «فاز 4» را عرضه کردهایم، که به آن کاهش نسخه جزئی به 100 درصد کاربران Chrome در نسخههای 101 و بالاتر گفته میشود. به روز رسانی را اینجا ببینید. |
نکات مشتری عامل کاربر
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
شمارش تمام نکات پشتیبانی شده | علاقه مندی به داشتن یک روش برنامه نویسی برای دانستن همه نکات پشتیبانی شده برای یک مرورگر. | ما از این بازخورد قدردانی می کنیم و در حال ارزیابی درخواست ویژگی هستیم. ما علاقه مندیم بدانیم که آیا این یک مورد استفاده رایج است یا خیر. |
انعطافپذیری هدر UA-CH در مقابل User-Agent | UA-CH در مقایسه با انعطافپذیری هدر User-Agent که توسط rfc7231 تعریف شده است، بسیار تجویزی است. | کروم ماهیت تجویزی سرصفحههای UA-CH را بهعنوان یک پیشرفت مهم نسبت به انعطافپذیری رشته UA میبیند، هم از نقطه نظر قابلیت همکاری نهایی بین مرورگرها و هم حفاظت از حریم خصوصی کاربر (با جلوگیری از افزودن دلخواه شناسههای آنتروپی بالا). در صورتی که دیگران نیز این نگرانی را داشته باشند و مایل به ارائه بازخورد باشند، موضوع باز میماند. |
UA-CH: نگرانی های ضد تقلب / ضد سوء استفاده | برخی از ویژگیهایی که ممکن است از طریق UA-CH از بین بروند: روی ردیاب تغییر مسیر کلیک کنید و کلیکهای جعلی. | این تیم در حال بررسی این مسائل بالقوه با ذینفعان ضد تقلب و اندازه گیری است. |
کارایی | نگرانی هایی در مورد تأخیر دریافت راهنمایی از طریق Critical-CH (در بارگذاری صفحه اول) وجود دارد. | Chrome در حال بررسی راههایی برای بهبود عملکرد است. |
Gnatcatcher (WIP)
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
نگرانی های تاخیر | افزودن پرش(های) اضافی می تواند بر تأخیر تأثیر بگذارد | ما در حال بررسی یک پراکسی دو پرش هستیم و راه هایی را برای یافتن تعادل مناسب بین حریم خصوصی کاربر و تأخیر بررسی می کنیم. ما آماده بازخورد هستیم و دوست داریم در انجمن های W3C بیشتر بحث کنیم. |
کلاهبرداری و محافظت از ربات | تأثیرات بر تقلب و محافظت از ربات، از جمله در کشورهای کمتر توسعه یافته | ایمنی یک نیاز اصلی است زیرا ما به دنبال راههایی برای بهبود حریم خصوصی کاربران به روشهای معنیدار، مانند پروکسی کردن آدرسهای IP هستیم. یک پروکسی دو هاپ که با شرکت های معتبر همکاری می کند، حریم خصوصی کاربر قابل تاییدی را فراهم می کند. ما همچنین در حال پرورش ایده هایی برای سیگنال های جدید برای کمک به انتقال اعتماد کاربران هستیم. |
رعایت قوانین حریم خصوصی محلی | گزارش داده های جغرافیایی در سطح کشور، انطباق با رژیم های محلی دقیق تر را دشوار می کند | ما اصول پیشنهادی خود را به صورت عمومی منتشر کردهایم که شامل رویکردهای بالقوهای است که به وبسایتها اجازه میدهد با الزامات محلی مطابقت داشته باشند. |
مرزهای حریم خصوصی بین سایتی را تقویت کنید
مجموعه های شخص اول
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
سودمندی برای انواع مختلف ذینفعان | تاثیر FPS برای ناشران کوچک در مقابل بزرگ | هدف اصلی Privacy Sandbox بهبود حریم خصوصی کاربر با جایگزینی روشهای فعلی با راهحلهایی است که بر مکانیزمهای ردیابی متقابل متکی نیستند. ما می خواهیم این راه حل ها تا حد امکان برای انواع و اندازه های مختلف ذینفعان مفید باشد. ما از ورودیهای ویژه و عملی در مورد چگونگی بهبود این راهحلها استقبال میکنیم و انتظار داریم که با بحث و آزمایش در جامعه به تکامل خود ادامه دهند. |
بهبود حریم خصوصی | تعداد زیادی سایت در یک مجموعه میتواند نتایج مشابهی با کوکیهای شخص ثالث داشته باشد | ما از این بازخورد قدردانی میکنیم و در حال ارزیابی این هستیم که آیا محدودیتهای مناسب میتواند وجود داشته باشد یا نه، در حالی که سعی میکنیم درمان یا سیگنالهایی را هم به کاربران و هم توسعهدهندگان ارائه دهیم که بتوانند بفهمند چه زمانی به چنین محدودیتی رسیده است. ما هنوز پیشنهاد خاصی برای به اشتراک گذاشتن نداریم، اما امیدواریم خیلی زود به اشتراک بگذاریم. |
پشتیبانی اکوسیستم از FPS | مجموعه ای از پشتیبانی و نگرانی برای ادامه توسعه FPS خارج از Privacy CG | در حالی که ما ترجیح میدهیم پیشنهاد مجموعههای شخص اول در PrivacyCG باقی بماند، مشتاقانه منتظر ادامه پیشنهاد در WICG هستیم. ما همچنین از اظهارات متعدد پشتیبانی برای ادامه بحث در مورد مجموعه های شخص اول و موارد استفاده ای که قرار است به آنها رسیدگی شود، تشویق شدیم. Google همچنان متعهد به یافتن راهحلهایی است که به وب اجازه میدهد به رشد و شکوفایی خود ادامه دهد به گونهای که از حریم خصوصی کاربر محافظت و به آن احترام بگذارد. |
قابلیت همکاری مرورگر | پیاده سازی توسط سایر مرورگرها | ما اهمیت قابلیت همکاری مرورگر را برای توسعه دهندگان درک می کنیم و به همکاری با سایر مرورگرها برای پیگیری استانداردسازی FPS ادامه خواهیم داد. |
الزامات مشترک سیاست حفظ حریم خصوصی | حفظ یک سیاست حفظ حریم خصوصی مشترک در همه محصولات و حوزههایی که باید بخشی از یک مجموعه باشند غیرممکن است. | Chrome هنوز در حال تعیین الزامات خطمشی ما است. و این بازخورد را در ذهن حفظ خواهد کرد. |
Fenced Frames API
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
درخواست مستندات | تفاوت با iframe های sandboxed | ما از بازخورد و پیشنهاد قدردانی می کنیم. بحث فعلی در مورد این موضوع در GitHub وجود دارد، جایی که امیدواریم به وضوح نهایی در مورد درخواست دست پیدا کنیم تا بتوانیم آن را به طور کامل ارزیابی کنیم. بحث عمومی در اینجا موجود است. |
قابلیت های متقابل API | پشتیبانی پیشفرض برای گزارش انتساب در قابهای حصاردار | ما در حال درخواست بازخورد در مورد پیشنهادی هستیم که بهطور پیشفرض اجازه میدهد API گزارش انتساب در «حالت تبلیغات غیر شفاف» قابهای حصاردار باشد. ما توسعه دهندگانی را که این موضوع را ارزشمند می دانند تشویق می کنیم تا در بحث بررسی کنند. |
API ذخیره سازی مشترک
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
محدودیت های داده | آیا محدودیتی در مورد میزان ذخیره داده در هر پارتیشن وجود خواهد داشت؟ | بله، محدودیت هایی وجود خواهد داشت. برای جزئیات بیشتر به مسئله github مراجعه کنید. ما به سهمیه ذخیره سازی نیاز خواهیم داشت. پیشنهاد کنونی ما این است که حداکثر اندازه هر ورودی 4 کیلوبایت باشد، کلیدها و مقادیر هر کدام به 1024 کاراکتر char16_t محدود میشوند، و سقف ورودی به ازای هر ورودی 10000 ورودی با مکانیزمی که مانع از انجام ورودیهای اضافی میشود. ظرفیت یک منبع پر است. ما فعالانه به دنبال بازخورد در مورد محدودیت های خاص پیشنهاد شده در اینجا هستیم. |
شفافیت کاربر | شفافیت کاربر برای منابع داده در مقابل استفاده از داده | ما از این بازخورد قدردانی می کنیم و فکر می کنیم این رویکرد امیدوارکننده ای است که ارزش بررسی دارد. به ویژه، ما در حال ارزیابی هستیم که آیا انجام این کار به گونه ای امکان پذیر است که شفافیت کافی برای کاربران ارائه دهد. |
چیپس
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
موانع فرزندخواندگی | آیا CHIPS باید به نام میزبان محدود شود؟ (الزام بدون دامنه) | ما در حال حذف این الزام از OT بر اساس بازخورد از شرکت کنندگان OT هستیم که این الزام پیچیدگی بیشتری را اضافه کرده و به عنوان مانعی برای پذیرش تراشه ها عمل می کند. ما این الزام را در گروه Privacy Community به عنوان بخشی از جوجه کشی استانداردها در اینجا مورد بحث قرار خواهیم داد. |
تبلیغات از کیس برای تراشه استفاده می کند | آیا می توان از CHIPS برای موارد استفاده تبلیغات در یک سایت استفاده کرد؟ | ردیابی کاربر در یک سایت یک مورد استفاده مجاز است. ما مقاله توسعه دهنده خود را برای برجسته کردن این مورد استفاده به روز کرده ایم. |
تعبیههای تایید شده | آیا وضعیت ورود به سیستم با CHIPS حفظ می شود؟ | حالت Signed در حال حاضر حفظ نشده است، اما مورد استفاده مورد نظر برای CHIPS نیست. ما از موارد استفاده جاسازیهای احراز هویت شده آگاه هستیم و در تلاشیم تا راهحلها را بررسی کنیم. |
هماهنگی تست | آیا اقدامات اضافی کاربر برای آزمایش پارتیشن بندی مورد نیاز است؟ | تا زمانی که توکن OT معتبر است و در سرصفحههای صفحات بازدید شده وجود دارد، این ویژگی باید برای کاربران در دسترس باشد، بدون اینکه نیازی به اقدامات اضافی کاربر باشد. |
سازگاری مرورگر | علاقه به درک اینکه مرورگرهای دیگر چگونه ویژگی های کوکی پارتیشن بندی شده را مدیریت می کنند. | Chrome همچنان به کار در گروههای استاندارد عمومی مانند W3C برای شناسایی طرحها و پیادهسازیهایی که میتوانند در مرورگرها کار کنند، ادامه میدهد. |
FedCM
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
بردارهای حمله بالقوه | بردارهای حمله بالقوه از طریق دکوراسیون پیوند و حملات زمان بندی | ما به طور فعال در حال جمع آوری اطلاعات عمومی و بررسی راه های بالقوه برای رسیدگی به این موضوع هستیم. |
UX برای اجازه دادن به چندین IDP | فقط یک IDP را می توان در یک زمان ارائه کرد | ما به حمایت از چند آوارگان داخلی اعتقاد داریم و فعالانه روی رویکردهایی برای حمایت کار می کنیم |
بیانگر بودن | با توجه به این نگرانی که از آنجایی که مرورگر بخشی از جریان هویت فدرال را ارائه میکند، به سختی میتوان تمام تفاوتهایی را که IDPها میخواهند به کاربران خود ارائه دهند، درک کرد. | Chrome در حال بررسی سفارشیسازیهای نام تجاری (مانند آرمها، رنگها) و سفارشیسازی رشتهها (مثلاً «دسترسی به این مقاله» در مقابل «ورود به سیستم با» است. Chrome این مبادله را تشخیص میدهد و به کار با اکوسیستم ادامه میدهد تا هم تا حد ممکن زمین را پوشش دهد و هم آن را تا حد امکان رسا کند. |
کاربرد و قابلیت همکاری | نگرانی از اینکه مرورگرهای دیگر FedCM را قبول یا پیاده سازی نکنند. | Chrome همچنین با سایر فروشندگان مرورگر کار می کند تا راه حل های مشترکی برای فدراسیون در گروه انجمن FedID پیدا کند. |
پیشنهاد حذف الزامات داده های شخصی در جریان ثبت نام | (1) یک UX که به کاربر نشان میدهد کدام IdP را انتخاب میکند، بدون اینکه نشان دهد ایمیل، تصویر و نام او به اشتراک گذاشته خواهد شد، برای حفظ حریم خصوصی دوستانهتر خواهد بود. (2) استفاده از موارد ثبت نام در تجربه کاربری و انتخاب ادعاهای IdP کم است | ما موافق هستیم و در حال بررسی نحوه اجرای بازخورد به روشی کاربر پسندتر و حفظ حریم خصوصی هستیم. |
تعامل کاربر با IdP | در صورت تجاوز از آستانه خطر، نیاز به تعامل مستقیم بین کاربر و IdP | ما فعالانه در حال بررسی این بازخورد هستیم. |
پارتیشن بندی وضعیت شبکه
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
کارایی | پارتیشن بندی وضعیت شبکه می تواند منجر به افزایش اتصالات منابع فشرده به CDN ها شود | ما هنوز در حال بررسی ویژگی های عملکرد پارتیشن بندی وضعیت شبکه، از جمله اندازه گیری طرح های کلیدی مختلف ممکن هستیم. ما هنوز تصمیمی بین مبادلات عملکرد، امنیت و حریم خصوصی نگرفتهایم و نیاز به جمعآوری دادههای بیشتر داریم. |
با اسپم و کلاهبرداری مبارزه کنید
Trust Tokens API
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
بازخورد نظارتی | نگرانی در مورد سرمایه گذاری زمان و منابع در Trust Tokens بدون سیگنال روشن از سوی تنظیم کننده ها در مورد دوام طولانی مدت | هدف ما ساختن فناوری است که برای اکوسیستم کار میکند و بازخورد صنعت و تنظیمکنندهها را برای فرآیند حیاتی میسازد. ما همچنان به مشورت با تنظیمکنندهها در سراسر جهان ادامه میدهیم، همانطور که Privacy Sandbox را توسعه میدهیم و پیشنهادات را در اختیار توسعهدهندگان، از جمله Trust Tokens قرار میدهیم. مانند تمام فناوری های جدید، شرکت ها باید بر اساس ارزیابی خود از الزامات نظارتی تصمیم گیری کنند. |
زمان راه اندازی | Trust Tokens چه زمانی به GA راه اندازی می شود؟ | ما برآوردهای فعلی خود را برای تحویل در جدول زمانی عمومی خود در privacysandbox.com ارائه می کنیم. به محض اینکه تصمیم نهایی را در مورد تاریخ تحویل آن به GA گرفتیم، آن را به صورت عمومی از طریق فرآیندهای انتشار Chrome پست می کنیم و جدول زمانی را در وب سایت به روز می کنیم. |
Trust Tokens در مقابل دیگران | با توجه به سایر توکنهایی که در حال استانداردسازی هستند، مانند توکنهای دسترسی خصوصی، توکنهای اعتماد چه نقشی دارند. | ما درگیر بحثهای استانداردسازی هستیم و هدف ما این است که تا آنجا که ممکن است با سایر تلاشها هماهنگ شویم و در عین حال موارد استفاده متفاوتی را که هر فناوری فراهم میکند را امکانپذیر کنیم. به عنوان مثال، نشانه های اعتماد و توکن های دسترسی خصوصی هر دو به پروتکل Privacy Pass متکی هستند. |
محدودیت های داده | حداکثر 2 صادرکننده برای بازخرید رمز در هر صفحه به طور بالقوه محدود است | ما به دنبال گزینههای بلندمدتی هستیم که بتوانیم با خیال راحت به شرکتها اجازه دهیم که توکنها را بدون خطر آنتروپی بیشتر کاربر پسخرید کنند، شاید با تقسیم کردن دسترسی به بازخرید توکنها . |
محدودیت های دسترسی | فقط مبداهای تایید شده (و تایید شده/غیر جعلی ارجاع دهنده) باید بتوانند وجود یک رمز را تأیید کرده و آن را بازخرید کنند. | ما در حال بررسی روشهایی برای افرادی هستیم که میتوانند توکنها را ببینند و از آنها استفاده کنند. |
پشتیبانی دستگاه | وابستگی های زمان اجرا جاوا اسکریپت استفاده را در دستگاه های خاص محدود می کند. آیا میتوان پشتیبانی TT را در انواع دیگر دستگاهها گسترش داد؟ | این چیزی است که ما می توانیم برای توسعه آینده در نظر بگیریم و موضوعی که دوست داریم بازخورد بیشتری از توسعه دهندگان در انجمن های W3C بشنویم. ما همچنین یک موضوع باز برای بحث در مورد عنوان HTTP ایجاد شده برای بازخرید توکن که بازخورد را در مورد آن دعوت می کنیم ، داریم. |
موارد استفاده کنید | مشخص نیست که موارد استفاده صحیح برای نشانه های اعتماد چیست. عدم وضوح در مورد مصارف مورد نظر. | هدف ما تسهیل نوآوری در فضای ضد کلاهبرداری است و درک هر شرکت ممکن است از تکنیک های اختصاصی با نشانه های اعتماد استفاده کند ، به همین دلیل ما در مورد استفاده (های) مورد نظر تجویز نشده ایم. با این حال ، ما به احتمال زیاد مستندات خود را گسترش خواهیم داد تا نمونه های بیشتری را به عنوان نقاط شروع برای شرکای خود که در نظر دارند آزمایش یا فرزندخواندگی را در نظر بگیرند ، درج کنیم. |
پوشش توکن اعتماد | حذف این خط مشی ویژگی "اعتماد به نفس-بازپرداخت" باید به میزان قابل توجهی پوشش Trust Token را افزایش دهد. | این مورد در نظر گرفته می شود زیرا ما از OT بازخورد می گیریم و در مورد مراحل بعدی تصمیم می گیریم. |
صدور اعتماد | چرا باید به وب سایتهایی که نشانه های اعتماد صادر کرده اند اعتماد کنیم؟ | هیچ راهنمایی در مورد صادرکننده وجود ندارد - هر کسی می تواند این کار را انجام دهد. انتظار می رود ناشران فقط با صادرکنندگان به آنها اعتماد کنند. علاوه بر این ، سایر بازیگران مشروع در اکوسیستم ADS سرانجام ترافیک مرتبط با صادرکنندگان مشکوک یا ناشناخته را تخفیف می دهند. |
خدمات تعبیه شده 3p | آیا خدمات تعبیه شده 3p می توانند نشانه های اعتماد را بازخرید و یا درخواست کنند؟ | بله ، یک سرویس تعبیه شده 3p می تواند نشانه های اعتماد را صادر و بازخرید کند. |
اکوسیستم صادرکنندگان | اگر سیگنال های اعتماد با سایر شرکت ها به اشتراک گذاشته شوند ، می توان از ابزار بیشتری برخوردار شد | Trust Tokens به گونه ای طراحی شده است که یک سطح بدوی پایین باشد و می تواند توسط صادرکنندگان/بازخرید کننده برای به اشتراک گذاشتن سیگنال های اعتماد/شهرت مورد استفاده قرار گیرد. |
نگهداری بالای سر | اجرای رمزنگاری که اساسی عملیات Trust Token در Boringssl است. که گوگل تنها نگهدارنده است. چگونه نگهداری از کتابخانه مدیریت خواهد شد؟ | Trust Tokens به عملیات رمزنگاری استاندارد متکی است (به پروتکل گذر از حریم خصوصی مراجعه کنید) که ممکن است در سایر کتابخانه ها نیز اجرا شود. ما توصیه می کنیم که توسعه دهندگان درخواست کنند/توسعه دهند و از این عملیات در کتابخانه های مورد نظر خود استفاده کنند. |
نگهداری بالای سر | مشخص نیست که نسخه های پروتکل چه مدت پشتیبانی می شوند | ما به دنبال توسعه و مستند سازی مشخصات بیشتر در مورد بازه های پشتیبانی مورد انتظار برای نسخه های پروتکل هستیم. |
محدودیت های صادرکننده | اگر بیشتر زنجیره ای را پایین بیاورید ، ممکن است فرصت شما برای اجرای نشانه های اعتماد ایجاد نشود | از آنجا که سازمان های بیشتری شروع به استفاده از نشانه های اعتماد می کنند ، ما به طور فزاینده ای می توانیم این نوع پویایی های زمان بندی را در بازی مشاهده کنیم و در حال بررسی راه حل های بالقوه هستیم. همانطور که قبلاً توضیح داده شد ، ما به دنبال گزینه های بلند مدت هستیم که می توانیم با اطمینان به شرکت ها اجازه دهیم نشانه ها را بدون خطر آنتروپی کاربر بیشتر بازخرید کنند ، که این امر اهمیت مکان را در صفحه یا سفارش بارگیری به حداقل می رساند. |
راه حل های جدید ضد کلاهبرداری در جوجه کشی
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
سیگنال های تأیید یکپارچگی دستگاه | به طور کلی پشتیبانی قوی برای دنبال کردن سیگنال های یکپارچگی دستگاه که توسط سیستم عامل ها گواهی شده و در دسترس وب قرار داده شده است | ما به جمع آوری بازخورد و دنبال کردن پیشنهاد از طریق طراحی عمومی و تکرار ادامه خواهیم داد. |
سیگنال های تأیید یکپارچگی دستگاه | سؤالاتی درباره میزان آنتروپی کاربر از طریق سیگنال های جدید قابل انتقال است ، و اینکه آیا موارد استفاده خاصی (مانند ورود کاربر به بانک خود) می تواند سیگنال های آنتروپی بالاتر را توجیه کند. | ما به سمت ارائه سیگنال های با ارزش بالا با آنتروپی کاربر در حد امکان برای حفظ حریم شخصی کاربر تکیه می کنیم. |
سیگنال های تأیید یکپارچگی دستگاه | آیا این سیگنال دسترسی به دستگاه های قدیمی تر یا سیستم عامل های منبع باز/اصلاح شده را محدود می کند؟ | هر سیگنال جدید باید دسترسی جهانی را به عنوان یک اصل اصلی در توسعه در نظر بگیرد و این سؤالات مهم برای پرداختن به صورت مقدماتی با ادامه جوجه کشی است. |
سیگنال های تأیید یکپارچگی دستگاه | نگرانی وجود دارد اگر سیگنال های جدید باعث ایجاد امنیت و شرکت های ضد کلاهبرداری شوند تا بیش از حد به مرورگر و سیستم عامل اعتماد کنند | هر سیگنال جدید باید به عنوان داده های تکمیلی مشاهده شود و نه نشانه "اعتماد" از مرورگر. ما کاملاً انتظار داریم که شرکت های امنیتی همچنان به داده های اختصاصی ، مدل ها و موتورهای تصمیم گیری خود با تأیید دستگاه به عنوان یک ورودی اضافی اعتماد کنند. امیدوارم هر سیگنال جدید تلاش های تشخیص را در سراسر اکوسیستم بهبود بخشد و اجرای آن را دشوارتر کند. |
سیگنال سن کوکی | مفهوم جالب اما به احتمال زیاد نیاز به بررسی بیشتر در مورد موارد استفاده قابل استفاده دارد. | بسته به سطح علاقه ، Chrome ممکن است ایده های بیشتری را در مورد این مفهوم انجام دهد ، و آن را به توضیح دهنده ای برای بازخورد اکوسیستم آینده تبدیل کند. |
سرورهای قابل اعتماد برای ضد کلاهبرداری | مفهوم جالب اما به احتمال زیاد نیاز به بررسی بیشتر در مورد موارد استفاده قابل استفاده دارد. | بسته به سطح علاقه ، Chrome ممکن است ایده های بیشتری را در مورد این مفهوم انجام دهد ، و آن را به توضیح دهنده ای برای بازخورد اکوسیستم آینده تبدیل کند. |
گزارش سه ماهه برای سال 2022 Q2 خلاصه بازخورد اکوسیستم دریافت شده از پیشنهادات ماسه ای حریم خصوصی و پاسخ کروم.
به عنوان بخشی از تعهدات خود در مورد CMA ، گوگل موافقت کرده است که گزارش های سه ماهه ای را در مورد فرآیند مشارکت ذینفعان برای پیشنهادات Sandbox حریم خصوصی خود ارائه دهد (به بندهای 12 و 17 (ج) (ii) تعهدات مراجعه کنید). این گزارش های خلاصه بازخورد Sandbox با جمع آوری بازخورد دریافت شده توسط Chrome از منابع مختلف که در نمای کلی بازخورد ذکر شده است ، از جمله اما محدود به: شماره های GitHub ، فرم بازخورد موجود در privacysandbox.com ، جلسات با ذینفعان صنعت ، و جلسات تولید می شود. انجمن های استاندارد وب. Chrome از بازخورد دریافت شده از اکوسیستم استقبال می کند و به طور فعال در حال بررسی راه های ادغام یادگیری در تصمیمات طراحی است.
مضامین بازخورد با شیوع در هر API رتبه بندی می شوند. این کار با جمع آوری میزان بازخوردی که تیم Chrome در اطراف یک موضوع معین دریافت کرده و به ترتیب نزولی کمیت ، سازماندهی می شود ، انجام می شود. مضامین بازخورد مشترک با بررسی مباحث بحث از جلسات عمومی (W3C ، PATCG ، IETF) ، بازخورد مستقیم ، GitHub و سوالات معمولاً پرسیده شده از طریق تیم های داخلی گوگل و فرم های عمومی مشخص شد.
به طور خاص ، دقایقی جلسات جلسات بدنه های استاندارد وب مورد بررسی قرار گرفت و برای بازخورد مستقیم ، سوابق Google از جلسات 1: 1 ذینفعان ، ایمیل های دریافت شده توسط مهندسین انفرادی ، لیست پستی API و فرم بازخورد عمومی در نظر گرفته شد. سپس گوگل بین تیم های درگیر در این فعالیت های مختلف دسترسی هماهنگ شد تا شیوع نسبی مضامین در رابطه با هر API را تعیین کند.
توضیحات مربوط به پاسخ های Chrome به بازخورد از سؤالات متداول منتشر شده ، پاسخ های واقعی به موضوعات مطرح شده توسط ذینفعان و تعیین موقعیت به طور خاص برای اهداف این تمرین گزارشگری عمومی تهیه شده است. با توجه به تمرکز فعلی توسعه و آزمایش ، سؤالات و بازخورد به ویژه با توجه به موضوعات ، API های گزارش دهی و انتساب دریافت شد.
بازخورد دریافت شده پس از پایان دوره گزارش فعلی ممکن است هنوز پاسخ Chrome در نظر گرفته نشده باشد.
واژه نامه مخفف
- چیپس
- کوکی هایی که دارای وضعیت تقسیم شده مستقل هستند
- DSP
- بستر سمت تقاضا
- فدستان
- مدیریت اعتبار فدرال
- FPS
- مجموعه های مهمانی اول
- IAB
- دفتر تبلیغات تعاملی
- بیجاشدگان داخلی
- ارائه دهنده هویت
- IETF
- نیروی ضربت مهندسی اینترنت
- IP
- آدرس پروتکل اینترنت
- OpenRTB
- مناقصه در زمان واقعی
- OT
- محاکمه مبداء
- پتک
- گروه جامعه فناوری تبلیغات خصوصی
- RP
- متکی به حزب
- SSP
- بستر عرضه
- TEE
- محیط اعدام قابل اعتماد
- UA
- رشته عامل کاربر
- ua-ch
- نکات مشتری عامل کاربر
- W3C
- کنسرسیوم وب جهانی
- WIPB
- نابینایی IP اراده
بازخورد عمومی ، هیچ API/فناوری خاص
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
جدول زمانی واضح تر | برنامه های انتشار واضح تر و دقیق تر برای فن آوری های Sandbox Privace. | ما برنامه های فعلی خود را برای برنامه استقرار در privacysandbox.com تنظیم کرده و ماهانه آن را به روز می کنیم. اینها زمان توسعه را برای توسعه دهندگان Chrome و وب و همچنین بازخوردی که از اکوسیستم گسترده تر به موقع لازم برای آزمایش و اتخاذ فن آوری های جدید دریافت کرده ایم ، در نظر می گیرد. هر فناوری چندین مرحله از آزمایش تا انتشار (راه اندازی) را طی می کند و زمان هر مرحله با آنچه در مرحله قبل می آموزیم و کشف می کنیم ، آگاه می شود. در حالی که ما در حال حاضر در حال حاضر نسخه های متعهدانه ای نداریم ، همانطور که انجام می دهیم ، مطمئناً جدول زمانی عمومی خود را در PrivacysandBox.com به روز خواهیم کرد. |
سودمندی برای انواع مختلف ذینفعان | نگرانی از اینکه فن آوری های ماسهبازی حریم خصوصی از توسعه دهندگان بزرگتر حمایت می کنند و سایت های طاقچه (کوچکتر) بیشتر از سایت های عمومی (بزرگتر) کمک می کنند. | ما می دانیم که برخی از توسعه دهندگان نگرانی در مورد تأثیر فن آوری های ماسهبازی حریم خصوصی دارند. Google متعهد شده است كه CMA پیشنهادات Sandbox را به حریم خصوصی طراحی یا پیاده سازی كند ، به گونه ای كه رقابت را با پیشگویی از تجارت خود Google تحریف كند و تأثیر خود را در رقابت در تبلیغات دیجیتال و ناشران و تبلیغات و همچنین تأثیرات در نظر بگیرد. در مورد نتایج حریم خصوصی و تجربه کاربر. ما همچنان با CMA همکاری نزدیکی داریم تا اطمینان حاصل کنیم که کار ما با این تعهدات مطابقت دارد. با پیشرفت آزمایش ماسهبازی حریم خصوصی ، یکی از سؤالات کلیدی که ما ارزیابی خواهیم کرد این است که چگونه فن آوری های جدید برای انواع مختلف ذینفعان انجام می دهند. بازخورد از این نظر بسیار مهم است ، به ویژه بازخورد خاص و عملی که می تواند به ما در بهبود بیشتر طرح های فنی کمک کند. |
جدول زمانی استهلاک کوکی شخص ثالث | درخواست ها برای جلوگیری از تأخیر بیشتر برای استهلاک کوکی شخص ثالث | ما از برخی از ذینفعان شنیده ایم که می خواهند Chrome با استهلاک کوکی شخص ثالث و بدون تأخیر پیش بروند ، و ما از دیگران شنیده ایم که معتقدند زمان بیشتری برای آزمایش و اتخاذ فن آوری های ماسهبازی حریم خصوصی لازم است. ما متعهد هستیم با توجه به پیچیدگی فناوری ها و اهمیت اکوسیستم درستی ، با مسئولیت پذیری اقدام کنیم. بازخورد از صنعت و تنظیم کننده ها برای این فرآیند بسیار مهم بوده است. |
جدول زمانی استهلاک کوکی شخص ثالث | درخواست ها برای به تأخیر انداختن استهلاک کوکی شخص ثالث و فراهم کردن زمان بیشتری برای آزمایش API ها. | ما از برخی از ذینفعان شنیده ایم که می خواهند Chrome با استهلاک کوکی شخص ثالث و بدون تأخیر پیش بروند ، و ما از دیگران شنیده ایم که معتقدند زمان بیشتری برای آزمایش و اتخاذ فن آوری های ماسهبازی حریم خصوصی لازم است. ما متعهد هستیم با توجه به پیچیدگی فناوری ها و اهمیت اکوسیستم درستی ، با مسئولیت پذیری اقدام کنیم. بازخورد از صنعت و تنظیم کننده ها برای این فرآیند بسیار مهم بوده است. |
درخواست های مستند سازی | درخواست منابع بیشتر در مورد نحوه مدیریت آزمایش ، تجزیه و تحلیل و اجرای. | ما قدردانی می کنیم که توسعه دهندگان مواد فعلی ما را مفید دانسته اند ، و ما متعهد هستیم که مطالب بیشتری از جمله ساعات دفتر توسعه دهنده و اسناد فنی را طی هفته ها و ماه های آینده ارائه دهیم تا توسعه دهندگان بتوانند درک کنند که چگونه فناوری های جدید می توانند برای آنها کار کنند. ما همچنین جلسات ساعات اداری توسعه دهنده خارجی را برای به اشتراک گذاشتن بهترین شیوه ها و نسخه های نمایشی به همراه جلسات پرسش و پاسخ با محصول و مهندسی برگزار کرده ایم تا امکان بحث و گفتگوی زنده را فراهم کند. |
تخصص صنعت | تیم Chrome درگیر با نهادهای استاندارد در اکوسیستم ADS لازم برای تعادل صحیح حفظ حریم خصوصی و ابزار فاقد تخصص است. | ما می دانیم که مسئولیت بزرگی داریم و برای به دست آوردن این حق به بازخورد خاص بستگی داریم. ما همچنین حریم خصوصی و اثربخشی را معیارهای طراحی مهم و ضروری می دانیم. در سراسر تیمی که روی ماسهبازی حریم خصوصی برای وب کار می کند ، تعداد کل سالهای کار در اکوسیستم تبلیغات در صدها نفر خوب است. |
نمایش محتوای و تبلیغات مربوطه
موضوعات
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
سودمندی برای انواع مختلف ذینفعان | نگرانی هایی در مورد مقدار ایجاد شده و توزیع آن مقدار برای سایت ها بسته به سطح ترافیک آنها یا میزان تخصصی محتوای آنها مطرح شده است. | سودمندی API از طریق آزمایش مورد بررسی قرار می گیرد. Chrome انتظار دارد تا طبقه بندی و سایر پارامترها بر اساس نتایج آزمایش تکامل یابد. تکامل طبقه بندی یا پارامترها ممکن است نیازی به تغییرات ناسازگار به عقب نداشته باشد. علاوه بر این ، Chrome انتظار دارد بازخورد همچنان بر تأثیرگذاری بر مباحث تکامل API پس از استهلاک کوکی شخص ثالث ادامه یابد. |
طبقه بندی | ذینفعان صنعت آرزو می کنند در تأثیرگذاری بر طبقه بندی صدایی داشته باشند. | Chrome برای ورود به طبقه بندی باز است. Chrome بسیار علاقه مند به بازخورد در مورد مدل حاکمیت برای اصلاح طبقه بندی و بحث در مورد چگونگی سایر نهادهای صنعت می توانند نقش فعال تری در توسعه و حفظ طبقه بندی در دراز مدت داشته باشند. |
تاریخچه مرور کافی نیست | پیشنهاد به موضوعات سطحی که تماس گیرنده در هفته های گذشته دیده است اگر کاربر سابقه مرور کافی برای ایجاد 5 موضوع برای جدیدترین هفته داشته باشد | برای طراحی فعلی ما ، آنها به طور تصادفی انتخاب می شوند. ما همبستگی با مباحث گذشته را بررسی خواهیم کرد و در نظر خواهیم گرفت که آیا امکان ترکیب این امر وجود دارد ، با این حال ، همبستگی ممکن است دارای ملاحظات حریم خصوصی منفی باشد که باید در آن مورد بررسی قرار گیرند. |
مباحث به نمایندگی از ناشر | آیا یک ارائه دهنده خدمات شخص ثالث می تواند موضوعاتی را با ناشر به اشتراک بگذارد؟ | بله ، این روشی است که ما انتظار داریم از موضوعات استفاده شود. |
بردارهای حمله بالقوه | شناسایی مباحث پر سر و صدا | بر اساس بازخورد بسیاری از افراد در اکوسیستم ، Chrome تصمیم به فیلتر کردن موضوعات و معرفی سر و صدا گرفت. این تصمیمات با توجه به حریم خصوصی گرفته شده است - برای محدود کردن دسترسی به اطلاعات به مواردی که در غیر این صورت به چنین اطلاعاتی دسترسی ندارند و به ترتیب قابلیت اطمینان قابل قبول را برای کاربران معرفی می کنند. ما می دانیم که این تصمیمات دارای اشکالاتی هستند ، مانند بردار حمله که در اینجا بیان شده است. با این حال ، ارزیابی ما این است که مزایای حریم خصوصی از خطرات احتمالی فراتر می رود. ما از بحث عمومی در مورد این تصمیم استقبال می کنیم. |
واجد شرایط بودن محاکمه مبدا | آیا راهی برای تشخیص اینکه آیا کاربر واجد شرایط آزمایش مبدا است ، وجود دارد؟ | یک ویژگی آزمایشی Origin ممکن است به دلیل تنظیمات مرورگر یا عوامل دیگر ، در دسترس کاربر نباشد ، حتی اگر آنها از یک صفحه وب بازدید کنند که یک نشانه آزمایشی معتبر را ارائه می دهد و مرورگر آنها در گروهی که آزمایش آن فعال است ، گنجانده شده است. به همین دلیل ، قبل از تلاش برای استفاده از آن ، همیشه باید از تشخیص ویژگی استفاده شود تا بررسی کند که آیا یک ویژگی آزمایشی Origin موجود است. |
تأثیرات عملکرد | نگرانی های سربار و تأخیر با موضوعات | ما در حال درخواست بازخورد برای رویکردها برای جلوگیری از Iframes گران قیمت و آهسته X-Origin و پیشنهاد برای جدا کردن مباحث API به گونه ای است که گرفتن مباحث باعث تغییر وضعیت مرور نمی شود. |
موضوعات تقسیم عملکرد API | کنترل بیشتر بر سه جنبه مختلف API | ما مورد استفاده را درک می کنیم و یک روش ممکن برای حل این مسئله در GitHub پیشنهاد کرده ایم. ما در حال حاضر در انتظار بازخورد بیشتر از اکوسیستم در مورد ساخت عملکرد هستیم. بحث مداوم را در اینجا مشاهده کنید. |
جدول زمانی و مستندات طبقه بندی کننده | توسعه دهندگان اطلاعات بیشتری در مورد طبقه بندی کننده درخواست کرده اند. | ما اطلاعات بیشتری در مورد طبقه بندی کننده در اینجا ارائه داده ایم. و همچنین اینجا و اینجا . |
کنترل کاربر و ایمنی | موضوعات خاص ممکن است پروکسی برای گروه های حساس باشد و کاربران برای جلوگیری از نتایج منفی به کنترل بیشتری نیاز دارند. | مباحث یک گام مهم به جلو برای کنترل و شفافیت کاربر نشان می دهد. کاربران می توانند از موضوعات خودداری کنند ، مباحثی را که به آنها اختصاص داده شده است ، مرور کنند ، مباحث را حذف کنند و بدانند که شرکت ها با موضوعات خود در یک صفحه خاص در تعامل هستند. علاوه بر این ، کاربران همچنین می توانند با حذف تاریخ مرور خود ، مباحث خود را تحت تأثیر قرار دهند. ما از ادامه بحث در مورد کنترل های پیشرفته کاربر ، مانند موارد پیشنهادی توسط توسعه دهندگان استقبال می کنیم. با این حال ما باید اطمینان حاصل کنیم که برای نگرانی های مطرح شده در این اشکال ، در واقع خطرات را از بین می برد (برای مثال ، حذف موضوع فقط "مطالعه زبان خارجی" اما وب سایت هایی که موضوع را از مرور تاریخ ایجاد کرده اند به طور کامل از کاربر محافظت نمی کنند ). |
استفاده از مباحث مربوط به سایتهای Prebid.js | آیا می توان از مباحث API در وب سایت هایی با prebid.js استفاده کرد؟ | پاسخ کوتاه بله است. اطلاعات بیشتر در اینجا منتشر شده است. |
استفاده از موضوعات API در ویجت توصیه | آیا می توانیم از API موضوعات در ویجت توصیه شده استفاده کنیم (به عنوان مثال Outbrain) | ما مورد استفاده از مباحث بازیابی شده پس از فراخوانی API را محدود نمی کنیم (که به خط مشی داده هر توسعه دهنده بستگی دارد). |
سیاست حفظ حریم خصوصی | اگر برخی از اشخاص ثالث مباحث خود را با هر کسی که تماس می گیرد ، سؤالاتی در مورد هدف فیلتر پاسخ توسط تماس گیرنده وجود دارد. | براساس بازخورد بسیاری از افراد در اکوسیستم ، Chrome این طرح را برای محدود کردن دسترسی به اطلاعات به مواردی که در غیر این صورت دسترسی به چنین اطلاعاتی نداشتند ، انتخاب کرد. البته ناشران و اشخاص ثالث که مباحث دریافت می کنند می توانند برای خودشان تصمیم بگیرند که چه اطلاعاتی را با طرفین در سایت خود به اشتراک می گذارند. اگر آنها این نوع اشتراک را انجام دهند ، Chrome آنها را به شدت تشویق می کند که در مورد چنین اشتراک گذاری برای کاربران خود شفاف باشند و کنترل آنها را ارائه دهند. |
سیگنال های پر سر و صدا | ارائه یک موضوع تصادفی 5 ٪ از زمان ممکن است سیگنال نویز / کاذب زیادی ایجاد کند. | نویز یک روش مهم برای محافظت از حریم خصوصی کاربر است و سطح سر و صدا در مقابل سودمندی مباحث از طریق آزمایش مورد بررسی قرار می گیرد. |
گله
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
هماهنگی آزمایش | آزمایش برای عملکرد و تأثیر درآمد | عملکرد Fledge ، و اینکه چگونه می توانیم از آزمایش اکوسیستم در طول آزمایشات مبدا و همچنین در دسترس بودن عمومی پشتیبانی کنیم ، در جلسات عمومی WICG به طور فعال مورد بحث قرار می گیرد. |
سرور قابل اعتماد برای Fledge | چه زمانی سرور قابل اعتماد برای آزمایش در دسترس خواهد بود؟ | ما از این بازخورد قدردانی می کنیم و به طور جدی روی یک برنامه دقیق تر کار می کنیم که می توانیم برای استفاده از سرورهای قابل اعتماد در Fledge به اشتراک بگذاریم. |
استاندارد سازی پروتکل | آیا یک پروتکل مشترک برای انتقال داده ها بین SSP ها و DSP ها ، مانند برچسب های مشترک برای گروه های ذینفع وجود دارد؟ | ما از بازخورد DSP ها ، SSP ها و اکوسیستم ADS گسترده تر در مورد استاندارد سازی بالقوه مشخصات استقبال می کنیم. برای اهداف آزمایش اولیه در این زمان ، توصیه می کنیم مستقیماً با شرکای تست خود کار کنید زیرا آنها در حال آزمایش با رویکردهای مختلف هستند. ما همچنین سازمان های تجاری ADS را نیز تشویق می کنیم و قصد داریم با هم کار خود را ادامه دهند تا در صورت مفید بودن برای شرکت های عضو خود ، استاندارد سازی را ایجاد کنند. |
محدودیت فرکانس | کنترل فرکانس هر کاربر در یک گروه کمپین و تبلیغات. | Fledge از پوشش فرکانس برای حراج های روی دستگاه و کمپین های متنی / برندسازی نیز پشتیبانی می کند. ذخیره های مشترک و کلاه های خاص سایت نیز می توانند برای کنترل های اضافی درپوش فرکانس استفاده شوند. |
تأثیر Fledge بر عملکرد | داوطلبان محاسباتی فشرده در حراج Fledge | Chrome در مورد تأثیر بالقوه بر عملکرد سایت در حال بحث و گفتگو با توسعه دهندگان است. Chrome از فرصت یادگیری بیشتر در طول آزمایش استقبال می کند. |
آزمایش با سایر ویژگی ها | چگونه گزارش های سطح رویداد از API گزارش انتساب و Fledge در کنار هم قرار خواهد گرفت؟ | این مورد در یک تماس اخیر WICG/Conversion-Tuary-API ، با پیوندی به دقایق دقیق در اینجا مورد بحث قرار گرفت. خلاصه ای از جلسه این است که طراحی فعلی برای گزارش های تبلیغاتی فریم های حصارکشی ، امکان ایجاد شناسه تولید شده در داخل قاب حصارکشی را با اطلاعات متنی فراهم می کند. گزارش های سطح رویداد که در داخل قاب حصار تولید می شوند ، به همان اطلاعات متنی در سرور وصل می شوند (با استفاده از 2 اتصال سرور به جای 1). |
شمارش برداشت | کدام روش شمارش برداشت باید بین خریداران و فروشندگان استفاده شود | API Fledge در حال حاضر از تراز روش شناسی بین فروشنده و خریدار در حراج پشتیبانی می کند. ما در مورد پیاده سازی های متناوب بدون بازخورد در مورد اینکه چرا طراحی فعلی ما نمی تواند برای اکوسیستم کار کند ، پیشنهاداتی دریافت کرده ایم. |
نمایش چندین تبلیغ | آیا می توان چندین تبلیغ را در یک حراج در یک قاب حصار نشان داد | این در حال حاضر از طریق تبلیغات مؤلفه امکان پذیر است (با حراج های مؤلفه اشتباه گرفته نمی شود). برای این کار ، تمام تبلیغات باید در یک گروه علاقه باشند. |
مشخصات "فروشنده تعریف شده (SDA)" مشخصات و Fledge | آیا Fledge می تواند به مکانیسمی برای جلوگیری از پروفایل های ساختمان از SDA در درخواست های تبلیغاتی تبدیل شود؟ | Fledge برای جلوگیری از نشت اطلاعات طراحی شده است که وقتی ناشر می داند SDAS خود را در چه مواردی قرار می دهد و هدف قرار می دهد ، همان سایت است. اگر مهم است که از خرید در SDA ها در تمام حفاظت های ساخته شده در Fledge پشتیبانی کنید ، ممکن است یک راه حل برای فروشنده باشد که برچسب های SDA را به حراج در دستگاه خود منتقل کند و یک فناوری تبلیغی طرف خرید برای ایجاد گروه علاقه خود منطق مناقصه ای که می گوید "من می خواهم مخاطب X را بخرم." |
پشتیبانی از ارزها علاوه بر دلار | پشتیبانی از آزمایش Fledge با ارزهای فراتر از دلار | ما از این فراخوانی قدردانی می کنیم و در حمایت از سایر ارزها در بازپرداخت درخواست های ویژگی ، ساختمان را اضافه کرده ایم. امیدواریم که این خیلی زود در دسترس باشد. |
پشتیبانی از هدف قرار دادن گروه علاقه منفی | API برای پشتیبانی از هدف قرار دادن IG منفی: نشان دادن تبلیغات فقط در صورتی که کاربر متعلق به IG نباشد. | بحث در حال انجام ، از جمله برخی از گزینه های پیشنهادی برای پشتیبانی ، در شماره GitHub . |
چند SSP در Fledge | خطر طرفداری از Google هنگام اجرای حراج های چند سطحی در Fledge | پشتیبانی از SSP های متعدد در Fledge به منظور فراهم کردن یک زمین بازی منصفانه و عادلانه اضافه شد. گوگل قول داده است که طبق تعهدات برای طراحی ، توسعه یا پیاده سازی پیشنهادهای ماسه ای حریم خصوصی به روش هایی که باعث می شود رقابت با پیشگویی از محصولات و خدمات تبلیغاتی خود تحریف کند. Google این موضوع را جدی می گیرد ، و برای بحث در مورد هرگونه نگرانی که ذینفعان در مورد جنبه های خاص این فناوری دارند ، بسیار باز است. برای اطلاعات ، Chrome مکانیسم حراج مؤلفه را در اینجا ثبت کرده است. |
اندازه گیری تبلیغات دیجیتال
گزارش انتساب (و سایر API ها)
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
انتساب چند لمسی | ناشران درخواست پشتیبانی از انتساب چند لمسی | روشهای فعلی انتساب چند لمسی مستلزم اتصال قطعی است تا برداشت های کاربر (و بنابراین هویت) را در وب سایت های مختلف به هم وصل کند. در نتیجه ، این عملکرد به شکل فعلی خود با اهداف Sandbox Privacy ، که هدف آن پشتیبانی از موارد اصلی استفاده از موارد بدون ردیابی متقابل در سایت است ، هماهنگ نیست. در بعضی موارد ، تقریب واگذاری اعتبار (به عنوان مثال ، با استفاده از اولویت های وزنی و تصادفی) بدون ردیابی کاربران فردی امکان پذیر است. |
تولید سر و صدا | سؤالاتی در مورد سطح سر و صدای گزارش ها | آزمایش اولیه ما به توسعه دهندگان این امکان را می دهد تا ارزش اپسیلون خود را تعیین کنند تا بتوانند نحوه تغییر گزارش ها بر اساس سطح سر و صدا را تجربه کنند. از هم اکنون ، توسعه دهندگان می توانند مقدار Epsilon را تا Epsilon = 64 انتخاب کنند. ما این کار را به طور خاص انجام داده ایم تا توسعه دهندگان آزمایش API ها را آسانتر کنیم و در مورد مقادیر مناسب اپسیلون بازخورد خود را ارائه دهیم. ما همچنین برای چنین بازخورد درخواست عمومی کرده ایم. |
هماهنگی آزمایش | آیا می توان از ابزار آزمایش محلی برای OT استفاده کرد؟ | بله ، از ابزار آزمایش محلی می توان برای مدت زمان OT استفاده کرد. تا زمانی که کوکی های شخص ثالث در دسترس باشند ، از ابزار آزمایش محلی می توان با گزارش های اشکال زدایی استفاده کرد. |
ارگونومی پرس و جو | کلیدهای پرس و جو را فعال کنید | ما موافقیم که به نظر می رسد این امر ارگونومی API را با هزینه کمی و بدون هزینه حفظ حریم خصوصی بهبود می بخشد. ما یک پیشنهاد ارائه خواهیم داد و خواهیم دید که آیا اجماع گسترده ای وجود دارد که ارزش حمایت از آن را دارد یا خیر. |
داده های کمتر دقیق برای سایت های کوچک | سایت ها یا کمپین های کوچکتر ممکن است داده های دقیق کمتری دریافت کنند. | Chrome تشخیص می دهد که حفاظت از حریم خصوصی مبتنی بر سر و صدا تأثیر بیشتری در برش داده های کوچکتر دارد. با این حال ، این امکان وجود دارد که روش هایی مانند جمع شدن در مدت زمان طولانی تر این مشکل را حل کنند. همچنین مشخص نیست که نتیجه گیری بر اساس برش های داده بسیار کوچک (مانند یک یا دو خرید) برای تبلیغ کنندگان معنی دارد. در طول آزمایش مبدا ، Chrome آزمایش کنندگان را ترغیب می کند تا از توانایی آزمایش با طیف گسترده ای از پارامترهای حریم خصوصی و سر و صدا استفاده کنند تا بتوانند بازخورد ویژه تری در مورد این موضوع ارائه دهند. |
ردیابی پنهانی را محدود کنید
کاهش عامل کاربر
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
حفاظت از ربات | تأثیر UA-R در محافظت از ربات | ما از این بازخورد قدردانی می کنیم و در حال جمع آوری اطلاعات در مورد رویکردهای حفاظت از ربات هستیم تا از طرح های آینده خود مطلع شویم. |
وابستگی های استقرار | پرداختن به وابستگی های استقرار کاربر ساخت یافته (SUA) | ما "فاز 4" ، با نام مستعار نسخه جزئی را به 100 ٪ از کاربران Chrome در نسخه های 101 و بالاتر کاهش داده ایم. به روزرسانی را در اینجا مشاهده کنید. |
اشاره مشتری عامل کاربر
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
شمارش تمام نکات پشتیبانی شده | علاقه به داشتن یک روش برنامه ای برای دانستن تمام نکات پشتیبانی شده برای یک مرورگر. | ما از این بازخورد قدردانی می کنیم و در حال ارزیابی درخواست ویژگی هستیم. ما علاقه مند به درک این موضوع هستیم که آیا این یک مورد استفاده مشترک است یا خیر. |
انعطاف پذیری UA-Ch در مقابل عنوان عامل کاربر | UA-CH در مقایسه با انعطاف پذیری که هدر عامل کاربر ارائه می دهد ، همانطور که توسط RFC7231 تعریف شده است ، بیش از حد تجویز می شود. | Chrome ماهیت تجویز هدرهای UA-CH را به عنوان یک پیشرفت مهم نسبت به انعطاف پذیری رشته UA ، هم از نظر قابلیت همکاری متقابل مرورگر متقاطع و محافظت از حریم خصوصی کاربر (با جلوگیری از افزودنیهای دلخواه شناسه های آنتروپی بالا) می بیند. در صورتی که دیگران این نگرانی را نیز به اشتراک بگذارند ، این مسئله باز است و مایل به ارائه بازخورد است. |
UA-Ch: نگرانی های ضد کلاهبرداری / ضد سوء استفاده | ویژگی های خاصی که ممکن است از طریق UA-CH از بین بروند: روی Redirect Tracker و کلیک های کلاهبرداری کلیک کنید. | این تیم در حال بررسی این مسائل احتمالی با ذینفعان ضد کلاهبرداری و اندازه گیری است. |
کارایی | نگرانی هایی در مورد تأخیر در گرفتن نکات از طریق Critical-CH (در بار صفحه اول) وجود دارد. | Chrome در حال بررسی روش های بهبود عملکرد است. |
gnatcatcher (WIP)
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
نگرانی های تأخیر | اضافه کردن هاپ (های) اضافی می تواند بر تأخیر تأثیر بگذارد | ما در حال بررسی یک پروکسی دو هاپ هستیم و راه هایی را برای یافتن تعادل مناسب بین حریم شخصی کاربر و تأخیر در حال بررسی هستیم. ما برای بازخورد باز هستیم و دوست داریم بحث بیشتر در انجمن های W3C را دوست داشته باشیم. |
کلاهبرداری و محافظت از ربات | تأثیرات مربوط به کلاهبرداری و محافظت از ربات ، از جمله در کشورهای کمتر توسعه یافته | ایمنی یک نیاز اصلی است زیرا ما به دنبال راه هایی برای بهبود حریم خصوصی کاربر به روش های معنی دار ، مانند آدرس های IP پروکسی هستیم. همکاری دو پروکسی Hop با شرکت های معتبر ، حریم شخصی قابل اثبات را فراهم می کند. ما همچنین برای کمک به انتقال اعتماد کاربر ، ایده هایی را برای سیگنال های جدید انکوب می کنیم. |
رعایت قوانین حفظ حریم خصوصی محلی | گزارش داده های GEO در سطح کشور ، رعایت رژیم های محلی گرامی بیشتر را دشوار می کند | ما اصول پیشنهادی خود را به صورت عمومی ارسال کرده ایم ، که شامل رویکردهای بالقوه در مورد آن می تواند وب سایت ها مطابق با الزامات محلی باقی بمانند. |
مرزهای حریم خصوصی بین سایتی را تقویت کنید
ست های شخص اول
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
سودمندی برای انواع مختلف ذینفعان | تأثیر FPS برای ناشران کوچک در مقابل بزرگ | هدف اصلی ماسهبازی حریم خصوصی ، بهبود حریم شخصی کاربر با جایگزینی شیوه های فعلی با راه حل هایی است که به مکانیسم های ردیابی متقابل متکی نیستند. ما می خواهیم این راه حل ها تا حد امکان برای انواع و اندازه های مختلف ذینفعان مفید باشد. ما از ورودی خاص و عملی در مورد چگونگی بهبود این راه حلها استقبال می کنیم و انتظار داریم که آنها با بحث و آزمایش جامعه به تکامل خود ادامه دهند. |
بهبود حریم خصوصی | بیش از حد بسیاری از سایت ها در همان مجموعه می توانند منجر به نتایج مشابه کوکی های شخص ثالث شوند | ما از این بازخورد قدردانی می کنیم و در حال ارزیابی این هستیم که آیا محدودیت های مناسب یا چه محدودیتی می تواند باشد ، در حالی که سعی می کنیم به کاربران و توسعه دهندگان درمان یا سیگنال ها را نیز ارائه دهیم تا بتوانند درک کنند که در چه حد چنین محدودیتی وجود دارد. ما هنوز یک پیشنهاد خاص برای به اشتراک گذاشتن نداریم اما امیدواریم خیلی زود. |
پشتیبانی اکوسیستم از FPS | جمع آوری پشتیبانی و نگرانی برای ادامه توسعه FPS در خارج از حریم خصوصی CG | در حالی که ما ترجیح می دادیم که پیشنهاد مجموعه های شخص اول در PrivacyCG باقی بماند ، ما مشتاقانه منتظر هستیم تا این پیشنهاد را در WICG دنبال کنیم. ما همچنین از اظهارات بی شماری از حمایت برای ادامه بحث در مورد مجموعه های شخص اول و موارد استفاده ای که برای پرداختن به آن استفاده می شود ، مورد تشویق قرار گرفتیم. Google متعهد به یافتن راه حل هایی است که به وب اجازه می دهد تا به شکلی که از حریم شخصی کاربر محافظت و احترام می گذارد ، به رشد و رشد خود ادامه دهد. |
قابلیت همکاری مرورگر | اجرای سایر مرورگرها | ما اهمیت قابلیت همکاری مرورگر را برای توسعه دهندگان تشخیص می دهیم و به همکاری با سایر مرورگرها برای پیگیری استاندارد FPS ادامه خواهیم داد. |
الزام سیاست حفظ حریم خصوصی مشترک | حفظ یک خط مشی رازداری مشترک در تمام محصولات و حوزه های قضایی که باید بخشی از همان مجموعه باشند ، غیرقابل تحمل است. | Chrome هنوز هم الزامات خط مشی ما را تعریف می کند. و این بازخورد را در خاطر داشته باشید. |
Fenced Frames API
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
درخواست مستندات | تفاوت با iframes ماسه ای | ما از بازخورد و پیشنهاد قدردانی می کنیم. بحث فعلی در این باره در مورد GitHub وجود دارد ، جایی که ما امیدواریم که در مورد درخواست وضوح نهایی را بدست آوریم تا بتوانیم آن را به طور کامل ارزیابی کنیم. بحث عمومی در اینجا موجود است. |
قابلیت های متقابل API | پشتیبانی پیش فرض از گزارش انتساب در قاب های حصارکشی | ما در حال درخواست بازخورد در مورد یک پیشنهاد برای اجازه دادن به API گزارش انتساب در "حالت Opaque-Ads" فریم های حصارکشی به طور پیش فرض هستیم. ما توسعه دهندگان را تشویق می کنیم که این موضوع را برای بحث و گفتگو در مورد بحث و گفتگو می دانند. |
API ذخیره سازی مشترک
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
محدودیت داده ها | آیا محدودیتی در میزان ذخیره اطلاعات در هر پارتیشن وجود خواهد داشت؟ | بله ، محدودیت هایی وجود خواهد داشت. برای اطلاعات بیشتر به شماره GitHub مراجعه کنید. ما به سهمیه ذخیره سازی نیاز خواهیم داشت. پیشنهاد فعلی ما این است که یک کلاه اندازه در هر اندازه 4 کیلوبایت داشته باشیم ، هر دو کلید و مقادیر محدود به 1024 کاراکتر char16_t و یک کلاه ورودی در هر منظر از 10،000 مدخل با مکانیسمی که مانع از ورود ورودی های اضافی در هنگام انجام موارد اضافی می شود ، محدود می شود. ظرفیت منشأ پر است. ما به طور جدی به دنبال بازخورد در مورد محدودیت های خاص ارائه شده در اینجا هستیم. |
شفافیت کاربر | شفافیت کاربر برای منابع داده در مقابل استفاده از داده ها | ما از این بازخورد قدردانی می کنیم و فکر می کنیم این یک رویکرد امیدوار کننده است که ارزش کاوش دارد. به طور خاص ، ما ارزیابی می کنیم که آیا انجام این کار به گونه ای امکان پذیر است که شفافیت کافی را برای کاربران ارائه دهد. |
چیپس
موضوع بازخورد (رتبه بندی شده توسط شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
موانع پذیرش | آیا تراشه ها باید شامل نام میزبان باشند؟ (نیاز به دامنه) | ما بر اساس بازخورد شرکت کنندگان در OT ، این نیاز را از OT حذف می کنیم که این نیاز به پیچیدگی اضافی اضافه می کند و به عنوان مانعی برای پذیرش تراشه ها عمل می کند. ما در مورد این نیاز در گروه جامعه حریم خصوصی به عنوان بخشی از جوجه کشی استاندارد در اینجا بحث خواهیم کرد. |
تبلیغات از مواردی برای تراشه ها استفاده می کنند | آیا می توان از تراشه ها برای موارد تبلیغاتی در یک سایت واحد استفاده کرد؟ | ردیابی کاربر در یک سایت یک مورد استفاده مجاز است. ما مقاله توسعه دهنده خود را به روز کرده ایم تا این مورد استفاده را برجسته کنیم. |
جاسازی های معتبر | آیا وضعیت ورود به سیستم با تراشه ها حفظ شده است؟ | Signed in state is not currently preserved, but it is not the intended use-case for CHIPS. We are aware of the authenticated embeds use case and are working to explore solutions. |
Testing coordination | Are there any additional user actions needed to test partitioning? | As long as the OT token is valid and present in the headers of the pages visited, the feature should be available for users, without requiring any additional user actions |
سازگاری مرورگر | Interest in understanding how other browsers have handled partitioned cookie attributes. | Chrome continues to work within public standards groups such as the W3C to identify designs and implementations that can work across browsers. |
FedCM
Feedback Theme (Ranked by Prevalence) | Questions and Concerns Summary | Chrome Response |
Potential attack vectors | Potential attack vectors via link decoration and timing attacks | We are actively gathering public input and investigating potential ways to address this issue . |
UX to allow for multiple IDPs | Only one IDP can be presented at a time | We believe in supporting multiple IDPs, and are actively working on approaches to support |
بیانگر بودن | Concern that because the browser renders part of the federated identity flow, it is hard to capture all of the nuances that IDPs would like to present to their users. | Chrome is exploring including branding customizations (eg logos, colors) and string customization (eg "access this article" as opposed to "login with"). Chrome recognizes the trade-off and will continue to work with the ecosystem to both cover as much ground as possible and to make it as expressive as possible. |
Applicability and Interoperability | Concern that other browsers will not adopt or implement FedCM. | Chrome has also been working with other browser vendors to find common solutions for federation at the FedID Community Group. |
Suggestion to remove personal data requirements in sign-up flow | (1) a UX that indicates to the user which IdP they are choosing, without signaling that their email, picture, and name will be shared would be more privacy friendly (2) Use-cases-sign-up is sparse in its user experience and selection of claims from the IdP | We are in agreement and are exploring how to implement the feedback in a more user, and privacy, friendly way. |
User interaction with IdP | Need for direct interaction between user and IdP if a risk threshold is exceeded | We are actively investigating this feedback. |
Network State Partitioning
Feedback Theme (Ranked by Prevalence) | Questions and Concerns Summary | Chrome Response |
کارایی | Partitioning network state could lead to increase in resource intensive connections to CDNs | We are still investigating the performance characteristics of Network State Partitioning, including measuring different possible keying schemes. We have not yet made a decision between the trade-offs of performance, security, and privacy and need to gather more data. |
Fight spam and fraud
Trust Tokens API
Feedback Theme (Ranked by Prevalence) | Questions and Concerns Summary | Chrome Response |
Regulatory feedback | Concerns about investing time and resources in Trust Tokens without clear signal from regulators about long-term viability | Our goal is to build technology that works for the ecosystem, making feedback from the industry and regulators critical to the process. We will continue to consult with regulators around the world as we develop the Privacy Sandbox and make the proposals available to developers, including Trust Tokens. As with all new technologies, companies should make decisions based on their own assessment of regulatory requirements. |
Launch timing | When will Trust Tokens be launched to GA? | We provide our current estimates for delivery in our public timeline on privacysandbox.com . As soon as we make a final decision on its delivery date to GA, we'll post it publicly via Chrome's release processes and update the timeline on the website. |
Trust Tokens vs others | What role do Trust Tokens play given the other tokens undergoing standardization, such as Private Access Tokens | We are engaged in standardization discussions and our goal is to align with other efforts as much as possible, while enabling the different use cases each technology affords. For example, Trust Tokens and Private Access Tokens both rely on the Privacy Pass protocol. |
Data limits | Max 2 Issuers for token redemption per page potentially limiting | We are looking for long term options where we can safely allow companies to redeem tokens without risking more user entropy, perhaps by partitioning access to token redemptions . |
محدودیت های دسترسی | Only approved (and verified/not spoofed referrer) origins should be able to verify presence of a token and redeem | We are exploring approaches for who can see and redeem tokens. |
پشتیبانی دستگاه | Javascript runtime dependencies limit use on certain devices. Can TT support be extended to work across other types of devices? | This is something we could consider for future development and a topic we would love to hear more feedback from developers in W3C forums. We also have an open issue for discussing an HTTP Header triggered token redemption that we invite feedback on. |
موارد استفاده کنید | Unclear what the right use cases for Trust Tokens are. Lack of clarity about intended uses. | Our goal is to facilitate innovation within the anti-fraud space, and understand each company may employ proprietary techniques with trust tokens, which is why we have not been prescriptive regarding intended use(s). However, we will likely expand our documentation to include more examples as starting points for partners who are considering experimentation or adoption. |
Trust Token Coverage | Removing this 'trust-token-redemption' feature policy should significantly increase the trust token coverage. | This is in consideration as we collect feedback from the OT and make decisions about next steps. |
Issuer trust | Why should we trust websites that issued trust tokens? | There are no guidelines on becoming an issuer - anyone can do it. It is expected that the publishers would only work with issuers they trust. Additionally, other legitimate actors in the ads ecosystem would eventually discount (or stop buying) traffic associated with suspicious or unknown issuers. |
3P embedded services | Can 3P embedded services redeem and/or request trust tokens? | Yes, a 3P embedded service can issue and redeem Trust Tokens. |
Ecosystem of issuers | Greater utility can be achieved if trust signals can be shared with other companies | Trust Tokens is designed to be a low-level primitive, and can be used by cooperating issuers/redeemers to share trust/reputation signals. |
Maintenance overhead | The cryptographic implementation underlying Trust Token operations is in BoringSSL; which Google is the sole maintainer of. How will maintenance of the library be managed? | Trust Tokens relies on standardized cryptographic operations (see Privacy Pass protocol ) that may also be implemented in other libraries. We recommend that developers request/develop/maintain support for these operations in the libraries of their choice. |
Maintenance overhead | Not clear how long protocol versions will be supported | We are looking into developing and documenting more specifics on the expected support timeframes for protocol versions. |
Issuer Limits | If you are further down the chain, your opportunity to execute Trust Tokens might not arise | As more organizations begin to use trust tokens, we could increasingly see these types of timing dynamics at play, and are investigating potential solutions. As described previously, we are looking for long term options where we can safely allow companies to redeem tokens without risking more user entropy, which would minimize the importance of location on page or loading order. |
New Anti-Fraud Solutions in Incubation
Feedback Theme (Ranked by Prevalence) | Questions and Concerns Summary | Chrome Response |
Device Integrity Attestation Signals | Generally strong support for pursuing device integrity signals attested by platforms and made available to the web | We will continue to gather feedback and pursue the proposal through public design and iteration. |
Device Integrity Attestation Signals | Questions over how much user entropy could be conveyed through new signals, and whether certain use cases (such as a user logging into their bank) could justify higher entropy signals. | We lean towards providing high value signals with as little user entropy as possible to preserve user privacy. |
Device Integrity Attestation Signals | Would this signal limit access for older devices or open-source/modified platforms? | Any new signals should consider universal access as a key principle in development, and these are important questions to address upfront as we continue incubation. |
Device Integrity Attestation Signals | There was some concern if new signals cause security and anti-fraud companies to overly rely on the browser and platforms | Any new signal should be viewed as supplemental data and not an indication of "trust" from the browser. We fully expect security companies to continue to rely on their own proprietary data, models and decision engines with device attestation as an additional input. Hopefully any new signal will improve detection efforts across the ecosystem and make fraud more difficult to execute. |
Cookie Age Signal | Interesting concept but likely requires more investigation into applicable use cases. | Depending on levels of interest, Chrome may conduct further ideation on this concept, and craft it into an explainer for future ecosystem feedback. |
Trusted Servers for Anti-fraud | Interesting concept but likely requires more investigation into applicable use cases. | Depending on levels of interest, Chrome may conduct further ideation on this concept, and craft it into an explainer for future ecosystem feedback. |