অ্যাপ্লিকেশনের নিরাপত্তা

ওয়েব অ্যাপের নিরাপত্তা নিয়ন্ত্রণের জন্য ফায়ারফক্স ওএস প্রধানত যা করেঃ

• ব্রাউজারে গিয়ে কোন ওয়েব পেইজ ব্রাউজ করে দেখা ওয়েব ওয়াপ নয়! বরং এদের সরাসরিভাবে ইন্সটল করতে হবে আর ব্যবহার করার জন্য চালু করতে হবে। ব্যবহারের আগে এদের সরাসরি ইন্সটল করতে হবে। ব্যবহারকারী'র নিরাপত্তা নিশ্চিত করার জন্য ওএস এর নিরাপত্তা মডেল অ্যাপ আপডেট এবং মুছে ফেলা নিয়ন্ত্রণ করে।
• নতুন নতুন ওয়েব এপিআই ব্যবহার করতে চাইলে সকল অ্যাপ কে আগে থেকেই ঘোষণা করতে হবে, অ্যাপ ইন্সটল করার সময়ই ব্যবহারকারী দেখতে পারবেন তার অ্যাপ কি কি অনুমতি চাইছে। আর যেসব অ্যাপ গুরুত্বপূর্ণ APIগুলো ব্যবহার করতে চায় তাদের বিশেষ কিছু প্রয়োজনীয়তা পূরণ করতে হবে, এবং মার্কেটপ্লেসে জমা দেওয়ার পর সেগুলো রিভিউ এবং সাইন করা বাধ্যতামূলক।
• ওয়েব অ্যাপগুলোকে "স্যান্ডবক্স" করা হয় মানে তারা শুধু নিজেদের রিসোর্স (কুকি, অফলাইন স্টোরেজ IndexedDB ডেটাবেইজ এবং অন্যান্য) ই ব্যবহার করতে পারবে। যদি দুটি আলাদা অ্যাপও একই URL লোড করতে চায় তাহলেও URL টি, দুটি আলাদা অ্যাপ এর জন্য ভিন্ন (একই অরিজিন বা উৎসের নয়) বলে বিবেচিত হবে, যেহেতু url টি দুটি পৃথক অ্যাপ থেকে লোড করা হচ্ছে।

অ্যাপের প্রকারভেদ (টাইপ)

ফায়ারফক্স ওএস এ তিন ধরণের ওয়েব অ্যাপ আছেঃ "web", "privileged" এবং "certified"। অ্যাপটি কোন প্রকারের সেটি তার মেনিফেস্ট ফাইলে বলে দিতে হয় এবং কোন প্রকারের তার ওপর ভিত্তি করেই অ্যাপটি কি কি অনুমতি পাবে তা নির্ধারণ করা হয়।

• ওয়েব অ্যাপঃ  বেশিরভাগ অ্যাপই (যেগুলো তৃতীয় পক্ষ তৈরি করে) "web" অ্যাপ। এই টাইপটি হচ্ছে ডিফল্ট। এই টাইপের অ্যাপ হলে সাধারণ ওয়েবে যা যা অনুমতি থাকে, সেগুলো ছাড়া বিশেষ কোন অনুমতি পাবে না। কোন যাচাই ছাড়াই যেকোন ওয়েবসাইট থেকে ইন্সটল করা যাবে। অ্যাপটি জিপ করে প্যাকেজ করেও দিতে পারবেন কিন্তু এর ফলে সাধারণ অনুমতিগুলো ছাড়া বাড়তি কোন অনুমতি পাওয়া যাবে না।
• প্রিভিলিজড বা সুবিধাভোগী অ্যাপঃ এসব অ্যাপের বাড়তি অনেক কিছু করার অনুমতি থাকে, তাই এসব সুবিধাভোগী অ্যাপগুলো নিয়ন্ত্রণ করার জন্য মার্কেটপ্লেস থেকে সাইন করা থাকতে হবে।
• সারটিফায়েড বা প্রত্যয়িত অ্যাপঃ এসব প্রত্যয়িত অ্যাপ এখন শুধুমাত্র আগে থেকেই ডিভাইসে OEM এর ইচ্ছামত ইন্সটল করে দেওয়া যাবে, ব্যবহারকারী নিজের ইচ্ছায় ইন্সটল করতে পারবেন না নিজের নিরাপত্তার খাতিরেই।

