برنامه های وب ایزوله

وب یک پلتفرم کاربردی واقعاً منحصر به فرد است. برنامه‌های ساخته شده بر روی آن، فوراً و بدون نیاز به تغییر کد یا کامپایل، در هر سیستم عاملی قابل دسترسی هستند. هر زمان که کاربری به برنامه شما مراجعه می‌کند، همیشه جدیدترین نسخه را در اختیار دارد. آنها قابل نصب هستند و می‌توانند به صورت آفلاین کار کنند، بسیار توانمند هستند و فقط با یک لینک به راحتی قابل اشتراک‌گذاری هستند. یک برنامه وب بسازید، و همه جا کار می‌کند.

از آنجا که وب به طور پیش‌فرض قصد دارد ایمن و مطمئن باشد، مدل امنیتی آن باید بسیار محافظه‌کارانه باشد. هر قابلیت جدیدی که اضافه می‌شود باید برای یک کاربر معمولی که به طور تصادفی از طریق یک URL به آن برخورد می‌کند، ایمن باشد. ما این مدل امنیتی را drive by web می‌نامیم. اگرچه این مدل برای بسیاری از برنامه‌ها عالی است و می‌توان با استفاده از سیاست‌های امنیت محتوا و جداسازی متقابل مبدا ، آن را ایمن‌تر کرد، اما برای هر مورد استفاده‌ای کار نمی‌کند. تعدادی از APIهای بسیار مهم و بسیار قدرتمند، مانند Direct Sockets و Controlled Frame ، که توسعه‌دهندگان به آنها نیاز دارند، نمی‌توانند به اندازه کافی برای drive by web ایمن شوند.

برای این برنامه‌ها، آنها در حال حاضر گزینه‌ای برای ساخت روی وب ندارند. برای برخی دیگر، مدل امنیتی وب ممکن است به اندازه کافی محافظه‌کارانه نباشد؛ آنها ممکن است این فرض را که سرور قابل اعتماد است، قبول نداشته باشند و در عوض برنامه‌های مستقل با نسخه‌بندی و امضا شده را ترجیح دهند. یک مدل امنیتی جدید و با قابلیت اعتماد بالا مورد نیاز است. برنامه‌های وب ایزوله (IWA) یک مدل برنامه ایزوله، بسته‌بندی شده، نسخه‌بندی شده، امضا شده و قابل اعتماد را ارائه می‌دهند که بر روی پلتفرم وب موجود ساخته شده است تا این توسعه‌دهندگان بتوانند از آن استفاده کنند.

طیفی از اعتماد در وب

شما می‌توانید امنیت و قابلیت‌های وب را به صورت یک طیف در نظر بگیرید.

تصویری که طیف اعتماد در وب را نشان می‌دهد. در سمت چپ، یک کره زمین که نشان‌دهنده وب درایو-بای (drive-by web) است. در وسط، برنامه‌های وب پیش‌رونده (progressive web apps) قرار دارند. در سمت راست، یک تنگ ماهی با یک ماهی قرمز درون آن، نشان‌دهنده برنامه‌های وب ایزوله (isolated web apps) است. یک خط مشکی ممتد هر سه آیکون را به صورت افقی به هم متصل می‌کند و یک خط قرمز خط‌چین، برنامه‌های وب پیش‌رونده را از برنامه‌های وب ایزوله جدا می‌کند.

وبِ درایو-بای (drive-by web) که در سمت چپ تصویر قرار دارد، کمترین مدل امنیتی اعتماد را دارد زیرا باید بیشترین دسترسی را داشته باشد و بنابراین کمترین دسترسی را به سیستم کاربر دارد. برنامه‌های وب نصب‌شده توسط مرورگر، که در وسط تصویر قرار دارند، اعتماد بیشتری را به خود جلب می‌کنند و می‌توانند کمی عمیق‌تر در سیستم کاربر ادغام شوند. کاربران معمولاً می‌توانند بدون مشکل بین نسخه‌های وب درایو-بای برنامه‌ها و نسخه‌های نصب‌شده توسط مرورگر جابجا شوند.

سپس نوبت به برنامه‌های وب ایزوله و با اعتماد بالا می‌رسد.

آنها بیشتر شبیه برنامه‌های بومی عمل می‌کنند و حس می‌شوند و می‌توانند به یکپارچه‌سازی‌های عمیق سیستم و قابلیت‌های قدرتمند دسترسی پیدا کنند. کاربران نمی‌توانند بین آنها و درایو-بای-وب جابجا شوند. اگر به این سطح از امنیت یا این قابلیت‌ها نیاز دارید، دیگر راه برگشتی وجود ندارد.

