[আউটডেটেড] প্রথম পক্ষের সেট এবং একই পার্টি অ্যাট্রিবিউট

সতর্কতা: প্রথম পক্ষের সেট প্রস্তাব আপডেট করা হয়েছে এবং এই নিবন্ধটি আর আপ টু ডেট নয়। সর্বশেষ তথ্যের জন্য ব্যাখ্যাকারী এবং পরীক্ষার নির্দেশাবলী পড়ুন।

অনেক প্রতিষ্ঠানের বিভিন্ন ডোমেন নামের সাথে সম্পর্কিত সাইট রয়েছে, যেমন brandx.site এবং fly-brandx.site —অথবা বিভিন্ন দেশের জন্য ডোমেইন যেমন example.com , example.rs , example.co.uk ইত্যাদি।

ব্রাউজারগুলি ওয়েবে গোপনীয়তা উন্নত করার জন্য তৃতীয় পক্ষের কুকিজকে অপ্রচলিত করার দিকে অগ্রসর হচ্ছে, কিন্তু এই ধরনের সাইটগুলি প্রায়শই কুকিগুলির উপর নির্ভর করে কার্যকারিতার জন্য যার জন্য ডোমেন জুড়ে অবস্থা বজায় রাখা এবং অ্যাক্সেস করা প্রয়োজন (যেমন একক সাইন-অন এবং সম্মতি ব্যবস্থাপনা)।

প্রথম পক্ষের সেটগুলি সংশ্লিষ্ট ডোমেন নামগুলিকে অনুমতি দিতে পারে যা একই সত্তার মালিকানাধীন এবং পরিচালিত হয় এমন পরিস্থিতিতে প্রথম পক্ষ হিসাবে বিবেচিত হতে পারে যেখানে প্রথম পক্ষ এবং তৃতীয় পক্ষকে অন্যথায় ভিন্নভাবে আচরণ করা হয়৷ প্রথম-পক্ষের সেটের মধ্যে থাকা ডোমেন নামগুলিকে একই-পার্টি হিসাবে বিবেচনা করা হয় এবং তারা একই-পক্ষের প্রসঙ্গে কোন কুকি সেট বা পাঠানোর উদ্দেশ্যে লেবেল করতে পারে। উদ্দেশ্য হল তৃতীয়-পক্ষ দ্বারা ক্রস-সাইট ট্র্যাকিং প্রতিরোধ করার মধ্যে একটি ভারসাম্য খুঁজে বের করা এবং এখনও এমন একটি পথ বজায় রাখা যা বৈধ ব্যবহারের ক্ষেত্রে ভঙ্গ করে না।

ফার্স্ট-পার্টি সেটের প্রস্তাবটি বর্তমানে পরীক্ষার পর্যায়ে রয়েছে, এটি কীভাবে কাজ করে এবং আপনি কীভাবে এটি ব্যবহার করে দেখতে পারেন তা জানতে পড়ুন।

প্রথম পক্ষ এবং তৃতীয় পক্ষের কুকির মধ্যে পার্থক্য কি?

কুকিগুলি সহজাতভাবে প্রথম-পক্ষ বা তৃতীয়-পক্ষ নয়, এটি বর্তমান প্রেক্ষাপটের উপর নির্ভর করে যেখানে কুকি অন্তর্ভুক্ত করা হয়েছে৷ এটি হয় cookie হেডারে অথবা JavaScript-এ document.cookie মাধ্যমে একটি অনুরোধে।

উদাহরণস্বরূপ, যদি video.site একটি theme=dark কুকি থাকে, যখন আপনি video.site ব্রাউজ করছেন এবং video.site এ একটি অনুরোধ করা হয়, এটি একই-সাইটের প্রসঙ্গ এবং অন্তর্ভুক্ত কুকিটি প্রথম পক্ষের ।

যাইহোক, আপনি যদি my-blog.site এ থাকেন যা video.site এর জন্য একটি iframe প্লেয়ার এম্বেড করে, যখন অনুরোধ করা হয় my-blog.site থেকে video.site এ যা ক্রস-সাইট প্রসঙ্গ এবং theme কুকি তৃতীয় পক্ষের হয় .

কুকি অন্তর্ভুক্তি কুকির SameSite বৈশিষ্ট্য দ্বারা নির্ধারিত হয়:

