گزارش فصلی برای سه ماهه دوم سال 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ها)
موضوع بازخورد (رتبه بندی بر اساس شیوع) | خلاصه سوالات و نگرانی ها | پاسخ کروم |
انتساب چند لمسی | ناشران درخواست پشتیبانی برای اسناد چند لمسی | روشهای کنونی انتساب چند لمسی مستلزم پیوند قطعی برداشتهای کاربر (و بنابراین هویت) در وبسایتهای مختلف است. در نتیجه، این عملکرد در شکل فعلیاش با اهداف Privacy Sandbox که هدف آن پشتیبانی از موارد استفاده از تبلیغات کلیدی بدون ردیابی بین سایتی است، مطابقت ندارد. در برخی موارد، تقریب تخصیص اعتبار (مثلاً با استفاده از اولویتهای وزنی و تصادفی) بدون ردیابی تک تک کاربران امکانپذیر است. |
تولید نویز | سوالات مربوط به سطوح نویز در گزارش ها | آزمایش اولیه ما به توسعه دهندگان اجازه می دهد تا مقدار اپسیلون خود را تعیین کنند تا بتوانند نحوه تغییر گزارش ها را بر اساس سطح نویز تجربه کنند. در حال حاضر، توسعه دهندگان می توانند مقدار 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 در حال بررسی است که شامل سفارشیسازیهای نام تجاری (مثلاً آرمها، رنگها) و سفارشیسازی رشتهها (بهعنوان مثال «دسترسی به این مقاله» به جای «ورود به سیستم»). کروم این مبادله را تشخیص میدهد و به کار با اکوسیستم ادامه میدهد تا هم تا حد ممکن زمین را پوشش دهد و هم آن را تا حد ممکن رسا کند. |
کاربرد و قابلیت همکاری | نگرانی از اینکه مرورگرهای دیگر 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 Tokens چیست. عدم شفافیت در مورد کاربردهای مورد نظر. | هدف ما تسهیل نوآوری در فضای ضد کلاهبرداری است و درک اینکه هر شرکت ممکن است از تکنیکهای اختصاصی با نشانههای اعتماد استفاده کند، به همین دلیل است که ما در مورد استفاده (های مورد نظر) تجویزی نکردهایم. با این حال، ما احتمالاً اسناد خود را گسترش خواهیم داد تا نمونههای بیشتری را به عنوان نقطه شروع برای شرکای که در حال بررسی آزمایش یا پذیرش هستند، در بر گیرد. |
پوشش توکن اعتماد | حذف این خط مشی ویژگی «توکن اعتماد-بازخرید» باید به طور قابل توجهی پوشش نماد اعتماد را افزایش دهد. | این مورد در نظر گرفته می شود زیرا ما بازخوردهای OT را جمع آوری می کنیم و در مورد مراحل بعدی تصمیم می گیریم. |
اعتماد صادرکننده | چرا باید به وب سایت هایی که توکن های اعتماد صادر کرده اند اعتماد کنیم؟ | هیچ دستورالعملی برای تبدیل شدن به یک صادرکننده وجود ندارد - هر کسی می تواند این کار را انجام دهد. انتظار می رود که ناشران فقط با ناشران مورد اعتماد خود کار کنند. علاوه بر این، سایر بازیگران قانونی در اکوسیستم تبلیغات در نهایت ترافیک مرتبط با ناشران مشکوک یا ناشناخته را کاهش می دهند (یا خرید را متوقف می کنند). |
خدمات تعبیه شده 3P | آیا سرویسهای تعبیهشده 3P میتوانند توکنهای اعتماد را بازخرید و/یا درخواست کنند؟ | بله، یک سرویس تعبیهشده 3P میتواند توکنهای Trust را صادر و بازخرید کند. |
اکوسیستم صادرکنندگان | اگر بتوان سیگنال های اعتماد را با شرکت های دیگر به اشتراک گذاشت، سودمندی بیشتری حاصل می شود | Trust Tokens بهگونهای طراحی شدهاند که ابتدائی سطح پایین هستند و میتوانند توسط صادرکنندگان/بازخریدکنندگان همکار برای به اشتراک گذاشتن سیگنالهای اعتماد/شهرت مورد استفاده قرار گیرند. |
سربار تعمیر و نگهداری | اجرای رمزنگاری زیربنای عملیات Trust Token در BoringSSL است. که گوگل تنها نگهدارنده آن است. نگهداری از کتابخانه چگونه مدیریت خواهد شد؟ | Trust Tokens متکی به عملیات رمزنگاری استاندارد شده است (به پروتکل Privacy Pass مراجعه کنید) که ممکن است در کتابخانه های دیگر نیز پیاده سازی شود. توصیه میکنیم که توسعهدهندگان درخواست/توسعه/حفظ پشتیبانی برای این عملیات در کتابخانههای مورد نظر خود داشته باشند. |
سربار تعمیر و نگهداری | مشخص نیست نسخه های پروتکل برای چه مدت پشتیبانی می شوند | ما به دنبال توسعه و مستندسازی جزئیات بیشتر در مورد بازههای زمانی مورد انتظار پشتیبانی برای نسخههای پروتکل هستیم. |
محدودیت های صادرکننده | اگر در پایینتر از زنجیره باشید، ممکن است فرصتی برای اجرای Trust Tokens ایجاد نشود | همانطور که سازمانهای بیشتری شروع به استفاده از نشانههای اعتماد میکنند، میتوانیم به طور فزایندهای شاهد این نوع پویاییهای زمانبندی باشیم و در حال بررسی راهحلهای بالقوه هستیم. همانطور که قبلاً توضیح داده شد، ما به دنبال گزینههای بلندمدتی هستیم که بتوانیم با خیال راحت به شرکتها اجازه دهیم توکنها را بدون خطر آنتروپی بیشتر کاربر پسخرید کنند، که این امر اهمیت مکان در صفحه یا سفارش بارگیری را به حداقل میرساند. |
راه حل های جدید ضد تقلب در جوجه کشی
موضوع بازخورد (رتبه بندی بر اساس شیوع) | سؤال و نگرانی خلاصه | پاسخ کروم |
سیگنال های تأیید یکپارچگی دستگاه | به طور کلی پشتیبانی قوی برای دنبال کردن سیگنال های یکپارچگی دستگاه که توسط سیستم عامل ها گواهی شده و در دسترس وب قرار داده شده است | ما به جمع آوری بازخورد و دنبال کردن پیشنهاد از طریق طراحی عمومی و تکرار ادامه خواهیم داد. |
سیگنال های تأیید یکپارچگی دستگاه | سؤالاتی درباره میزان آنتروپی کاربر از طریق سیگنال های جدید قابل انتقال است ، و اینکه آیا موارد استفاده خاصی (مانند ورود کاربر به بانک خود) می تواند سیگنال های آنتروپی بالاتر را توجیه کند. | ما به سمت ارائه سیگنال های با ارزش بالا با آنتروپی کاربر در حد امکان برای حفظ حریم شخصی کاربر تکیه می کنیم. |
سیگنال های تأیید یکپارچگی دستگاه | آیا این سیگنال دسترسی به دستگاه های قدیمی تر یا سیستم عامل های منبع باز/اصلاح شده را محدود می کند؟ | هر سیگنال جدید باید دسترسی جهانی را به عنوان یک اصل اصلی در توسعه در نظر بگیرد و این سؤالات مهم برای پرداختن به صورت مقدماتی با ادامه جوجه کشی است. |
سیگنال های تأیید یکپارچگی دستگاه | نگرانی وجود دارد اگر سیگنال های جدید باعث ایجاد امنیت و شرکت های ضد کلاهبرداری شوند تا بیش از حد به مرورگر و سیستم عامل اعتماد کنند | هر سیگنال جدید باید به عنوان داده های تکمیلی مشاهده شود و نه نشانه "اعتماد" از مرورگر. ما کاملاً انتظار داریم که شرکت های امنیتی همچنان به داده های اختصاصی ، مدل ها و موتورهای تصمیم گیری خود با تأیید دستگاه به عنوان یک ورودی اضافی اعتماد کنند. امیدوارم هر سیگنال جدید تلاش های تشخیص را در سراسر اکوسیستم بهبود بخشد و اجرای آن را دشوارتر کند. |
سیگنال سن کوکی | مفهوم جالب اما به احتمال زیاد نیاز به بررسی بیشتر در مورد موارد استفاده قابل استفاده دارد. | بسته به سطح علاقه ، Chrome ممکن است ایده های بیشتری را در مورد این مفهوم انجام دهد ، و آن را به توضیح دهنده ای برای بازخورد اکوسیستم آینده تبدیل کند. |
سرورهای قابل اعتماد برای ضد کلاهبرداری | مفهوم جالب اما به احتمال زیاد نیاز به بررسی بیشتر در مورد موارد استفاده قابل استفاده دارد. | بسته به سطح علاقه ، Chrome ممکن است ایده های بیشتری را در مورد این مفهوم انجام دهد ، و آن را به توضیح دهنده ای برای بازخورد اکوسیستم آینده تبدیل کند. |