অ্যাপ সরবরাহ

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

হোস্ট করা অ্যাপ

হোস্ট করা অ্যাপ, ডেভেলপারের ওয়েব সাইটে হোস্ট বা আপলোড করা একটি অ্যাপ্লিকেশন বৃত্তান্ত বা মেনিফেস্ট  ফাইল ছাড়া আর কিছুই না। এই ফাইলে বলা থাকে অ্যাপের index ফাইল (বা ইন্সটল হবে কোথা থেকে) কোথায়। এছাড়া প্রায়ই মেনিফেস্ট ফাইলে অ্যাপটি'র appcache বৃতান্ত ফাইলেরও ঠিকানা দেওয়া থাকে, যা ব্যবহার করে অ্যাপটি যাতে অফলাইনেও চলে এবং দ্রুত চালু করা যায়, সেই সুবিধা দেওয়া যায়। তবে এটা ঐচ্ছিক।  নিরাপত্তার কথা ভাবলে হোস্ট করা অ্যাপ অন্য সব ওয়েবসাইটের মতই আচরণ করে। হোস্টেড অ্যাপ যখন কোন URL দেখায়, তখন URL টি ব্রাউজারে দেখলে যেসব সুবিধা পেতেন, অ্যাপ থেকেও হুবুহু একই সুবিধা পাবেন, বাড়তি কোন কিছুই যোগ বা বিয়োগ হয় না। তাই ওয়েবসাইটে এক পাতা থেকে অন্য পাতা বা রিসোর্সে (ছবি ইত্যাদি) যেভাবে লিঙ্ক করতেন, সাধারণ হোস্টেড ওয়েব অ্যাপেও হুবুহু একই ভাবে লিঙ্ক করতে হবে।

প্যাকেজড অ্যাপ

সেসব ওপেন-ওয়েব অ্যাপকে প্যাকেজড অ্যাপ  বলা হয় যাদের সব রিসোর্স  বা ফাইল/কোড (HTML, CSS, JavaScript, অ্যাপ মেনিফেস্ট এবং অন্যান্য ফাইল) একটি zip ফাইলে ব্যবহারকারীর কাছে পৌঁছে দেওয়া হয়, কোন ওয়েব সার্ভারে আপলোড করার পরিবর্তে। বিস্তারিত পাবেন প্যাকেজড অ্যাপ পাতায়।

অ্যাপ ইন্সটল করা

অ্যাপ জাভাস্ক্রিপ্ট API ব্যবহার করে অ্যাপ ইন্সটল করা হয়ঃ

• হোস্ট করা অ্যাপঃ navigator.mozApps.install(manifestURL) ফাংশনটি কল করে হোস্টেড অ্যাপ ইন্সটল করা হয়, যেখানে manifestURL অ্যাপের ঠিকানা বলে দেওয়া URL। বিস্তারিত জানার জন্য অ্যাপ ইন্সটল করা দেখুন।
• প্যাকেজড অ্যাপঃ navigator.mozApps.installPackage(packageURL)ফাংশন কল করে অ্যাপ ইন্সটল করা হয়। প্যাকেজড অ্যাপের বেলায়, প্যাকেজের ভেতরেই প্রধান মেনিফেস্ট ফাইলটি দেওয়া থাকে, সাইন করা অবস্থায়। এছাড়া দ্বিতীয় আরেকটি "ছোট্ট মেনিফেস্ট" ফাইল থাকে, ইন্সটল প্রক্রিয়া শুরু করার জন্য। আরও তথ্যের জন্য প্যাকেজড অ্যাপ ইন্সটল করা এবং প্যাকেজড অ্যাপ দেখুন।

কোন অ্যাপ যে আসলেই ওয়েব অ্যাপ হিসেবে ইন্সটল হতে চায় - এটা নিশ্চিত করাটা জরুরী। এজন্য যেকোন ওয়েবসাইট-ই যেন কোন একটা মেনিফেস্ট ফাইল হোস্ট করে আমাদের ফাকি দিতে না পারে সেজন্য মেনিফেস্ট ফাইলের বিশেষ ধরনের mime-type সহ পাঠাতে হবেঃ application/x-web-app-manifest+json। তবে যদি যে ওয়েবসাইট অ্যাপ ইন্সটল করাতে চায় তার অরিজিন আর অ্যাপের মেনিফেস্টের অরিজিন একই হয় তাহলে এই শর্ত শিথিলযোগ্য।