• SameSite=Lax , Strict , বা None এর সাথে একই-সাইটের প্রসঙ্গ কুকিকে ফার্স্ট-পার্টি করে।
• SameSite এর সাথে ক্রস-সাইট প্রসঙ্গ SameSite=None কুকি তৃতীয় পক্ষ তৈরি করে না।

যাইহোক, এটি সবসময় এত পরিষ্কার হয় না। কল্পনা করুন brandx.site একটি ভ্রমণ বুকিং সাইট এবং তারা আলাদা ফ্লাইট এবং গাড়ি ভাড়া করার জন্য fly-brandx.site এবং drive-brandx.site ব্যবহার করে। একটি যাত্রা বুকিং করার সময়, দর্শকরা তাদের বিভিন্ন বিকল্প নির্বাচন করতে এই সাইটগুলির মধ্যে যান-তারা আশা করে যে তাদের নির্বাচনের "শপিং কার্ট" এই সাইটগুলি জুড়ে অব্যাহত থাকবে। brandx.site একটি SameSite=None কুকি দিয়ে ব্যবহারকারীর সেশন পরিচালনা করে যাতে এটি ক্রস-সাইট প্রসঙ্গে অনুমতি দেয়। যদিও নেতিবাচক দিক হল এখন কুকির কোন ক্রস সাইট রিকোয়েস্ট ফোরজি (CSRF) সুরক্ষা নেই। যদি evil.site brandx.site এর একটি অনুরোধ থাকে তাহলে তাতে সেই কুকি অন্তর্ভুক্ত হবে!

কুকি ক্রস-সাইট, কিন্তু সেই সমস্ত সাইট একই প্রতিষ্ঠানের মালিকানাধীন এবং পরিচালিত। দর্শকরাও বোঝে যে এটি একই সংস্থা এবং একই সেশন চায়, অন্য কথায়—একটি ভাগ করা পরিচয়, তাদের মধ্যে।

দ্রষ্টব্য: ফার্স্ট-পার্টি সেটগুলির সাথে পরিস্থিতিগুলিকে সংজ্ঞায়িত করার জন্য একটি রুট রয়েছে যেখানে একটি ক্রস-সাইট প্রসঙ্গ এখনও প্রথম-পক্ষ । কুকি প্রথম পক্ষের সেটের মধ্যে অন্তর্ভুক্ত করা যেতে পারে এবং তৃতীয় পক্ষের প্রসঙ্গে বাদ দেওয়া যেতে পারে।

প্রথম পক্ষের নীতি সেট করে

প্রথম পক্ষের সেটগুলি একই পক্ষের মালিকানাধীন এবং পরিচালিত একাধিক সাইট জুড়ে এই সম্পর্কটিকে স্পষ্টভাবে সংজ্ঞায়িত করার জন্য একটি পদ্ধতি প্রস্তাব করে৷ এটি brandx.site fly-brandx.site , drive-brandx.site ইত্যাদির সাথে তার প্রথম-পক্ষের সম্পর্ককে সংজ্ঞায়িত করতে সক্ষম করবে৷

গোপনীয়তা মডেল যা বিভিন্ন গোপনীয়তা স্যান্ডবক্স প্রস্তাবনাগুলিকে চালিত করে তা ক্রস-সাইট ট্র্যাকিং প্রতিরোধ করার জন্য বিভাজন পরিচয়ের ধারণার উপর ভিত্তি করে তৈরি করা হয় - ব্যবহারকারীদের সনাক্ত করতে ব্যবহার করা যেতে পারে এমন কোনও তথ্যের অ্যাক্সেস সীমিত করে এমন সাইটগুলির মধ্যে একটি সীমানা তৈরি করে৷

যদিও ডিফল্ট বিকল্পটি হল সাইট দ্বারা বিভাজন, যা অনেকগুলি প্রথম-পক্ষের ব্যবহারের ক্ষেত্রে সমাধান করে, brandx.site উদাহরণ দেখায় যে একটি প্রথম পক্ষ শুধুমাত্র একটি সাইটের চেয়ে বড় হতে পারে।

