Isolated Web App

เว็บเป็นแพลตฟอร์มแอปพลิเคชันที่มีเอกลักษณ์อย่างแท้จริง แอปที่สร้างบนแพลตฟอร์มนี้จะเข้าถึงได้ทันที ในระบบปฏิบัติการใดก็ได้โดยไม่ต้องเปลี่ยนแปลงโค้ดหรือคอมไพล์ เมื่อใดก็ตามที่ผู้ใช้เข้าสู่แอปของคุณ ผู้ใช้จะมีเวอร์ชันล่าสุดเสมอ ติดตั้งและใช้งานแบบออฟไลน์ได้ มีความสามารถสูง และแชร์ได้ง่ายๆ เพียงแค่ลิงก์ สร้าง เว็บแอปพลิเคชัน แล้วใช้งานได้ทุกที่

เนื่องจากเว็บมีเป้าหมายที่จะปลอดภัยโดยค่าเริ่มต้น โมเดลความปลอดภัยจึงต้องมีความระมัดระวังเป็นอย่างมาก ความสามารถใหม่ๆ ที่เพิ่มเข้ามาจะต้องปลอดภัยสำหรับผู้ใช้ทั่วไปที่อาจพบโดยไม่ตั้งใจผ่าน URL เราเรียกรูปแบบความปลอดภัยนี้ว่าการโจมตีแบบไดรฟ์ บายเว็บ แม้ว่าวิธีนี้จะเหมาะกับแอปพลิเคชันหลายอย่างและสามารถเพิ่มความปลอดภัยได้ โดยใช้นโยบายความปลอดภัยของเนื้อหาและการแยกต้นทางข้าม แต่ก็ใช้ไม่ได้กับกรณีการใช้งานบางอย่าง API ที่สำคัญและมีประสิทธิภาพมาก เช่น Direct Sockets และ Controlled Frame ซึ่งนักพัฒนาแอปจำเป็นต้องใช้ ไม่สามารถทำให้ปลอดภัยเพียงพอสำหรับเว็บที่ใช้การดาวน์โหลดโดยไม่แจ้งให้ทราบ

สำหรับแอปพลิเคชันเหล่านี้ ปัจจุบันยังไม่มีตัวเลือกสำหรับการสร้างบนเว็บ สำหรับผู้ใช้รายอื่นๆ โมเดลความปลอดภัยของเว็บอาจไม่เพียงพอ ผู้ใช้เหล่านี้อาจไม่เห็นด้วยกับสมมติฐานที่ว่าเซิร์ฟเวอร์มีความน่าเชื่อถือ และอาจต้องการแอปพลิเคชันแบบสแตนด์อโลนที่ลงนามและมีการควบคุมเวอร์ชันอย่างรอบคอบแทน เราจึงต้องมีโมเดลความปลอดภัยใหม่ที่มีความน่าเชื่อถือสูง Isolated Web App (IWA) มีรูปแบบแอปพลิเคชันที่แยกไว้ รวมไว้ มีการควบคุมเวอร์ชัน มีการลงนาม และเชื่อถือได้ ซึ่งสร้างขึ้นบนแพลตฟอร์มเว็บที่มีอยู่ เพื่อช่วยให้นักพัฒนาแอปเหล่านี้ทำงานได้

ระดับความน่าเชื่อถือบนเว็บ

คุณอาจคิดถึงความปลอดภัยและความสามารถบนเว็บในแง่ของสเปกตรัม

ภาพที่แสดงให้เห็นสเปกตรัมของความน่าเชื่อถือบนเว็บ ทางด้านซ้ายจะมี ลูกโลกที่แสดงถึงเว็บแบบไดรฟ์บาย ตรงกลางคือ Progressive Web App ทางด้านขวาเป็นโหลปลาที่มีปลาทองอยู่ข้างใน ซึ่งแสดงถึง Isolated Web App เส้นสีดำทึบเชื่อมต่อไอคอนทั้ง 3 ในแนวนอน และเส้นสีแดงประ แยก Progressive Web App ออกจาก Isolated Web App

