স্টোরেজ পার্টিশন

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

বাস্তবায়নের অবস্থা

এই বৈশিষ্ট্যটি Chrome 115 এবং তার পরবর্তী সংস্করণের সকল ব্যবহারকারীর জন্য সক্রিয় করা হয়েছে। Firefox এবং Safari এর মতো অন্যান্য প্রধান ব্রাউজারেও একই ধরণের স্টোরেজ পার্টিশন প্রচেষ্টা চালু আছে বা পরিকল্পনা করা হয়েছে। GitHub-এ স্টোরেজ পার্টিশন প্রস্তাবটি আরও আলোচনার জন্য উন্মুক্ত।

স্টোরেজ পার্টিশনিং কী?

নির্দিষ্ট ধরণের সাইড-চ্যানেল ক্রস-সাইট ট্র্যাকিং প্রতিরোধ করতে, Chrome তৃতীয় পক্ষের প্রেক্ষাপটে স্টোরেজ এবং যোগাযোগ API গুলিকে পার্টিশন করে।

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

ঐতিহাসিকভাবে, স্টোরেজ শুধুমাত্র origin দ্বারা চিহ্নিত করা হয়েছে। এর মানে হল যে যদি example.com থেকে একটি iframe a.com এবং b.com এ এমবেড করা থাকে, তাহলে এটি স্টোরেজ থেকে একটি ID সংরক্ষণ এবং সফলভাবে পুনরুদ্ধার করে এই দুটি সাইটের জন্য আপনার ব্রাউজিং অভ্যাস সম্পর্কে জানতে পারে। তৃতীয় পক্ষের স্টোরেজ পার্টিশন সক্ষম করার সাথে, example.com এর স্টোরেজ দুটি ভিন্ন পার্টিশনে বিদ্যমান, একটি a.com এর জন্য এবং অন্যটি b.com এর জন্য।

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

আগে

পার্টিশন ছাড়াই স্টোরেজ API।
স্টোরেজ পার্টিশন করার আগে, example.com a.com এ এমবেড করা অবস্থায় ডেটা লিখতে পারে এবং তারপর b.com এ এমবেড করা অবস্থায় তা পড়তে পারে।

পরে

পার্টিশন সহ স্টোরেজ API।
স্টোরেজ পার্টিশন করার পরে, example.com, যখন b.com এ এমবেড করা হয়, a.com এ এমবেড করা হলে example.com এর স্টোরেজ অ্যাক্সেস করতে পারে না।

শৃঙ্খলিত আইফ্রেমে স্টোরেজ পার্টিশন

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

উদাহরণস্বরূপ, A1-এ B-এর জন্য একটি iframe রয়েছে যেখানে A2-এর জন্য একটি iframe রয়েছে এবং A1 এবং A2 উভয়ই একই সাইটে রয়েছে। যদি পার্টিশনিংকে শুধুমাত্র শীর্ষ-স্তরের সাইট এবং বর্তমান ফ্রেমের উৎপত্তি বিবেচনা করা হয়, তাহলে iframe A2 ভুল করে 'প্রথম-পক্ষ' হিসেবে বিবেচিত হতে পারে কারণ এটি শীর্ষ-স্তরের (A1) সাথে একটি সাইট শেয়ার করে, যদিও এর মধ্যে ক্রস-সাইট iframe B থাকে। যদি A2-এর ডিফল্টরূপে পার্টিশনবিহীন স্টোরেজ অ্যাক্সেস থাকে তবে এটি A2-কে ক্লিকজ্যাকিংয়ের মতো নিরাপত্তা ঝুঁকির সম্মুখীন করতে পারে।

এই সমস্যা সমাধানের জন্য, ক্রোম স্টোরেজ পার্টিশন কী-তে একটি "পূর্বপুরুষ বিট" যোগ করে। বর্তমান আইফ্রেম এবং শীর্ষ-স্তরের সাইটের মধ্যে কোনও ডকুমেন্ট যদি ভিন্ন (ক্রস-সাইট) উৎস থেকে আসে তবে এই বিটটি সেট হয়ে যায়। এই ক্ষেত্রে, সাইট B ক্রস-সাইট তাই বিটটি A2 এর জন্য সেট করা হবে এবং এর স্টোরেজ A1 থেকে পার্টিশন করা হবে।