প্রথম-পক্ষ সেট প্রস্তাবের একটি গুরুত্বপূর্ণ অংশ হল ব্রাউজার জুড়ে নীতি অপব্যবহার বা অপব্যবহার প্রতিরোধ করে তা নিশ্চিত করা। উদাহরণ স্বরূপ, প্রথম-পক্ষের সেটগুলি অবশ্যই অসম্পর্কিত সাইটগুলিতে ব্যবহারকারীর তথ্যের আদান-প্রদান সক্ষম করবে না, বা একই সত্তার মালিকানাধীন নয় এমন সাইটগুলির গ্রুপিং সক্ষম করবে না৷ ধারণাটি নিশ্চিত করা যে একটি প্রথম-পক্ষের সেট এমন কিছুর মানচিত্র তৈরি করে যা একজন ব্যক্তি প্রথম-পক্ষ হিসাবে বোঝে এবং বিভিন্ন পক্ষের মধ্যে পরিচয় ভাগ করে নেওয়ার উপায় হিসাবে ব্যবহৃত হয় না।

একটি প্রথম পক্ষের সেট নিবন্ধন করার একটি সম্ভাব্য উপায় হল সাইটটি তাদের প্রস্তাবিত গ্রুপের ডোমেনগুলিকে একটি পাবলিক ট্র্যাকারে (যেমন একটি ডেডিকেটেড গিটহাব রিপোজিটরি) জমা দিতে পারে এবং ব্রাউজার নীতিকে সন্তুষ্ট করার জন্য প্রয়োজনীয় তথ্য সহ।

দ্রষ্টব্য: একটি নতুন প্রথম-পক্ষের সেটের জন্য গ্রহণ প্রক্রিয়াটি W3C-এর সাথে আলোচনার অধীনে রয়েছে এবং বিবেচিত বিকল্পগুলির মধ্যে একটি হল যাচাইকরণের জন্য একটি স্বাধীন সত্তা, ব্রাউজার কোম্পানি নয়।

নীতি অনুসারে প্রথম পক্ষের সেটের দাবি যাচাই করা হয়ে গেলে, ব্রাউজারগুলি একটি আপডেট প্রক্রিয়ার মাধ্যমে সেটগুলির তালিকা আনতে পারে।

মূল বিচারের একটি সংজ্ঞায়িত নীতি রয়েছে যা চূড়ান্ত নয়, তবে নীতিগুলি একই থাকতে পারে:

• একটি প্রথম পক্ষের সেটের ডোমেনগুলি অবশ্যই একই সংস্থার মালিকানাধীন এবং পরিচালিত হতে হবে৷
• ডোমেনগুলি একটি গ্রুপ হিসাবে ব্যবহারকারীদের কাছে স্বীকৃত হওয়া উচিত।
• ডোমেনগুলির একটি সাধারণ গোপনীয়তা নীতি ভাগ করা উচিত৷

দ্রষ্টব্য: প্রথম পক্ষের সেটগুলির জন্য প্রস্তাবিত নীতি সম্পর্কে আরও জানুন।

কিভাবে একটি প্রথম পক্ষের সেট সংজ্ঞায়িত করতে হয়

একবার আপনি আপনার প্রতিষ্ঠানের প্রথম পক্ষের সেটের সদস্য এবং মালিককে শনাক্ত করলে, আপনার প্রস্তাবিত সেট অনুমোদনের জন্য জমা দেওয়া একটি গুরুত্বপূর্ণ পদক্ষেপ হবে। সঠিক প্রক্রিয়াটি এখনও আলোচনার অধীন।

সতর্কতা: একটি প্রথম পক্ষের সেট একই প্রতিষ্ঠানের অন্তর্গত সাইটগুলির একটি সম্পূর্ণ তালিকা নয় । আপনাকে শুধুমাত্র সাইটগুলির মধ্যে একটি সেট তৈরি করতে হবে যদি আপনার স্পষ্টভাবে একটি ক্রস-সাইট কুকির প্রয়োজন হয় যা তাদের জুড়ে অনুমোদিত হয়৷ নিশ্চিত করুন যে আপনি প্রথম-পক্ষ সেট অরিজিন ট্রায়ালের জন্য কোন ব্যবহারের ক্ষেত্রে সঠিক তা পরীক্ষা করে দেখুন? নীচে