هنگام تلاش برای تصمیم‌گیری در مورد اینکه در کجای این طیف باید هدف خود را مشخص کنید، به طور پیش‌فرض از مدل امنیتی با کمترین میزان اعتماد ممکن، مانند یک برنامه وب پیش‌رونده، استفاده کنید. این مدل بیشترین دسترسی را به شما می‌دهد، شما را ملزم به مدیریت کمترین میزان نگرانی‌های امنیتی می‌کند و برای توسعه‌دهندگان و کاربران شما انعطاف‌پذیرترین خواهد بود.

ایمن از طریق طراحی

برنامه‌های وب ایزوله، یک مدل امنیتی با قابلیت اعتماد بالا برای برنامه‌های وب ارائه می‌دهند. با این حال، برای فعال کردن این امر، برخی از فرضیاتی که Drive by web در مورد اعتماد مطرح می‌کند، باید مورد بازنگری قرار گیرند. بلوک‌های سازنده وب اصلی، مانند سرورها و DNS، دیگر نمی‌توانند به صراحت مورد اعتماد باشند. بردارهای حمله‌ای که ممکن است برای برنامه‌های بومی مرتبط‌تر به نظر برسند، ناگهان اهمیت پیدا می‌کنند. بنابراین، برای دسترسی به مدل امنیتی جدید با قابلیت اعتماد بالا که توسط IWAها ارائه می‌شود، برنامه‌های وب باید بسته‌بندی، ایزوله و قفل شوند.

بسته‌بندی شده

صفحات و دارایی‌های برنامه‌های وب ایزوله را نمی‌توان از سرورهای زنده سرویس‌دهی کرد یا مانند برنامه‌های وب معمولی از طریق شبکه دریافت کرد. در عوض، برای دسترسی به مدل امنیتی جدید با قابلیت اعتماد بالا، برنامه‌های وب باید تمام منابع مورد نیاز برای اجرا را در یک بسته وب امضا شده (Signed WebBundle) بسته‌بندی کنند. بسته‌های وب امضا شده، تمام منابع مورد نیاز برای اجرای یک سایت را دریافت کرده و آنها را در یک فایل .swbn بسته‌بندی می‌کنند و آنها را با یک بلوک یکپارچگی به هم متصل می‌کنند. این امر به برنامه وب اجازه می‌دهد تا به طور کامل و ایمن دانلود شود و حتی در حالت آفلاین به اشتراک گذاشته یا نصب شود.

با این حال، این موضوع مشکلی برای تأیید صحت کد سایت ایجاد می‌کند: کلیدهای TLS برای کار کردن به اتصال اینترنت نیاز دارند. به جای کلیدهای TLS، 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:// .

برنامه خود را بسته‌بندی کنید

با در دسترس بودن کلید امضایتان، وقت آن رسیده که برنامه وب خود را بسته‌بندی کنید. برای انجام این کار، می‌توانید از بسته‌های رسمی NodeJS برای بسته‌بندی و سپس امضای IWAهای خود استفاده کنید (ابزارهای خط فرمان Go نیز موجود هستند). ابتدا، از بسته wbn استفاده کنید و با اشاره به پوشه‌ای که شامل تمام فایل‌های تولیدی IWA شما (در اینجا dist) است، آنها را در یک بسته بدون امضا قرار دهید:

npx wbn --dir dist

این یک بسته وب بدون امضا از آن دایرکتوری در out.wbn. پس از تولید، از کلید رمزگذاری شده Ed25519 یا ECDSA P-256 که قبلاً ایجاد کرده‌اید برای امضای آن با استفاده از wbn-sign استفاده کنید:

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

این کار یک بسته وب امضا شده از بسته وب امضا نشده به نام signed.swbn تولید می‌کند. پس از امضا، ابزار، شناسه بسته وب و منبع برنامه وب ایزوله شده آن را نیز نمایش می‌دهد. منبع برنامه وب ایزوله شده، نحوه شناسایی IWA شما در مرورگر است.

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

اگر از Webpack ، Rollup یا ابزاری که از افزونه‌های آنها پشتیبانی می‌کند (مانند Vite ) استفاده می‌کنید، می‌توانید از یکی از افزونه‌های bundler ( Webpack ، Rollup ) که این بسته‌ها را به جای فراخوانی مستقیم آنها در بر می‌گیرد، استفاده کنید. انجام این کار یک بسته امضا شده به عنوان خروجی ساخت شما ایجاد می‌کند.

