এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

বিচ্ছিন্ন ওয়েব অ্যাপস

দ্রষ্টব্য: আইসোলেটেড ওয়েব অ্যাপের প্রাথমিক প্রকাশ, এবং যেকোনো উচ্চ-বিশ্বাসযোগ্য API যার জন্য এগুলোর প্রয়োজন, শুধুমাত্র Chrome এন্টারপ্রাইজ পরিচালিত ChromeOS ডিভাইস এবং নির্বাচিত ডেভেলপমেন্ট পার্টনারদের জন্য উপলব্ধ থাকবে। আমরা ভবিষ্যতে এটি অতিরিক্ত পার্টনার এবং অ-পরিচালিত এবং ক্রস-প্ল্যাটফর্ম ডিভাইসগুলিতে প্রসারিত করার চেষ্টা করছি।

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

যেহেতু ওয়েব ডিফল্টভাবে নিরাপদ এবং সুরক্ষিত থাকার লক্ষ্য রাখে, তাই এর নিরাপত্তা মডেলটি খুব রক্ষণশীল হওয়া প্রয়োজন। যেকোনো নতুন ক্ষমতা যুক্ত করা হলে তা নিরাপদ হওয়া উচিত যাতে একজন সাধারণ ব্যবহারকারী দুর্ঘটনাক্রমে একটি URL এর মাধ্যমে দেখতে না পান। আমরা এই নিরাপত্তা মডেলটিকে drive by web বলি। যদিও এটি অনেক অ্যাপ্লিকেশনের জন্য দুর্দান্ত, এবং Content Security Policies এবং cross-origin isolation ব্যবহার করে আরও সুরক্ষিত করা যেতে পারে, এটি প্রতিটি ব্যবহারের ক্ষেত্রে কাজ করে না। ডাইরেক্ট সকেট এবং কন্ট্রোলড ফ্রেমের মতো বেশ কয়েকটি গুরুত্বপূর্ণ এবং অত্যন্ত শক্তিশালী API, যা ডেভেলপারদের প্রয়োজন, তা drive by web এর জন্য যথেষ্ট নিরাপদ করা যায় না।

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

ওয়েবে আস্থার এক বিস্তৃত পরিসর

আপনি ওয়েবে নিরাপত্তা এবং সক্ষমতা সম্পর্কে একটি বর্ণালীর পরিপ্রেক্ষিতে ভাবতে পারেন।

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

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

তারপর আছে উচ্চ-বিশ্বাসযোগ্য, আইসোলেটেড ওয়েব অ্যাপ্লিকেশন।

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

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

নকশা দ্বারা সুরক্ষিত

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

প্যাকেজ করা

আইসোলেটেড ওয়েব অ্যাপের জন্য পৃষ্ঠা এবং সম্পদগুলি লাইভ সার্ভার থেকে পরিবেশন করা যাবে না বা সাধারণ ওয়েব অ্যাপ্লিকেশনের মতো নেটওয়ার্কের মাধ্যমে আনা যাবে না। পরিবর্তে, নতুন উচ্চ-বিশ্বাসের সুরক্ষা মডেলে অ্যাক্সেস পেতে, ওয়েব অ্যাপগুলিকে একটি Signed WebBundle- এ চালানোর জন্য প্রয়োজনীয় সমস্ত সংস্থান প্যাকেজ করতে হবে। Signed ওয়েব বান্ডেলগুলি একটি সাইট চালানোর জন্য প্রয়োজনীয় সমস্ত সংস্থান গ্রহণ করে এবং সেগুলিকে একটি .swbn ফাইলে প্যাকেজ করে, একটি integrity block- এর সাথে সংযুক্ত করে। এটি ওয়েব অ্যাপটিকে সম্পূর্ণরূপে নিরাপদে ডাউনলোড করার অনুমতি দেয়, এমনকি অফলাইনে থাকাকালীনও শেয়ার বা ইনস্টল করার অনুমতি দেয়।

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

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

সাইনিং কী তৈরি করুন

