ব্যক্তিগত নেটওয়ার্ক অ্যাক্সেস আপডেট: একটি অবচয় ট্রায়াল উপস্থাপন করা হচ্ছে

Titouan Rigoudy

Yifan Luo

আপডেট

• 23 মার্চ, 2023 : টাইমলাইন আপডেট করা হয়েছে এবং Chrome 117 পর্যন্ত অবচয় ঘটবে না।

• জানুয়ারী 19, 2023 : টাইমলাইন আপডেট করা হয়েছে এবং Chrome 114 পর্যন্ত অবচয় ঘটবে না।

• 12 আগস্ট, 2022 : টাইমলাইন আপডেট করা হয়েছে এবং Chrome 109 পর্যন্ত অবচয় ঘটবে না।

• ফেব্রুয়ারী 10, 2022 : প্রাইভেট নেটওয়ার্ক অ্যাক্সেসে একটি আপডেট করা নিবন্ধ প্রকাশিত হয়েছে: প্রিফ্লাইটগুলি প্রবর্তন করা হচ্ছে

• আগস্ট 25, 2021 : আপডেট করা টাইমলাইন ঘোষণা এবং একটি অবচয় বিচারের প্রবর্তন।

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

Chrome নিম্নলিখিত পরিবর্তনগুলি প্রবর্তন করবে:

• Chrome 94 এ শুরু হওয়া অনিরাপদ পাবলিক ওয়েবসাইট থেকে ব্যক্তিগত নেটওয়ার্কে অনুরোধ ব্লক করা।
• একটি অবমূল্যায়ন ট্রায়াল উপস্থাপন করা হচ্ছে যা Chrome-এ শেষ হবে৷
  1. এটি ডেভেলপারদের বেছে নেওয়া উৎসের জন্য একটি সময় বাড়ানোর অনুরোধ করার অনুমতি দেবে, যা অবচয় ট্রায়ালের সময় প্রভাবিত হবে না।
• একটি Chrome নীতি প্রবর্তন করা হচ্ছে যা পরিচালিত ক্রোম স্থাপনাগুলিকে স্থায়ীভাবে অবচয়কে বাইপাস করার অনুমতি দেবে৷ Chrome 92 এ উপলব্ধ।

অবচয় ট্রায়ালের জন্য অবচয় রেজিস্টারের প্রভাব প্রশমিত করার জন্য আপনার যদি আরও সময়ের প্রয়োজন হয়।

আপনার ব্যবহারকারীদের উপর আপনার প্রশাসনিক নিয়ন্ত্রণ থাকলে, আপনি Chrome নীতিগুলি ব্যবহার করে বৈশিষ্ট্যটি পুনরায় সক্ষম করতে পারেন৷

নতুন বিধিনিষেধের প্রভাব কমাতে, নিম্নলিখিত কৌশলগুলির মধ্যে একটি ব্যবহার করুন:

• আপনার ওয়েবসাইট আপগ্রেড করুন HTTPS, এবং প্রয়োজনে লক্ষ্য সার্ভারে ।
• আপনার ওয়েবসাইটকে HTTPS-এ আপগ্রেড করুন এবং WebTransport ব্যবহার করুন ।
• এম্বেডিং সম্পর্ক বিপরীত .

টাইমলাইন

