ক্রোম কীভাবে প্রথম পক্ষের সেটের প্রস্তাব তৈরি করেছে

আপডেট: ফার্স্ট-পার্টি সেটের নাম পরিবর্তন করে রিলেটেড ওয়েবসাইট সেট করা হয়েছে। নাম পরিবর্তন সম্পর্কে আরও জানতে, ব্লগ পোস্ট পড়ুন।

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

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

পটভূমি

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

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

যেখানে আমরা শুরু করেছি

যেহেতু ব্রাউজারটি বর্তমানে "প্রথম-পক্ষ" বনাম "তৃতীয়-পক্ষ" ব্যাখ্যা করতে সাইট-স্তরের সীমানা ব্যবহার করে, একটি সংস্থা পরিচালনা করতে পারে এমন ডোমেনের পরিসরের হিসাব করার জন্য, এই প্রযুক্তিগত সীমানাটিকে আরও সূক্ষ্ম সংজ্ঞা দিয়ে প্রতিস্থাপন করা উপযুক্ত বলে মনে হয়েছে। .

2021 সালে, Chrome প্রাথমিকভাবে প্রথম পক্ষের সেটগুলির জন্য SameParty কুকি বৈশিষ্ট্যের প্রস্তাব করেছিল যাতে সাইটগুলি "একই পক্ষের" মধ্যে থাকা সাইটগুলি থেকে উদ্ভূত কুকিগুলিকে সংজ্ঞায়িত করতে পারে। "একই দল" কী গঠন করবে তা নির্ধারণ করতে আমরা একটি ব্যবহারকারী-এজেন্ট নীতি ব্যবহার করেছি। এই নীতির সংজ্ঞাটি "পার্টি" (উদাহরণস্বরূপ, W3C DNT স্পেসিফিকেশন থেকে) বিদ্যমান কাঠামোর উপর গড়ে তোলার চেষ্টা করেছে এবং প্রাসঙ্গিক গোপনীয়তা বক্তৃতা থেকে সুপারিশগুলিকে অন্তর্ভুক্ত করেছে (যেমন 2012 ফেডারেল ট্রেড কমিশন রিপোর্ট "দ্রুত পরিবর্তনের যুগে ভোক্তাদের গোপনীয়তা রক্ষা করা " )

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

প্রাথমিক প্রস্তাব সম্পর্কে প্রতিক্রিয়া

ওয়েব ইকোসিস্টেমের স্টেকহোল্ডারদের সাথে অনেক কথোপকথনের মাধ্যমে, আমরা দেখেছি যে এই প্রাথমিক ডিজাইনের সীমাবদ্ধতা রয়েছে।

SameParty অ্যাট্রিবিউটের মাধ্যমে প্যাসিভ কুকি অ্যাক্সেস সহ গোপনীয়তা চ্যালেঞ্জ

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

ব্রাউজার জুড়ে ওয়েব ইন্টারঅপারেবিলিটি খোঁজার পাশাপাশি গোপনীয়তার সুবিধার উন্নতির স্বার্থে, আমরা এই দিকে এগিয়ে যাওয়ার সিদ্ধান্ত নিয়েছি।

প্রস্তাবিত নীতির সাথে বাস্তবায়ন চ্যালেঞ্জ

মূল নীতিতে ডোমেনগুলির জন্য একটি একক সেটে তিনটি প্রয়োজনীয়তা প্রস্তাব করা হয়েছে: "সাধারণ মালিকানা", "সাধারণ গোপনীয়তা নীতি", এবং "সাধারণ গোষ্ঠী পরিচয়"।

বৃহত্তর ইকোসিস্টেম থেকে, আমরা চারটি প্রধান থিম অনুসরণ করার নীতিতে আমরা যে প্রতিক্রিয়া পেয়েছি তা খুঁজে পেয়েছি।

সাধারণ মালিকানা খুব সীমাবদ্ধ

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

একটি একক নীতি কেস ব্যবহার করার জন্য এক্সটেনসিবিলিটি সীমিত করে

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

গোষ্ঠী পরিচয় সম্পর্কে ব্যবহারকারীদের উপলব্ধি এবং বোঝার পার্থক্য হতে পারে

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

