مجموعه‌های شخص اول (FPS) برای پشتیبانی از تجربه مرور وب کاربران پس از منسوخ شدن کوکی‌های شخص ثالث در Chrome طراحی شده‌اند. این پیشنهاد به طور قابل توجهی در انجمن های وب باز در طول دوره نهفتگی FPS ، ابتدا در گروه جامعه حریم خصوصی W3C، و اکنون در گروه جامعه جوجه کش وب، تکامل یافته است.
در این پست وبلاگ، روند تکامل را خلاصه می‌کنیم، تغییرات کلیدی را برجسته می‌کنیم و در مورد اینکه چرا معتقدیم چنین تغییراتی حریم خصوصی را در وب بهبود می‌بخشد و در عین حال به حمایت از اکوسیستم ادامه می‌دهد، بحث خواهیم کرد.
پس زمینه
سایت ها اغلب به دسترسی به کوکی های خود در زمینه شخص ثالث برای ارائه تجربیات یکپارچه و متناسب به کاربران متکی هستند. علاوه بر APIهای تبلیغات حفظ حریم خصوصی (موضوعات، API مخاطبان محافظت شده، و Attribution) ، تیم Chrome به دنبال درک دامنه سناریوهایی بود که در آن از کوکی‌های شخص ثالث، فراتر از اهداف شخصی‌سازی یا اندازه‌گیری تبلیغات، برای ارائه تجربه‌های مرور پیشرفته‌تر استفاده می‌شد. برای کاربران
ما متوجه شدیم که سازمان‌ها ممکن است به کوکی‌های شخص ثالث تکیه کنند زیرا معماری وب آنها برای استفاده از دامنه‌های متعدد طراحی شده است. به عنوان مثال، یک سازمان ممکن است یک دامنه برای وبلاگ پیاده روی خود و دیگری برای فروشگاه کمپینگ خود داشته باشد و بخواهد از سفرهای کاربر در آن سایت ها پشتیبانی کند. یک سازمان همچنین ممکن است چندین دامنه با کد کشور را با زیرساخت مشترک برای سرویس وب خود حفظ کند. برای مواردی مانند این، ما تصمیم گرفتیم راه حلی را ایجاد کنیم که با نیازهای چنین سازمان هایی هماهنگ باشد و در عین حال انتظارات کاربران را برای حفظ حریم خصوصی آنها در وب حفظ کند.
از جایی که شروع کردیم
از آنجایی که مرورگر در حال حاضر از مرز سطح سایت برای تفسیر "شخص اول" در مقابل "شخص ثالث" استفاده می کند، تا دامنه دامنه هایی را که یک سازمان ممکن است مدیریت کند، در نظر بگیرد، به نظر می رسد مناسب است که این مرز فنی را با یک تعریف دقیق تر جایگزین کنیم. .
در سال 2021، کروم در ابتدا ویژگی کوکی SameParty را برای مجموعه‌های شخص اول پیشنهاد کرد تا سایت‌ها بتوانند کوکی‌هایی را که از سایت‌های درون «همان حزب» سرچشمه می‌گیرند تعریف کنند. ما از یک خط‌مشی عامل کاربر برای تعریف «حزب یکسان» استفاده کردیم. این تعریف خط‌مشی تلاش کرد بر چارچوب‌های موجود «حزب» (به عنوان مثال، از مشخصات W3C DNT ) و توصیه‌هایی از گفتمان حفظ حریم خصوصی مرتبط (مانند گزارش کمیسیون تجارت فدرال در سال 2012 با عنوان «حفاظت از حریم خصوصی مصرف‌کننده در عصر تغییرات سریع» ایجاد شود. " ).
در آن زمان، ما احساس کردیم این رویکرد انعطاف کافی را برای انواع مختلف سازمان‌ها، در سراسر صنایع فراهم می‌کند، در حالی که به هدف اساسی ما برای به حداقل رساندن ردیابی گسترده از طریق کوکی‌های شخص ثالث نیز پایبند بودیم.
بازخورد در مورد پیشنهاد اولیه
از طریق گفتگوهای بسیاری با سهامداران در اکوسیستم وب، متوجه شدیم که این طراحی اولیه محدودیت هایی دارد.
چالش های حریم خصوصی با دسترسی غیرفعال به کوکی از طریق ویژگی SameParty
سایر فروشندگان مرورگر یک رویکرد فعال را برای دسترسی به کوکی های شخص ثالث ترجیح می دهند که نیاز به فراخوانی صریح API دارد، به جای ایجاد مرزی که در آن دسترسی غیرفعال کوکی می تواند حفظ شود. درخواست‌های فعال برای دسترسی به کوکی، دید و کنترل مرورگر را فراهم می‌کند تا خطر ردیابی مخفیانه از طریق کوکی‌های شخص ثالث کاهش یابد. علاوه بر این، این قابلیت به مرورگرها اجازه می‌دهد تا به کاربران اجازه دهند یا مسدود کردن چنین دسترسی کوکی‌ها را انتخاب کنند.
به منظور جستجوی قابلیت همکاری وب در بین مرورگرها و همچنین بهبود مزایای حفظ حریم خصوصی، تصمیم گرفتیم در این مسیر حرکت کنیم.
چالش های اجرایی با سیاست پیشنهادی
خط‌مشی اصلی سه شرط لازم برای قرار گرفتن دامنه‌ها در یک مجموعه را پیشنهاد می‌کرد: «مالکیت مشترک»، «خط مشی حریم خصوصی مشترک» و «هویت گروه مشترک».
از اکوسیستم گسترده تر، بازخوردی را که در مورد این خط مشی دریافت کردیم، یافتیم که از چهار موضوع اصلی پیروی می کند.
مالکیت مشترک بسیار محدود کننده است
با توجه به الزامات «مالکیت مشترک»، بازخورد دریافت کردیم مبنی بر اینکه تعریف FPS که صرفاً بر مالکیت شرکتی متمرکز است، به شرکت‌های بزرگتر توانایی بیشتری برای جمع کردن داده‌ها در طیف گسترده‌ای از دامنه‌ها و سرویس‌های کاربر در مقایسه با شرکت‌های کوچک‌تر می‌دهد. از آنجایی که هدف ما ساختن جعبه ایمنی حریم خصوصی برای کل اکوسیستم است، این بازخورد را جدی گرفتیم و راه حلی را اولویت بندی کردیم که فراگیرتر باشد.
یک خط مشی واحد توسعه پذیری برای موارد استفاده را محدود می کند
در حالی که ایده یک خط‌مشی کل‌نگر برای حاکم کردن یک مرز برای ارائه انعطاف‌پذیری برای انواع مختلف دامنه‌هایی که باید در FPS یک سازمان باشند، در نظر گرفته شد، ما دریافتیم که برخی از موارد استفاده حیاتی نمی‌توانند این طرح خط‌مشی را برآورده کنند. برای مثال، دامنه‌های خدماتی (مانند آنهایی که محتوای تولید شده توسط کاربر را میزبانی می‌کنند) ممکن است برای احراز هویت یا شناسایی کاربران نیاز به دسترسی به کوکی‌های خود در زمینه شخص ثالث داشته باشند. چنین دامنه هایی به ندرت دارای صفحه اصلی قابل دسترسی برای کاربر هستند، بنابراین الزامات "هویت گروه مشترک" یا "خط مشی رازداری مشترک" با سایر دامنه ها در همان FPS برآورده نمی شود.
درک و درک کاربران از هویت گروه ممکن است متفاوت باشد
ما در ابتدا نرده‌هایی را برای تعریف «هویت گروهی مشترک» به عنوان تلاشی برای محدود کردن دامنه‌ها در یک مجموعه واحد به حوزه‌هایی پیشنهاد کردیم که به راحتی می‌توان با هویت گروهی مشترک مرتبط شوند. با این حال، ما قادر به تعریف ابزار فنی برای اندازه گیری و ارزیابی این نبودیم که آیا هویت گروه مشترک می تواند "به راحتی توسط کاربران قابل کشف باشد". این امر بالقوه ای برای سوء استفاده و سؤالاتی در مورد اجرا ایجاد کرد.
ما همچنین بازخورد دریافت کردیم مبنی بر اینکه درک معنای مرزهای "مالکیت مشترک" ممکن است از کاربری به کاربر دیگر متفاوت باشد، که ایجاد دستورالعمل هایی را که می تواند در همه سایت ها اعمال شود دشوار می کند.
اجرای یک سیاست ذهنی در مقیاس دشوار است
با توجه به ماهیت ذهنی الزامات خاص (مانند "هویت گروه مشترک")، و نیاز به پوشش استثناها یا موارد لبه برای دیگران ( در مورد "خط مشی رازداری مشترک" ) درخواست های زیادی برای دستورالعمل های دقیق تر دریافت کردیم.
برای اطمینان از اعمال منصفانه و مداوم این خط‌مشی، Chrome باید دستورالعمل‌های بسیار خاص‌تری را به نویسندگان سایت ارائه می‌کرد. ما تشخیص دادیم که تلاش برای ایجاد دستورالعمل‌های سخت‌گیرانه‌تر می‌تواند منحصراً به ضرر اکوسیستم باشد.
در حالی که ما در ابتدا پیشنهاد کرده بودیم که یک نهاد مجری مستقل نقش بررسی و اجرای انطباق با سیاست را بر عهده بگیرد، در اکوسیستم فعلی، یافتن یک نهاد مجری مستقل با تخصص مناسب برای انجام این مسئولیت ها به شیوه ای بی طرفانه چالش برانگیز بود. در عوض، ما تلاش کردیم تا به سیاستی بپردازیم که می‌تواند از نظر فنی اجرا شود تا اطمینان حاصل شود که پیاده‌سازی می‌تواند به طور مداوم و عینی اعمال شود.
تکامل
در پاسخ به بازخورد، FPS را دوباره طراحی کردیم. ما به مشکلات خاصی که در تلاش برای رسیدگی به آن بودیم بازگشتیم و تصمیم گرفتیم که این پیشنهاد را مستقیماً در مورد موارد استفاده خاصی که در حال حل آنها بودیم چارچوب بندی کنیم.
حل موارد استفاده کلیدی
Chrome سه «زیرمجموعه» هدفمند مختلف را برای پاسخگویی به موارد استفاده کلیدی در وب توسعه داد. رویکرد زیرمجموعه‌ها با خصوصی‌تر بودن، خاص‌تر بودن و اجرای مداوم آسان‌تر، نسبت به رویکرد قدیمی بهبود یافت.
- "ccTLD" (دامنه های سطح بالای کد کشور) - سازمان ها ممکن است سایت هایی با ccTLD های مختلف را برای تجربیات محلی نگهداری کنند و این سایت ها ممکن است همچنان به خدمات و زیرساخت های مشترک نیاز داشته باشند.
- دامنه‌های "سرویس" - سایت‌ها ممکن است از دامنه‌های مجزا برای اهداف امنیتی یا عملکردی استفاده کنند و این سایت‌ها ممکن است برای انجام وظایف خود نیاز به دسترسی به هویت کاربر داشته باشند.
- دامنه‌های «مرتبط» – سازمان‌ها ممکن است چندین سایت را برای برندها یا محصولات مختلف، مرتبط نگهداری کنند. آنها ممکن است برای موارد استفاده مانند تجزیه و تحلیل سفرهای کاربر در سایت‌های مرتبط، دسترسی به کوکی بین‌سایتی را بخواهند تا درک بهتری از نحوه تعامل پایگاه کاربر سازمان با سایت‌هایشان داشته باشند، یا برای به خاطر سپردن وضعیت ورود کاربر در یک سایت مرتبط که بر همان سایت متکی است. زیرساخت ورود
برای هر یک از این موارد استفاده، الزامات خط‌مشی گسسته، بررسی‌های اعتبارسنجی فنی مربوطه، و رفتار خاص مدیریت مرورگر وجود دارد (در دستورالعمل‌های ارسال اطلاعات بیشتر بیاموزید). این تغییرات با کنار گذاشتن طرح «یک اندازه متناسب با همه»، و ترجیح دادن به یک چارچوب تقسیم‌بندی‌شده و مبتنی بر کیس، محدودیت‌های پیشنهاد اصلی را برطرف می‌کند.
فرصتی برای قابلیت همکاری از طریق درخواست های فعال برای دسترسی به کوکی های شخص ثالث
کروم مایل است قابلیت همکاری با سایر مرورگرها را برای حفظ سلامت پلتفرم وب ارتقا دهد. از آنجایی که مرورگرهای دیگری مانند Safari، Firefox و Edge در حال حاضر از Storage Access API (SAA) برای تسهیل درخواست‌های کوکی فعال استفاده می‌کنند، ما از SAA در Chrome نه تنها برای کمک به پاسخگویی به بازخوردهای کلیدی که دریافت کرده‌ایم، بلکه برای پشتیبانی از قابلیت همکاری وب استفاده می‌کنیم.
برای ارائه انعطاف‌پذیری بیشتر برای توسعه‌دهندگان و رفع محدودیت‌های شناخته شده SAA، API requestStorageAccessForOrigin را نیز پیشنهاد کرده‌ایم.
فرصتی برای استفاده از Storage Access API و FPS با هم
هنگام پیاده‌سازی Storage Access API (SAA)، مرورگرها ممکن است مستقیماً از کاربران اجازه بخواهند و دیگران ممکن است تعداد محدودی از درخواست‌ها را بدون درخواست مجوز مجاز کنند .
کروم معتقد است که FPS می تواند با محدود کردن اصطکاک کاربر و جلوگیری از خستگی سریع برای موارد استفاده کلیدی و محدود، یک لایه شفاف روی SAA ارائه دهد. FPS همچنین به مرورگرها این انعطاف‌پذیری را می‌دهد تا در صورت درخواست مجوز از کاربران، زمینه اضافی در مورد عضویت در مجموعه را به کاربران ارائه دهند.
با FPS، توسعه دهندگان این فرصت را دارند تا سایت های تحت تاثیر خود را که موارد استفاده کلیدی را ارائه می دهند، شناسایی کنند. این به توسعه‌دهندگان این امکان را می‌دهد تا با استفاده از FPS یا یک جایگزین کوکی شخص ثالث، نحوه عملکرد سایت‌هایشان را برای کاربران پیش‌بینی کنند و اقداماتی را برای محدود کردن تأثیر آن بر تجربه کاربر انجام دهند. علاوه بر این، FPS قابلیت پیش بینی پلت فرم توسعه دهندگان را فراهم می کند، برخلاف اکتشافی که ممکن است در طول زمان تغییر کند یا منجر به رفتارهای متفاوت برای کاربران مختلف شود.
در نهایت، توسعه‌دهندگانی که SAA را برای کار با FPS در کروم پیاده‌سازی می‌کنند، می‌توانند از SAA برای عملکرد سایت‌های خود در سایر مرورگرها، حتی مرورگرهایی که FPS ارسال نمی‌کنند، استفاده کنند.
ادامه بحث
ما بر این باوریم که آخرین پیشنهاد ما تعادل مناسبی را در فضایی چالش برانگیز ایجاد می کند که نیازهای کاربران و توسعه دهندگان را در نظر می گیرد. از بازخوردهای مطرح شده توسط ذینفعان اکوسیستم وب که به ما در تکامل پیشنهاد FPS کمک کرد، قدردانی می کنیم.
ما می دانیم که ذینفعان اکوسیستم وب هنوز با پیشنهاد به روز شده آشنا هستند. لطفاً با ما در ارتباط باشید تا بتوانیم به بهبود طراحی به روشی ادامه دهیم که برای توسعه دهندگان مفیدتر باشد و حفظ حریم خصوصی را در وب بهبود بخشد. Google همچنین به همکاری با سازمان رقابت و بازارهای بریتانیا (CMA) برای اطمینان از رعایت تعهدات ادامه خواهد داد.
برای مشارکت، منابع زیر را بررسی کنید:
- جوجه کشی در WICG
- دستورالعمل های تست FPS
- مجموعه های شخص اول: راهنمای یکپارچه سازی
- دستورالعمل های ارسال FPS
کار با اکوسیستم
دیدن شرکت‌هایی مانند Salesforce و CafeMedia که در بازخوردهای کلیدی و توسعه مجموعه‌های First-Party درگیر هستند، بسیار خوب است. آنها در پیشرفت فناوری نقش موثری داشته اند. چندین نفر دیگر نیز نظرات خود را در مورد مجموعه های شخص اول و تلاش های Chrome برای کار با اکوسیستم وب به اشتراک گذاشته اند:
"Chrome در حال توسعه مجموعه های شخص اول است تا با بسیاری از موارد استفاده ما، مانند حفظ سفرهای کاربر، هماهنگ شود. این به ما نشان می دهد که تیم Google در حال کار برای درک انواع مختلف نیازهای صاحبان سایت در سراسر وب است." - Mercado Libre
"در VWO، ما از تلاش‌های گوگل برای ارتقای استانداردهای حریم خصوصی قدردانی می‌کنیم، در حالی که اطمینان حاصل می‌کنیم که موارد استفاده واقعی رسیدگی می‌شود. بسیار خوب است که تیم با اکوسیستم توسعه‌دهنده همکاری می‌کند و دائماً در حال بهبود اجرای پیشنهاد مجموعه‌های شخص اول بر اساس بازخورد سهامداران وب ما از اینکه بخشی از سفر آزمایشی این پیشنهاد هستیم و مشتاقانه منتظر الحاق آن به مرورگر هستیم، هیجان زده هستیم. - نیتیش میتال، مدیر مهندسی VWO