เว็บแบบไดรฟ์บายทางด้านซ้ายมีโมเดลความปลอดภัยที่เชื่อถือได้ต่ำที่สุดเนื่องจาก ต้องเข้าถึงได้มากที่สุด จึงมีสิทธิ์เข้าถึงระบบของผู้ใช้น้อยที่สุด เว็บแอปที่ติดตั้งในเบราว์เซอร์จะได้รับความน่าเชื่อถือมากขึ้นเล็กน้อย และ สามารถผสานรวมกับระบบของผู้ใช้ได้ลึกขึ้นเล็กน้อย โดยทั่วไปแล้ว ผู้ใช้จะสลับ ระหว่างแอปเวอร์ชันเว็บที่เข้าชมโดยตรงกับเวอร์ชันที่ติดตั้งในเบราว์เซอร์ได้โดยไม่มีปัญหา

และสุดท้ายคือ Isolated Web Application ที่มีความน่าเชื่อถือสูง

โดยจะทำงานและให้ความรู้สึกเหมือนแอปดั้งเดิมมากขึ้น และสามารถเข้าถึงการผสานรวมระบบอย่างลึกซึ้งและความสามารถอันทรงพลัง ผู้ใช้จะสลับระหว่างหน้าเว็บเหล่านั้นกับ การโจมตีแบบไดรฟ์บายเว็บไม่ได้ หากคุณต้องการระดับความปลอดภัยหรือความสามารถเหล่านี้ คุณจะ ย้อนกลับไม่ได้

เมื่อพยายามตัดสินใจว่าคุณควรเลือกใช้ความปลอดภัยระดับใดในสเปกตรัมนี้ ให้เลือกใช้โมเดลความปลอดภัยที่มีความน่าเชื่อถือต่ำสุดเท่าที่จะทำได้ เช่น Progressive Web App วิธีนี้จะช่วยให้คุณเข้าถึงผู้ใช้ได้มากที่สุด คุณจะต้องจัดการข้อกังวลด้านความปลอดภัยด้วยตนเองน้อยที่สุด และจะเป็นวิธีที่ยืดหยุ่นที่สุดสำหรับนักพัฒนาแอปและผู้ใช้

ออกแบบเพื่อความปลอดภัย

Isolated Web App มีโมเดลความปลอดภัยที่เชื่อถือได้สูงสำหรับเว็บแอปพลิเคชัน แต่หากต้องการเปิดใช้ฟีเจอร์ดังกล่าว คุณจะต้องพิจารณาใหม่เกี่ยวกับสมมติฐานบางอย่างที่การโจมตีแบบไดรฟ์บายเว็บมีต่อความน่าเชื่อถือ องค์ประกอบหลักในการสร้างเว็บ เช่น เซิร์ฟเวอร์และ DNS ไม่สามารถ เชื่อถือได้อย่างชัดเจนอีกต่อไป เวกเตอร์การโจมตีที่อาจดูมีความเกี่ยวข้องมากขึ้นสำหรับ แอปเนทีฟก็กลายเป็นสิ่งสำคัญขึ้นมาทันที ดังนั้น หากต้องการเข้าถึงโมเดลความปลอดภัยที่มีความน่าเชื่อถือสูงแบบใหม่ ที่ IWA มอบให้ เว็บแอปจะต้องได้รับการแพ็กเกจ แยก และ ล็อกดาวน์

แพ็กเกจ

ระบบจะแสดงหน้าเว็บและชิ้นงานสำหรับ Isolated Web App จากเซิร์ฟเวอร์ที่ใช้งานจริงหรือ ดึงข้อมูลผ่านเครือข่ายเหมือนกับเว็บแอปพลิเคชันปกติไม่ได้ แต่หากต้องการเข้าถึง โมเดลความปลอดภัยที่มีความน่าเชื่อถือสูงแบบใหม่ เว็บแอปจะต้องแพ็กเกจทรัพยากรทั้งหมดที่จำเป็นต่อการเรียกใช้เป็น WebBundle ที่ลงชื่อแล้ว Signed web bundles จะนำทรัพยากรทั้งหมดที่จำเป็นต่อการเรียกใช้เว็บไซต์มาจัดแพ็กเกจ รวมกันเป็นไฟล์ .swbn โดยเชื่อมต่อกับบล็อกความสมบูรณ์ ซึ่งช่วยให้ดาวน์โหลดเว็บแอปได้อย่างปลอดภัยทั้งแอป และยังแชร์หรือติดตั้งขณะออฟไลน์ได้ด้วย