সাইনিং কীগুলি হল Ed25519 অথবা ECDSA P-256 কী জোড়া, যেখানে বান্ডেল সাইন করার জন্য প্রাইভেট কী এবং বান্ডেল যাচাই করার জন্য পাবলিক কী ব্যবহার করা হয়। আপনি OpenSSL ব্যবহার করে একটি Ed25519 অথবা ECDSA P-256 কী তৈরি এবং এনক্রিপ্ট করতে পারেন:

# Generate an unencrypted Ed25519 key
openssl genpkey -algorithm Ed25519 -out private_key.pem

# or generate an unencrypted ECDSA P-256 key
openssl ecparam -name prime256v1 -genkey -noout -out private_key.pem

# Encrypt the generated key. This will ask for a passphrase, make sure to use a strong one
openssl pkcs8 -in private_key.pem -topk8 -out encrypted_key.pem

# Delete the unencrypted key
rm private_key.pem

সাইনিং কীগুলিরও একটি গৌণ উদ্দেশ্য রয়েছে। যেহেতু একটি ডোমেন সার্ভারের মতো নিয়ন্ত্রণ হারানোর ঝুঁকিতে থাকতে পারে, তাই এটি ইনস্টল করা IWA সনাক্ত করতে ব্যবহার করা যাবে না। পরিবর্তে, একটি IWA বান্ডেলের পাবলিক কী দ্বারা চিহ্নিত করা হয়, যা এর স্বাক্ষরের অংশ এবং প্রাইভেট কী-এর সাথে সংযুক্ত। এটি ড্রাইভ-বাই ওয়েব কীভাবে কাজ করে তার একটি উল্লেখযোগ্য পরিবর্তন, তাই HTTPS ব্যবহার করার পরিবর্তে, IWA গুলি একটি নতুন স্কিমও ব্যবহার করে: isolated-app:// ।

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

আপনার অ্যাপটি বান্ডেল করুন

আপনার সাইনিং কী উপলব্ধ থাকায়, আপনার ওয়েব অ্যাপটি বান্ডিল করার সময় এসেছে। এটি করার জন্য, আপনি অফিসিয়াল NodeJS প্যাকেজগুলি ব্যবহার করে আপনার IWA গুলি বান্ডিল করতে পারেন এবং তারপর সাইন করতে পারেন ( Go কমান্ড-লাইন টুলগুলিও উপলব্ধ )। প্রথমে, wbn প্যাকেজটি ব্যবহার করুন, যেখানে আপনার IWA এর সমস্ত প্রোডাকশন ফাইল (এখানে dist) রয়েছে এমন ফোল্ডারটি নির্দেশ করে একটি স্বাক্ষরবিহীন বান্ডিলে মুড়ে ফেলুন:

npx wbn --dir dist

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

এটি out.wbn. একবার তৈরি হয়ে গেলে, wbn-sign ব্যবহার করে সাইন ইন করার জন্য আপনার পূর্বে তৈরি করা এনক্রিপ্ট করা Ed25519 অথবা ECDSA P-256 কী ব্যবহার করুন:

npx wbn-sign -i out.wbn -k encrypted_key.pem -o signed.swbn

এটি signed.swbn নামক unsigned ওয়েব বান্ডেল থেকে একটি signed ওয়েব বান্ডেল তৈরি করবে। একবার সাইন ইন হয়ে গেলে, টুলটি ওয়েব বান্ডেল আইডি এবং এর Isolated Web App অরিজিনও আউটপুট করবে। Isolated Web App অরিজিন হল ব্রাউজারে আপনার IWA কীভাবে সনাক্ত করা হয়।

Web Bundle ID: ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic
Isolated Web App Origin: isolated-app://ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic/

যদি আপনি Webpack , Rollup , অথবা এমন কোন টুল ব্যবহার করেন যা তাদের প্লাগইনগুলিকে সমর্থন করে (যেমন Vite ), তাহলে আপনি bundler plugins ( Webpack , Rollup ) ব্যবহার করতে পারেন যা এই প্যাকেজগুলিকে সরাসরি কল করার পরিবর্তে মোড়ানো হয়। এটি করলে আপনার বিল্ডের আউটপুট হিসাবে একটি স্বাক্ষরিত বান্ডেল তৈরি হবে।

