بسیاری از سازمان‌ها دارای سایت‌های مرتبط با نام‌های دامنه متفاوت هستند، مانند brandx.site و fly-brandx.site — یا دامنه‌هایی برای کشورهای مختلف مانند example.com ، example.rs ، example.co.uk و غیره.
مرورگرها برای بهبود حریم خصوصی در وب به سمت منسوخ کردن کوکی‌های شخص ثالث حرکت می‌کنند، اما سایت‌هایی مانند این اغلب برای عملکردهایی که نیاز به حفظ و دسترسی به وضعیت در سراسر دامنه دارند (مانند ورود به سیستم و مدیریت رضایت) به کوکی‌ها متکی هستند.
مجموعه‌های شخص اول می‌توانند به نام‌های دامنه مرتبطی که تحت مالکیت و اداره یک نهاد واحد هستند اجازه دهند در شرایطی که شخص اول و شخص ثالث به طور متفاوتی رفتار می‌کنند، به عنوان شخص اول تلقی شوند. نام‌های دامنه در یک مجموعه شخص اول به عنوان یک شخص در نظر گرفته می‌شوند و می‌توانند برچسب‌گذاری کنند که کدام کوکی‌ها در نظر گرفته شده برای تنظیم یا ارسال در زمینه همان شخص هستند. هدف یافتن تعادلی بین جلوگیری از ردیابی متقابل سایت توسط اشخاص ثالث و در عین حال حفظ مسیری است که موارد استفاده معتبر را نقض نمی کند.
پیشنهاد First-Party Sets در حال حاضر در مرحله آزمایش است، برای اینکه بدانید چگونه کار می کند و چگونه می توانید آن را امتحان کنید، به ادامه مطلب مراجعه کنید.
تفاوت بین کوکی های شخص اول و شخص ثالث چیست؟
کوکی ها ذاتا شخص اول یا شخص ثالث نیستند، این بستگی به شرایط فعلی دارد که کوکی در آن گنجانده شده است. این یا بر اساس درخواست در هدر cookie یا از طریق document.cookie در جاوا اسکریپت است.
برای مثال، اگر video.site دارای یک theme=dark cookie است، هنگامی که در حال مرور video.site هستید و درخواستی از video.site ارسال می شود، این یک زمینه همان سایت است و کوکی ارائه شده شخص اول است.
با این حال، اگر در my-blog.site هستید که یک پخش کننده iframe را برای video.site جاسازی می کند، زمانی که درخواست از my-blog.site به video.site ارسال می شود که زمینه بین سایتی است و کوکی theme شخص ثالث است. .
گنجاندن کوکی توسط ویژگی SameSite کوکی تعیین می شود:
- زمینه مشابه سایت با
SameSite=Lax،StrictیاNoneکوکی را به شخص اول تبدیل می کند. - زمینه بین سایتی با
SameSite=Noneکوکی را شخص ثالث نمی کند.
با این حال، این همیشه آنقدر واضح نیست. تصور کنید brandx.site یک سایت رزرو سفر است و آنها همچنین از fly-brandx.site و drive-brandx.site برای جدا کردن پروازها و کرایه ماشین استفاده می کنند. در طول رزرو یک سفر، بازدیدکنندگان بین این سایت‌ها می‌روند تا گزینه‌های مختلف خود را انتخاب کنند—آنها انتظار دارند «سبد خرید» انتخاب‌هایشان در این سایت‌ها باقی بماند. brandx.site جلسه کاربر را با کوکی SameSite=None مدیریت می کند تا در زمینه های بین سایتی اجازه دهد. اما نکته منفی این است که اکنون کوکی فاقد حفاظت از جعل درخواست متقابل سایت (CSRF) است. اگر evil.site شامل درخواستی به brandx.site باشد، آن کوکی را نیز شامل می شود!
کوکی بین سایتی است، اما همه آن سایت ها متعلق به یک سازمان هستند و اداره می شوند. بازدیدکنندگان همچنین می‌دانند که این همان سازمان است و می‌خواهند جلسه یکسانی داشته باشند، به عبارت دیگر - یک هویت مشترک در بین آنها.
خط مشی First-Party Sets
First-Party Sets روشی را برای تعریف صریح این رابطه در چندین سایت که متعلق به یک طرف هستند و توسط یک طرف اداره می شوند پیشنهاد می کند. این امر به brandx.site امکان می دهد تا رابطه شخص اول خود را با fly-brandx.site ، drive-brandx.site و غیره تعریف کند.
مدل Privacy که پیشنهادهای مختلف Privacy Sandbox را هدایت می‌کند، مبتنی بر مفهوم پارتیشن‌بندی هویت برای جلوگیری از ردیابی متقابل سایت است - ترسیم مرزی بین سایت‌ها که دسترسی به هر اطلاعاتی را که می‌تواند برای شناسایی کاربران استفاده شود محدود می‌کند.
در حالی که گزینه پیش فرض پارتیشن بندی بر اساس سایت است که بسیاری از موارد استفاده شخص اول را حل می کند، مثال brandx.site نشان می دهد که یک شخص اول می تواند بزرگتر از یک سایت باشد.
بخش مهمی از پیشنهاد مجموعه های شخص اول این است که اطمینان حاصل شود که خط مشی در مرورگرها از سوء استفاده یا سوء استفاده جلوگیری می کند. برای مثال، مجموعه‌های شخص اول نباید تبادل اطلاعات کاربر را در سایت‌های غیرمرتبط یا گروه‌بندی سایت‌هایی که متعلق به یک نهاد نیستند، فعال کند. ایده این است که اطمینان حاصل شود که یک مجموعه شخص اول به چیزی نگاشت می شود که شخص به عنوان یک شخص اول درک می کند و به عنوان راهی برای اشتراک گذاری هویت بین طرف های مختلف استفاده نمی شود.
یکی از راه های ممکن برای یک سایت برای ثبت یک مجموعه شخص اول می تواند این باشد که سایت گروه دامنه های پیشنهادی خود را به یک ردیاب عمومی (مانند یک مخزن اختصاصی GitHub) همراه با اطلاعات مورد نیاز برای برآورده کردن خط مشی مرورگر ارسال کند.
هنگامی که ادعای مجموعه شخص اول مطابق با خط مشی تأیید شد، مرورگرها ممکن است لیستی از مجموعه ها را از طریق یک فرآیند به روز رسانی واکشی کنند.
کارآزمایی مبدأ یک خط مشی تعریف شده دارد که نهایی نیست، اما اصول احتمالاً یکسان باقی می مانند:
- دامنه‌های موجود در یک مجموعه شخص اول باید متعلق به همان سازمان باشند و اداره شوند.
- دامنه ها باید برای کاربران به صورت گروهی قابل تشخیص باشند.
- دامنه ها باید یک سیاست حفظ حریم خصوصی مشترک داشته باشند.
چگونه یک مجموعه شخص اول را تعریف کنیم
هنگامی که اعضا و صاحب مجموعه شخص اول سازمان خود را شناسایی کردید، یک گام مهم ارائه مجموعه پیشنهادی خود برای تأیید خواهد بود. روند دقیق هنوز در دست بحث است.
برای اعلام یک مجموعه شخص اول، منابع JSON ایستا که اعضا و مالکان را فهرست می کنند باید در /.well-known/first-party-set در سطح بالای هر دامنه شامل میزبانی شوند.
در مثال مجموعه شخص اول brandx ، دامنه مالک موارد زیر را در https://brandx.site/.well-known/first-party-set میزبانی می کند:
{
"owner": "brandx.site",
"version": 1,
"members": ["fly-brandx.site", "drive-brandx.site"]
}
هر یک از اعضای مجموعه همچنین میزبان یک منبع JSON استاتیک است که به صاحب مجموعه اشاره می کند. در https://fly-brandx.site/.well-known/first-party-set ما داریم:
{ "owner": "brandx.site" }
و در https://drive-brandx.site/.well-known/first-party-set :
{ "owner": "brandx.site" }
چند محدودیت برای مجموعه های شخص اول وجود دارد:
- یک مجموعه ممکن است فقط یک مالک داشته باشد.
- یک عضو ممکن است فقط به یک مجموعه تعلق داشته باشد، بدون همپوشانی یا اختلاط.
- فهرست اعضا در نظر گرفته شده است که نسبتاً قابل خواندن برای انسان باقی بماند و بیش از حد بزرگ نباشد.
چگونه مجموعه‌های شخص اول بر کوکی‌ها تأثیر می‌گذارند؟
عنصر منطبق برای کوکی ها ویژگی SameParty پیشنهادی است. مشخص کردن SameParty به مرورگر می‌گوید که کوکی را در زمانی که زمینه آن بخشی از همان مجموعه شخص اولی است که زمینه سطح بالایی دارد، اضافه کند.
یعنی اگر brandx.site این کوکی را تنظیم کند:
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
سپس وقتی بازدیدکننده در fly-brandx.site است و درخواستی به brandx.site می‌رود، کوکی session در آن درخواست گنجانده می‌شود. اگر سایت دیگری که بخشی از مجموعه شخص اول نیست، برای مثال hotel.xyz ، درخواستی را به brandx.site ارسال کند، کوکی شامل نمی شود.
تا زمانی که SameParty به طور گسترده پشتیبانی نشود، از ویژگی SameSite همراه با آن برای تعریف رفتار بازگشتی برای کوکی ها استفاده کنید. می‌توانید ویژگی SameParty را به‌عنوان تنظیمی بین SameSite=Lax و SameSite=None در نظر بگیرید.
-
SameSite=Lax; SamePartyعملکردLaxرا گسترش می دهد تا زمینه های هم حزبی را در مواردی که پشتیبانی می شود شامل شود، اما در غیر این صورت به محدودیت هایLaxباز می گردد. -
SameSite=None; SamePartyعملکردNoneفقط به زمینه‌های هم حزبی که پشتیبانی می‌شود محدود می‌کند، اما در غیر این صورت به مجوزهایNoneباز می‌گردد.
برخی الزامات اضافی وجود دارد:
- کوکی های
SamePartyباید شاملSecureباشند. - کوکی های
SamePartyنباید شاملSameSite=Strictباشد.
Secure اجباری است زیرا این هنوز بین سایتی است و شما باید با اطمینان از اتصالات ایمن (HTTPS) این خطرات را کاهش دهید. به همین ترتیب، از آنجا که این یک رابطه بین سایتی است، SameSite=Strict نامعتبر است، زیرا همچنان به محافظت CSRF مبتنی بر سایت در یک مجموعه اجازه می دهد.
چه موارد استفاده برای ست های شخص اول مناسب است؟
مجموعه‌های First-Party برای مواردی که سازمان به نوعی هویت مشترک در سایت‌های سطح بالا نیاز دارد، مناسب است. هویت مشترک در این مورد به معنای هر چیزی است، از یک راه حل کامل ورود به سیستم تا نیاز به یک اولویت مشترک در بین سایت ها.
سازمان شما ممکن است دامنه‌های سطح بالای مختلفی برای موارد زیر داشته باشد:
- دامنه های برنامه :
office.com،live.com،microsoft.com - دامنه های مارک دار
disney.comamazon.com،audible.com،pixar.com - دامنه‌های خاص کشور برای فعال کردن محلی‌سازی:
google.co.in،google.co.uk - دامنه‌های خدماتی که کاربران هرگز مستقیماً با آنها ارتباط برقرار نمی‌کنند، اما خدماتی را در سایت‌های همان سازمان ارائه می‌دهند:
gstatic.com،githubassets.com،fbcdn.net - دامنه‌های جعبه ایمنی که کاربران هرگز مستقیماً با آنها تعامل ندارند، اما به دلایل امنیتی وجود دارند:
googleusercontent.com،githubusercontent.com
چگونه درگیر می شوید؟
اگر مجموعه‌ای از سایت‌ها دارید که با معیارهای بالا مطابقت دارند، چندین گزینه برای مشارکت وجود دارد. سبک ترین سرمایه گذاری خواندن و پیوستن به بحث در مورد دو پیشنهاد است:
در طول مرحله آزمایش، می‌توانید عملکرد را با استفاده از پرچم خط فرمان --use-first-party-set و ارائه فهرستی از سایت‌های جدا شده با کاما امتحان کنید.
پس از راه‌اندازی Chrome با پرچم زیر، می‌توانید این را در سایت آزمایشی در https://fps-member1.glitch.me/ امتحان کنید:
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
اگر می‌خواهید در محیط برنامه‌نویسی خود آزمایش کنید، یا می‌خواهید ویژگی SameParty را در یک محیط زنده اضافه کنید، مفید است تا ببینید چگونه یک مجموعه شخص اول روی کوکی‌ها تأثیر می‌گذارد.
اگر پهنای باند آزمایش و بازخورد دارید، می‌توانید در Origin Trial for First Party Sets و SameParty که از نسخه 89 تا 93 در Chrome موجود است، ثبت‌نام کنید.
نحوه به روز رسانی کوکی ها برای نسخه آزمایشی اصلی
اگر به آزمایش اولیه می‌پیوندید و ویژگی SameParty را روی کوکی‌های خود آزمایش می‌کنید، در اینجا دو الگو وجود دارد که باید در نظر بگیرید.
انتخاب 1
ابتدا، جایی که کوکی هایی دارید که آنها را به عنوان SameSite=None برچسب زده اید اما می خواهید به زمینه های شخص اول محدود کنید، می توانید ویژگی SameParty را به آنها اضافه کنید. در مرورگرهایی که نسخه آزمایشی اصلی فعال است، کوکی در زمینه های بین سایتی خارج از مجموعه ارسال نمی شود.
با این حال، برای اکثر مرورگرهای خارج از نسخه آزمایشی اصلی، کوکی به طور معمول به ارسال بین سایتی ادامه خواهد داد. این را به عنوان یک رویکرد بهبود پیشرونده در نظر بگیرید.
قبل از: set-cookie: cname=cval; SameSite=None; Secure
بعد از: set-cookie: cname=cval; SameSite=None; Secure; SameParty
گزینه 2
گزینه دوم کار بیشتر است، اما به شما اجازه می دهد تا نسخه آزمایشی اصلی را به طور کامل از عملکردهای موجود جدا کنید و به طور خاص امکان تست SameSite=Lax; SameParty ترکیب SameSite=Lax; SameParty .
قبل از: set-cookie: cname=cval; SameSite=None; Secure
بعد از:
set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty
هنگام بررسی کوکی در درخواست‌های دریافتی، تنها در صورتی باید انتظار داشته باشید که کوکی cname-fps را در یک درخواست متقابل سایت مشاهده کنید که سایت‌های درگیر در مجموعه هستند و مرورگر در مرحله آزمایشی اصلی قرار دارد. این رویکرد را مانند راه‌اندازی همزمان یک ویژگی به‌روزرسانی شده قبل از رد کردن نسخه قبلی در نظر بگیرید.
چرا ممکن است به یک مجموعه شخص اول نیاز نداشته باشید؟
برای اکثر سایت ها، مرز سایت آنها محل قابل قبولی برای ترسیم پارتیشن یا مرز حریم خصوصی است. این مسیری است که با CHIPS (کوکی‌های دارای حالت پارتیشن‌شده مستقل) پیشنهاد می‌شود که به سایت‌ها از طریق ویژگی Partitioned یک مسیر انتخابی می‌دهد تا همچنان آن جاسازی‌ها، منابع، APIها و سرویس‌های مهم بین سایتی را داشته باشند، در حالی که از نشت اطلاعات جلوگیری می‌کند. شناسایی اطلاعات در سراسر سایت ها
چند نکته دیگر که باید در نظر بگیرید به این معنی است که سایت شما ممکن است بدون نیاز به مجموعه خوب باشد:
- شما از مبداهای مختلف میزبانی می کنید، نه سایت های متفاوت. در مثال بالا، اگر
brandx.siteدارایfly.brandx.siteوdrive.brandx.siteبود، آنها زیر دامنه‌های مختلفی هستند که همگی در یک سایت قرار دارند. کوکی ها می توانند ازSameSite=Laxاستفاده کنند و هیچ مجموعه ای مورد نیاز نیست. - شما جاسازی های شخص ثالث را برای سایت های دیگر ارائه می دهید. در مقدمه، نمونه ویدیویی از
video.siteتعبیه شده درmy-blog.siteیک شکاف آشکار شخص ثالث است. این سایت‌ها توسط سازمان‌های مختلف اداره می‌شوند و کاربران آنها را به‌عنوان نهادهای جداگانه می‌بینند. این دو سایت نباید در یک مجموعه با هم باشند. - شما خدمات ورود به سیستم اجتماعی شخص ثالث را ارائه می دهید. ارائه‌دهندگان هویتی که از چیزهایی مانند OAuth یا OpenId connect استفاده می‌کنند، اغلب به کوکی‌های شخص ثالث برای تجربه ورود راحت‌تر کاربران متکی هستند. این یک مورد استفاده معتبر است، اما برای مجموعه‌های شخص اول مناسب نیست زیرا تفاوت آشکاری در سازمان‌ها وجود دارد. پیشنهادهای اولیه مانند WebID در حال بررسی راه هایی برای فعال کردن این موارد استفاده هستند.