برنامه خود را آزمایش کنید

شما می‌توانید IWA خود را به یکی از دو روش زیر آزمایش کنید: یا با اجرای سرور توسعه از طریق پروکسی توسعه‌دهنده IWA داخلی کروم، یا با نصب IWA همراه خود. برای انجام این کار، باید از کروم یا ChromeOS 120 یا بالاتر استفاده کنید، پرچم‌های IWA را فعال کنید و برنامه خود را از طریق Chrome's Web App Internals نصب کنید:

  1. chrome://flags/#enable-isolated-web-app-dev-mode را فعال کنید.
  2. با رفتن به صفحه Web App Internals کروم به chrome://web-app-internals IWA خود را آزمایش کنید.

وقتی در صفحه Web App Internals هستید، دو انتخاب دارید: Install IWA with Dev Mode Proxy یا Install IWA from Signed Web Bundle .

اگر از طریق یک Dev Mode Proxy نصب کنید، می‌توانید هر URL، از جمله سایت‌هایی که از یک سرور توسعه محلی اجرا می‌شوند، را به عنوان یک IWA نصب کنید، بدون اینکه آنها را به صورت بسته‌ای (bundle) درآورید، با فرض اینکه سایر الزامات نصب IWA را برآورده می‌کنند. پس از نصب، یک IWA برای آن URL به سیستم شما اضافه می‌شود که دارای سیاست‌های امنیتی و محدودیت‌های صحیح و دسترسی به APIهای مخصوص IWA است. یک شناسه تصادفی به آن اختصاص داده می‌شود. Chrome Dev Tools نیز در این حالت در دسترس است تا به شما در اشکال‌زدایی برنامه‌تان کمک کند. اگر از یک Signed Web Bundle نصب کنید، IWA امضا شده و بسته‌بندی شده خود را آپلود می‌کنید و طوری نصب می‌شود که انگار توسط یک کاربر نهایی دانلود شده است.

در صفحه Web App Internals، می‌توانید بررسی‌های به‌روزرسانی را برای هر برنامه‌ای که از طریق Dev Mode Proxy یا از یک Signed Web Bundle نصب شده است، اجباری کنید تا فرآیند به‌روزرسانی نیز آزمایش شود.

ایزوله

اعتماد، کلید برنامه‌های وب ایزوله است. این موضوع با نحوه اجرای آنها شروع می‌شود. کاربران بسته به اینکه یک برنامه در یک مرورگر یا در یک پنجره مستقل اجرا می‌شود، مدل‌های ذهنی متفاوتی برای آنچه یک برنامه می‌تواند و باید بتواند انجام دهد، دارند و عموماً معتقدند که برنامه‌های مستقل دسترسی بیشتری دارند و قدرتمندتر هستند. از آنجا که IWAها می‌توانند به APIهای با اعتماد بالا دسترسی پیدا کنند، برای هماهنگی با این مدل ذهنی، ملزم به اجرا در یک پنجره مستقل هستند. این امر آنها را از نظر بصری از مرورگر جدا می‌کند. اما این فراتر از جداسازی بصری است.

برنامه‌های وب ایزوله (Isolated Web Apps) بر روی پروتکلی جداگانه نسبت به وب‌سایت‌های درون مرورگر اجرا می‌شوند ( isolated-app در مقابل http یا https ). این بدان معناست که هر IWA به لطف سیاست same-origin ( همان منبع) کاملاً از وب‌سایت‌هایی که درون مرورگر اجرا می‌شوند، جدا است، حتی اگر توسط یک شرکت ساخته شده باشند. فضای ذخیره‌سازی IWA نیز از یکدیگر جدا است. این امر در کنار هم تضمین می‌کند که محتوای بین مبدایی نمی‌تواند بین IWAهای مختلف یا بین IWAها و زمینه مرور عادی کاربر نشت کند.