อย่างไรก็ตาม วิธีนี้ทำให้เกิดปัญหาในการยืนยันความถูกต้องของโค้ดของเว็บไซต์ เนื่องจากคีย์ TLS ต้องใช้การเชื่อมต่ออินเทอร์เน็ตจึงจะทำงานได้ IWA จะลงชื่อด้วยคีย์ที่เก็บไว้แบบออฟไลน์ได้อย่างปลอดภัยแทนที่จะใช้คีย์ TLS ข่าวดีคือหากรวบรวมไฟล์การผลิตทั้งหมดไว้ในโฟลเดอร์เดียวได้ คุณก็สามารถเปลี่ยนโฟลเดอร์นั้นเป็น 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 จะระบุด้วยคีย์สาธารณะของ Bundle ซึ่งเป็นส่วนหนึ่งของ ลายเซ็นและเชื่อมโยงกับคีย์ส่วนตัวแทน การเปลี่ยนแปลงนี้เป็น การเปลี่ยนแปลงที่สำคัญต่อวิธีการทำงานของเว็บแบบไดรฟ์บาย ดังนั้น IWA จึงใช้รูปแบบใหม่แทนการใช้ HTTPS ด้วย isolated-app://

จัดกลุ่มแอป

เมื่อมีคีย์ Signing แล้ว ก็ถึงเวลาจัดกลุ่มเว็บแอปของคุณ โดยคุณสามารถใช้แพ็กเกจ NodeJS อย่างเป็นทางการเพื่อจัดกลุ่มแล้วลงนาม IWA (เครื่องมือบรรทัดคำสั่งGo ก็พร้อมใช้งานเช่นกัน) ก่อนอื่น ให้ใช้แพ็กเกจ wbn โดยชี้ไปยังโฟลเดอร์ที่มีไฟล์เวอร์ชันที่ใช้งานจริงทั้งหมดของ IWA (ที่นี่คือ dist) เพื่อรวมไฟล์เหล่านั้นไว้ใน Bundle ที่ไม่ได้ลงนาม

npx wbn --dir dist

ซึ่งจะสร้าง Web Bundle ที่ไม่ได้ลงนามของไดเรกทอรีนั้นไปยัง out.wbn. เมื่อสร้างแล้ว ให้ใช้คีย์ Ed25519 หรือ ECDSA P-256 ที่เข้ารหัสซึ่งคุณสร้างไว้ก่อนหน้านี้ เพื่อลงนามโดยใช้ wbn-sign ดังนี้

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

การดำเนินการนี้จะสร้าง Signed Web Bundle จาก Web Bundle ที่ไม่ได้ลงนามซึ่งมีชื่อว่า signed.swbn เมื่อลงชื่อแล้ว เครื่องมือจะแสดงรหัสชุดของเว็บและต้นทางของ Isolated Web App ด้วย ต้นทางของ Isolated Web App คือวิธีระบุ IWA ในเบราว์เซอร์

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

หากใช้ Webpack, Rollup หรือเครื่องมือที่รองรับปลั๊กอิน (เช่น Vite) คุณสามารถใช้ปลั๊กอิน Bundler อย่างใดอย่างหนึ่ง (Webpack, Rollup) ที่รวมแพ็กเกจเหล่านี้แทนการเรียกใช้โดยตรง การดำเนินการนี้จะสร้าง Bundle ที่ลงชื่อแล้ว เป็นเอาต์พุตของการสร้าง

ทดสอบแอป

คุณทดสอบ IWA ได้ 2 วิธี ได้แก่ เรียกใช้เซิร์ฟเวอร์ การพัฒนาผ่านพร็อกซีสำหรับนักพัฒนา IWA ในตัวของ Chrome หรือติดตั้ง IWA ที่ รวมไว้ โดยคุณจะต้องใช้ Chrome หรือ ChromeOS เวอร์ชัน 120 ขึ้นไป เปิดใช้ค่าสถานะ IWA และติดตั้งแอปผ่านส่วนภายในของเว็บแอปใน Chrome โดยทำดังนี้

  1. เปิดใช้ฟีเจอร์ทดลองของ chrome://flags/#enable-isolated-web-app-dev-mode
  2. ทดสอบ IWA โดยไปที่หน้า "ส่วนประกอบภายในของเว็บแอป" ของ Chrome ที่ chrome://web-app-internals