যখন আইফ্রেম শৃঙ্খলে শুধুমাত্র একই-সাইট প্রেক্ষাপট থাকে (উদাহরণস্বরূপ, সাইট A1 যেখানে A2 থাকে, যেখানে A3 থাকে), তখন পূর্বপুরুষ বিট তাদের স্টোরেজকে আরও বিভাজন করবে না। এই ধরনের ক্ষেত্রে, তাদের স্টোরেজ ভাগ করা থাকে, তাদের সাধারণ উৎস এবং শীর্ষ-স্তরের সাইট দ্বারা চাবিবদ্ধ।

যেসব সাইটের চেইনড আইফ্রেম জুড়ে পার্টিশনবিহীন অ্যাক্সেসের প্রয়োজন, তাদের জন্য ক্রোম এই ব্যবহারের ক্ষেত্রে সক্ষম করার জন্য স্টোরেজ অ্যাক্সেস API প্রসারিত করার পরীক্ষা-নিরীক্ষা করছে। যেহেতু স্টোরেজ অ্যাক্সেস API-এর জন্য ফ্রেমযুক্ত সাইটটিকে স্পষ্টভাবে API চালু করতে হয়, এটি ক্লিকজ্যাকিংয়ের ঝুঁকি হ্রাস করে।

পার্টিশনের কারণে API পরিবর্তন হচ্ছে

পার্টিশনিং দ্বারা প্রভাবিত API গুলিকে নিম্নলিখিত গ্রুপে ভাগ করা যেতে পারে:

স্টোরেজ API গুলি

  • কোটা সিস্টেম
    কোটা সিস্টেমটি স্টোরেজের জন্য কত ডিস্ক স্থান বরাদ্দ করা হয়েছে তা নির্ধারণ করতে ব্যবহৃত হয়। কোটা সিস্টেম প্রতিটি পার্টিশনকে একটি পৃথক বাকেট হিসাবে পরিচালনা করে, কত স্থান অনুমোদিত এবং কখন এটি খালি করা হবে তা নির্ধারণ করে।
    navigator.storage.estimate() পদ্ধতি এখন স্টোরেজ পার্টিশনের জন্য নির্দিষ্ট তথ্য প্রদান করে। window.webkitStorageInfo এবং navigator.webkitTemporaryStorage এর মতো Chrome-কেবল API গুলি বন্ধ করা হয়েছে।
    IndexedDB এবং ক্যাশে স্টোরেজ পার্টিশন করা কোটা সিস্টেম ব্যবহার করে।
  • ওয়েব স্টোরেজ API
    ওয়েব স্টোরেজ API এমন একটি প্রক্রিয়া প্রদান করে যার মাধ্যমে ব্রাউজারগুলি কী-মান জোড়া সংরক্ষণ করতে পারে। দুটি প্রক্রিয়া রয়েছে: স্থানীয় স্টোরেজ এবং সেশন স্টোরেজ । এগুলি কোটা-পরিচালিত নয়, তবে এখনও বিভাজিত।
  • অরিজিন প্রাইভেট ফাইল সিস্টেম
    ব্যবহারকারীর অ্যাক্সেস মঞ্জুর করার পর ফাইল সিস্টেম অ্যাক্সেস API একটি সাইটকে ডিভাইসের ফাইল এবং ফোল্ডারে সরাসরি পরিবর্তনগুলি পড়তে বা সংরক্ষণ করতে দেয়। অরিজিন প্রাইভেট ফাইল সিস্টেম একটি অরিজিনকে সরাসরি ডিস্কে ব্যক্তিগত সামগ্রী সংরক্ষণ করতে সক্ষম করে। এই সামগ্রীটি ব্যবহারকারীর জন্য অ্যাক্সেসযোগ্য থাকে তবে এখন এটি পার্টিশন করা হয়েছে।
  • স্টোরেজ বাকেট API
    স্টোরেজ বাকেট এপিআই স্টোরেজ স্ট্যান্ডার্ডের জন্য তৈরি করা হচ্ছে যা বাকেট নামক একটি নতুন ধারণা ব্যবহার করে বিভিন্ন স্টোরেজ এপিআই যেমন ইনডেক্সডডিবি এবং লোকালস্টোরেজকে একত্রিত করে। বাকেটগুলিতে সংরক্ষিত ডেটা এবং বাকেটের সাথে সম্পর্কিত মেটাডেটা পার্টিশন করা হয়।
  • ক্লিয়ার-সাইট-ডেটা হেডার
    প্রতিক্রিয়ায় Clear-Site-Data হেডার অন্তর্ভুক্ত করলে সার্ভার ব্যবহারকারীর ব্রাউজারে সংরক্ষিত ডেটা সাফ করার অনুরোধ করতে পারে। ক্যাশে, কুকিজ এবং DOM স্টোরেজ সাফ করা যেতে পারে। হেডার ব্যবহার করলে শুধুমাত্র একটি পার্টিশনের মধ্যে থাকা স্টোরেজ সাফ হয়।
  • ব্লব ইউআরএল স্টোর
    একটি ব্লব ইউআরএল একটি ব্লব , যা কাঁচা ডেটা ধারণ করে এমন একটি বস্তুতে অ্যাক্সেস প্রদান করে। স্টোরেজ পার্টিশন ছাড়াই, একটি সাইটের তৃতীয়-পক্ষের আইফ্রেমে তৈরি একটি ব্লব ইউআরএল অন্য সাইটে এমবেড করা একই-অরিজিন আইফ্রেমে ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, যদি example.com আইফ্রেমগুলি a.com এবং b.com উভয়েই এমবেড করা থাকে, তাহলে a.com এ এমবেড করা আইফ্রেমে তৈরি একটি ব্লব ইউআরএল কোনও বিধিনিষেধ ছাড়াই a.com এ এমবেড করা b.com পাস করা যেতে পারে এবং তারপর ব্যবহার করা যেতে পারে। Chrome 137 (27 মে, 2025 সালে প্রকাশিত) থেকে শুরু করে, ব্লব ইউআরএলগুলি শীর্ষ-স্তরের নেভিগেশন ছাড়া সকল ব্যবহারের জন্য পার্টিশন করা হয়। এখন যে ক্ষেত্রে ব্লক করা হবে তার মধ্যে রয়েছে যখন ক্রস-পার্টিশন ব্লব ইউআরএলগুলি fetch() দিয়ে বা বিভিন্ন HTML উপাদানের জন্য src অ্যাট্রিবিউট মান হিসাবে ব্যবহার করা হয়। ব্লব ইউআরএলগুলিতে window.open() কল করা বা target='_blank' সহ কোনও লিঙ্কে ক্লিক করার মতো শীর্ষ-স্তরের নেভিগেশনগুলি ক্রস-পার্টিশন হলে ব্লক করা হবে না, তবে ব্লব ইউআরএল সাইটটি যদি নেভিগেশন শুরু করা পৃষ্ঠার শীর্ষ-স্তরের সাইট থেকে ক্রস-সাইট হয় তবে noopener প্রয়োগ করা হবে। noopener প্রয়োগ করার অর্থ হল নেভিগেশন শুরু করা ডকুমেন্টটি খোলা ব্লব ইউআরএল ডকুমেন্টের জন্য একটি উইন্ডো হ্যান্ডেল পেতে বাধা দেবে। পূর্ববর্তী উদাহরণে, পার্টিশনিং b.com এর আইফ্রেমকে ব্লব ইউআরএলের বিষয়বস্তু আনতে বাধা দেবে কিন্তু এটি এখনও window.open() করতে সক্ষম হবে।

যোগাযোগ API গুলি

স্টোরেজ API-এর পাশাপাশি, যে যোগাযোগ APIগুলি একটি প্রসঙ্গকে মূল সীমানা জুড়ে যোগাযোগ করার অনুমতি দেয় সেগুলিও বিভক্ত। পরিবর্তনগুলি মূলত সেই APIগুলিকে প্রভাবিত করে যা সম্প্রচার বা একই-অরিজিন মিলনস্থল ব্যবহার করে অন্যান্য প্রসঙ্গ আবিষ্কারের অনুমতি দেয়।

পার্টিশনের কারণে, নিম্নলিখিত যোগাযোগ API গুলি তৃতীয়-পক্ষের আইফ্রেমগুলিকে তাদের একই-উৎপত্তিগত প্রেক্ষাপটের সাথে ডেটা বিনিময় করতে বাধা দেয়:

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