আপনার অ্যাপটি পরীক্ষা করুন

আপনি দুটি উপায়ের একটিতে আপনার IWA পরীক্ষা করতে পারেন: হয় Chrome এর অন্তর্নির্মিত IWA ডেভেলপার প্রক্সির মাধ্যমে আপনার ডেভেলপমেন্ট সার্ভারটি চালিয়ে, অথবা আপনার বান্ডেল করা IWA ইনস্টল করে। এটি করার জন্য, আপনাকে Chrome বা ChromeOS 120 বা তার পরবর্তী সংস্করণে থাকতে হবে, IWA ফ্ল্যাগগুলি সক্ষম করতে হবে এবং Chrome এর ওয়েব অ্যাপ ইন্টারনালের মাধ্যমে আপনার অ্যাপটি ইনস্টল করতে হবে:

chrome://flags/#enable-isolated-web-app-dev-mode ফ্ল্যাগটি সক্ষম করুন
chrome://web-app-internals এ Chrome-এর ওয়েব অ্যাপ ইন্টার্নাল পৃষ্ঠায় গিয়ে আপনার IWA পরীক্ষা করুন।

একবার ওয়েব অ্যাপ ইন্টার্নাল পৃষ্ঠায়, আপনার কাছে দুটি পছন্দ আছে: Install IWA with Dev Mode Proxy অথবা Install IWA from Signed Web Bundle ।

যদি আপনি একটি ডেভ মোড প্রক্সির মাধ্যমে ইনস্টল করেন, তাহলে আপনি যেকোনো URL, স্থানীয় ডেভেলপমেন্ট সার্ভার থেকে চলমান সাইটগুলি সহ, IWA হিসেবে ইনস্টল করতে পারবেন, তাদের বান্ডেল না করে, ধরে নিয়ে যে তারা অন্যান্য IWA ইনস্টলেশন প্রয়োজনীয়তা পূরণ করে। ইনস্টল করার পরে, সেই URL এর জন্য একটি IWA আপনার সিস্টেমে সঠিক সুরক্ষা নীতি এবং বিধিনিষেধ সহ যোগ করা হবে এবং IWA-কেবল API-তে অ্যাক্সেস থাকবে। এটি একটি র্যান্ডম শনাক্তকারী বরাদ্দ করা হবে। আপনার অ্যাপ্লিকেশন ডিবাগ করতে সাহায্য করার জন্য Chrome Dev Tools এই মোডেও উপলব্ধ। আপনি যদি একটি সাইনড ওয়েব বান্ডেল থেকে ইনস্টল করেন, তাহলে আপনি আপনার সাইনড, বান্ডেলড IWA আপলোড করবেন এবং এটি এমনভাবে ইনস্টল হবে যেন এটি একজন শেষ-ব্যবহারকারী দ্বারা ডাউনলোড করা হয়েছে।

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

বিচ্ছিন্ন

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

আইসোলেটেড ওয়েব অ্যাপগুলি ইন-ব্রাউজার ওয়েবসাইটগুলির চেয়ে আলাদা প্রোটোকলে চলে ( isolated-app বনাম http অথবা https )। এর অর্থ হল প্রতিটি IWA ইন-ব্রাউজারে চলমান ওয়েবসাইটগুলি থেকে সম্পূর্ণ আলাদা, এমনকি যদি সেগুলি একই কোম্পানি দ্বারা নির্মিত হয়, একই-অরিজিন নীতির জন্য ধন্যবাদ। IWA স্টোরেজও একে অপরের থেকে পৃথক। এটি একসাথে নিশ্চিত করে যে ক্রস-অরিজিন কন্টেন্ট বিভিন্ন IWA-এর মধ্যে বা IWA-এর মধ্যে এবং ব্যবহারকারীর স্বাভাবিক ব্রাউজিং প্রসঙ্গের মধ্যে লিক হতে পারে না।

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