เมื่ออยู่ในหน้าส่วนประกอบภายในของเว็บแอป คุณจะมี 2 ตัวเลือก ได้แก่ Install IWA with Dev Mode Proxy หรือ Install IWA from Signed Web Bundle

หากติดตั้งผ่านพร็อกซีโหมดนักพัฒนาแอป คุณจะติดตั้ง URL ใดก็ได้ รวมถึง เว็บไซต์ที่ทำงานจากเซิร์ฟเวอร์การพัฒนาในเครื่องเป็น IWA โดยไม่ต้องรวมไว้ด้วย หาก URL นั้นเป็นไปตามข้อกำหนดอื่นๆ ในการติดตั้ง IWA เมื่อติดตั้งแล้ว ระบบจะเพิ่ม IWA สำหรับ URL นั้นลงในระบบของคุณพร้อมกับนโยบายด้านความปลอดภัยที่ถูกต้อง และการจำกัดที่เหมาะสม รวมถึงสิทธิ์เข้าถึง API ที่ใช้ได้กับ IWA เท่านั้น ระบบจะกำหนด ตัวระบุแบบสุ่มให้ เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ยังพร้อมใช้งานในโหมดนี้เพื่อช่วยคุณ แก้ไขข้อบกพร่องของแอปพลิเคชันด้วย หากติดตั้งจาก Signed Web Bundle คุณจะต้องอัปโหลด IWA ที่ลงนามและจัดกลุ่มไว้ แล้วระบบจะติดตั้งเหมือนกับว่าผู้ใช้ปลายทาง ดาวน์โหลดมา

ในหน้า "ข้อมูลภายในของเว็บแอป" คุณยังบังคับให้ตรวจสอบการอัปเดตสำหรับแอปพลิเคชันที่ติดตั้งผ่านพร็อกซีโหมดนักพัฒนาแอปหรือจาก Web Bundle ที่ลงชื่อเพื่อทดสอบกระบวนการอัปเดตได้ด้วย

แยก

ความน่าเชื่อถือเป็นสิ่งสำคัญสำหรับ Isolated Web App ซึ่งเริ่มต้นด้วยวิธีที่แอปทำงาน ผู้ใช้มี โมเดลความคิดที่แตกต่างกันเกี่ยวกับสิ่งที่แอปทำได้และควรทำได้ โดยขึ้นอยู่กับ ว่าแอปทำงานในเบราว์เซอร์หรือในหน้าต่างแบบสแตนด์อโลน โดยทั่วไป ผู้ใช้เชื่อว่าแอปแบบสแตนด์อโลนมีสิทธิ์เข้าถึงมากกว่าและมีประสิทธิภาพมากกว่า เนื่องจาก IWA สามารถเข้าถึง API ที่มีความน่าเชื่อถือสูงได้ จึงต้องทำงานใน หน้าต่างแบบสแตนด์อโลนเพื่อให้สอดคล้องกับโมเดลทางจิตวิทยา ซึ่งจะแยกแอปออกจากเบราว์เซอร์อย่างชัดเจน แต่การแยกนี้ไม่ได้มีแค่ภาพ

Isolated Web App ทำงานบนโปรโตคอลที่แยกต่างหากจากเว็บไซต์ในเบราว์เซอร์ (isolated-app เทียบกับ http หรือ https) ซึ่งหมายความว่า IWA แต่ละรายการจะแยกออกจากเว็บไซต์ที่ทำงานในเบราว์เซอร์โดยสิ้นเชิง แม้ว่าบริษัทเดียวกันจะเป็นผู้สร้างก็ตาม เนื่องจากนโยบายต้นทางเดียวกัน นอกจากนี้ พื้นที่เก็บข้อมูลของ IWA ยังแยกออกจากกันด้วย การทำงานร่วมกันนี้ช่วยให้มั่นใจได้ว่าเนื้อหาแบบข้ามต้นทางจะไม่รั่วไหลระหว่าง IWA ต่างๆ หรือระหว่าง IWA กับบริบทการท่องเว็บปกติของผู้ใช้