اما اگر یک IWA بتواند پس از نصب، کد دلخواه را دانلود و اجرا کند، نه ایزوله کردن و نه بسته‌بندی و امضای کد سایت برای ایجاد اعتماد مفید نیستند. برای اطمینان از این امر و در عین حال اجازه اتصال IWAها به سایت‌های دیگر برای دریافت محتوا، IWAها مجموعه‌ای دقیق از سیاست‌های امنیت محتوا را اجرا می‌کنند:

  • فقط جاوا اسکریپت را از بسته نرم‌افزاری مجاز می‌کند؛ با این حال، اجازه می‌دهد Wasm صرف نظر از منبع آن اجرا شود. ( script-src )
  • به جاوا اسکریپت اجازه می‌دهد تا از دامنه‌های امن و غیر محلیِ چند-مبدأی، نقاط پایانی WebSocket و WebTransport و URLهای blob و data ( connect-src ) را دریافت کند.
  • با تنظیم نحوه استفاده از توابع دستکاری DOM ( require-trusted-types-for ) در برابر حملات تزریق اسکریپت بین سایتی (XSS) از DOM محافظت می‌کند.
  • فریم‌ها، تصاویر، صدا و ویدیو را از هر دامنه HTTPS ( frame-src ، img-src ، media-src ) مجاز می‌کند.
  • فونت‌ها را از بسته و blobs ( 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 ) مشخص شده‌اند را مجاز کنید.
  • درخواست‌های بین مبدایی بدون CORS را رد کنید ( Cross-Origin-Resource-Policy )
  • جداسازی پردازشی زمینه مرور از اسناد بین مبدا، جلوگیری از ارجاعات window.opener و دسترسی به اشیاء سراسری ( Cross-Origin-Opener-Policy )
  • جلوگیری از جاسازی سایت در یک فریم یا iframe (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 قبل از نصب یا به‌روزرسانی یک برنامه انجام دهند.

برای تسهیل این امر، برنامه‌های وب ایزوله (Isolated Web Apps) به طور پیش‌فرض تمام درخواست‌های مجوز را مسدود می‌کنند. سپس توسعه‌دهندگان می‌توانند با اضافه کردن فیلد permissions_policy به مانیفست برنامه وب خود، مجوز مورد نیاز خود را انتخاب کنند. این فیلد شامل جفت‌های کلید/مقدار از دستورالعمل‌های سیاست مجوز و لیست‌های مجاز سیاست مجوز برای هر مجوزی است که IWA یا هر فریم فرزند مانند یک فریم کنترل‌شده یا یک iframe ممکن است درخواست کند. اضافه کردن یک مجوز در اینجا به طور خودکار آن را اعطا نمی‌کند. در عوض، آن را در دسترس قرار می‌دهد تا هنگام درخواست برای آن قابلیت، درخواست شود.

به عنوان مثال، در نظر بگیرید که در حال ساخت یک IWA ردیابی ناوگان هستید. ممکن است به IWA نیاز داشته باشید که بتواند موقعیت مکانی کاربر را درخواست کند و یک نقشه جاسازی شده نیز بتواند موقعیت مکانی را درخواست کند. همچنین ممکن است بخواهید هر سایت جاسازی شده بتواند به صورت تمام صفحه نمایش داده شود تا یک نمای فراگیر برای کاربر فراهم کند. برای انجام این کار، باید سیاست مجوز زیر را در مانیفست برنامه وب خود تنظیم کنید:

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

از آنجا که WebBundles می‌تواند هدرهای سیاست مجوزها را نیز مشخص کند، فقط مجوزهای اعلام شده در هر دو مجاز خواهند بود و سپس فقط مبدأهایی در لیست‌های مجاز که در هر دو هستند مجاز خواهند بود.

نامگذاری و نسخه‌بندی شده

برنامه‌های وب معمولی برای شناسایی خود به کاربران به نام دامنه خود متکی هستند و می‌توانند با تغییر کدی که در آن دامنه ارائه می‌شود، به‌روزرسانی شوند. اما به دلیل محدودیت‌های امنیتی پیرامون برنامه‌های وب ایزوله، هویت و به‌روزرسانی‌ها باید به طور متفاوتی مدیریت شوند. دقیقاً مانند برنامه‌های وب پیش‌رونده، برنامه‌های وب ایزوله برای شناسایی خود به کاربران شما به یک فایل مانیفست برنامه وب نیاز دارند.

مانیفست برنامه وب

برنامه‌های وب ایزوله، همان ویژگی‌های کلیدی manifest را برای مانیفست برنامه وب خود، مانند 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 : فیلدی اختیاری ، اما توصیه شده که به یک URL HTTPS (یا 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 (یا localhost برای آزمایش) که به بسته میزبانی شده برای آن نسخه (فایل .swbn ) اشاره می‌کند. آدرس‌های اینترنتی نسبی نسبت به فایل مانیفست به‌روزرسانی برنامه وب هستند.
  • 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 را دریافت خواهد کرد.

مانیفست‌های به‌روزرسانی برنامه‌های وب می‌توانند روی هر سروری میزبانی شوند. به‌روزرسانی‌ها هر ۴ تا ۶ ساعت بررسی می‌شوند.

مدیریت شده توسط ادمین

در اولین راه‌اندازی، برنامه‌های وب ایزوله فقط می‌توانند توسط یک مدیر و از طریق پنل مدیریت، روی کروم‌بوک‌های مدیریت‌شده توسط کروم انترپرایز نصب شوند.

برای شروع، از پنل مدیریت خود، به مسیر Devices > Chrome > Apps & extensions > Users & browsers بروید. این تب به شما امکان می‌دهد برنامه‌ها و افزونه‌ها را از فروشگاه وب Chrome، Google Play و وب برای کاربران سراسر سازمان خود اضافه کنید. افزودن موارد با باز کردن دکمه زرد رنگ شناور add ( + ) در گوشه پایین سمت راست صفحه و انتخاب نوع مورد برای افزودن انجام می‌شود.

وقتی باز شد، یک آیکون مربع درون یک مربع دیگر با عنوان « افزودن یک برنامه وب ایزوله» (Add an Isolated Web App ) وجود خواهد داشت. با کلیک بر روی آن، یک پنجره برای اضافه کردن یک IWA به OU شما باز می‌شود. برای انجام این کار، به دو اطلاعات نیاز دارید: شناسه بسته وب IWA (که از کلید عمومی برنامه شما تولید می‌شود و پس از بسته‌بندی و امضای برنامه نمایش داده می‌شود) و URL مربوط به مانیفست به‌روزرسانی برنامه وب برای IWA. پس از نصب، مجموعه گزینه‌های استاندارد پنل مدیریت را برای مدیریت آن خواهید داشت:

  • سیاست نصب : نحوه نصب IWA، یا نصب اجباری، نصب اجباری و پین شدن به قفسه ChromeOS، یا جلوگیری از نصب.
  • راه‌اندازی هنگام ورود : نحوه‌ی اجرای IWA، یا اجازه دادن به کاربر برای راه‌اندازی دستی، یا اجرای اجباری IWA هنگام ورود کاربر، اما اجازه بستن آن توسط کاربر، یا اجرای اجباری هنگام ورود کاربر و جلوگیری از بسته شدن آن.

پس از ذخیره، برنامه دفعه بعد که به‌روزرسانی خط‌مشی روی کروم‌بوک‌های آن واحد سازمانی اعمال شود، نصب خواهد شد. پس از نصب، دستگاه کاربر هر ۴ تا ۶ ساعت به‌روزرسانی‌ها را از Web App Update Manifest بررسی می‌کند.

علاوه بر نصب اجباری IWAها، می‌توانید به طور خودکار برخی از مجوزها را به آنها اعطا کنید، همانطور که برای سایر برنامه‌های وب می‌توانید. برای انجام این کار، به Devices > Chrome > Web capabilities بروید و روی دکمه Add origin کلیک کنید. در Origin / site pattern field ، شناسه بسته وب IWA را وارد کنید ( isolated-app:// به طور خودکار به عنوان پروتکل آن به آن اضافه می‌شود). از آنجا، می‌توانید سطوح دسترسی را برای APIهای مختلف (مجاز/مسدود/غیرفعال) تنظیم کنید، از جمله مدیریت پنجره، مدیریت فونت محلی و API نظارت بر صفحه نمایش . برای APIهایی که ممکن است برای فعال کردن نیاز به انتخاب اضافی از یک مدیر داشته باشند، مانند API نظارت بر صفحه نمایش اجباری، یک کادر محاوره‌ای اضافی برای تأیید انتخاب شما ظاهر می‌شود. پس از اتمام کار، تغییرات خود را ذخیره کنید و کاربران شما آماده استفاده از IWA شما خواهند بود!

کار با افزونه‌ها

اگرچه برنامه‌های وب ایزوله (Isolated Web Apps) به طور پیش‌فرض با افزونه‌ها کار نمی‌کنند، اما می‌توانید افزونه‌های خودتان را به آنها متصل کنید. برای انجام این کار، باید فایل مانیفست افزونه را ویرایش کنید. بخش externally_connectable در مانیفست، صفحات وب خارجی یا سایر افزونه‌های کروم را که افزونه شما می‌تواند با آنها تعامل داشته باشد، تعریف می‌کند. مبدا IWA خود را در قسمت matches در externally_connectable اضافه کنید (مطمئن شوید که طرح isolated-app:// را وارد می‌کنید): 

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

اگرچه این به افزونه شما اجازه می‌دهد تا در برنامه وب ایزوله اجرا شود، اما اجازه تزریق محتوا به آن را نمی‌دهد؛ شما محدود به انتقال پیام‌ها بین افزونه و IWA خود هستید.