একটি প্রথম পক্ষের সেট ঘোষণা করতে, সদস্য এবং মালিকদের তালিকাভুক্ত স্ট্যাটিক 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 যেখানে সমর্থিত একই-পার্টি প্রসঙ্গগুলি অন্তর্ভুক্ত করার জন্য SameSite=Lax; SameParty Lax কার্যকারিতা প্রসারিত করবে, কিন্তু যদি না থাকে তবে Lax বিধিনিষেধে ফিরে আসে।
• SameSite=None; SameParty None কার্যকারিতাকে শুধুমাত্র একই-পার্টি প্রেক্ষাপটে সীমাবদ্ধ করবে যেখানে সমর্থিত হবে, কিন্তু যদি না থাকে তবে বৃহত্তর None অনুমতিতে ফিরে আসবে।

কিছু অতিরিক্ত প্রয়োজনীয়তা আছে:

• SameParty কুকিতে অবশ্যই Secure অন্তর্ভুক্ত থাকতে হবে।
• SameParty কুকিতে SameSite=Strict অন্তর্ভুক্ত করা উচিত নয় ।

Secure বাধ্যতামূলক করা হয়েছে কারণ এটি এখনও ক্রস-সাইট এবং আপনার নিরাপদ (HTTPS) সংযোগগুলি নিশ্চিত করে সেই ঝুঁকিগুলি হ্রাস করা উচিত। একইভাবে, যেহেতু এটি একটি ক্রস-সাইট সম্পর্ক, SameSite=Strict অবৈধ কারণ এটি এখনও একটি সেটের মধ্যে শক্তভাবে সাইট-ভিত্তিক CSRF সুরক্ষার অনুমতি দেয়।

মূল পয়েন্ট: SameParty অ্যাট্রিবিউট শুধুমাত্র সেই প্রসঙ্গগুলিকে প্রভাবিত করে যেখানে একটি কুকি পাঠানো হতে পারে, এটি একটি ভাগ করা কুকি জার তৈরি করে না । brandx.site থেকে একটি কুকি শুধুমাত্র brandx.site এর জন্য অনুরোধ বা নথিতে উপলব্ধ, কুকি কখনই সরাসরি fly-brandx.site এ উপলব্ধ হয় না। এটি বিভ্রান্তিকর হতে পারে কারণ আপনি এটিকে শেয়ার্ড আইডেন্টিটি হিসাবে উল্লেখ করতে পারেন, কিন্তু এর মানে হল যে সাইটগুলির মধ্যে শিথিল সীমানা তাদের একই-পার্টি, ক্রস-সাইট প্রসঙ্গে কুকি সেট করতে বা পাঠাতে দেয় — এমন নয় যে কুকিগুলি সরাসরি শেয়ার করা হয়।

প্রথম পক্ষের সেটগুলির জন্য কোন ব্যবহারের ক্ষেত্রে সঠিক?

ফার্স্ট-পার্টি সেটগুলি সেই ক্ষেত্রেগুলির জন্য একটি ভাল মিল যখন কোনও সংস্থার বিভিন্ন শীর্ষ-স্তরের সাইটগুলিতে ভাগ করা পরিচয়ের প্রয়োজন হয়৷ এই ক্ষেত্রে শেয়ার্ড আইডেন্টিটি মানে সম্পূর্ণ একক সাইন-অন সমাধান থেকে শুরু করে সমস্ত সাইট জুড়ে শেয়ার করা পছন্দের প্রয়োজন।

দ্রষ্টব্য: আপনি এই ব্যবহারের ক্ষেত্রে সম্ভাব্য প্রার্থীদের সনাক্ত করতে পারেন কারণ তারা এমন উদাহরণ যেখানে আপনি ইতিমধ্যেই একটি কুকিকে SameSite=None হিসাবে চিহ্নিত করেছেন যদিও এটি শুধুমাত্র ক্রস-সাইট প্রসঙ্গে যেখানে আপনি জড়িত সমস্ত সাইটের মালিক।

আপনার প্রতিষ্ঠানের জন্য বিভিন্ন শীর্ষ-স্তরের ডোমেন থাকতে পারে:

• অ্যাপ ডোমেইন : office.com , live.com , microsoft.com
• ব্র্যান্ডেড ডোমেইন : amazon.com , audible.com / disney.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 অ্যাট্রিবিউট যোগ করার চেষ্টা করতে চাইলে এটি সহায়ক।

আপনার যদি পরীক্ষা এবং প্রতিক্রিয়ার জন্য ব্যান্ডউইথ থাকে, তাহলে আপনি ফার্স্ট পার্টি সেট এবং সেমপার্টির জন্য অরিজিন ট্রায়ালের জন্য সাইন আপ করতে পারেন যা 89 থেকে 93 সংস্করণ পর্যন্ত Chrome-এ উপলব্ধ।