শুধুমাত্র বান্ডেল থেকে জাভাস্ক্রিপ্ট চালানোর অনুমতি দেয়; তবে, এটি Wasm কে তার উৎস নির্বিশেষে চালানোর অনুমতি দেয়। ( script-src )
জাভাস্ক্রিপ্টকে নিরাপদ, নন-লোকালহোস্ট ক্রস-অরিজিন ডোমেন থেকে আনার, ওয়েবসকেট এবং ওয়েবট্রান্সপোর্ট এন্ডপয়েন্ট সংযোগ করার এবং ব্লব এবং ডেটা URL ( connect-src ) করার অনুমতি দেয়।
DOM ম্যানিপুলেশন ফাংশনগুলি কীভাবে ব্যবহার করা যেতে পারে তা নিয়ন্ত্রণ করে DOM ক্রস-সাইট স্ক্রিপ্ট ইনজেকশন (XSS) আক্রমণ থেকে রক্ষা করে ( require-trusted-types-for )
যেকোনো HTTPS ডোমেন ( frame-src , img-src , media-src ) থেকে ফ্রেম, ছবি, অডিও এবং ভিডিও অনুমোদন করে।
বান্ডেল এবং ব্লব থেকে ফন্টগুলিকে অনুমতি দেয় ( font-src )
বান্ডেল থেকে ইনলাইন CSS অথবা CSS ( style-src ) অনুমতি দিন।
<object> , <embed> , এবং <base> উপাদান ব্যবহার করা যাবে না ( object-src এবং base-uri )
শুধুমাত্র অন্য যেকোনো CSP-আচ্ছাদিত অনুরোধের জন্য বান্ডেল থেকে রিসোর্স অনুমোদন করে ( default-src )

Content-Security-Policy: script-src 'self' 'wasm-unsafe-eval';
  connect-src 'self' https: wss: blob: data:;
  require-trusted-types-for 'script';
  frame-src 'self' https: blob: data:;
  img-src 'self' https: blob: data:;
  media-src 'self' https: blob: data:;
  font-src 'self' blob: data:;
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
  default-src 'self';

এই CSP গুলি সম্ভাব্য ক্ষতিকারক তৃতীয়-পক্ষ কোড থেকে সম্পূর্ণরূপে সুরক্ষা দেওয়ার জন্য যথেষ্ট নয়। IWA গুলিও ক্রস-অরিজিন আইসোলেটেড , যা তৃতীয়-পক্ষের সংস্থানগুলিকে প্রভাবিত করার ক্ষমতা হ্রাস করার জন্য হেডার সেট করে:

শুধুমাত্র বান্ডেল অথবা ক্রস-অরিজিন রিসোর্স থেকে রিসোর্সগুলিকে অনুমতি দিন, যেগুলিকে স্পষ্টভাবে CORS সমর্থনকারী হিসেবে চিহ্নিত করা হয়েছে, হয় একটি ক্রস-অরিজিন রিসোর্স পলিসি (CORP) হেডার সেট অথবা crossorigin অ্যাট্রিবিউট সহ। ( Cross-Origin-Embedder-Policy )
NO-CORS ক্রস-অরিজিন অনুরোধগুলিকে অনুমোদন না করুন ( Cross-Origin-Resource-Policy )
ক্রস-অরিজিন ডকুমেন্ট থেকে ব্রাউজিং কনটেক্সট প্রক্রিয়া-বিচ্ছিন্ন করুন, window.opener রেফারেন্স এবং গ্লোবাল অবজেক্ট অ্যাক্সেস প্রতিরোধ করুন ( Cross-Origin-Opener-Policy )
সাইটটিকে একটি ফ্রেম বা আইফ্রেমের মধ্যে এমবেড করা থেকে বিরত রাখুন (CSP, frame-ancestors )

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
Content-Security-Policy: frame-ancestors 'self'

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

লক ডাউন

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

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

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

"permissions_policy": {
   "geolocation": [ "self", "https://map.example.com" ],
   "fullscreen": [ "*" ]
}

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

নামকরণ এবং সংস্করণ

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