• নভেম্বর 2020: আসন্ন পরিবর্তন সম্পর্কে মতামতের জন্য কল করুন ।
• মার্চ 2021: প্রতিক্রিয়া পর্যালোচনা এবং আউটরিচ করার পরে, আসন্ন পরিবর্তনগুলি ঘোষণা করা হয়। স্পেসিফিকেশনের নামকরণ করা হয়েছে CORS-RFC1918 থেকে প্রাইভেট নেটওয়ার্ক অ্যাক্সেসে।
• এপ্রিল 2021: Chrome 90 স্থিতিশীল-এ রোল আউট, অবচয় সংক্রান্ত সতর্কতাগুলিকে সামনে রেখে৷
• জুন 2021: ক্রোম 92 বিটাতে রোল আউট, অনিরাপদ প্রসঙ্গ থেকে ব্যক্তিগত নেটওয়ার্ক অনুরোধ নিষিদ্ধ করে। সামঞ্জস্য করার জন্য আরও সময় দেওয়ার অনুরোধ ডেভেলপারদের প্রতিক্রিয়ার পরে, অবচয়কে স্থগিত করা হয়েছে Chrome 93-এ, একটি অবচয় ট্রায়ালের সাথে।
• জুলাই 2021: ডেভেলপারদের কাছ থেকে আরও প্রতিক্রিয়ার পরে, অবচয়ন এবং সহগামী ট্রায়াল Chrome 94-এ স্থগিত করা হয়েছে। উপরন্তু, ব্যক্তিগত ওয়েবসাইটগুলি আর অবচয় দ্বারা প্রভাবিত হয় না।
• আগস্ট 2021: Chrome 94 বিটাতে রোল আউট। ওয়েব ডেভেলপাররা অবচয় ট্রায়ালের জন্য সাইন আপ করা শুরু করতে পারেন।
• সেপ্টেম্বর 2021: Chrome 94 Stable-এ রোল আউট। ওয়েব ডেভেলপারদের অবচয় ট্রায়ালের জন্য সাইন আপ করা উচিত ছিল এবং উৎপাদনে ট্রায়াল টোকেন স্থাপন করা উচিত ছিল।
• ডিসেম্বর 2022: অরিজিন ট্রায়াল সমীক্ষা পাঠানো হয়েছে এবং প্রতিক্রিয়া পাওয়া গেছে। অবচয় ট্রায়াল Chrome 113 পর্যন্ত প্রসারিত করা হয়েছে।
• মার্চ 2023: অবচয় ট্রায়াল Chrome 116-এ প্রসারিত করা হয়েছে, এবং Chrome 117-এ শেষ হতে সেট করা হয়েছে৷ Chrome 114-এ প্রাথমিক রিলিজকে লক্ষ্য করে একটি অনুমতি-ভিত্তিক বিকল্প প্রক্রিয়া তৈরি করা হচ্ছে৷
• মে 2023 (অস্থায়ী): অনুমতি-ভিত্তিক প্রক্রিয়াটি Chrome 114-এ রোল আউট করা হয়েছে। ওয়েবসাইটগুলি এটিকে অবচয় ট্রায়াল থেকে বেরিয়ে আসতে ব্যবহার করতে পারে।
• সেপ্টেম্বর 2023: Chrome 117 Stable-এ রোল আউট, অবচয় ট্রায়ালের সমাপ্তি। ক্রোম সর্বজনীন, অ-সুরক্ষিত প্রসঙ্গ থেকে সমস্ত ব্যক্তিগত নেটওয়ার্ক অনুরোধগুলিকে ব্লক করে৷

ব্যক্তিগত নেটওয়ার্ক অ্যাক্সেস কি

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

