گزارش فصلی برای سه ماهه دوم سال 2023، خلاصه ای از بازخورد اکوسیستم دریافت شده در مورد پیشنهادات جعبه ایمنی حریم خصوصی و پاسخ Chrome.
بهعنوان بخشی از تعهدات خود به CMA، Google موافقت کرده است که گزارشهای فصلی فرآیند تعامل با ذینفعان را برای پیشنهادات جعبه ایمنی حریم خصوصی خود به صورت عمومی ارائه کند (به پاراگرافهای 12 و 17(c)(ii) تعهدات مراجعه کنید). این گزارشهای خلاصه بازخورد جعبه ایمنی حریم خصوصی با جمعآوری بازخوردهای دریافتی توسط Chrome از منابع مختلف که در نمای کلی بازخورد فهرست شده است، ایجاد میشوند، از جمله اما نه محدود به: مشکلات GitHub، فرم بازخورد موجود در privacysandbox.com ، جلسات با سهامداران صنعت، و انجمن استانداردهای وب Chrome از بازخوردهای دریافتی از اکوسیستم استقبال می کند و به طور فعال در حال بررسی راه هایی برای ادغام آموخته ها در تصمیمات طراحی است.
مضامین بازخورد بر اساس شیوع در هر API رتبهبندی میشوند. این کار با جمعآوری مقدار بازخوردی که تیم Chrome در مورد یک موضوع خاص دریافت کرده و به ترتیب نزولی از نظر سازماندهی انجام میشود. مضامین رایج بازخورد با بررسی موضوعات بحث از جلسات عمومی (W3C، PatCG، IETF)، بازخورد مستقیم، GitHub و سوالات متداول مطرح شده از طریق تیمهای داخلی Google و فرمهای عمومی شناسایی شدند.
به طور خاص، صورتجلسات جلسات بدنه استاندارد وب بررسی شد و برای بازخورد مستقیم، سوابق Google از جلسات 1:1 ذینفعان، ایمیلهای دریافتی توسط مهندسان فردی، فهرست پستی API و فرم بازخورد عمومی در نظر گرفته شد. سپس گوگل بین تیمهای درگیر در این فعالیتهای ارتباطی مختلف هماهنگ کرد تا شیوع نسبی موضوعات در حال ظهور در رابطه با هر API را تعیین کند.
توضیحات پاسخهای Chrome به بازخورد از پرسشهای متداول منتشر شده، پاسخهای واقعی به مسائل مطرحشده توسط ذینفعان و تعیین موقعیت بهویژه برای اهداف این گزارش گزارش عمومی ایجاد شده است. با توجه به تمرکز فعلی توسعه و آزمایش، سؤالات و بازخوردها به ویژه در رابطه با موضوعات، مخاطبین محافظت شده و APIهای گزارش اسناد دریافت شد.
بازخورد دریافت شده پس از پایان دوره گزارش فعلی ممکن است هنوز پاسخی در نظر گرفته شده برای Chrome نداشته باشد.
واژه نامه کلمات اختصاری
- چیپس
- کوکی هایی که دارای حالت تقسیم شده مستقل هستند
- DSP
- پلتفرم سمت تقاضا
- FedCM
- مدیریت اعتبار فدرال
- FPS
- مجموعه های مهمانی اول
- IAB
- دفتر تبلیغات تعاملی
- بیجاشدگان داخلی
- ارائه دهنده هویت
- IETF
- کارگروه مهندسی اینترنت
- IP
- آدرس پروتکل اینترنت
- openRTB
- مناقصه در زمان واقعی
- OT
- آزمایش مبدا
- PatCG
- گروه اجتماعی فناوری تبلیغات خصوصی
- RP
- حزب اتکا
- SSP
- پلت فرم سمت عرضه
- TEE
- محیط اجرای مورد اعتماد
- UA
- رشته عامل کاربر
- UA-CH
- نکات مشتری عامل کاربر
- W3C
- کنسرسیوم وب جهانی
- WIPB
- کوری IP ارادی
بازخورد عمومی، بدون API/فناوری خاصی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
حاکمیت داده و انطباق با مقررات | راهنمای اکوسیستم در مورد استفاده از جعبه ایمنی حریم خصوصی در انطباق با الزامات قانونی. | مانند هر فن آوری جدید، هر شرکت مسئول اطمینان از این است که استفاده از جعبه ایمنی حریم خصوصی مطابق با قانون است. Google قادر به ارائه مشاوره حقوقی به دیگران نیست. با این حال، ما آگاه هستیم که این یک حوزه کلیدی مورد علاقه برای اکوسیستم است. برای هر API، ما مستندات فنی گستردهای منتشر کردهایم که باید مبنایی را برای ارزیابیهای قانونی لازم فراهم کند، و در حال کار بر روی در دسترس قرار دادن مواد اضافی برای حمایت از تلاشهای شرکتها برای رعایت الزامات نظارتی هستیم. |
پیشنهاد تست کمی CMA | اطلاعات بیشتر در مورد پیشنهاد تست کمی CMA | ما در حال همکاری با CMA هستیم تا آزمایشهایی را طراحی کنیم که تصویری از تأثیر حذف کوکیهای شخص ثالث و معرفی پیشنهادات جعبه ایمنی حریم خصوصی بر روی اکوسیستم ارائه میدهند. در ماه آوریل، CMA راهنمایی های سطح بالا را در مورد آنچه در طول دوره آزمایش و آزمایش انتظار می رود منتشر کرد و سپس راهنمایی های دقیق در ماه ژوئن ارائه شد. ما توصیه می کنیم که سؤالات یا بازخورد در مورد پیشنهاد آزمایش کمی CMA به طور مستقیم با CMA به اشتراک گذاشته شود. |
حالتهای آزمایش با تسهیل کروم | اطلاعات بیشتر و شفاف سازی در مورد برنامه های تست | ما یک پست وبلاگی را در 18 مه منتشر کردیم که در آن اطلاعات بیشتری در مورد دو حالت آزمایش تسهیل شده توسط Chrome به اشتراک گذاشته شد. این جزئیات نهایی نیستند، و با پیشرفت در سه ماهه سوم 2023، دستورالعمل های اجرایی بیشتری را منتشر خواهیم کرد. |
ذخیره سازی پارتیشن بندی شده | آیا از فضای ذخیرهسازی پارتیشنبندی شده در طول آزمایش کروم استفاده میشود؟ | پارتیشن بندی فضای ذخیره سازی قبل از آزمایش منسوخ شدن کوکی های شخص ثالث برای همه کاربران ارسال می شود. بنابراین برای همه بازوهای آزمایش فعال خواهد شد. سایتها میتوانند در این بازه زمانی، یک دوره آزمایشی منسوخ را فعال کنند تا فضای ذخیرهسازی پارتیشن نشده را بازگرداند. |
پشتیبانی تولید | فرآیند Chrome برای پشتیبانی از مشکلات فنی و تشدیدهایی که اکوسیستم را تحت تأثیر قرار میدهند Privacy Sandbox چیست؟ | Google طیف وسیعی از کانالها را فراهم میکند تا به فناوریهای تبلیغاتی اجازه دهد مشکلات را گزارش کنند و هرگونه تشدید لازم را فعال کنند. لطفاً برای اطلاعات بیشتر در مورد تالارهای گفتمان عمومی و خصوصی برای بازخورد و تشدید، پست توسعه دهنده ما را ببینید. |
جدول زمانی ثبت نام | بازه زمانی فعلی برای ثبت نام بسیار کوتاه است | ما هنوز در حال ارزیابی مهلت اجرایی هستیم و میخواهیم از اکوسیستم بشنویم که چه جدول زمانی مناسبتر است. |
شماره DUNS | اطلاعات بیشتر در مورد نیاز شماره DUNS برای ثبت نام و تأیید | شرکت کنندگان می توانند شرایط لازم برای دریافت شماره DUNS را در وب سایت Dun and Bradstreet بیابند. الزامات بسته به بازار متفاوت است، بنابراین شرکت کنندگان باید مطمئن شوند که وب سایت را برای بازار خاصی که به آن علاقه دارند بررسی کنند. آدرس و اطلاعات تماس مالک یا مدیر کسب و کار. همچنین ممکن است از شرکت کنندگان خواسته شود که اطلاعات مالی مانند درآمد سالانه کسب و کار را ارائه دهند. پس از تکمیل درخواست، D&B آن را بررسی می کند و در صورت تایید درخواست، شماره DUNS صادر می کند. |
انتقال از Origin Trial به General Availability | آیا انتقال از Origin Trial به General Availability بر آزمایشکنندههای Origin Trial فعلی تأثیر میگذارد؟ | از ماه جولای، آزمایشکنندگان میتوانند به APIهای مرتبط و اندازهگیری در دسترس عموم دسترسی داشته باشند. این یک همپوشانی بین در دسترس بودن آزمایشی مبدأ و در دسترس بودن عمومی ایجاد می کند. |
مطالعه AdExchanger | اطلاعات بیشتر در مورد روش تحقیق | در این نظرسنجی از پاسخ دهندگان خواسته شد تا نرخ همگام سازی و درآمد کسب و کار خود را تخمین بزنند. روش پاسخ دهندگان برای پاسخ به سؤالات فردی آنها به آنها بستگی داشت. |
مقادیر پارامتر | مقادیر پارامترها مانند سطح نویز، آستانه ناشناس بودن و بودجه حریم خصوصی چگونه تعیین می شوند؟ | این توضیح دهنده GitHub اصول کلی تری را در پشت API های Privacy Sandbox بیان می کند. بسیاری از ارزش ها هنوز در حال نهایی شدن هستند و ما از بازخورد در مورد این موضوع استقبال می کنیم. |
نمایش محتوا و تبلیغات مرتبط
موضوعات
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
حفظ حریم خصوصی | تحقیق در مورد ارزیابی موضوعات API در مورد حفظ حریم خصوصی | ما به طور فعال با جامعه تحقیقاتی درگیر هستیم و تحقیقات خود را در مورد ویژگیهای حریم خصوصی Topics API در مقالات، گزارشها و ارائههای کارگاهی ارائه میکنیم. ما خوشحالیم که اعضای خارجی بیشتری از جامعه تحقیقاتی با این حوزه درگیر هستند. Topics API از کاربران در برابر ردیابی عمومی در وب محافظت می کند و ردیابی کاربران را در مقیاس بسیار دشوار می کند. این مقالات نشان میدهند که ما این کار را با Topics API با موفقیت انجام میدهیم. این کوکی خصوصی تر از کوکی های شخص ثالث است و در حین پشتیبانی از سایت هایی که از بازدید آنها لذت می برند از کاربران محافظت می کند. |
موضوعات طبقه بندی به اندازه کافی دانه بندی نشده است | تاکسونومی موضوعات گسترده شامل موضوعات جزئی تر، از جمله منطقه خاص نیست. | در پاسخ به بازخورد قبلی از اکوسیستم، ما یک پست وبلاگی را در 15 ژوئن منتشر کردیم که در آن یک طبقهبندی به روز شده جدید را که شامل پیشرفتهای متعدد پس از بازخورد اکوسیستم است، شرح میدهد. به عنوان بخشی از کارمان بر روی طبقهبندی اصلاحشده، ما با چندین شرکت در سراسر اکوسیستم، مانند Raptive (سابق CafeMedia) و Criteo درگیر شدهایم. طبقهبندی بهروزرسانی شده دستههایی را که شنیدهایم مفید نیستند حذف میکند، به نفع دستههایی که بهتر با علایق تبلیغکننده مطابقت دارند، در حالی که تعهد خود را برای حذف موضوعات بالقوه حساس حفظ میکنیم. ما اکوسیستم را تشویق می کنیم تا آخرین طبقه بندی را بررسی کند و بازخورد خود را در مورد تغییرات ارائه دهد. |
فرآیند به روز رسانی طبقه بندی و طبقه بندی | اطلاعات بیشتر در مورد تاکسونومی موضوعات و سرعت انتشار طبقهبندیکننده و نحوه آماده شدن شرکتها برای چنین بهروزرسانیهایی. | همانطور که در پست وبلاگ اخیر به اشتراک گذاشته شد، ما انتظار داریم که طبقه بندی در طول زمان تکامل یابد، و در نهایت مدیریت طبقه بندی به یک حزب خارجی که نماینده سهامداران از سراسر صنعت است، تبدیل شود. همچنین طرح رمپ آپ را در گروه اعلام موضوعات به اشتراک گذاشتیم. |
تاثیر بر سیگنال های شخص اول | افزایش تعداد موضوعات در بهروزرسانی اخیر Taxonomy ممکن است بسیار ارزشمند باشد و در نتیجه سایر سیگنالهای مبتنی بر علاقه شخص اول را کاهش دهد. | در گزارش سه ماهه اول 2023، CMA اظهار داشت که "ما درک می کنیم که گوگل در حال بحث در مورد طبقه بندی جدید پیشنهادی خود با چندین شرکت کننده بازار در سراسر زنجیره تامین فناوری تبلیغات بوده است. در حالی که چند ناشر بزرگ گفته اند که کاربرد بیشتر موضوعات فشار رقابتی را افزایش می دهد. راه حل های مبتنی بر داده های شخص اول آنها، دیدگاه اولیه ما این است که کاربرد بیشتر برای رقابت در کل بهتر است - به ویژه برای توانایی ناشران کوچکتر برای ادامه درآمدزایی از موجودی خود پس از منسوخ شدن کوکی های شخص ثالث. دیدگاه ما با این نظر ارائه شده توسط CMA مطابقت دارد. |
سودمندی برای انواع مختلف ذینفعان | فناوریهای تبلیغاتی که بهعنوان SSP و DSP عمل میکنند ممکن است مزایای قابل توجهی نسبت به سایر بازیگران اکوسیستم داشته باشند. | پاسخ ما نسبت به فصل های گذشته بدون تغییر است: «Google به CMA متعهد شده است که پیشنهادات جعبه ایمنی حریم خصوصی را به گونهای طراحی و اجرا کند که با ترجیح دادن خود به کسبوکار Google، رقابت را مخدوش نکند و تأثیر آن را بر رقابت در تبلیغات دیجیتال و ناشران و تبلیغکنندگان، صرف نظر از اندازه آنها ما به همکاری نزدیک با CMA ادامه می دهیم تا مطمئن شویم که کار ما با این تعهدات مطابقت دارد از این نظر بسیار مهم است، به ویژه بازخوردهای خاص و عملی که می تواند به ما در بهبود بیشتر طرح های فنی کمک کند. اطلاعات به فعالان بازار و فرصتی برای اظهار نظر در مورد رویکردهای پیشنهادی." |
موضوعات مربوط به نسل | با توجه به اینکه معیارهای انتخاب موضوع فراوانی بازدید از مرورگر است، آیا تقسیم بندی بخش ها منجر به این می شود که موضوعات بعدی هرگز به بالاترین سطح نخواهند رسید؟ | Chrome در حال حاضر در حال ارزیابی سایر روشهای رتبهبندی، و بررسی سیگنالهای دیگری است که ممکن است رتبهبندی را بهبود بخشد. ما برنامه های اصلاح شده خود را در زمان مناسب به اکوسیستم اطلاع خواهیم داد. |
حساسیت | هدف Topics API باید اطمینان حاصل شود که اطلاعات کاربر بهدستآمده یا مشتقشده از Topics API نسبت به آنچه که میتوان با استفاده از روشهای ردیابی امروزی به دست میآید، حساسیت شخصی کمتری داشته باشد. | ما معتقدیم Topics API به طور قابل توجهی خصوصی تر از فناوری های فعلی است، شناسایی مجدد کاربران را به طور قابل توجهی محدود می کند، و برای حذف موضوعات حساس طراحی شده است. ما تصدیق میکنیم که موضوعات را میتوان با دادههای شخص اول مرتبط یا ترکیب کرد تا دستههای حساس ایجاد شود، اما معتقدیم Topics API گامی رو به جلو برای حفظ حریم خصوصی کاربر است و متعهد به ادامه بهبود API هستیم. |
ساختار طبقه بندی | شناسه، نسخه سازی و سایر ساختارهای ابرداده را به تاکسونومی موضوعات اضافه کنید | در حال حاضر، در پاسخ API، شناسه طبقهبندی را درج میکنیم. همانطور که به سمت حاکمیت بلندمدت پیش می رویم، منطقی است که شی Topics را بررسی کنیم و در صورت نیاز، ابرداده های اضافی را در مورد نسخه سازی اضافه کنیم. |
کنترل ناشر | ناشران باید در مورد موضوعاتی که سایتهایشان باید طبقهبندی شوند، نظر بدهند. | طبقهبندی نادرست سایتها ممکن است باعث شود سیگنال Topics بهعنوان یک سیگنال کلی کمتر مفید باشد، اما سایتهای خاصی که به اشتباه طبقهبندی شدهاند، بیشتر و کمتر از سایر سایتها آسیب نمیبینند. این به این دلیل است که اطلاعات متنی یک سایت همیشه برای مزایده ها در سایت آنها در دسترس خواهد بود، که اطلاعات قابل مقایسه با موضوع صحیح را ارائه می دهد، حتی در صورت طبقه بندی اشتباه. ما از بازخورد در مورد این موضوع در اینجا استقبال می کنیم. اجازه دادن به ناشران برای کنترل طبقه بندی خود خطراتی دارد. سایتها ممکن است به اشتباه سایتهای خود را بهطور عمدی طبقهبندی کنند، کاربرد را برای همه کاهش دهند، یا معانی حساس را در موضوعات کمتر رایج رمزگذاری کنند، و به حریم خصوصی کاربران آسیب بزنند. |
افزونه های کروم | به برنامههای افزودنی Chrome اجازه دهید موضوعات را مدیریت و فیلتر کنند، مشابه برنامههای افزودنی مدیریت کوکیهای کنونی | همانطور که در GitHub مورد بحث قرار گرفت، این باید از قبل امکان پذیر باشد، اما ما از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
انتقال به در دسترس بودن عمومی | آیا هنگام انتقال از Origin Trial به General Availability تأثیری بر روی Topics API خواهد داشت؟ | هیچ داده ای برای کاربرانی که از Origin Trial به General Availability منتقل می شوند، از دست نخواهد رفت. |
حریم خصوصی | نام میزبان ممکن است حاوی اطلاعات خصوصی باشد که ممکن است توسط Topics API فاش شود | همانطور که در اینجا به آن اشاره شده است، تعدادی از اقدامات کاهشی برای تضمین حریم خصوصی داریم. |
تقلب و سوء استفاده | چگونه از دستکاری موضوعات توسط بازدیدهای تقلبی جلوگیری کنیم | موارد کاهش در اینجا توضیح داده شده است . |
طبقه بندی موضوعات | آیا وب سایت ها می توانند درخواست تغییر طبقه بندی موضوعات خود را داشته باشند؟ | ما علاقه مندیم که از اکوسیستم در مورد این موضوع بشنویم و از بازخورد اینجا استقبال می کنیم . |
سایت های ارائه دهنده موضوعات | وبسایتهای خاصی را که میزبان محتوای بسیاری از موضوعات هستند بهعنوان «سایتهای ارائهدهنده موضوعات ویژه» تعیین کنید و طبقهبندیکنندهها را بر اساس برچسبهای ارائهشده در صفحات وب آموزش دهید. | ما در حال بحث در مورد پیشنهاد در اینجا هستیم و از بازخورد اضافی استقبال می کنیم. |
API مخاطب محافظت شده (FLEDGE سابق)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
شکل دهی ترافیک | تأثیر عملکرد فیلتر مبتنی بر SSP برای بهینهسازی بار پرسشها در ثانیه (QPS) | ما زمان قابل توجهی را صرف فکر کردن در مورد شکلدهی ترافیک کردهایم و توصیه این است که SSPها از قابلیت ذخیرهسازی استفاده کنند. |
حجم تست | چالش برانگیز برای آزمایش مخاطبان محافظت شده زیرا SSP ها و DSP ها برای به دست آوردن حجم ترافیک زیاد در تلاش هستند. | ما دائماً شرکای SSP و DSP را برای پذیرش و آزمایش مخاطبان محافظت شده درگیر می کنیم. در دسترس بودن عمومی آغاز شده است و ما مطمئن هستیم که درصد ترافیک با فعال بودن PA آن را برای شرکا برای آزمایش دلپذیرتر می کند. |
پیچیدگی | اجرای راه حل های مخاطب محافظت شده نیازمند تلاش و هزینه های قابل توجهی است. | ما تصدیق میکنیم که استفاده از فناوریهای جدید، از جمله Privacy Sandbox، دشوار است. تیم Privacy Sandbox از نزدیک با طیف وسیعی از ذینفعان برای آموزش و حمایت از تلاشهای آنها کار میکند و به طور مستمر در حال ارزیابی سایر شتابدهندهها برای حمایت از پذیرش اکوسیستم است. |
محیط های اجرایی مورد اعتماد | پشتیبانی از Trusted Execution Environments (TEE) در محیط های ابری غیر عمومی | در حالی که ما در حال بررسی گزینههای پشتیبانی بالقوه فراتر از راهحلهای مبتنی بر ابر هستیم، در حال حاضر پشتیبانی از TEEهای داخلی با توجه به محدودیتهای امنیتی درون محل که نیاز به ارزیابی زمانبر برای Privacy Sandbox دارد، امکانپذیر نیست. با توجه به الزامات امنیتی Privacy Sandbox و چالشهای قابل توجهی که توسط استقرارهای داخلی ارائه میشود، ما معتقدیم که ادامه گسترش و بهبود استقرارهای مبتنی بر ابر (مثلاً پشتیبانی از GCP علاوه بر AWS) برای اکوسیستم بسیار سودمند است. با این حال، ما از بازخورد اضافی در مورد اینکه چرا چنین الزامی ضروری است استقبال می کنیم . |
ساختار هزینه | پیشنهاد خدمات مناقصه و حراج هزینه و پیچیدگی را برای Ad Techs در مقایسه با مدل های سمت مشتری افزایش می دهد. | ما در حال حاضر در حال توسعه راهنمای تخمین هزینه های پشتیبانی از مناقصه و جریان کار حراج در سرور Bidding & Auction هستیم که با استفاده از فناوری تبلیغاتی مرتبط است و یکی از اهداف طرح های ما را برآورده می کند. |
جدول زمانی K-Anon | محدودیت های برنامه ریزی شده k-anonymity چه زمانی در «renderUrl» اعمال می شوند؟ | ما در حال کار بر روی توضیحی برای جدول زمانی اجرایی هستیم که به زودی منتشر خواهیم کرد. |
محدودیت های runAdAuction | آیا کروم میتواند runAdAuction محدود کند تا فقط از صفحه بالا قابل فراخوانی باشد؟ | در حالی که طراحی ما به طور کامل از runAdAuction برای قابل فراخوانی از صفحه بالا پشتیبانی می کند، ما معتقدیم که برای ناشران مضرتر است که آن را محدود کنند که فقط از دامنه بالا قابل فراخوانی باشد.ما به طور خاص از اکوسیستم شنیدهایم که Privacy Sandbox باید بار ناشران و تبلیغکنندگان را به حداقل برساند. این بازخورد با اصل کلی توسعه وب مطابقت دارد که صاحبان سایت می توانند از ابزارهای شخص ثالث در اجرای سایت های خود استفاده کنند. هدف Privacy Sandbox تشویق یک اکوسیستم سالم بدون نیاز به تجویز نحوه کار ناشران و فناوری های تبلیغاتی بوده است. ما معتقدیم که با اجازه دادن به ناشر انتخاب کند که چگونه و چه کسی runAdAuction در سایت خود فراخوانی کند، ما معتقدیم که به ناشران انعطاف پذیری ارائه می دهیم تا بهترین مسیر را برای نیازهای خود پیدا کنند. |
پشتیبانی پیاده سازی | آیا Chrome میتواند یک حراجی چند فروشنده را ایجاد کند یا در اجرای متن باز مشارکت کند؟ | هدف Privacy Sandbox توسعه فناوریهای حفظ حریم خصوصی است که به کوکیهای شخص ثالث یا سایر شناسههای بین سایتی متکی نیستند. ما می خواهیم یک اکوسیستم سالم را بدون نیاز به تجویز نحوه عملکرد فناوری های تبلیغاتی تشویق کنیم. ما راهنمایی در مورد نحوه عملکرد APIها در مخزن GitHub خود منتشر کردهایم و آماده کاوش در راهحلهای صنعت هستیم. ما قصد نداریم پیاده سازی خاصی بسازیم زیرا وظیفه اصلی ما ساخت فناوری های پلت فرم است، نه دیکته کردن استراتژی برای استفاده از آن فناوری ها. فنآوریهای ما به شرکتهای فناوری تبلیغات کمک میکند تا با نردههای محافظ حریم خصوصی مناسب برای مصرفکنندگان، بهترین خدمات را به مشتریان خود ارائه دهند. |
حراج چند فروشنده | آیا Chrome اجباری به اشتراک گذاری یک برنده «مطابقی» با مزایدههای مؤلفه خواهد داشت؟ | Protected Audience API به گونهای طراحی شده است که به طرفهایی که حراج چند فروشنده را آغاز میکنند، این امکان را ارائه دهد که اطلاعات را به مزایده مؤلفه منتقل کنند (توجه: فقط قبل از شروع حراج). با این حال، ما هیچ راهی برای مرورگر نمی بینیم که تشخیص دهد آیا یک قطعه اطلاعات برنده متنی است یا خیر، بنابراین نمی توانیم مسدود کردن یا نیاز به اطلاعات خاص را اعمال کنیم. |
اولویت کاربر برای ردیابی رضایت | Adtech از PA می پرسد که چگونه ردیابی رضایت کاربر را به درستی پیاده سازی کند | پاسخ ما شامل آنچه در Q1 گفتیم است: "برای تبلیغات خاص، فناوری تبلیغات مربوطه بهترین طرفی است که می تواند کنترل هایی را در مورد اینکه کدام خلاقیت ها نشان داده می شوند یا نحوه انتخاب آنها ارائه می دهد." ما تعدادی از سناریوهای مرتبط با این موضوع را در جلسه مه WICG مورد بحث قرار دادیم و از بازخورد و بحث بیشتر در مورد این موضوع استقبال می کنیم. |
مخاطبان سفارشی | آیا موارد استفاده SSP مربوط به ایجاد مخاطبان سفارشی توسط Protected Audience API پشتیبانی می شود؟ | Protected Audience API به SSPها و سایر ارائه دهندگان فناوری تبلیغاتی اجازه می دهد تا مخاطبان سفارشی را داشته باشند و مدیریت کنند. راهنمایی بیشتر در مورد نحوه ادغام یک SSP با API PA در حال توسعه است و برای SSPها و سایر ارائه دهندگان فناوری تبلیغات برای حمایت از تلاش های یکپارچه سازی آنها در دسترس قرار خواهد گرفت. |
فرمت ها | آیا ویدیو توسط Protected Audience API پشتیبانی می شود؟ | تبلیغات ویدیویی به یکی از دو روش ارائه میشوند: بهعنوان VAST XML یا HTML (یک تبلیغ خارج از جریان که در نهایت ممکن است VAST XML را در پخشکننده ویدیو نیز بارگیری کند). خریداران می توانند هر کدام از قالب ها را از طریق یک renderURL برگردانند. مشخصات VAST اخیراً برای پشتیبانی از Attribution Reporting API به روز شده است. سایتهایی که تبلیغات ویدیویی ارائه میکنند باید برای نحوه ارائه تبلیغات از طریق API مخاطب محافظتشده آماده شوند. این بدان معنی است که مطمئن شوید برچسبهای مکان میتوانند URL را از یک iframe مخاطب محافظتشده به پخشکننده ویدیو منتقل کنند. برای قابهای حصاردار، ما برای رفع نیازهای ویدیویی پیش از نیاز به استفاده از قابهای حصاردار که زودتر از سال 2026 نیست، کار خواهیم کرد. |
قدم زدن | نحوه استفاده Pacing با API مخاطب محافظت شده چگونه کار می کند؟ | ما از بازخورد قدردانی می کنیم. ما علاقه مند هستیم که نمونه های بیشتری از این درخواست را با جزئیات بیشتر از شرکای SSP بیشتری ببینیم زیرا این موضوع تا به امروز بیشتر یک نگرانی DSP بوده است. |
فرکانس به روز رسانی | تعداد تماسها از dailyUpdate (حداکثر 1 تماس برای هر گروه علاقهمند در روز) ممکن است برای موارد استفاده خاص، مانند بهروزرسانی اطلاعات محصول، کافی نباشد. | ما از بازخورد قدردانی می کنیم. راهحلهای دیگری نیز وجود دارد که به فناوریهای تبلیغاتی اجازه میدهد از سیگنالهایی استفاده کنند که در آهنگهای مختلف مانند جستجوی K/V بهروزرسانی میشوند. |
کنترل کیفیت تبلیغات | ناشران چگونه کنترل کیفیت تبلیغات را اجرا می کنند؟ | امروزه، Protected Audience API عملکردی را برای ناشران ارائه میدهد تا SSPهای خود را در مورد کنترلهای خاصی که میتوانند به عنوان بخشی از پیکربندی حراج ایجاد کنند، قبل از پیشنهاد (یعنی فهرستهای رد بر اساس برچسبهای مرتبط با تبلیغات) ایجاد کنند. ما از بازخورد در مورد هر عملکرد اضافی که اکوسیستم ممکن است نیاز داشته باشد استقبال می کنیم. |
اشکال زدایی | چه زمانی عملکرد forDebuggingOnly حذف می شود؟ | ما قصد داریم برای forDebuggingOnly برای رویدادهای از دست دادن با منسوخ شدن کوکی شخص ثالث بازنشسته شویم. ما قصد داریم برای forDebuggingOnly برای رویدادهای پیروزی در سال 2026 بازنشسته شویم. |
گروه های علاقه متقابل دستگاه | پیشنهاد برای فعال کردن گروههای علاقه بین دستگاهی برای نمایندگان کاربر تأیید شده | ما در حال ارزیابی این پیشنهاد هستیم، اما ویژگی بالای هدفگیری بین دستگاهها نگرانیهای مهمی را در خصوص حریم خصوصی ایجاد میکند، همانطور که در این شماره GitHub مورد بحث قرار گرفت. |
(همچنین در Q1 گزارش شده است) بازاریابی مجدد پویا | آیا پس از منسوخ شدن کوکی های شخص ثالث، بازاریابی مجدد پویا همچنان با API مخاطب محافظت شده امکان پذیر خواهد بود؟ | ما معتقدیم که این مورد استفاده با استفاده از مخاطب محافظت شده، همانطور که در اینجا توضیح داده شده است ، امکان پذیر است. |
روی داده های مرتبط کلیک کنید | داده های مربوط به کلیک را به browserSignals. | ما در حال حاضر در حال توضیح در مورد اینکه چه زمانی کلیک برای ارائه یک موقعیت اولیه رخ داده است، می خواهیم. |
(همچنین در سه ماهه چهارم 2022 گزارش شده است) توابع تعریف شده توسط کاربر در مخاطبین محافظت شده | چگونه توابع تعریف شده توسط کاربر (UDF) در API مخاطبان محافظت شده پشتیبانی می شوند؟ اینها توابعی هستند که می توانند توسط کاربران نهایی برای گسترش عملکرد API برنامه ریزی شوند. | تکنسین تبلیغاتی که این موضوع را مطرح کرد همچنین اشاره کرد که آنها هنوز در حال ارزیابی کارهایی هستند که می توانند با UDF انجام دهند، بنابراین هنوز هیچ بازخورد عملی در اینجا وجود ندارد که بتوان به آن واکنش نشان داد، حداقل تا زمانی که در دسترس بودن عمومی باشد. |
ارز | مبالغ ارز نباید با استفاده از امتیاز شناور نمایش داده شود. | ما در اینجا به طور مفصل به این موضوع پرداختیم. |
قابلیت انتخاب آگهی غیر DSP | سرورهای تبلیغاتی چه نقشی در حراج های Protect Audience API ایفا می کنند؟ | ما از درخواستهای سرورهای تبلیغاتی برای ادامه ارائه خدمات انتخاب آگهی پس از مناقصه / بهینهسازی خلاقیت پویا آگاه هستیم. ما در حال حاضر در حال ارزیابی تجزیه و تحلیل شکاف دقیقی هستیم که بین API مخاطب محافظتشده فعلی و این درخواستها وجود دارد. |
GenerateBid | از پیشنهاد Google Ads برای بازگرداندن بیش از یک آگهی نامزد به ازای هر گروه مورد علاقه از generateBid و امتیازدهی آن نامزدها در «scoreAd» پشتیبانی کنید. | این در حال حاضر در حال ارزیابی است. ما از بازخورد اضافی در اینجا استقبال می کنیم. |
سفارش حراج | آیا لازم است که حراج های API مخاطب محافظت شده آخرین موردی باشد که اجرا می شود تا بتواند از نتیجه همه حراج های دیگر ورودی بگیرد؟ | هیچ الزام فنی برای آخرین اجرا API مخاطب محافظت شده وجود ندارد. |
ناوبری غیر کاربر آغاز شده است | ناوبری غیر کاربر را در معرض نمایش قرار دهید | ما در حال بررسی این درخواست و بحث در مورد آن در اینجا هستیم و از بازخورد اضافی استقبال می کنیم. |
ذخیره سازی | اگر وضعیت کاربر تغییر کند، SSP نباید سیگنالهای perBuyerSignals یک DSP را از یک کش بسازد. | ما میدانیم که حافظه پنهان برای هر موردی برای سیگنالهای perBuyer کار نمیکند و در حال ارزیابی گزینههای بیشتر هستیم. ما از هرگونه بازخورد اضافی از اکوسیستم در مورد اینکه آیا حافظه پنهان برای موارد استفاده آنها کار می کند یا خیر، استقبال می کنیم. |
گزارش اسناد و مخاطب محافظت شده | چگونه API گزارش Attribution و API مخاطب محافظت شده با هم کار می کنند؟ | در حال حاضر یکپارچهسازیها برای API مخاطب محافظتشده برای هر دو حالت API Reporting Attribution (گزارشهای خلاصه و سطح رویداد) در دسترس هستند. ما اطلاعات بیشتری در مورد بهبود یافته API مخاطبین محافظت شده و ادغام Attribution Reporting در تاریخ 1 ژوئن به اشتراک گذاشتهایم. میتوانید در مورد آنها اینجا بخوانید . |
نقطه پایانی سرور | آیا نقطه پایانی سرور در طراحی نهایی سرور جمعآوری مورد اعتماد خواهد بود؟ | نقطه پایانی سرور یک نقطه پایانی با فناوری تبلیغاتی است که مستقل از سرورهای تراکم اعتماد مورد استفاده برای پردازش گزارشهای جمعآوریشده و تبدیل شده است. در حال حاضر هیچ تغییری برای نقطه پایانی گزارش برنامه ریزی نشده است. هدف طراحی فعلی این است که اطمینان حاصل شود که گزارشهای جمعآوریشده (با بارهای رمزگذاریشده) دادههای بینسایتی را درز نمیکنند، بنابراین یک نقطه پایانی قابل اعتماد لازم نیست. یک عارضه دیگر این است که فناوری های تبلیغاتی مختلف احتمالاً استراتژی های دسته بندی مورد نظر متفاوتی خواهند داشت. ما از بازخورد اضافی در اینجا استقبال می کنیم. |
WebIDL | مشخصات API مخاطب محافظت شده فعلی با مشخصات WebIDL سازگار نیست. | ما در حال ارزیابی این بازخورد و بحث در مورد موضوع در اینجا هستیم. |
مدیریت رضایت | نحوه عبور سیگنال رضایت در API مخاطب محافظت شده چگونه انجام می شود؟ | اطلاعات متنی در محدوده API مخاطب محافظت شده نیست. ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی استقبال می کنیم. |
بازاریابی مبتنی بر حساب | آیا موارد استفاده از بازاریابی مبتنی بر حساب امکان پذیر است؟ | Protected Audience API از انواع موارد استفاده بازاریابی مبتنی بر مخاطب پشتیبانی می کند. ما همچنان به درک اینکه چگونه API مخاطب محافظت شده میتواند این مورد خاص را به بهترین شکل پشتیبانی کند، ادامه میدهیم و از بازخورد اضافی در مورد این موضوع از اکوسیستم استقبال میکنیم . |
حراج قطعات | شرکت کنندگان در حراج قطعات چه امتیازی می گیرند؟ | حراج های مؤلفه مستقیماً به گروه های علاقه امتیاز نمی دهند - بلکه آنها به تبلیغات و پیشنهاداتی که یک DSP از تابع generateBid ارسال می کند امتیاز می دهند. تابع generateBid() به ازای هر گروه علاقه اجرا می شود و DSP هنگام اجرای generalBid موارد زیر را برمی گرداند: return { 'ad': adObject, 'adCost': optionalAdCost, 'bid': bidValue, 'render': renderUrl, 'adComponents': [adComponent1, adComponent2, ...], 'allowComponentAuction': false, 'modelingSignals': 123}; } |
مشارکت های خارجی | درخواست برای پشتیبانی از مشارکتهای خارجی در پایگاه کد GitHub سرور Key/Value. | ما به دنبال به روز رسانی فرآیندهای مربوطه خود برای پشتیبانی از مشارکت های خارجی در کد GitHub هستیم. |
اندازه گروه مورد علاقه | حداکثر تعداد کلیدهایی که IG می تواند پشتیبانی کند چقدر است؟ | محدودیت فعلی 50 کیلوبایت در اندازه یک IG است و کلیدها به عنوان بخشی از آن محسوب می شوند. ما از بحث بیشتر در مورد محدودیت اندازه استقبال می کنیم. |
دسته بندی | چگونه می توان تعداد تماس های سرور K/V را کاهش داد؟ | می توانید از هدرهای HTTP Cache-Control برای کاهش تعداد تماس های K/V استفاده کنید. برای مثال، میتوان آن را در حراجهای مؤلفهها و همچنین در میان جایگاههای تبلیغاتی در یک صفحه ذخیره کرد. |
کنترل نسخه | پشتیبانی از چندین نسخه کد تبلیغاتی | خدمات مناقصه و مزایده از نسخه های متعدد کد تبلیغاتی پشتیبانی می کند. در Bidding and Auction API، درخواست SelectAd می تواند نسخه کد مورد استفاده برای درخواست حراج (یعنی برای مناقصه / حراج و همچنین گزارش) را مشخص کند. |
فضای ذخیره سازی مشترک | در سرویس مزایده و مزایده از نوشتن به ذخیرهسازی مشترک پشتیبانی کنید. | در حال حاضر، Bidding and Auction Services از ذخیرهسازی مشترک پشتیبانی نمیکند، اما از بازخورد اضافی درباره اینکه چرا چنین موارد استفاده برای اکوسیستم مهم هستند، استقبال میکنیم. |
وب به برنامه | از اشتراک گذاری وب به برنامه گروه های علاقه مند پشتیبانی کنید. | وب به برنامه در حال حاضر در استقرار API مخاطب محافظت شده در کروم و اندروید گنجانده نشده است، اما ما علاقه مندیم که از اکوسیستم درباره اهمیت این مورد استفاده بشنویم. |
K-ناشناس بودن | نحوه رسیدگی به بک گراندهای K-Anonymity | ما در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی استقبال می کنیم. |
اندازه گیری تبلیغات دیجیتال
گزارش انتساب (و سایر APIها)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تنظیمات گزارش سطح رویداد VTC جایگزین | بازخورد در مورد پیکربندیهای گزارش سطح رویداد VTC جایگزین | ما بازخوردهایی شنیدهایم مبنی بر اینکه پیکربندیهای سطح رویداد فعلی بهینه نیستند و ما در مورد تنظیمات جهانی بهینه بازخورد میخواهیم. ما آماده بازخورد اضافی در این زمینه هستیم و فکر می کنیم که توضیح دهنده انعطاف پذیر در سطح رویداد ما به این موضوع نیز کمک می کند. |
پیکربندی های انعطاف پذیر در سطح رویداد | وضعیت ویژگی پیکربندیهای سطح رویداد انعطافپذیر چگونه است؟ | ما اسنادی را در مورد پیکربندی انعطاف پذیر در سطح رویداد به اشتراک گذاشته ایم. این ویژگی هنوز در مرحله پیشنهاد است و ما به دنبال بازخورد بیشتری در مورد اینکه آیا این ویژگی برای اکوسیستم ارزشمند خواهد بود یا خیر. |
پیکربندی های انعطاف پذیر در سطح رویداد | چگونه می توان گزارش های متناقض از طرف های مختلف را با هم تطبیق داد؟ | بیشتر سناریوهای گزارشدهی از طریق استفاده از گزارشهای انبوه مورد بررسی قرار میگیرند، در حالی که پیشنهاد پیکربندی سطح رویداد انعطافپذیر بهطور خاص برای انعطافپذیری بیشتر برای گزارشهای سطح رویداد است، که اغلب برای موارد استفاده بهینهسازی استفاده میشود. ما از هرگونه نظر/بازخورد اکوسیستم اضافی در رابطه با این سناریو استقبال می کنیم. |
ثبت منبع | اگر ثبت منبع پس از ثبت تریگر اتفاق بیفتد، چه؟ | در حال حاضر، اگر ثبت منبع پس از ثبت تریگر اتفاق بیفتد، منبع و ماشه نمی توانند به یکدیگر نسبت داده شوند. به نظر می رسد این یک سناریوی حاشیه ای باشد. ما از هر گونه بازخورد اضافی در مورد این موضوع استقبال می کنیم و در صورت سناریویی که به نظر می رسد بسیاری از فناوری های تبلیغاتی با آن مواجه هستند، به دنبال آن هستیم. |
کار با چندین آژانس تبلیغاتی | وقتی یک تبلیغکننده با آژانسهای تبلیغاتی متعدد کار میکند، DSPها چگونه میتوانند از API گزارش Attribution استفاده کنند؟ | API از تغییر مسیرها پشتیبانی می کند و بنابراین می تواند حتی زمانی که یک تبلیغ کننده با چندین آژانس تبلیغاتی کار می کند، استفاده شود. علاوه بر این، محدودیتهایی در مورد تغییر مسیرها وجود دارد تا اطمینان حاصل شود که API حریم خصوصی را بهبود میبخشد. ما همچنین یک راهحل بالقوه با استفاده از API ذخیرهسازی مشترک برای سناریوی خاصی که فناوری تبلیغات مطرح کرده است، شناسایی کردهایم. ما از هرگونه بازخورد اضافی در مورد این سناریو استقبال می کنیم و بر اساس آن بازخورد به تکرار ادامه می دهیم. |
محدودیت های مقصد | مورد استفاده از آگهیهای بازخوانی خودکار ممکن است تحت تأثیر محدودیتهای مقصد قرار گیرد. | ما این موضوع را در جلسه WICG در 1 مه مورد بحث قرار دادیم و به دنبال بازخورد در مورد محدودیت معقول هستیم. ما به گزارش Attribution با توضیح گزارشهای سطح رویداد اضافه کردهایم که بیان میکند که مرورگر میتواند تعداد eTLD+1 «مقصد» را که توسط سایتهای منبع ارائه میشوند محدود کند. (به درخواست کشش مراجعه کنید). |
گزارش اسناد و مخاطب محافظت شده | چگونه API گزارش Attribution و API مخاطب محافظت شده با هم کار می کنند؟ | در حال حاضر یکپارچهسازیها برای API مخاطب محافظتشده برای هر دو حالت API Reporting Attribution (گزارشهای خلاصه و سطح رویداد) در دسترس هستند. ما اطلاعات بیشتری در مورد بهبود یافته API مخاطبین محافظت شده و ادغام Attribution Reporting در تاریخ 1 ژوئن به اشتراک گذاشتهایم. میتوانید در مورد آنها اینجا بخوانید . |
پیکربندی های انعطاف پذیر در سطح رویداد | اکنون که پارامترها قابل تنظیم هستند، بهترین روش ها برای شبیه سازی نویز را به اشتراک بگذارید. | ما کدی را در GitHub به اشتراک گذاشتهایم که هر کسی میتواند از آن برای ارزیابی افزایش اطلاعات و تأثیر نویز برای هر پیکربندی انعطافپذیر در سطح رویداد که میخواهد استفاده کند، استفاده کند. ما علاقه مند به شنیدن نظرات هر کسی هستیم که می خواهد با کد آزمایش کند و مایل است بازخورد خود را به اشتراک بگذارد. |
اندازه گیری اسناد بین برنامه و وب | چه زمانی اندازه گیری اسناد بین برنامه ای و وب در دسترس خواهد بود؟ | ما در 9 مه آزمایشی را برای اندازهگیری اعتبار بین برنامهها و وب از طریق API گزارش اسناد اعلام کردیم. در حالی که در دسترس بودن عمومی برای ارتباط و اندازهگیری API در Chrome 115 برنامهریزی شده است، در حال حاضر برنامهریزی نشده است که اندازهگیری اعتبار بین برنامهها و وب با Chrome 115 در دسترس عموم قرار گیرد. |
تبدیلها را کپی کنید | چگونه می توان راه حل های اندازه گیری مستقل را با ARA تطبیق داد؟ | همانطور که با روش استاندارد فعلی ، تبلیغ کنندگان با یک ارائه دهنده اندازه گیری مستقل شخص ثالث برای گزارش های تبدیل تبدیل به کار می کنند. ما منابعی را در مورد چگونگی اختصاص دادن تبدیل برای گزارش سطح رویداد ارائه داده ایم. |
از دست دادن داده ها در هنگام به روزرسانی های پایگاه داده گزارش انتساب | آیا هنگامی که Chrome پایگاه داده گزارش انتساب را به روز می کند ، از دست دادن داده ها وجود خواهد داشت؟ | با شروع Chrome Stable 115 ، ما به طور پیش فرض امکان API های ارتباط و اندازه گیری را برای بخشی از کاربران Chrome شروع خواهیم کرد. این در دسترس بودن عمومی به عنوان ما نظارت می کنیم تا مسائل احتمالی را کنترل کنیم. هدف این خواهد بود که طی یک دوره از هفته ، توسط Q3 2023 به 100 ٪ در دسترس بودن برسد. از ماه ژوئیه ، آزمایش کنندگان قادر به ثبت نام برای دسترسی به این API ها به طور کلی در دسترس هستند. این امر همپوشانی بین در دسترس بودن آزمایش مبدا و در دسترس بودن عمومی از طریق ثبت نام فراهم می کند. نشانه محاکمه منشاء شما تا 19 سپتامبر معتبر خواهد بود ، اما توصیه می کنیم قبل از انقضا برای API ها ثبت نام کنید تا یکپارچه از محاکمه مبدا خارج شوید بدون اینکه هرگونه آزمایش مداوم را قطع کنید. همانطور که در این اطلاعیه ذکر شد ، داده های ثبت شده از نسخه های قدیمی تر (M113 و قبل از آن) پس از بروزرسانی منتقل نمی شوند ، بنابراین ممکن است از دست دادن داده ها وجود داشته باشد. این از دست دادن داده ها در گزارش اشکال زدایی نشان داده نمی شود ، و ما سعی خواهیم کرد از از دست دادن داده ها از 114 به 115 جلوگیری کنیم. |
صورتحساب | با استفاده از گزارش انتساب برای صورتحساب هزینه در هر نتیجه | همانطور که در این مقاله بیان شد ، API گزارش انتساب ممکن است برای نیازهای صورتحساب هزینه در هر نتیجه مناسب نباشد ، به دلیل سر و صدای اضافه شده به گزارش های سطح و خلاصه. ما بازیکنان اکوسیستم را تشویق می کنیم تا در مورد تأثیر مدل های مختلف صورتحساب توسط API گزارشگر API در GitHub ، بازخورد خود را به اشتراک بگذارند. |
سرویس تجمیع
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
گزارش تجمعی تغییر تأخیر تغییر | واکنشهای مثبت به پیشنهاد تغییر تأخیر گزارش قابل جمع شدن از [10-60 دقیقه] به [0-10 دقیقه] پس از بازخورد از اکوسیستم | ما خوشحالیم که شاهد واکنش مثبت نسبت به تغییر پیشنهادی هستیم و اکوسیستم را ترغیب می کنیم تا همچنان به ارائه بازخورد در مورد پیشنهادات خود ادامه دهیم. |
راه حل پیش فرض | آیا می توان سرویس جمع آوری را در مراکز داده پیش فرض مستقر کرد؟ | در حالی که ما در حال بررسی گزینه های بالقوه پشتیبانی فراتر از راه حل های مبتنی بر ابر هستیم ، در حال حاضر پشتیبانی از TEE های پیش فرض با محدودیت های امنیتی پیش فرض که نیاز به ارزیابی وقت گیر برای ماسهبازی حریم خصوصی دارد ، امکان پذیر نیست. با توجه به الزامات امنیتی Sandbox حریم خصوصی و چالش های مهم ارائه شده توسط استقرار در پیش فرض ، ما معتقدیم که ادامه گسترش و بهبود استقرار های مبتنی بر ابر (به عنوان مثال پشتیبانی از GCP علاوه بر AWS) برای اکوسیستم مفیدترین است. با این حال ، ما از بازخورد اضافی در مورد اینکه چرا چنین الزامی ضروری است استقبال می کنیم . |
گزارش های پردازش مجدد برای دوره های زمانی مختلف | امکان پردازش گزارش ها برای دوره های زمانی مختلف | ما درخواست های مشابهی را شنیده ایم تا بتوانیم دسته ای را برای محدوده های مختلف تاریخ تقسیم کنیم. یک پیشنهاد این است که امکان گسترش شناسه مشترک با یک برچسب تعریف شده از فناوری را فراهم می کند تا گزارش ها به دسته های مختلف تقسیم شوند. ما در مراحل اولیه ارزیابی این فرآیند هستیم و با تکامل این پیشنهاد ، اکوسیستم را به روز می کنیم. |
پیامدهای حریم خصوصی محیط اجرای قابل اعتماد | احساسات مثبت نسبت به پیامدهای حریم خصوصی محیط های اجرا قابل اعتماد | ما خوشحالیم که از واکنش های مثبت اکوسیستم در مورد پیشنهادات خود می شنویم و از بازخورد اضافی استقبال می کنیم که همچنان به تکرار و توسعه می پردازیم. |
شرایط خدمات | مهلت پذیرش شرایط خدمات جمع آوری چیست؟ | در حالی که ما هنوز مهلت پذیرش شرایط و ضوابط را مشخص نکرده ایم ، ما شرکت های اکوسیستم را ترغیب می کنیم تا در اسرع وقت شرایط و ضوابط را بپذیرند تا از تأخیر در ثبت نام جلوگیری کنیم. ما شرکت ها را ترغیب می کنیم که در صورت داشتن هر گونه سؤالی ، به این نتیجه برسند. |
کشف کلیدی | ویژگی کلیدی کشف ، آزمایش کنندگان را قادر می سازد تا گزارش های کل را بدون نیاز به لیست صریح ترکیبات کلیدی احتمالی به منظور پردازش گزارش های خلاصه برای انتساب شبکه متقابل برای بهبود عملکرد و صحت ، پرس و جو کنند. | ما در حال حاضر در حال بررسی راه حل ها و راه حل های احتمالی هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
API تجمع خصوصی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
گزارش دهنده | منشأ گزارش چگونه تعریف می شود؟ | گزارش منشأ همیشه منشأ فیلمنامه تماس گیرنده جمع آوری خصوصی است. |
فضای کلید 128 بیتی | وضوح در محدودیت فضای کلیدی 128 بیتی | ما این محدودیت فضای کلید را واضح تر می کنیم و ناسازگاری ها را در صفحات برطرف می کنیم. توصیه می کنیم از استراتژی های هیدی برای ماندن در این فضای کلیدی استفاده کنید. |
حداکثر سهم در هر گزارش | حد فعلی 20 مشارکت در هر گزارش خیلی کم است. | به جای افزایش حداکثر تعداد مشارکت ، ما به جای کوتاه کردن در حد مجاز ، در نظر داریم گزارش های تقسیم شده را در نظر بگیریم. ما با تکامل این پیشنهاد ، اکوسیستم را درگیر خواهیم کرد. |
به گزارشگری برسید | درخواست برای گزارش متقابل/گزارش متقابل. Reach یک معیار اساسی تبلیغات برند است. تبلیغ کنندگان برای تجزیه و تحلیل کمپین های خود و تخصیص هزینه به تقریب های متقابل/متقاطع برای گزارش و گزارش فرکانس متکی هستند. مدل های REACH از کوکی های شخص ثالث به عنوان سیگنال اندازه گیری تبلیغات نشان داده شده در محیط های شخص ثالث استفاده می کنند ، بنابراین تکنیک های تبلیغاتی پس از کاهش کوکی های شخص ثالث درخواست راه حل جایگزین کرده اند. | تیم Sandbox حریم خصوصی در حال بررسی ویژگی هایی برای پشتیبانی از روشهای دستیابی به دامنه متقابل پس از استهلاک کوکی شخص ثالث است. ما از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
ردیابی پنهانی را محدود کنید
کاهش نماینده کاربر/نکات مشتری عامل کاربر
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در Q1 2023 گزارش شده است) نکات مربوط به فاکتورهای شکل اضافی | درخواست نکات مشتری عامل کاربر (UA-CH) برای ارائه فاکتورهای فرم اضافی مانند تلویزیون ، VR | ما هنوز در حال کار بر روی برخی از تصمیمات کلیدی طراحی هستیم (خواه یک مقدار واحد مانند "تلویزیون" یا لیستی از قابلیت های فاکتور فرم را ارائه دهیم) ، اما به نمونه سازی این ایده علاقه مند هستیم . |
بودجه حریم خصوصی | محدودیت های بودجه حریم خصوصی می تواند باعث شود درخواست های UA-CH در صورت ارسال بیش از حد درخواست ها ، غیر تعیین کننده شوند. | ما در حال حاضر هیچ به روزرسانی جدیدی در مورد پیشنهاد بودجه حریم خصوصی نداریم ، اما ما متعهد شده ایم که قبل از کاهش کوکی های شخص ثالث ، درخواست نکات مشتری UA را محدود نکنیم. |
سازگاری سایت | وب سایت ها از مارک UA-CH برای محدود کردن مرورگرهای خاص از دسترسی به سایت ها استفاده می کنند. | موارد استفاده معتبری برای داشتن لیست برند وجود دارد و یکی از آنها دقیقاً سازگاری است. UA رایگان است که چندین مارک برای کار در این زمینه ها داشته باشد. |
محافظت از IP (قبلاً Gnatcatcher)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
کلاهبرداری و سوء استفاده | چگونه شرکت ها می توانند اقدامات ضد کلاهبرداری را با محافظت از IP تنظیم کنند؟ | ما اهمیت موارد استفاده ضد کلاهبرداری و تأثیر احتمالی آن موارد استفاده را درک می کنیم. ما قصد داریم در اواخر تابستان امسال جزئیات بیشتری را در مورد حمایت از ضد کلاهبرداری منتشر کنیم. ما به دنبال بازخورد اکوسیستم هستیم که چگونه می توانیم از موارد استفاده ضد کلاهبرداری بهتر پشتیبانی کنیم. |
GeoIP | اطلاعات بیشتر در مورد جدول زمانی آزمایش و استقرار برای GEOIP | Chrome اخیراً اطلاعات جدیدی را منتشر کرده است که جزئیات برنامه های GEOIP ما را نشان می دهد. ما در حال برنامه ریزی برای انتشار اطلاعات بیشتر در مورد جدول زمانی استقرار در Q3 هستیم. ما انتظار داریم که در ابتدا در درصد کمی از ترافیک ، از IP محافظت کنیم. دلیل این امر این است که ما می دانیم که این پیشنهاد ممکن است تغییرات مهمی را برای شرکت ها شامل شود و ما می خواهیم به اکوسیستم زمان برای تنظیم و ارائه بازخورد قبل از اینکه این ویژگی به طور گسترده تر پخش شود ، ارائه دهیم. |
احراز هویت حساب | چگونه احراز هویت حساب با سرور پروکسی دقیقاً کار خواهد کرد؟ | ما قصد داریم اواخر تابستان امسال جزئیات بیشتری را در مورد تأیید اعتبار حساب منتشر کنیم ، اگرچه ما قبلاً ملاحظات اولیه را به اشتراک گذاشته ایم. |
کاهش ردیابی گزاف گویی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
راهنمایی تست | اطلاعات در مورد نحوه آزمایش کاهش ردیابی گزاف گویی | ما یک وبلاگ در ماه مه با اطلاعات بیشتر در مورد نحوه آزمایش کاهش ردیابی گزاف گویی منتشر کردیم. |
مستندات | وضوح در پیشنهاد ردیابی گزاف گویی | پیشنهاد فعلی بسیار کار در حال پیشرفت است و Chrome همچنان به روزرسانی این پیشنهاد را برای ارائه وضوح و اطلاعات به اکوسیستم ادامه می دهد. ما در حال ارائه جزئیات بیشتر هستیم و از هرگونه بازخورد اضافی استقبال می کنیم. |
حذف کوکی | آیا کاهش ردیابی همه کوکی ها را در یک دامنه حذف می کند؟ | همانطور که در اینجا توضیح داده شده است ، کاهش ردیابی Bounce (BTM) تمام ذخیره و حافظه نهان را پاک می کند. |
دور زدن ردیابی گزاف گویی | طبقه بندی ردیاب Bounce ممکن است با انجام تغییر مسیر با پاپ آپ یا زبانه های جدید دور شود. | مشخصات کاهش ردیابی گزاف گویی هنوز کار در حال انجام است. ما تاکنون بیشتر روی تغییر مسیر همان تابین متمرکز شده ایم اما قصد داریم در آینده روی جریان های پاپ آپ کار کنیم. ما در اینجا از بازخورد اضافی استقبال می کنیم. |
بودجه حریم خصوصی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
مجاورت هدف قرار دادن | بودجه حریم خصوصی ممکن است موارد استفاده از هدف را تحت تأثیر قرار دهد. | ما در مورد این موضوع بازخورد دریافت کرده ایم و علاقه مند به شنیدن بیشتر در مورد تأثیرات احتمالی اکوسیستم هستیم. |
مرزهای حفظ حریم خصوصی سایت را تقویت کنید
ست های شخص اول
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در سه ماهه قبلی گزارش شده است) حد دامنه | درخواست گسترش تعداد حوزه های مرتبط | Chrome در حال ارزیابی حد عددی مناسب برای زیر مجموعه های مرتبط است که باعث حفظ حریم خصوصی و ابزار برای موارد استفاده شده است. از همان ابتدا ، Chrome به اشتراک گذاشت که تعداد دقیق زیر مجموعه مرتبط هنوز نهایی نشده است. |
مورد استفاده جاسازی شده | پشتیبانی از موارد استفاده جاسازی شده که به مجموعه های شخص اول ، تراشه ها و ذخیره سازی مشترک نیاز دارند | Chrome بازخورد این مورد را دریافت کرده است و تیم در حال بررسی و استقبال از بازخورد اضافی است. |
مدیریت مخازن | در صورت وجود اختلافات یا غفلت ، اطلاعات مربوط به خط مشی برای حذف مجموعه های شخص اول از مخزن GitHub | Chrome بازخورد این مورد را دریافت کرده است. این تیم در حال تحقیق است و از بازخورد اضافی استقبال می کند. |
آموزش کاربر | Chrome باید آگاهی و درک کاربر از مجموعه های شخص اول را برای هدایت فرزندخواندگی افزایش دهد. | Chrome متعهد به آموزش کاربران در مورد مجموعه های شخص اول است و یک مقاله مرکز راهنما (مرتبط با UI Chrome) را برای این منظور منتشر کرده است. Chrome همچنین در ادامه یادگیری نحوه آموزش بهترین کاربران در زمینه های مناسب سرمایه گذاری می شود. |
ارسال 3 عدد | کوکی های شخص ثالث پس از استهلاک کوکی های شخص ثالث ، در یک مجموعه شخص اول وجود خواهند داشت. | در حالی که requestStorageAccess و requestStorageAccessFor در واقع کوکی های شخص ثالث را دوباره برای موارد استفاده خاص و کاملاً تعریف شده در دسترس قرار می دهند ، آنها اکنون به جای اینکه به طور پیش فرض در دسترس باشند ، مانند وضعیت فعلی کوکی های شخص ثالث ، به دعوت فعال توسط سایت نیاز دارند (در کروم).در حالی که این دعوت در یک مجموعه واحد نیازی به تأیید کاربر نخواهد داشت ، کاربران با انتخاب این رفتار در تنظیمات ، توانایی جلوگیری از این امر را دارند. اطلاعات بیشتر در مقاله مرکز راهنما (مرتبط از UI Chrome) در دسترس کاربران است. ما قصد داریم با عنوان رمپ FPS تا 100 ٪ ، راهنمای توسعه دهنده موجود را گسترش دهیم. |
مجموعه های شخص اول ارسال | تغییر نام مورد نیاز .well-known/first-party-set برای شامل یک پسوند .json تغییر دهید. | ما این تغییر را برای اطمینان از پشتیبانی برخی از برنامه های میزبانی وب انجام داده ایم. |
ثبت نام | first_party_sets.JSON باید در IANA ثبت شود | ما در حال بررسی این پیشنهاد هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
قاب های حصارکشی API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
مسدود کردن | فریم های حصارکشی ممکن است مسدود کننده های تبلیغات را برای مسدود کردن تبلیغات آسانتر کند. | پسوندها می توانند با قاب های حصارکشی شبیه به نحوه تعامل آنها با Iframes ارتباط برقرار کنند. URL واقعی که قاب حصارکشی در آن قرار دارد نیز به آن منتقل شود ، برای پسوندها نیز قابل مشاهده خواهد بود و بنابراین می توانند هرگونه قوانین مطابق با URL را برای مسدود کردن همانطور که در Iframes انجام می دهند ، اعمال کنند. به سادگی مسدود کردن همه قاب های حصارکشی بدون قید و شرط ممکن است مواردی از ADS را از قاب های حصارکشی استفاده کند. |
API ذخیره سازی مشترک
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
پذیرش گسترده تر | ذخیره سازی مشترک باید یک استاندارد در سطح صنعت باشد که در مرورگرها موجود است. | ما از این بازخورد استقبال می کنیم و تصدیق می کنیم. Chrome همچنان به طور فعال در W3C FORA شرکت می کند تا این پیشنهاد را قهرمان کند ، به دنبال بازخورد و پذیرش باشد. |
دروازه های خروجی | دروازه های خروجی ذخیره سازی مشترک بسیار محدود هستند. | ما در حال بررسی این بازخورد هستیم و از بازخورد اکوسیستم اضافی در مورد اینکه چرا دروازه های خروجی خیلی محدود هستند استقبال می کنیم. |
رعایت مقررات | چگونه ذخیره سازی مشترک مطابق با سیاست های حفظ داده ها خواهد بود؟ | ذخیره سازی مشترک انعطاف پذیری را برای اجرای و سفارشی سازی منطق برای کنترل طول عمر و انقضاء هرگونه داده ذخیره شده فراهم می کند. فناوری های تبلیغاتی می توانند داده های ذخیره سازی مشترک را بر اساس زمان بندی نوشتن به روز یا پاک کنند. |
تست A/B | چگونه می توان آزمایش A/B برای ذخیره سازی مشترک و API مخاطبان محافظت شده را انجام داد؟ | ما در حال تلاش برای انتشار راهنمایی های اضافی در مورد این موضوع هستیم و امیدواریم که در آینده جزئیات بیشتری را به اشتراک بگذاریم. |
حد ذخیره مشترک | چه اتفاقی خواهد افتاد که محدودیت ذخیره سازی مشترک رخ دهد؟ | در صورت رسیدن به حد ، هیچ ورودی دیگری ذخیره نمی شود. |
دسترسی چندگانه در همان بار صفحه | چه اتفاقی می افتد که به ذخیره سازی مشترک چندین بار در همان بار صفحه دسترسی پیدا کنید؟ | بهترین راه برای رسیدگی به این کار از طریق عملکرد window.sharedStorage.append(key, value) است. به جای به روزرسانی ارزش برای هر تبلیغ ، که در صورت وجود تبلیغات متعدد می تواند باعث تصادف شود. عملکرد Append فقط مقدار جدید را به انتهای مورد موجود اضافه می کند. |
عملکرد iframe | آیا ذخیره سازی مشترک پس از استهلاک کوکی شخص ثالث ، از عملکرد خاص Iframe پشتیبانی می کند؟ | استهلاک کوکی شخص ثالث ، ذخیره محلی در Iframes توسط سایت سطح بالا تقسیم می شود اما خود Iframes مسدود نمی شود. داده های موجود در ذخیره محلی IFRAME در چندین سایت سطح بالا قابل تکرار نیست ، اما هنوز هم می توان از ذخیره محلی در IFRAME استفاده کرد. |
تراشه
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
حد پارتیشن | 10 KIB در هر سایت پارتیشن هنوز هم قابل توجه است و دوست دارد آن را کاهش دهد. | Firefox قبلاً موقعیت مثبتی در تراشه ها نشان داده است. برای پشتیبانی WebKit ، ما توسعه دهندگان را ترغیب می کنیم تا به طور مستقیم در مورد این مسئله GitHub در مورد موارد استفاده از آنها که کوکی های پارتیشن شده نسبت به ذخیره سازی تقسیم شده ترجیح داده می شوند ، به اپل ارائه دهند. |
جاسازی های معتبر | تراشه ها ممکن است به دلیل پارتیشن بندی های مختلف بر تعبیه های معتبر تأثیر بگذارد. | ما قصد داریم از API دسترسی به ذخیره سازی (با استفاده از کاربر) استفاده کنیم تا از مورد استفاده از جاسازی های معتبر پشتیبانی کنیم و اخیراً یک قصد به پیش بینی ارسال کرده ایم. |
سیاست های طول عمر | آیا سیاست های احتمالی طول عمر در مورد کوکی های شخص اول اعمال می شود؟ | ما در حال حاضر هیچ برنامه ای برای تحمیل محدودیت های طول عمر در کوکی های شخص اول نداریم. |
فدستان
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
پشتیبانی مجوز OAUTH | در مجوز دامنه های OAUTH غیرانتفاعی تراز کنید | ما به طور فعال به دنبال ورودی از جامعه هویت وب از طریق W3C FedID CG در بهترین راه های پشتیبانی از مجوز فراتر از تأیید اعتبار اصلی پس از استهلاک کوکی شخص ثالث هستیم. |
پشتیبانی از SAML | با الزامات پشتیبانی SAML تراز کنید | این تیم به طور جدی به دنبال ورودی از جوامع تحقیق و آموزش و پرورش در مورد نیازهای پشتیبانی SAML (علاوه بر پشتیبانی از اتصال OpenID) پس از استهلاک کوکی شخص ثالث است. |
با هرزنامه و کلاهبرداری مبارزه کنید
API Token State Private (و سایر API)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
کاوش در سیگنال های جدید | چندین شریک احساسات مثبت نسبت به کاوش سیگنال های تسهیل شده مرورگر از یکپارچگی دستگاه یا اعتماد کاربر ابراز کرده اند. به طور کلی ، آنها همچنین در مورد سیگنال های جدید ساخته شده برای حفظ سطح فعلی تشخیص کلاهبرداری محتاط هستند. | ما هیجان زده هستیم که پیشنهادات جدید را با هم در جامعه ضد کلاهبرداری و ایمنی وب بررسی کنیم ، و همچنین نگرانی های آنها را تصدیق و به اشتراک می گذاریم - به همین دلیل است که "مبارزه با اسپم و کلاهبرداری" یک کار اصلی در زمینه ماسهبازی حریم خصوصی بوده است و چرا ما همچنان اولویت بندی می کنیم سرمایه گذاری در حفظ ایمنی وب در حالی که ما حریم شخصی کاربر را بهبود می بخشیم. |
بازخورد مثبت در مورد PST | چندین شریک ابراز علاقه به آزمایش یا استفاده از PST برای موارد مختلف استفاده از ایمنی کلاهبرداری یا وب. | ما از شنیدن حمایت و علاقه به کاوش بیشتر راه حل های جدید که از PST استفاده می کنند ، هیجان زده هستیم. ما منابع و کد نمونه را از طریق سایت توسعه دهنده Chrome در دسترس داریم و از بازخورد بیشتر استقبال می کنیم. |
کلاهبرداری و سوء استفاده | راهنمایی برای پیشگیری / تشخیص کلاهبرداری AD در اندازه گیری پس از استهلاک کوکی شخص ثالث هنگامی که شناسه ها دیگر در دسترس نیستند. | ما ابزارهایی مانند نشانه های دولتی خصوصی را معرفی کرده ایم که به بازیابی برخی از سیگنال های از دست رفته توسط کوکی های شخص ثالث برای اهداف ضد کلاهبرداری کمک می کند ، اما با کنترل های جدید حریم خصوصی وجود دارد. ما به طور فعال در حال سرمایه گذاری در پیشنهادات جدید ضد کلاهبرداری و ضد سوء استفاده برای حفظ قابلیت ها با سایر تغییرات ماسهبازی حریم خصوصی هستیم. |
صادرکننده به نرخ اطلاعات مبدا | نرخ اطلاعات صادرکننده به منظر به اندازه کافی بالا برای شناسایی کاربران منحصر به فرد است. | ما این مشخصات را به روز کرده ایم تا در مورد آنچه داده های کاربر قادر به انتقال با استفاده از نشانه های حالت خصوصی هستند ، واضح تر شود. با طراحی ، حداکثر شش کلید عمومی می تواند در یک زمان استفاده شود ، که ممکن است یک "حالت" برای یک کاربر خاص باشد. این مجموعه از کلیدها فقط هر 60 روز یکبار به روز می شوند (به جز در موارد نادر که چرخش کلید اضطراری لازم است) ، که باعث کاهش پتانسیل پیوستن به داده های اضافی کاربر در طول زمان می شود. با هر API وب جدید ، تعادل ابزار ارائه شده و اطلاعات جدید کاربر جدید که ارائه می دهد وجود دارد. ما تخمین می زنیم که PST ها در محافظت از حریم خصوصی کاربر در ضمن امکان استفاده از موارد اصلی استفاده ضد کلاهبرداری که تحت تأثیر استهلاک کوکی شخص ثالث قرار دارد ، تعادل مناسب را به خود اختصاص می دهد. |
ادغام واکشی | ادغام fetch پیچیده و غیر ضروری است. | برای استفاده از fetch جوانب مثبت و منفی وجود دارد ، و ما می خواهیم استاندارد سازی بیشتری را در اکوسیستم وب دنبال کنیم ، اما فکر می کنیم تا زمانی که حس واضح تری داشته باشیم که استاندارد به نظر می رسد ، این تغییر خیلی زود است. اگر و هنگامی که یک استاندارد ظهور می کند ، ما نیز متعهد هستیم که توسعه دهندگان وب را با مسئولیت پذیری به آن استاندارد منتقل کنیم. |
محل ذخیره سازی | توکن های حالت خصوصی تنظیمات کلیدی باید در همان مکان پروتکل Privacypass ذخیره شوند. | در حین آزمایش در طول آزمایش مبدا ، توسعه دهندگان اظهار داشتند که آنها انعطاف پذیری را برای ذخیره کلیدهای خود در URL های عمومی به جای در یک دایرکتوری شناخته شده ترجیح می دهند. فرمت تعهد اصلی در PrivacyPass به ویژه برای نسخه ای مناسب نیست که در آن کلیدها در نظر گرفته شده باشند تا ارزش ضمنی "ابرداده عمومی" را فراهم کنند. اگر نوعی از Privacypass با ابرداده های عمومی (یا به عنوان یک POPRF ، نابینایی جزئی RSA یا کلیدها) استاندارد شود ، ممکن است برای پشتیبانی از آن به نسخه بعدی PST برویم. |
اجرای هدر API | سوالات مربوط به اجرای هدر API | از آنجا که API استاندارد می شود و استفاده از اکوسیستم از این API بالغ می شود ، امیدواریم که از هر دو نسخه استاندارد غیر رهبر این API پشتیبانی کنیم و در صورت کمبود استفاده به اندازه کافی کم ، نسخه هدر را کاهش می دهد یا به اندازه کافی ابزار/پشتیبانی توسعه دهنده برای استاندارد وجود دارد. روشهای همبستگی درخواست صدور/بازخرید با سایر داده ها. ما در اینجا در مورد موضوع بحث می کنیم . |
ثبت نام | آیا ساختن صادرکنندگان با فروشندگان مرورگر عملی هستند؟ | ما مشخصات را برای توصیف روند ثبت نام صادرکننده برای نشانه های دولتی خصوصی به روز کرده ایم. در حالی که از فرآیند خاص خود استفاده می کند ، شبیه به برنامه های ثبت نام برای بقیه کارهای Sandbox Privacy است ، جایی که از صادرکنندگان می خواهیم بیانیه عمومی را برای نحوه استفاده از PST و تأیید محدودیت های فنی که از حریم شخصی کاربر محافظت می کند ، بیان کنند. |