ওয়েব অ্যাপ ম্যানিফেস্ট

আইসোলেটেড ওয়েব অ্যাপগুলি তাদের ওয়েব অ্যাপ ম্যানিফেস্টের জন্য PWA-এর মতো একই কী ম্যানিফেস্ট বৈশিষ্ট্য ভাগ করে, কিছু সামান্য পরিবর্তন সহ। উদাহরণস্বরূপ, display একটু ভিন্নভাবে কাজ করে; browser এবং minimal-ui উভয়কেই একটি minimal-ui ডিসপ্লেতে জোর করা হয়, এবং fullscreen এবং standalone উভয়কেই একটি standalone ডিসপ্লেতে জোর করা হয় (অতিরিক্ত display_override বিকল্পগুলি প্রত্যাশা অনুযায়ী কাজ করে)। এছাড়াও, আরও দুটি ক্ষেত্র অন্তর্ভুক্ত করা উচিত, version এবং update_manifest_url :

version : বিচ্ছিন্ন ওয়েব অ্যাপের জন্য প্রয়োজনীয় । একটি স্ট্রিং যা এক বা একাধিক পূর্ণসংখ্যার সমন্বয়ে গঠিত যা একটি বিন্দু ( . ) দ্বারা পৃথক করা হয়। আপনার সংস্করণটি 1 , 2 , 3 , ইত্যাদির মতো সহজ কিছু হতে পারে... অথবা SemVer ( 1.2.3 ) এর মতো জটিল কিছু হতে পারে। সংস্করণ নম্বরটি নিয়মিত এক্সপ্রেশনের সাথে মিলিত হওয়া উচিত ^(\d+.?)*\d$ ।
update_manifest_url : ঐচ্ছিক , কিন্তু প্রস্তাবিত ক্ষেত্র যা একটি HTTPS URL (অথবা পরীক্ষার জন্য localhost ) নির্দেশ করে যেখানে একটি ওয়েব অ্যাপ্লিকেশন আপডেট ম্যানিফেস্ট পুনরুদ্ধার করা যেতে পারে।

একটি আইসোলেটেড ওয়েব অ্যাপের জন্য একটি ন্যূনতম ওয়েব অ্যাপ ম্যানিফেস্ট দেখতে এরকম কিছু হতে পারে:

{
  "name": "IWA Kitchen Sink",
  "version": "0.1.0",
  "update_manifest_url": "https://example.com/updates.json",
  "start_url": "/",
  "icons": [
    {
      "src": "/images/icon.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "any"
    },
    {
      "src": "/images/icon-mask.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "maskable"
    }
  ]
}

ওয়েব অ্যাপ্লিকেশন আপডেট ম্যানিফেস্ট

একটি ওয়েব অ্যাপ্লিকেশন আপডেট ম্যানিফেস্ট হল একটি JSON ফাইল যা একটি প্রদত্ত ওয়েব অ্যাপ্লিকেশনের প্রতিটি সংস্করণ বর্ণনা করে। JSON অবজেক্টে একটি প্রয়োজনীয় ক্ষেত্র থাকে, version , যা version , src এবং channels ধারণকারী অবজেক্টের একটি তালিকা:

version - অ্যাপ্লিকেশনের সংস্করণ নম্বর, ওয়েব অ্যাপ ম্যানিফেস্টের version ক্ষেত্রের মতোই
src - HTTPS URL (অথবা পরীক্ষার জন্য localhost ) যা সেই সংস্করণের ( .swbn ফাইল) হোস্ট করা বান্ডেলের দিকে নির্দেশ করে। আপেক্ষিক URL গুলি ওয়েব অ্যাপ্লিকেশন আপডেট ম্যানিফেস্ট ফাইলের সাথে সম্পর্কিত।
channels - এই সংস্করণটি যে আপডেট চ্যানেলের অংশ তা সনাক্ত করার জন্য স্ট্রিংগুলির একটি তালিকা। একটি বিশেষ default চ্যানেল ব্যবহার করা হয় প্রাথমিক চ্যানেলটি বর্ণনা করার জন্য যা অন্য কোনও চ্যানেল নির্বাচন না করা হলে ব্যবহৃত হবে।