মূল শব্দ: রিজিন ট্রায়ালগুলি হল ক্রোমের উপায় যা বহিরাগত বিকাশকারীদেরকে ওয়েব প্ল্যাটফর্মের প্রয়োজনীয়তা পূরণ করে এমন কিছুর প্রতি বিকাশ এবং পুনরাবৃত্তি করার জন্য প্রয়োজনীয় প্রতিক্রিয়া প্রদানের জন্য বাস্তব-বিশ্বের পরিস্থিতিতে প্রাথমিক প্রস্তাবগুলি পরীক্ষা করতে সক্ষম করে৷ 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 কম্বিনেশন।

আগে: 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 কুকি দেখার আশা করা উচিত যদি জড়িত সাইটগুলি সেটে থাকে এবং ব্রাউজারটি অরিজিন ট্রায়ালে থাকে। পূর্ববর্তী সংস্করণটি প্রত্যাখ্যান করার আগে একটি আপডেট বৈশিষ্ট্যের সমসাময়িক লঞ্চের মতো এই পদ্ধতিটি বিবেচনা করুন।

কেন আপনি একটি প্রথম পক্ষের সেট প্রয়োজন হতে পারে না?

বেশিরভাগ সাইটের জন্য, তাদের সাইটের সীমানা পার্টিশন বা গোপনীয়তার সীমানা আঁকার জন্য একটি গ্রহণযোগ্য স্থান। এটি সেই রুট যা চিপস (স্বাধীন বিভাজনকৃত রাজ্য থাকা কুকিজ) এর সাথে প্রস্তাব করা হচ্ছে যা সাইটগুলিকে Partitioned অ্যাট্রিবিউটের মাধ্যমে একটি অপ্ট-ইন রুট দেবে যাতে এখনও সেই সমালোচনামূলক ক্রস-সাইট এম্বেড, সংস্থান, API এবং পরিষেবাগুলি লিক হওয়া রোধ করা যায়। সাইট জুড়ে তথ্য সনাক্তকরণ.

আরও কয়েকটি বিষয় বিবেচনা করতে হবে যার অর্থ আপনার সাইটটি একটি সেটের প্রয়োজন ছাড়াই ভাল হতে পারে:

• আপনি বিভিন্ন উৎসের উপর হোস্ট করেন, ভিন্ন সাইট নয়। উপরের উদাহরণে, যদি brandx.site fly.brandx.site এবং drive.brandx.site থাকে তবে সেগুলি একই সাইটের মধ্যে আলাদা সাবডোমেন। কুকিজ SameSite=Lax ব্যবহার করতে পারে এবং কোন সেটের প্রয়োজন নেই।
• আপনি অন্যান্য সাইটে তৃতীয় পক্ষের এম্বেড প্রদান করেন। ভূমিকায়, my-blog.site এ এমবেড করা video.site থেকে একটি ভিডিওর উদাহরণ হল একটি স্পষ্ট তৃতীয় পক্ষের বিভাজন৷ সাইটগুলি বিভিন্ন সংস্থা দ্বারা পরিচালিত হয় এবং ব্যবহারকারীরা তাদের আলাদা সত্তা হিসাবে দেখেন৷ এই দুটি সাইট একসাথে একটি সেট করা উচিত নয়.
• আপনি তৃতীয় পক্ষের সামাজিক সাইন-ইন পরিষেবা প্রদান করেন। OAuth বা OpenId সংযোগের মতো জিনিসগুলি ব্যবহার করে পরিচয় প্রদানকারীরা ব্যবহারকারীদের জন্য একটি মসৃণ সাইন-ইন অভিজ্ঞতার জন্য প্রায়ই তৃতীয় পক্ষের কুকিগুলির উপর নির্ভর করে। এটি একটি বৈধ ব্যবহারের ক্ষেত্রে, তবে এটি প্রথম পক্ষের সেটগুলির জন্য উপযুক্ত নয় কারণ সংস্থাগুলির মধ্যে একটি স্পষ্ট পার্থক্য রয়েছে৷ ওয়েবআইডির মতো প্রাথমিক প্রস্তাবগুলি এই ব্যবহারের ক্ষেত্রে সক্ষম করার উপায়গুলি অন্বেষণ করছে৷