แต่การแยก การรวม และการลงนามในโค้ดของเว็บไซต์นั้นไม่มีประโยชน์ในการสร้างความน่าเชื่อถือหาก IWA สามารถดาวน์โหลดและเรียกใช้โค้ดโดยไม่มีกฎเกณฑ์หลังการติดตั้ง IWA จะบังคับใช้ชุดนโยบายรักษาความปลอดภัยเนื้อหาที่เข้มงวดเพื่อให้มั่นใจในเรื่องนี้ในขณะที่ยังอนุญาตให้ IWA เชื่อมต่อกับเว็บไซต์อื่นๆ เพื่อดูเนื้อหาได้

  • อนุญาตเฉพาะ JavaScript จาก Bundle แต่จะอนุญาตให้ Wasm ทำงานได้ไม่ว่าจะมีแหล่งที่มาใดก็ตาม (script-src)
  • อนุญาตให้ JavaScript ดึงข้อมูลจากโดเมนแบบข้ามต้นทางที่ไม่ใช่ localhost ที่ปลอดภัย เชื่อมต่อ WebSocket และ WebTransport ปลายทาง รวมถึง blob และ data URL (connect-src)
  • ป้องกันการโจมตีด้วยการแทรกสคริปต์ข้ามเว็บไซต์ (XSS) ใน DOM โดย ควบคุมวิธีใช้ฟังก์ชันการจัดการ DOM (require-trusted-types-for)
  • อนุญาตเฟรม รูปภาพ เสียง และวิดีโอจากโดเมน HTTPS ใดก็ได้ (frame-src, img-src, media-src)
  • อนุญาตแบบอักษรจากแพ็กเกจและ Blob (font-src)
  • อนุญาต CSS แบบอินไลน์หรือ CSS จากชุดข้อมูล (style-src)
  • <object> <embed> และ <base> ใช้ไม่ได้ (object-src และ base-uri)
  • อนุญาตเฉพาะทรัพยากรจาก Bundle สำหรับคำขออื่นๆ ที่ครอบคลุมโดย 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 ยังแยกต้นทาง ข้ามโดเมนด้วย โดยตั้งค่าส่วนหัวเพื่อลดความสามารถของแหล่งข้อมูลของบุคคลที่สามในการส่งผลต่อ 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 ป้องกันปัญหานี้โดย ไม่อนุญาตให้มีการ Deep Link โดยพลการจากเว็บไซต์ภายนอก และอนุญาตให้ เปิดแอปพลิเคชันได้โดยไปที่จุดแรกเข้าที่กำหนดไว้อย่างชัดเจน เช่น start_url เครื่องจัดการ โปรโตคอล เป้าหมายการ แชร์ หรือผ่านเครื่องจัดการ การเปิด

ล็อกดาวน์

การแพ็กเกจและการแยกทำให้มั่นใจได้ว่าระบบจะอนุญาตให้เรียกใช้สิ่งใดและสิ่งนั้นมาจากที่ใด แต่ลักษณะแบบไดนามิกของสิทธิ์บนเว็บหมายความว่าการแพ็กเกจและการแยกเพียงอย่างเดียวไม่สามารถรับประกันได้ว่าเว็บแอปพลิเคชันจะใช้เฉพาะความสามารถที่จำเป็นเท่านั้น เนื่องจากความสามารถที่แตกต่างกันมีข้อควรพิจารณาด้านความปลอดภัยที่แตกต่างกัน ผู้ใช้หรือผู้ดูแลระบบจึงควรตรวจสอบสิทธิ์ที่ IWA อาจใช้ เช่นเดียวกับที่ทำกับแอปเนทีฟอื่นๆ เช่น Android และ iOS ก่อนที่จะติดตั้งหรืออัปเดตแอป

Isolated Web App จะบล็อกคำขอสิทธิ์ทั้งหมดโดยค่าเริ่มต้นเพื่ออำนวยความสะดวกในเรื่องนี้ จากนั้นนักพัฒนาแอปจะเลือกใช้สิทธิ์ที่ต้องการได้โดยการเพิ่มฟิลด์ permissions_policy ลงในไฟล์ Manifest ของ Web App ฟิลด์นี้มีคู่คีย์/ค่าของคำสั่งนโยบายสิทธิ์ และรายการที่อนุญาตของนโยบายสิทธิ์ สำหรับสิทธิ์แต่ละรายการที่ IWA หรือเฟรมย่อย เช่น เฟรมที่ควบคุมหรือ iframe อาจขอ การเพิ่มสิทธิ์ที่นี่ไม่ได้เป็นการให้สิทธิ์โดยอัตโนมัติ แต่จะทำให้สิทธิ์พร้อมให้ขอเมื่อมีการขอความสามารถนั้น