আপনি আপনার channels আইডির একটি অবজেক্ট, একটি চ্যানেল ফিল্ডও অন্তর্ভুক্ত করতে পারেন, প্রতিটি আইডির জন্য একটি ঐচ্ছিক name বৈশিষ্ট্য সহ, যাতে একটি মানব-পঠনযোগ্য নাম প্রদান করা যায় ( default চ্যানেল সহ। যে চ্যানেলে name বৈশিষ্ট্য অন্তর্ভুক্ত থাকে না, অথবা channels অবজেক্টে অন্তর্ভুক্ত থাকে না, সে তার আইডিটিকে তার নাম হিসেবে ব্যবহার করে।

একটি ন্যূনতম আপডেট ম্যানিফেস্ট দেখতে এরকম কিছু হতে পারে:

{
  "versions": [
    {
      "version": "5.2.17",
      "src": "https://cdn.example.com/app-package-5.2.17.swbn",
      "channels": ["next", "5-lts", "default"]
    },
    {
      "version": "5.3.0",
      "src": "v5.3.0/package.swbn",
      "channels": ["next", "default"]
    },
    {
      "version": "5.3.1",
      "src": "v5.3.1/package.swbn",
      "channels": ["next"]
    },
  ],
  "channels": {
    "default": {
      "name": "Stable"
    },
    "5-lts": {
      "name": "5.x Long-term Stable"
    }
  }
}

এই উদাহরণে, তিনটি চ্যানেল আছে: default যা Stable লেবেলযুক্ত হবে, 5-lts যা 5.x Long-term Stable লেবেলযুক্ত হবে, এবং next যা next লেবেলযুক্ত হবে। যদি কোনও ব্যবহারকারী চ্যানেল 5-lts এ থাকে, তাহলে তারা সংস্করণ 5.2.17 পাবে, যদি তারা চ্যানেল default থাকে তবে তারা সংস্করণ 5.3.0 পাবে, এবং যদি তারা next চ্যানেলে থাকে তবে তারা সংস্করণ 5.3.1 পাবে।

ওয়েব অ্যাপ্লিকেশন আপডেট ম্যানিফেস্ট যেকোনো সার্ভারে হোস্ট করা যেতে পারে। প্রতি ৪-৬ ঘন্টা অন্তর আপডেট পরীক্ষা করা হয়।

প্রশাসক পরিচালিত

প্রাথমিক লঞ্চের সময়, আইসোলেটেড ওয়েব অ্যাপগুলি শুধুমাত্র অ্যাডমিন প্যানেলের মাধ্যমে একজন প্রশাসক দ্বারা Chrome এন্টারপ্রাইজ পরিচালিত Chromebook গুলিতে ইনস্টল করা যাবে।

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

খোলা হলে, একটি বর্গক্ষেত্রের ভিতরে একটি বর্গক্ষেত্রের আইকন থাকবে, যার নাম থাকবে "Add an Isolated Web App" । এটিতে ক্লিক করলে আপনার OU-তে একটি IWA যোগ করার জন্য একটি মডেল খুলবে। এটি করার জন্য, আপনার দুটি তথ্যের প্রয়োজন হবে: IWA-এর ওয়েব বান্ডেল আইডি (আপনার অ্যাপের পাবলিক কী থেকে তৈরি এবং অ্যাপটি বান্ডেল এবং স্বাক্ষর করার পরে প্রদর্শিত হবে) এবং IWA-এর জন্য ওয়েব অ্যাপ আপডেট ম্যানিফেস্টের URL। ইনস্টল হয়ে গেলে, এটি পরিচালনা করার জন্য আপনার কাছে অ্যাডমিন প্যানেলের স্ট্যান্ডার্ড বিকল্পগুলির সেট থাকবে:

ইনস্টলেশন নীতি : আপনি যেভাবে IWA ইনস্টল করতে চান, হয় জোর করে ইনস্টল করুন, জোর করে ইনস্টল করুন এবং ChromeOS শেল্ফে পিন করুন, অথবা ইনস্টলেশন বন্ধ করুন।
লগইন করলে লঞ্চ করুন : আপনি যেভাবে IWA চালু করতে চান, হয় ব্যবহারকারীকে ম্যানুয়ালি লঞ্চ করার অনুমতি দিন, ব্যবহারকারী লগ ইন করলে IWA চালু করতে বাধ্য করুন, কিন্তু তাদের এটি বন্ধ করতে দিন, অথবা ব্যবহারকারী লগ ইন করলে জোর করে লঞ্চ করুন এবং এটি বন্ধ হওয়া থেকে বিরত রাখুন।

একবার সেভ হয়ে গেলে, পরের বার যখন সেই OU-তে Chromebook-এ কোনও নীতি আপডেট প্রয়োগ করা হবে তখন অ্যাপটি ইনস্টল করা হবে। ইনস্টল হয়ে গেলে, ব্যবহারকারীর ডিভাইস প্রতি 4-6 ঘন্টা অন্তর ওয়েব অ্যাপ আপডেট ম্যানিফেস্ট থেকে আপডেটগুলি পরীক্ষা করবে।

IWA গুলিকে জোর করে ইনস্টল করার পাশাপাশি, আপনি অন্যান্য ওয়েব অ্যাপ্লিকেশনের মতোই তাদের জন্য কিছু অনুমতি স্বয়ংক্রিয়ভাবে প্রদান করতে পারেন। এটি করার জন্য, ডিভাইস > Chrome > ওয়েব ক্ষমতাগুলিতে যান এবং Add origin বোতামে ক্লিক করুন। Origin / site pattern field , IWA এর Web Bundle ID ( isolated-app:// স্বয়ংক্রিয়ভাবে এর প্রোটোকল হিসাবে এতে যুক্ত হবে) পেস্ট করুন। সেখান থেকে, আপনি উইন্ডো ব্যবস্থাপনা, স্থানীয় ফন্ট ব্যবস্থাপনা এবং স্ক্রিন মনিটরিং API সহ বিভিন্ন API (অনুমোদিত/ব্লকড/আনসেট) অ্যাক্সেস লেভেল সেট করতে পারেন। যেসব API সক্রিয় করার জন্য প্রশাসকের অতিরিক্ত অপ্ট-ইন প্রয়োজন হতে পারে, যেমন বাধ্যতামূলক স্ক্রিন মনিটরিং API, তাদের জন্য আপনার নির্বাচন নিশ্চিত করার জন্য একটি অতিরিক্ত ডায়ালগ পপ আপ হবে। একবার আপনার কাজ শেষ হয়ে গেলে, আপনার পরিবর্তনগুলি সংরক্ষণ করুন এবং আপনার ব্যবহারকারীরা আপনার IWA ব্যবহার শুরু করতে প্রস্তুত হবে!

এক্সটেনশনের সাথে কাজ করুন

যদিও আইসোলেটেড ওয়েব অ্যাপস এক্সটেনশনের সাথে বাইরের দিকে কাজ করে না, আপনি আপনার মালিকানাধীন এক্সটেনশনগুলিকে তাদের সাথে সংযুক্ত করতে পারেন। এটি করার জন্য, আপনাকে এক্সটেনশনের ম্যানিফেস্ট ফাইল সম্পাদনা করতে হবে। ম্যানিফেস্টের externally_connectable বিভাগটি নির্ধারণ করে যে কোন এক্সটার্নাল ওয়েব পৃষ্ঠা বা অন্যান্য Chrome এক্সটেনশনগুলির সাথে আপনার এক্সটেনশন ইন্টারঅ্যাক্ট করতে পারে। externally_connectable এর মধ্যে matches ফিল্ডের অধীনে আপনার IWA এর অরিজিন যোগ করুন ( isolated-app:// স্কিমটি অন্তর্ভুক্ত করতে ভুলবেন না):

{
  "externally_connectable": {
    "matches": ["isolated-app://79990854-bc9f-4319-a6f3-47686e54ed29/*"]
  }
}

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