আমরা এমন প্রতিক্রিয়াও পেয়েছি যে "সাধারণ মালিকানা" সীমানার অর্থ বোঝা ব্যবহারকারী থেকে ব্যবহারকারীর মধ্যে পরিবর্তিত হতে পারে, যা নির্দেশিকা তৈরি করা কঠিন করে তোলে যা সমস্ত সাইটে প্রয়োগ করা যেতে পারে।

একটি বিষয়ভিত্তিক নীতি স্কেলে প্রয়োগ করা কঠিন

আমরা আরও বিস্তারিত নির্দেশিকাগুলির জন্য অনেক অনুরোধ পেয়েছি, নির্দিষ্ট প্রয়োজনীয়তার বিষয়গত প্রকৃতির (যেমন "সাধারণ গোষ্ঠী পরিচয়") এবং অন্যদের জন্য ব্যতিক্রম বা প্রান্তের ক্ষেত্রে কভার করার প্রয়োজন ( "সাধারণ গোপনীয়তা নীতি" সম্পর্কিত )।

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

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

বিবর্তন

প্রতিক্রিয়ার প্রতিক্রিয়া হিসাবে, আমরা FPS পুনরায় ডিজাইন করেছি। আমরা যে নির্দিষ্ট সমস্যাগুলির সমাধান করার চেষ্টা করছিলাম সেগুলিতে ফিরে এসেছি, এবং আমরা যে নির্দিষ্ট ব্যবহারের ক্ষেত্রে সমাধান করছিলাম তার জন্য প্রস্তাবটি আরও সরাসরি ফ্রেম করার সিদ্ধান্ত নিয়েছি।

মূল ব্যবহারের ক্ষেত্রে সমাধান করা

ক্রোম ওয়েবে মূল ব্যবহারের ক্ষেত্রে মেটাতে তিনটি ভিন্ন উদ্দেশ্য-নির্মিত "সাবসেট" তৈরি করেছে। উপসেট পদ্ধতিগুলি আরও ব্যক্তিগত, আরও নির্দিষ্ট এবং ধারাবাহিকভাবে প্রয়োগ করা সহজ হওয়ার মাধ্যমে পুরানো পদ্ধতির উপর উন্নতি করেছে।

• "ccTLDs" (দেশ-কোড শীর্ষ-স্তরের ডোমেন) — সংস্থাগুলি স্থানীয় অভিজ্ঞতার জন্য বিভিন্ন ccTLD সহ সাইটগুলি বজায় রাখতে পারে এবং এই সাইটগুলির এখনও ভাগ করা পরিষেবা এবং অবকাঠামোতে অ্যাক্সেসের প্রয়োজন হতে পারে।
• "পরিষেবা" ডোমেন - সাইটগুলি নিরাপত্তা বা কর্মক্ষমতার উদ্দেশ্যে আলাদা ডোমেন ব্যবহার করতে পারে এবং এই সাইটগুলিকে তাদের কার্য সম্পাদন করার জন্য ব্যবহারকারীর পরিচয়ে অ্যাক্সেসের প্রয়োজন হতে পারে৷
• "সংশ্লিষ্ট" ডোমেনগুলি - সংস্থাগুলি বিভিন্ন, সম্পর্কিত ব্র্যান্ড বা পণ্যগুলির জন্য একাধিক সাইট বজায় রাখতে পারে৷ কোনও সংস্থার ব্যবহারকারীর ভিত্তি কীভাবে তাদের সাইটের সাথে ইন্টারঅ্যাক্ট করে তা আরও ভালভাবে বোঝার জন্য, বা একই উপর নির্ভর করে একটি সম্পর্কিত সাইটে ব্যবহারকারীর লগ-ইন অবস্থা মনে রাখতে তারা সংশ্লিষ্ট সাইটগুলিতে ব্যবহারকারীর ভ্রমণের বিশ্লেষণের মতো ব্যবহারের ক্ষেত্রে ক্রস-সাইট কুকি অ্যাক্সেস চাইতে পারে। লগইন পরিকাঠামো.

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

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

তৃতীয় পক্ষের কুকি অ্যাক্সেসের জন্য সক্রিয় অনুরোধের মাধ্যমে আন্তঃক্রিয়াশীলতার সুযোগ