সার্ভিস ওয়ার্কার এপিআই

সার্ভিস ওয়ার্কার এপিআই সাইটগুলিকে ব্যাকগ্রাউন্ডে কাজ সম্পাদন করার অনুমতি দেয়। সাইটগুলি এমন পরিষেবা কর্মীদের নিবন্ধন করে যারা ইভেন্টগুলিতে প্রতিক্রিয়া জানাতে নতুন কর্মী প্রসঙ্গ তৈরি করে। ঐতিহ্যগতভাবে, এই কর্মীরা যেকোনো একই-উৎপত্তিগত প্রসঙ্গ দিয়ে যোগাযোগ করতে পারে। তবে, যেহেতু পরিষেবা কর্মীরা নেভিগেশন অনুরোধের সময় পরিবর্তন করতে পারে, তাই তারা ইতিহাস স্নিফিংয়ের মতো ক্রস-সাইট তথ্য ফাঁসের ঝুঁকি তৈরি করে।

এই কারণে, তৃতীয় পক্ষের প্রেক্ষাপট থেকে নিবন্ধিত পরিষেবা কর্মীরা এখন বিভক্ত।

এক্সটেনশন API গুলি

এক্সটেনশন হল এমন প্রোগ্রাম যা ব্যবহারকারীদের তাদের ব্রাউজিং অভিজ্ঞতা কাস্টমাইজ করতে দেয়।

এক্সটেনশন পৃষ্ঠাগুলি ( chrome-extension:// স্কিম সহ পৃষ্ঠাগুলি) ওয়েব জুড়ে বিভিন্ন সাইটে এম্বেড করা যেতে পারে। এই পরিস্থিতিতে, এক্সটেনশন পৃষ্ঠাগুলি তাদের শীর্ষ-স্তরের পার্টিশনে অ্যাক্সেস অব্যাহত রাখে। এক্সটেনশনগুলি অন্যান্য সাইটগুলিও এম্বেড করতে পারে; যখন তারা তা করে, তখন সেই এম্বেড করা সাইটগুলি তাদের শীর্ষ-স্তরের পার্টিশন অ্যাক্সেস করবে, যদি এক্সটেনশনের জন্য হোস্ট অনুমতি থাকে।

আরও তথ্যের জন্য, এক্সটেনশন ডক্স দেখুন।

ডেমো: স্টোরেজ পার্টিশন পরীক্ষা করা হচ্ছে

ডেমো সাইট: https://storage-partitioning-demo-site-a.glitch.me/

ডেমো সাইটে বাম দিকে সবুজ টিক এবং ডানদিকে লাল ক্রস দেখানো হচ্ছে।
ডেমোটির স্ক্রিনশট, যেখানে বাম দিকে স্টোরেজ পার্টিশন সহ এবং ডানদিকে স্টোরেজ পার্টিশন ছাড়াই ব্রাউজারের আউটপুট দেখানো হচ্ছে।

ডেমোটি দুটি সাইট ব্যবহার করে: সাইট A এবং সাইট B।

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

আপাতত, আপনি --disable-features=ThirdPartyStoragePartitioning কমান্ড-লাইন সুইচ ব্যবহার করে Chrome-এ স্টোরেজ পার্টিশনিং বন্ধ করতে পারেন। দ্রষ্টব্য: এই কমান্ড-লাইন সুইচটি ডেভেলপমেন্ট এবং পরীক্ষার উদ্দেশ্যে তৈরি এবং ভবিষ্যতে Chrome সংস্করণগুলিতে এটি সরানো বা পরিবর্তন করা হতে পারে।

আপনি অন্যান্য ব্রাউজারগুলিকেও একইভাবে পরীক্ষা করে দেখতে পারেন তাদের পার্টিশনের অবস্থা দেখতে।

অতিরিক্ত মাইগ্রেশন সময়ের জন্য অনুরোধ করুন

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

আরও জানতে স্টোরেজ পার্টিশনিং ডিপ্রিকেশন ট্রায়াল রিনিউয়াল দেখুন।

অংশগ্রহণ করুন এবং মতামত শেয়ার করুন