আপডেট করা

অ্যাপ আপডেট করা পাতায় জানতে পারবেন কিভাবে আপনার অ্যাপ আপডেট করানো সম্ভব।

অনুমতিসমূহ

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

মেনিফেস্টে ঘোষণা করা

প্রতিটি অতিরিক্ত কাজ করার অনুমতি মেনিফেস্ট ফাইলে বলে দিতে হবে, সাথে আপনার ব্যবহারকারীরা যাতে জানতে পারে কেন আপনার বিশেষ অনুমতিটি লাগছে, সেটাও ব্যাখ্যা করতে হবে। যেমন কোন অ্যাপ যদি navigator.geolocation API ব্যবহার করতে চায় তাহলে মেনিফেস্ট ফাইলে নিচের মত বলতে হবেঃ

"permissions": {
  "geolocation":{ 
    "description": "Required for autocompletion in the share screen",  
  }
},

এর ফলে অ্যাপটি geolocation অনুমতি চাওয়ার জন্য প্রম্পট করবে, অন্যান্য ওয়েব পেইজের মতই।  অ্যাপ মেনিফেস্ট পাতায় বিস্তারিত দেখুন।

অনুমতি দেওয়া

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

অনুমতি বাতিল করা

ব্যবহারকারীরা যেকোন সময় prompt ধরণের অনুমতিগুলোর ব্যাপারে তাদের মতবদল করতে পারেন এবং ফায়ারফক্স ওএস সেটিংস অ্যাপ ব্যবহার করে আপনার অ্যাপের, এসব অনুমতি বাতিল করতে পারেন । তবে Allow ধরনের অনুমতিগুলো ব্যবহারকারীরা পরিবর্তন করতে পারেন না।

ওয়েব অ্যাপ স্যান্ডবক্স

প্রতিটি অ্যাপের নিজস্ব তথ্য রাখা

প্রতিটি অ্যাপ নিজের আলাদা স্যান্ডবক্সে চলে, মানে এক অ্যাপের জমা করা কোন তথ্য-ই অন্য আরেকটি অ্যাপ দেখতে পারবে না। এর মধ্যে কুকি'র তথ্য, localStorage তথ্য, indexedDB তথ্য এবং সাইটের অনুমতি সবকিছুই পরে।

এর মানে হল যদি কোন ব্যবহারকারী দুটি অ্যাপ "ক" এবং "খ" ইন্সটল করে তাহলে তাদের প্রত্যেকের নিজস্ব কুকি, ডিভাইসের তথ্য এবং অনুমতি থাকবে। যদি দুটি অ্যাপ এমন <iframe> খোলে যা একই অরিজিনে পয়েন্ট করা, তাহলেও ওপরের কথাটি প্রযোজ্য। যেমন, যদি ক এবং খ দুটি অ্যাপই এমন <iframe> খোলে যা "https://www.mozilla.org" এ পয়েন্ট করা, তাহলে দুটি অ্যাপই ওয়েবসাইটটি দেখাবে, তবে দুটি অ্যাপের কুকি এবং অন্যান্য তথ্য সম্পূর্ণ আলাদা আলাদা থাকবে।

এর মানে হল যদি ব্যবহারকারী "ক" অ্যাপে ফেসুবকে লগইন করেন, "খ" অ্যাপে এর কোন প্রভাবই থাকবে না। ফেসবুকে লগইন করার সময় ক অ্যাপ যেসব কুকি সংরক্ষণ করে, তা শুধুমাত্র ক অ্যাপ-ই দেখতে পাবে। তাই যদি এখন খ অ্যাপটি <iframe> ব্যবহার করে ফেসবুক খোলে তাহলে এটি ক অ্যাপের কুকিগুলো দেখতে পাবে না, তাই ব্যবহারকারী'র ফেসবুক অ্যাকাউন্ট দেখানোর বদলে খ অ্যাপটি ফেসুবকের লগইন পাতা দেখাবে।

অ্যাপগুলো একটি অন্যটিকে চালু করতে পারে না