สมมติว่าคุณกำลังสร้าง IWA สำหรับการติดตามกองยานพาหนะเป็นตัวอย่าง คุณอาจต้องมี IWA เพื่อขอตำแหน่งของผู้ใช้ และแผนที่ฝังตัวก็ต้องขอตำแหน่งด้วยเช่นกัน นอกจากนี้ คุณอาจต้องการให้เว็บไซต์ที่ฝังสามารถเข้าสู่ โหมดเต็มหน้าจอเพื่อให้ผู้ใช้ได้รับประสบการณ์การรับชมที่สมจริง โดยคุณจะต้องตั้งค่านโยบายสิทธิ์ต่อไปนี้ในไฟล์ Manifest ของเว็บแอป

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

เนื่องจาก WebBundle สามารถระบุส่วนหัวPermissions Policy ได้ด้วย ระบบจึงจะอนุญาตเฉพาะสิทธิ์ที่ประกาศในทั้ง 2 ส่วน และจะอนุญาตเฉพาะต้นทางในรายการที่อนุญาตซึ่งอยู่ในทั้ง 2 ส่วน

ตั้งชื่อและกำหนดเวอร์ชัน

เว็บแอปปกติจะอาศัยชื่อโดเมน เพื่อระบุตัวตนต่อผู้ใช้ และสามารถอัปเดตได้โดยการเปลี่ยนโค้ดที่ แสดงในโดเมนนั้น แต่เนื่องจากข้อจำกัดด้านความปลอดภัยเกี่ยวกับ Isolated Web Apps จึงต้องจัดการข้อมูลประจำตัวและการอัปเดตในลักษณะที่แตกต่างกัน เช่นเดียวกับ Progressive Web App, Isolated Web App ต้องมีไฟล์ Web App Manifest เพื่อ ระบุแอปต่อผู้ใช้

ไฟล์ Manifest ของเว็บแอป

Isolated Web App จะแชร์พร็อพเพอร์ตี้ไฟล์ Manifest หลักเดียวกันสำหรับ ไฟล์ Manifest ของเว็บแอปเหมือนกับ PWA โดยอาจมีการเปลี่ยนแปลงเล็กน้อย เช่น display จะทำงานแตกต่างออกไปเล็กน้อย โดยทั้ง browser และ minimal-ui จะเปลี่ยนเป็นminimal-ui minimal-ui และทั้ง fullscreen และ standalone จะเปลี่ยนเป็นstandalone standalone (ตัวเลือก display_override อื่นๆ จะทำงานตามที่คาดไว้) นอกจากนี้ ยังมีอีก 2 ฟิลด์ที่ควรระบุ ได้แก่ version และ update_manifest_url

  • version: ต้องระบุสำหรับเว็บแอปที่แยก สตริงที่ประกอบด้วยจำนวนเต็มอย่างน้อย 1 ตัวซึ่งคั่นด้วยจุด (.) เวอร์ชันของคุณอาจเป็นแบบง่ายๆ เช่น 1, 2, 3 ฯลฯ หรืออาจเป็นแบบซับซ้อน เช่น SemVer (1.2.3) หมายเลขเวอร์ชันควรตรงกับนิพจน์ทั่วไป ^(\d+.?)*\d$
  • update_manifest_url: ไม่บังคับ แต่เป็นฟิลด์ที่แนะนําซึ่งชี้ไปยัง URL HTTPS (หรือ localhost สําหรับการทดสอบ) ที่สามารถดึงข้อมูลไฟล์ Manifest การอัปเดตเว็บแอปพลิเคชัน ได้

ไฟล์ Manifest ของเว็บแอปแบบเรียบง่ายที่สุดสำหรับ Isolated Web App อาจมีลักษณะดังนี้

{
  "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"
    }
  ]
}

ไฟล์ Manifest การอัปเดตเว็บแอปพลิเคชัน