ক্রোম ওয়েব প্ল্যাটফর্মের স্বাস্থ্য বজায় রাখার জন্য অন্যান্য ব্রাউজারগুলির সাথে আন্তঃব্যবহারযোগ্যতা প্রচার করতে আগ্রহী। যেহেতু অন্যান্য ব্রাউজার যেমন Safari, Firefox, এবং Edge বর্তমানে সক্রিয় কুকি অনুরোধের সুবিধার্থে স্টোরেজ অ্যাক্সেস এপিআই (SAA) ব্যবহার করে, তাই আমরা ক্রোমে SAA ব্যবহার করার জন্য বেছে নিয়েছি শুধুমাত্র আমাদের প্রাপ্ত মূল প্রতিক্রিয়ার সমাধান করতে সাহায্য করার জন্য নয়, ওয়েব ইন্টারঅপারেবিলিটি সমর্থন করার জন্যও।

ডেভেলপারদের জন্য আরও নমনীয়তা প্রদান করতে এবং SAA-এর পরিচিত সীমাবদ্ধতাগুলি মোকাবেলা করতে, আমরা requestStorageAccessForOrigin API-এরও প্রস্তাব করেছি।

স্টোরেজ অ্যাক্সেস API এবং FPS একসাথে ব্যবহার করার সুযোগ

স্টোরেজ অ্যাক্সেস API (SAA) প্রয়োগ করার সময়, ব্রাউজারগুলি ব্যবহারকারীদের সরাসরি অনুমতির জন্য জিজ্ঞাসা করতে বেছে নিতে পারে এবং অন্যরা অনুমতি প্রম্পট ছাড়াই সীমিত সংখ্যক অনুরোধের অনুমতি দিতে পারে।

ক্রোম বিশ্বাস করে যে FPS ব্যবহারকারীর ঘর্ষণকে সীমিত করে এবং কী, সীমিত ব্যবহারের ক্ষেত্রে প্রম্পট ক্লান্তি রোধ করে SAA এর উপর একটি স্বচ্ছ স্তর সরবরাহ করতে পারে। FPS ব্যবহারকারীদের সেট সদস্যতা সম্পর্কে অতিরিক্ত প্রসঙ্গ প্রদান করার জন্য ব্রাউজারগুলিকে নমনীয়তা প্রদান করে, যদি তারা ব্যবহারকারীদের অনুমতির জন্য অনুরোধ করতে বেছে নেয়।

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

অবশেষে, যেসব ডেভেলপাররা Chrome-এ FPS-এর সাথে কাজ করার জন্য SAA প্রয়োগ করে তারা অন্যান্য ব্রাউজারে, এমনকি যেগুলি FPS পাঠায় না তাদের সাইটের পারফরম্যান্সের জন্য SAA ব্যবহার করতে সক্ষম হবে।

অব্যাহত আলোচনা

আমরা বিশ্বাস করি যে আমাদের সাম্প্রতিক প্রস্তাবনা একটি চ্যালেঞ্জিং ট্রেডঅফ স্পেসে সঠিক ভারসাম্য রক্ষা করে যা ব্যবহারকারী এবং ডেভেলপারদের চাহিদা বিবেচনা করে। আমরা ওয়েব ইকোসিস্টেম স্টেকহোল্ডারদের দ্বারা উত্থাপিত প্রতিক্রিয়ার প্রশংসা করি যা আমাদের FPS প্রস্তাবকে বিকশিত করতে সাহায্য করেছে।

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

জড়িত থাকার জন্য নিম্নলিখিত সংস্থানগুলি দেখুন:

• WICG- তে ইনকিউবেশন
• FPS পরীক্ষার নির্দেশাবলী
• প্রথম পক্ষের সেট: ইন্টিগ্রেশন গাইড
• FPS জমা দেওয়ার নির্দেশিকা

ইকোসিস্টেমের সাথে কাজ করা

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

"Chrome আমাদের অনেক ব্যবহারের ক্ষেত্রের সাথে সারিবদ্ধ করার জন্য প্রথম পক্ষের সেট তৈরি করছে, যেমন ব্যবহারকারীর ভ্রমণ সংরক্ষণ করা। এটি আমাদের কাছে প্রমাণ করে যে Google টিম ওয়েব জুড়ে সাইটের মালিকদের বিভিন্ন ধরনের চাহিদা বোঝার জন্য কাজ করছে।" - Mercado Libre

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