এর মানে আইফ্রেম ব্যবহার করে একটি অ্যাপ অন্য একটি অ্যাপ দেখাতে পারবে না। যদি ক অ্যাপ <iframe> ব্যবহার করে খ অ্যাপের URL, src এর মাণ হিসেবে দিয়ে দেয়, আসলে <iframe> এ খ অ্যাপটি চালু হবে না। শুধুমাত্র ঐ URL এর ওয়েবসাইট-টি সাধারণভাবে দেখানো হবে। খ অ্যাপের কুকি ব্যবহার করতে পারবে না এবং এমনভাবে আচরণ করবে যেন খ অ্যাপটি ডিভাইসে ইন্সটল করাই হয়নি।

প্যাকেজড অ্যাপের (নিচে বিস্তারিত আছে) বেলায়ও ওপরের কথা সত্য। যদি ক অ্যাপ খ নামের একটি প্যাকেজড অ্যাপকে <iframe> ব্যবহার করে লোড করতে চায় (খ অ্যাপের app:// URL ব্যবহার করে), তাহলে এটি সরাসরি ব্যর্থ হবে। ৪০৪ নাকি অন্য কোন ত্রুটি দেখানো হবে তা এখনো ঠিক করা হয়নি, তবে ত্রুটি হিসেবে দেখানো হবে এটা নিশ্চিত। এবং খ অ্যাপটি ডিভাইসে থাকুক বা না থাকুক ক অ্যাপ কোনভাবেই খ অ্যাপকে লোড করতে পারবে না, তাই ক অ্যাপ জানতেও পারবে না ডিভাইসে খ অ্যাপটি ইন্সটল করা আছে কি নাই।

একই জিনিস ঘটবে যদি ক অ্যাপের top-level frame এ খ অ্যাপের URL লোড করতে চাওয়া হয়। আমরা জানি কোন ফ্রেমে কোন অ্যাপ চলছে, তাই ঐ ফ্রেমে অন্য কোন অ্যাপ দেখাতে চাইলে ওপরে যেভাবে বলা হয়েছে সেভাবে ত্রুটি দেখানো হবে।

উদ্দেশ্য

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

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

এছাড়া বিশাল একটা নিরাপত্তাজনিত সুবিধা আছে। যেমন ধরি AwesomeSocial নামের কোন অ্যাপ ব্যবহার করে কেউ ফেসবুকে লগইন করেছেন। তাহলে তার আর SketchGame নামের কোন অ্যাপ নিয়ে এই দুশ্চিন্তা করতে হবে না যে অ্যাপটি ফেসবুকের কোন বাগ বা সীমাবদ্ধতা'র সুযোগ নিয়ে ব্যবহারকারী'র তথ্য হাতিয়ে নিতে পারে।

এছাড়া গোপনীয়তাজনিত ভাল সুবিধা আছে। ব্যবহারকারী নিশ্চিতে PoliticalPartyPlus নামের কোন অ্যাপ ইন্সটল করতে পারবেন এই দুশ্চিন্তা ছাড়া যে MegaCorpEmployeeApp নামের কোন অ্যাপ জানতে পারবে যে ব্যবহারকারী প্রথম অ্যাপটি ইন্সটল করেছেন কি না অথবা প্রথম অ্যাপের কোন তথ্য দ্বিতীয় অ্যাপতে পেয়ে যাবে কি না।

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

ওয়েবসাইটসমূহের তথ্যের মতই প্রতিটি অ্যাপের নিরাপত্তা তথ্যও স্যান্ডবক্স করা হয়। যদি অ্যাপ "ক" https://maps.google.com সাইটের কোন পাতা লোড করে এবং পাতাটি geolocation সুবিধার অনুমতি চাওয়ার পর ব্যবহারকারী তার অনুমতি দিয়ে দেন, এবং বলে দেন যাতে এই অনুমতিটির ব্যাপারে আর জানতে না চাওয়া হয়। শুধু অ্যাপ ক - ই এই সাইটটিতে অনুমতি পেয়েছে। অন্য কোন অ্যাপ "খ" https://maps.google.com, সাইটে গেলে নতুন করে অনুমতি নেওয়ার প্রয়োজন পড়বে।

আর সাধারণ ব্রাউজারে ব্যবহারের মতই একই অ্যাপে, কোন বিশেষ API বিভিন্ন সাইটে (অরিজিনে) ব্যবহার করতে চাইলে প্রত্যেক সাইটের জন্যই নতুন করে অনুমতি নিতে হবে। যদি "ক" অ্যাপ আইফ্রেমের ভেতর https://maps.google.com, সাইট খুলে GeoLocation ব্যবহারের অনুমতি পায়, তাহলে একই ওয়াপ থেকেও https://docs.google.com সাইটে গেলে এবং geolocation ব্যবহার করতে চাইলে নতুন করে অনুমতি লাগবে।

ব্রাউজার API স্যান্ডবক্স

এছাড়াও যেসব অ্যাপ অনেক অনেক URL লোড করে, যেমন ব্রাউজারসমূহ, তাদের জন্য আমরা browserContent ফ্ল্যাগ রেখেছি। এই ফ্ল্যাগের সাহায্যে কোন অ্যাপ একটি নয়, বরং দুটি স্যান্ডবক্স ব্যবহার করেঃ একটি তার নিজের জন্য, অন্যটি সে যেসব "ওয়েব কন্টেন্ট" দেখায় তাদের জন্য। যেমনঃ

ধরা যাক MyBrowser অ্যাপটি https://mybrowser.com ডোমেইন থেকে লোড করা হয়েছে। এই ডোমেইন থেকে স্ক্রিপ্ট এবং অন্যান্য রিসোর্স ফাইল লোড করা হয়, এসব স্ক্রিপ্ট এবং রিসোর্স ডোমেইনটি'র নিজস্ব।

এখন, যদি এই অ্যাপের কোন পাতা <iframe mozbrowser> তৈরি করে, এই <iframe> এর জন্য নতুন স্যান্ডবক্স তৈরি এবং ব্যবহার করা হবে, যা কিনা অ্যাপটি'র নিজস্ব স্যান্ডবক্স থেকে ভিন্ন। যেমন, এই <iframe> টি যদি https://mybrowser.com লোড করে, তাহলে <iframe mozbrowser> এর জন্য ভিন্ন কুকি এবং অন্যান্য সবকিছু ব্যবহার করা হবে। একইভাবে, <iframe mozbrowser> এর ভেতরের কন্টেন্ট অ্যাপটি'র নিজস্ব নয়, বরং ভিন্ন IndexedDB এবং localStorage ডেটাবেইজ ব্যবহার করবে।

যেমন, MyBrowser অ্যাপ যদি Google Maps নিয়ে কাজ করতে চায় অঞ্চলভিত্তিক ব্রাউজিং উপভোগ করার জন্য তাহলেও ওপরের কথা প্রযোজ্য। যদি অ্যাপটি <iframe> এ https://maps.google.com লোড করে, এটি https://maps.google.com ওয়েবসাইটের জন্য কিছু কুকি লোড করবে। এরপর যদি ব্যবহারকারী <iframe mozbrowser> এর ভেতর https://maps.google.com এ যায়, তাহলে মূল অ্যাপের থেকে ভিন্ন কুকি এবং অনুমতি ব্যবহার করা হবে।

আরেকটি উদাহরণ যেখানে এটি উপকারী তা হল Yelp এর মত অ্যাপ। এধরণের অ্যাপে ব্যবহারকারী সরাসরি অ্যাপ থেকেই বিভিন্ন রেস্টুরেন্টের সাইটে যেতে পারেন। যদি <iframe mozbrowser> ব্যবহার করে রেস্টুরেন্টের সাইট লোড করা হয়, তাহলে মূল Yelp অ্যাপটি নিশ্চিন্ত থাকতে পারবে যে রেস্টুরেন্টের সাইটে কোন <iframe> দিয়ে যদি Yelp অ্যাপেই আবার পয়েন্ট করে দেয় (ধরি অ্যাপটি  https://yelp.com), তাহলে রেস্টুরেন্টের সাইটটি তার আইফ্রেমে Yelp কে সাধারণ ওয়েবসাইট হিসেবেই পাবে, অ্যাপ হিসেবে নয়। যেহেতু মূল Yelp অ্যাপ তার তথ্য, কুকি রেস্টুরেন্টের সাইটের সাথে শেয়ার করবে না, তাই মূল অ্যাপ নিশ্চিন্ত থাকতে পারবে যে অন্য কোন ওয়েবসাইট একে আক্রমণ করছে না।

অ্যাপ নিরাপত্তা - সারমর্ম

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