ไฟล์ Manifest การอัปเดตเว็บแอปพลิเคชันคือไฟล์ JSON ที่อธิบายแต่ละเวอร์ชันของ เว็บแอปพลิเคชันที่ระบุ ออบเจ็กต์ JSON มีฟิลด์ที่ต้องระบุ 1 รายการ version ซึ่งเป็นรายการออบเจ็กต์ที่มี version, src และ channels

  • version - หมายเลขเวอร์ชันของแอปพลิเคชัน ซึ่งเหมือนกับฟิลด์ version ของ Manifest ของเว็บแอป
  • src - HTTPS URL (หรือ localhost สำหรับการทดสอบ) ที่ชี้ไปยัง แพ็กเกจที่โฮสต์สำหรับเวอร์ชันนั้น (ไฟล์ .swbn) URL ที่เกี่ยวข้องจะเกี่ยวข้องกับ ไฟล์ Manifest การอัปเดตเว็บแอปพลิเคชัน
  • channels - รายการสตริงเพื่อระบุช่องการอัปเดตที่เวอร์ชันนี้ เป็นส่วนหนึ่ง ระบบจะใช้defaultช่องพิเศษเพื่ออธิบายช่องหลัก ที่จะใช้หากไม่ได้เลือกช่องอื่น

นอกจากนี้ คุณยังใส่ฟิลด์ channels ซึ่งเป็นออบเจ็กต์ของรหัสช่องที่มีพร็อพเพอร์ตี้ name ที่ไม่บังคับสำหรับแต่ละรหัสเพื่อระบุชื่อที่อ่านได้ (รวมถึงสำหรับช่อง default ด้วย) ช่องที่ไม่มีพร็อพเพอร์ตี้ name หรือไม่ได้รวมอยู่ในออบเจ็กต์ channels จะใช้รหัสของช่องเป็นชื่อ

ไฟล์ Manifest การอัปเดตขั้นต่ำอาจมีลักษณะดังนี้

{
  "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"
    }
  }
}

ในตัวอย่างนี้ มี 3 ช่อง ได้แก่ default ซึ่งจะมีป้ายกำกับเป็น Stable, 5-lts ซึ่งจะมีป้ายกำกับเป็น 5.x Long-term Stable และ next ซึ่งจะมีป้ายกำกับเป็น next หากผู้ใช้ใช้ช่อง 5-lts ก็จะได้รับเวอร์ชัน 5.2.17 หากใช้ช่อง default ก็จะได้รับเวอร์ชัน 5.3.0 และหาก ใช้ช่อง next ก็จะได้รับเวอร์ชัน 5.3.1

คุณโฮสต์ไฟล์ Manifest การอัปเดตเว็บแอปพลิเคชันได้ในเซิร์ฟเวอร์ใดก็ได้ ระบบจะตรวจสอบการอัปเดตทุกๆ 4-6 ชั่วโมง

จัดการโดยผู้ดูแลระบบ

ในตอนแรก Isolated Web App จะติดตั้งได้เฉพาะใน Chromebook ที่จัดการโดย Chrome Enterprise เท่านั้น โดยผู้ดูแลระบบจะติดตั้งผ่านแผงผู้ดูแลระบบ

หากต้องการเริ่มต้น ให้ไปที่อุปกรณ์ > Chrome > แอปและ ส่วนขยาย > ผู้ใช้และเบราว์เซอร์จากแผงผู้ดูแลระบบ แท็บนี้ช่วยให้คุณเพิ่มแอปและส่วนขยาย จาก Chrome เว็บสโตร์, Google Play และเว็บสำหรับผู้ใช้ทั่วทั้ง องค์กรได้ การเพิ่มรายการทำได้โดยเปิดปุ่มเพิ่มสีเหลืองแบบลอย (+) ที่มุมขวาล่างของหน้าจอ แล้วเลือกประเภทรายการ ที่จะเพิ่ม