প্রাইভেট নেটওয়ার্ক রিকোয়েস্ট হল এমন অনুরোধ যার টার্গেট সার্ভারের আইপি অ্যাড্রেস তার থেকে বেশি ব্যক্তিগত যেখান থেকে রিকোয়েস্ট ইনিশিয়েটর আনা হয়েছিল। উদাহরণস্বরূপ, একটি সর্বজনীন ওয়েবসাইট ( https://example.com ) থেকে একটি ব্যক্তিগত ওয়েবসাইট ( http://router.local ) থেকে একটি অনুরোধ বা একটি ব্যক্তিগত ওয়েবসাইট থেকে স্থানীয় হোস্টের কাছে একটি অনুরোধ৷

ব্যক্তিগত নেটওয়ার্ক অ্যাক্সেস (CORS-RFC1918) এ সরকারী, ব্যক্তিগত, স্থানীয় নেটওয়ার্কগুলির মধ্যে সম্পর্ক।

ফিডব্যাক ওয়ান্টেড এ আরও জানুন: ব্যক্তিগত নেটওয়ার্কের জন্য CORS (RFC1918) ।

একটি অবচয় ট্রায়াল কি

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

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

আরও তথ্যের জন্য, Chrome এর অরিজিন ট্রায়ালের সাথে শুরু করা এবং নির্দেশাবলীর জন্য ওয়েব ডেভেলপার নির্দেশিকা অরিজিন ট্রায়াল দেখুন।

Chrome এ কি পরিবর্তন হচ্ছে

ক্রোম 94

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

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

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

ক্রোম 117

অবচয় ট্রায়াল শেষ হয়. সমস্ত ওয়েবসাইটকে অবশ্যই অবহেলিত বৈশিষ্ট্য থেকে স্থানান্তরিত করতে হবে, বা বৈশিষ্ট্যটি সক্ষম করা চালিয়ে যাওয়ার জন্য তাদের ব্যবহারকারীদের নীতিগুলি কনফিগার করা উচিত।

প্রস্তাবিত ডেভেলপার অ্যাকশন

প্রভাবিত ওয়েবসাইটগুলির জন্য প্রথম পদক্ষেপটি একটি সঠিক সমাধান স্থাপন করা না হওয়া পর্যন্ত কিছু সময় কেনার সম্ভাবনা বেশি: হয় অবচয় ট্রায়ালের জন্য নিবন্ধন করে বা নীতি ব্যবহার করে৷ তারপরে, প্রতিটি প্রভাবিত ওয়েবসাইটের পরিস্থিতির উপর নির্ভর করে প্রস্তাবিত পদক্ষেপটি পরিবর্তিত হয়।

অবমূল্যায়নের বিচারের জন্য নিবন্ধন করুন

দ্রষ্টব্য: একাধিক উত্সের সাথে অংশগ্রহণ করতে (যেমন examplepetstore.com এবং example-pet-store.com ), প্রতিটি উত্সের জন্য এই পদক্ষেপগুলি পুনরাবৃত্তি করুন৷

1. অংশগ্রহণকারী উত্সের জন্য একটি ট্রায়াল টোকেন পেতে অ-সুরক্ষিত প্রসঙ্গ উত্স ট্রায়াল থেকে ব্যক্তিগত নেটওয়ার্ক অ্যাক্সেসের জন্য নিবন্ধন করুন ক্লিক করুন৷
2. অরিজিন-নির্দিষ্ট Origin-Trial: $token আপনার প্রতিক্রিয়া হেডারে $token। এই প্রতিক্রিয়া শিরোনামটি শুধুমাত্র প্রধান সংস্থান এবং নেভিগেশন প্রতিক্রিয়াগুলিতে সেট করা প্রয়োজন যখন ফলাফল নথিটি অবহেলিত বৈশিষ্ট্য ব্যবহার করে। সাবরিসোর্স প্রতিক্রিয়াগুলির সাথে এই শিরোনামটি সংযুক্ত করা অকেজো (যদিও নিরীহ)।

যেহেতু কোনো ডকুমেন্টকে কোনো অনুরোধ করার অনুমতি দেওয়ার আগে এই ট্রায়ালটি সক্রিয় বা নিষ্ক্রিয় করা আবশ্যক, তাই এটি একটি <meta> ট্যাগের মাধ্যমে সক্ষম করা যাবে না । সাবরিসোর্স অনুরোধ জারি হওয়ার পরে এই ধরনের ট্যাগগুলি শুধুমাত্র প্রতিক্রিয়া বডি থেকে পার্স করা হয়। এটি এমন ওয়েবসাইটগুলির জন্য একটি চ্যালেঞ্জ উপস্থাপন করে যা প্রতিক্রিয়া শিরোনামগুলির নিয়ন্ত্রণে নেই, যেমন github.io স্ট্যাটিক ওয়েবসাইটগুলি তৃতীয় পক্ষ দ্বারা পরিবেশিত হয়৷

আরও বিশদ বিবরণের জন্য, মূল ট্রায়ালের জন্য ওয়েব বিকাশকারী নির্দেশিকা দেখুন।

নীতিগুলি সক্ষম করুন৷

যদি আপনার ব্যবহারকারীদের উপর আপনার প্রশাসনিক নিয়ন্ত্রণ থাকে, তাহলে আপনি নিম্নোক্ত নীতিগুলির যেকোনো একটি ব্যবহার করে অবমূল্যায়িত বৈশিষ্ট্যটিকে পুনরায় সক্ষম করতে পারেন:

• অনিরাপদ প্রাইভেট নেটওয়ার্কের অনুরোধ অনুমোদিত৷
• InsecurePrivateNetworkRequestsAllowedForUrls

আপনার ব্যবহারকারীদের জন্য নীতি পরিচালনার বিষয়ে আরও বিশদ বিবরণের জন্য, এই সহায়তা কেন্দ্র নিবন্ধটি দেখুন।

স্থানীয় হোস্ট অ্যাক্সেস করা হচ্ছে

যদি আপনার ওয়েবসাইটকে লোকালহোস্টে অনুরোধ জারি করতে হয়, তাহলে আপনাকে শুধু আপনার ওয়েবসাইটটিকে HTTPS-এ আপগ্রেড করতে হবে।

http://localhost (বা http://127.*.*.* , http://[::1] ) টার্গেট করা অনুরোধগুলি মিশ্র বিষয়বস্তু দ্বারা ব্লক করা হয় না, এমনকি নিরাপদ প্রসঙ্গ থেকে জারি করা হলেও।

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

ব্যক্তিগত আইপি ঠিকানা অ্যাক্সেস করা

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

• HTTPS-এ উভয় প্রান্ত আপগ্রেড করুন।
• টার্গেট সার্ভারের সাথে নিরাপদে সংযোগ করতে WebTransport ব্যবহার করুন।
• এম্বেডিং সম্পর্ক বিপরীত.

HTTPS-এ উভয় প্রান্ত আপগ্রেড করুন

এই সমাধানটির জন্য ব্যবহারকারীদের DNS রেজোলিউশনের উপর নিয়ন্ত্রণ প্রয়োজন, যেমন ইন্ট্রানেট প্রসঙ্গে হতে পারে, অথবা ব্যবহারকারীরা আপনার নিয়ন্ত্রণে থাকা DHCP সার্ভার থেকে তাদের নাম সার্ভারের ঠিকানাগুলি গ্রহণ করলে। এটি আপনার একটি সর্বজনীন ডোমেইন নাম থাকা প্রয়োজন।

HTTPS-এর মাধ্যমে ব্যক্তিগত ওয়েবসাইটগুলি পরিবেশন করার প্রধান সমস্যা হল যে পাবলিক কী ইনফ্রাস্ট্রাকচার সার্টিফিকেট অথরিটি (PKI CA) শুধুমাত্র পাবলিক ডোমেন নাম সহ ওয়েবসাইটগুলিতে TLS সার্টিফিকেট প্রদান করে। এই চারপাশে কাজ করতে:

1. একটি সর্বজনীন ডোমেন নাম নিবন্ধন করুন (উদাহরণস্বরূপ, intranet.example ) এবং সেই ডোমেন নামটিকে আপনার পছন্দের একটি সর্বজনীন সার্ভারে নির্দেশ করে DNS রেকর্ড প্রকাশ করুন৷
2. intranet.example এর জন্য একটি TLS শংসাপত্র পান।
3. আপনার ব্যক্তিগত নেটওয়ার্কের ভিতরে, টার্গেট সার্ভারের ব্যক্তিগত IP ঠিকানায় intranet.example সমাধান করতে DNS কনফিগার করুন।
4. intranet.example এর জন্য TLS শংসাপত্র ব্যবহার করতে আপনার ব্যক্তিগত সার্ভার কনফিগার করুন। এটি আপনার ব্যবহারকারীদের https://intranet.example এ ব্যক্তিগত সার্ভার অ্যাক্সেস করতে দেয়।

তারপরে আপনি HTTPS-এ অনুরোধগুলি শুরু করার ওয়েবসাইটটিকে আপগ্রেড করতে পারেন এবং আগের মতো অনুরোধগুলি চালিয়ে যেতে পারেন।

এই সমাধানটি ভবিষ্যৎ-প্রমাণ এবং আপনার নেটওয়ার্কে আপনার যে বিশ্বাস স্থাপন করে তা হ্রাস করে, আপনার ব্যক্তিগত নেটওয়ার্কের মধ্যে এন্ড-টু-এন্ড এনক্রিপশনের ব্যবহারকে প্রসারিত করে।

ওয়েব ট্রান্সপোর্ট

এই সমাধানটির জন্য আপনার ব্যবহারকারীদের DNS রেজোলিউশনের উপর নিয়ন্ত্রণের প্রয়োজন নেই। এটির প্রয়োজন হয় যে লক্ষ্য সার্ভারটি একটি ন্যূনতম ওয়েব ট্রান্সপোর্ট সার্ভার চালাবে (কিছু পরিবর্তন সহ HTTP/3 সার্ভার)।

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

আমরা স্বীকার করি যে এটি একটি ন্যায্য পরিমাণ কাজের প্রতিনিধিত্ব করে, তবে এটি WebRTC-এর উপরে নির্মাণের চেয়ে উল্লেখযোগ্যভাবে সহজ হওয়া উচিত; আমাদের আশা এই যে প্রয়োজনীয় বিনিয়োগের কিছু পরিমাণ পুনঃব্যবহারযোগ্য লাইব্রেরি হিসেবে বাস্তবায়িত হবে। আমরা এটিকে বিশেষভাবে সার্থক বলে মনে করি যে অ-সুরক্ষিত প্রসঙ্গগুলি আরও বেশি ওয়েব প্ল্যাটফর্ম বৈশিষ্ট্যগুলিতে অ্যাক্সেস হারাতে পারে কারণ প্ল্যাটফর্মটি সময়ের সাথে সাথে আরও শক্তিশালী উপায়ে HTTPS ব্যবহারকে উত্সাহিত করার দিকে এগিয়ে যায়৷ প্রাইভেট নেটওয়ার্ক অ্যাক্সেস নির্বিশেষে, এটি সম্ভবত একটি বুদ্ধিমান বিনিয়োগ হবে।

আমরা আশা করি HTTP/3-এর উপর WebTransport Chrome 96-এ শিপ করবে (এটি একটি মূল ট্রায়াল শুরু করেছে) কী শেয়ারিং এবং অন্যান্য নিম্নমানের নিরাপত্তা অনুশীলনের বিরুদ্ধে সুরক্ষার জন্য প্রশমন সহ:

• পিন করা শংসাপত্রের জন্য একটি সংক্ষিপ্ত সর্বোচ্চ মেয়াদ শেষ হওয়ার সময়।
• অপব্যবহারের সাপেক্ষে কিছু কী প্রত্যাহার করার জন্য একটি ব্রাউজার-নির্দিষ্ট প্রক্রিয়া।

WebTransport সম্পূর্ণরূপে চালু হওয়ার পর অন্তত দুই মাইলফলক না হওয়া পর্যন্ত আমরা নিরাপদ প্রসঙ্গ সীমাবদ্ধতা পাঠাব না। প্রয়োজনে অবচয় ট্রায়াল বাড়ানো হবে।

বিপরীত এমবেডিং

এই সমাধানটির জন্য নেটওয়ার্কের উপর কোনো প্রশাসনিক নিয়ন্ত্রণের প্রয়োজন নেই, এবং লক্ষ্য সার্ভারটি HTTPS চালানোর জন্য যথেষ্ট শক্তিশালী না হলে ব্যবহার করা যেতে পারে।

একটি পাবলিক ওয়েব অ্যাপ থেকে ব্যক্তিগত সাবরিসোর্সগুলি আনার পরিবর্তে, অ্যাপের একটি কঙ্কাল ব্যক্তিগত সার্ভার থেকে পরিবেশন করা যেতে পারে, যা তারপরে একটি পাবলিক সার্ভার থেকে, যেমন একটি CDN থেকে তার সমস্ত সাবরিসোর্স (যেমন স্ক্রিপ্ট বা ছবি) নিয়ে আসে৷ ফলস্বরূপ ওয়েব অ্যাপটি ব্যক্তিগত সার্ভারে অনুরোধ করতে পারে, কারণ এগুলি একই-উৎস হিসাবে বিবেচিত হয়। এমনকি এটি ব্যক্তিগত আইপি সহ অন্যান্য সার্ভারগুলিতে অনুরোধ করতে পারে (কিন্তু লোকালহোস্ট নয়), যদিও এটি দীর্ঘমেয়াদে পরিবর্তিত হতে পারে।

ব্যক্তিগত সার্ভারে শুধুমাত্র একটি কঙ্কাল হোস্ট করে, আপনি পাবলিক সার্ভারে নতুন রিসোর্স পুশ করে ওয়েব অ্যাপ আপডেট করতে পারেন, ঠিক যেমন আপনি একটি পাবলিক ওয়েব অ্যাপ আপডেট করবেন। অন্যদিকে, ফলস্বরূপ ওয়েব অ্যাপটি একটি সুরক্ষিত প্রসঙ্গ নয়, তাই এটির ওয়েবের আরও শক্তিশালী কিছু বৈশিষ্ট্যে অ্যাক্সেস নেই।

ভবিষ্যতের জন্য পরিকল্পনা

প্রাইভেট নেটওয়ার্কের অনুরোধগুলিকে সুরক্ষিত প্রেক্ষাপটে সীমাবদ্ধ করা ব্যক্তিগত নেটওয়ার্ক অ্যাক্সেস চালু করার প্রথম পদক্ষেপ। Chrome আগামী মাসে বাকি স্পেসিফিকেশন বাস্তবায়নের দিকে কাজ করছে। আপডেটের জন্য সাথে থাকুন!

ব্যক্তিগত ওয়েবসাইট থেকে স্থানীয় হোস্ট অ্যাক্সেস সীমাবদ্ধ করা

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

CORS প্রিফ্লাইট অনুরোধ

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

সংক্ষেপে, একটি CORS প্রিফ্লাইট অনুরোধ হল একটি HTTP OPTIONS অনুরোধ যাতে কিছু Access-Control-Request-* শিরোনাম থাকে যা পরবর্তী অনুরোধের প্রকৃতি নির্দেশ করে। সার্ভার তারপর Access-Control-Allow-* শিরোনামগুলির সাথে 200 OK উত্তর দিয়ে সূক্ষ্ম-দানাযুক্ত অ্যাক্সেস মঞ্জুর করবে কিনা তা সিদ্ধান্ত নিতে পারে।

স্পেসিফিকেশনে এই সম্পর্কে আরও বিশদ খুঁজুন।

নেভিগেশন ফেচ সীমাবদ্ধ করুন

Chrome অবহেলা করছে এবং অবশেষে ব্যক্তিগত নেটওয়ার্কগুলিতে সাবরিসোর্স অনুরোধগুলিকে ব্লক করছে৷ এটি ব্যক্তিগত নেটওয়ার্কগুলিতে নেভিগেশনকে প্রভাবিত করবে না, যা CSRF আক্রমণেও ব্যবহার করা যেতে পারে।

প্রাইভেট নেটওয়ার্ক অ্যাক্সেস স্পেসিফিকেশন দুটি ধরণের আনার মধ্যে পার্থক্য করে না, যা শেষ পর্যন্ত একই বিধিনিষেধের অধীন হবে।

Unsplash- এ Markus Spiske- এর কভার ফটো