เมื่อเปิดแล้ว จะมีไอคอนสี่เหลี่ยมจัตุรัสอยู่ภายในสี่เหลี่ยมจัตุรัส โดยมีป้ายกำกับว่าเพิ่ม Isolated Web App การคลิกไอคอนนี้จะเปิดโมดอลเพื่อเพิ่ม IWA ลงใน OU ของคุณ โดยคุณจะต้องมีข้อมูล 2 อย่าง ได้แก่ รหัส Web Bundle ของ IWA (สร้างจากคีย์สาธารณะของแอปและแสดงหลังจากที่แอปได้รับการจัดกลุ่มและลงนามแล้ว) และ URL ของไฟล์ Manifest สำหรับการอัปเดตเว็บแอปสำหรับ IWA เมื่อติดตั้งแล้ว คุณจะมีชุดตัวเลือกมาตรฐานของแผงผู้ดูแลระบบเพื่อจัดการ ดังนี้

  • นโยบายการติดตั้ง: วิธีที่คุณต้องการติดตั้ง IWA ไม่ว่าจะบังคับติดตั้ง บังคับติดตั้งและปักหมุดไว้ที่ชั้นวางของ ChromeOS หรือป้องกันการติดตั้ง
  • เปิดใช้เมื่อเข้าสู่ระบบ: วิธีที่คุณต้องการให้เปิดใช้ IWA ไม่ว่าจะอนุญาตให้ผู้ใช้ เปิดใช้ด้วยตนเอง บังคับให้ IWA เปิดใช้เมื่อผู้ใช้เข้าสู่ระบบ แต่ให้ผู้ใช้ ปิดได้ หรือบังคับให้เปิดใช้เมื่อผู้ใช้เข้าสู่ระบบและป้องกันไม่ให้ปิด

เมื่อบันทึกแล้ว ระบบจะติดตั้งแอปในครั้งถัดไปที่มีการใช้อัปเดตนโยบายกับ Chromebook ใน OU นั้น เมื่อติดตั้งแล้ว อุปกรณ์ของผู้ใช้จะตรวจสอบ การอัปเดตจากไฟล์ Manifest การอัปเดตเว็บแอปทุกๆ 4-6 ชั่วโมง

นอกเหนือจากการบังคับติดตั้ง IWA แล้ว คุณยังให้สิทธิ์บางอย่างโดยอัตโนมัติ สำหรับ IWA ได้ในลักษณะเดียวกับที่ทำกับเว็บแอปพลิเคชันอื่นๆ โดยไปที่อุปกรณ์ > Chrome > ความสามารถของเว็บ แล้วคลิกปุ่มเพิ่มต้นทาง ใน Origin / site pattern field ให้วางรหัสชุดของเว็บของ IWA (ระบบจะเพิ่ม isolated-app:// ลงในรหัสโดยอัตโนมัติเป็นโปรโตคอล) จากนั้น คุณสามารถตั้งค่าระดับการเข้าถึง API ต่างๆ (อนุญาต/บล็อก/ไม่ได้ตั้งค่า) รวมถึง API การจัดการหน้าต่าง การจัดการแบบอักษรในเครื่อง และ API การตรวจสอบหน้าจอ สำหรับ API ที่อาจต้องมีการเลือกใช้เพิ่มเติมจากผู้ดูแลระบบเพื่อเปิดใช้ เช่น API การตรวจสอบหน้าจอที่บังคับใช้ จะมีกล่องโต้ตอบเพิ่มเติมปรากฏขึ้นเพื่อยืนยัน การเลือกของคุณ เมื่อเสร็จแล้ว ให้บันทึกการเปลี่ยนแปลง แล้วผู้ใช้จะพร้อม เริ่มใช้ IWA ของคุณ

ใช้งานส่วนขยาย

แม้ว่า Isolated Web App จะไม่ทำงานร่วมกับส่วนขยายได้ทันที แต่คุณก็ เชื่อมต่อส่วนขยายที่คุณเป็นเจ้าของกับแอปเหล่านั้นได้ โดยจะต้องแก้ไขไฟล์ Manifest ของส่วนขยาย ส่วน externally_connectable ของไฟล์ Manifest จะกำหนดหน้าเว็บภายนอกหรือส่วนขยาย Chrome อื่นๆ ที่ส่วนขยายของคุณ โต้ตอบด้วยได้ เพิ่มต้นทางของ IWA ในช่อง matches ภายใน externally_connectable (อย่าลืมใส่รูปแบบ isolated-app://):

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

แม้ว่าการดำเนินการนี้จะช่วยให้ส่วนขยายทำงานในเว็บแอปที่แยกจากกันได้ แต่ก็จะไม่ อนุญาตให้แทรกเนื้อหาลงในเว็บแอปดังกล่าว คุณจะทำได้เพียง ส่งข้อความ ระหว่างส่วนขยายกับ IWA