אפליקציות אינטרנט מבודדות (IWA)

האינטרנט הוא פלטפורמת אפליקציות ייחודית. אפשר לגשת לאפליקציות שמבוססות על הטכנולוגיה הזו באופן מיידי בכל מערכת הפעלה, בלי לשנות את הקוד או לבצע קומפילציה. בכל פעם שמשתמש מגיע לאפליקציה שלכם, הוא תמיד מקבל את הגרסה הכי עדכנית. הם ניתנים להתקנה ויכולים לפעול במצב אופליין, הם בעלי יכולות גבוהות וקל מאוד לשתף אותם באמצעות קישור. פיתוח אפליקציית אינטרנט, והיא פשוט פועלת בכל מקום.

מכיוון שהאינטרנט שואף להיות בטוח ומאובטח כברירת מחדל, מודל האבטחה שלו צריך להיות מאוד שמרני. כל היכולות החדשות שנוספות צריכות להיות בטוחות למשתמשים מזדמנים, כך שלא יוכלו להיתקל בהן בטעות דרך כתובת URL. מודל האבטחה הזה נקרא drive-by web. השיטה הזו מצוינת להרבה אפליקציות, ואפשר להפוך אותה למאובטחת יותר באמצעות מדיניות אבטחת תוכן ובידוד בין מקורות שונים, אבל היא לא מתאימה לכל תרחיש שימוש. יש מספר ממשקים חשובים וחזקים מאוד של API, כמו Direct Sockets ו-Controlled Frame, שמפתחים צריכים, אבל אי אפשר להפוך אותם לבטוחים מספיק לשימוש ב-drive by web.

בשלב הזה, אין אפשרות ליצור את האפליקציות האלה באינטרנט. אחרים עשויים לחשוב שמודל האבטחה של האינטרנט לא מספיק שמרני. הם לא מסכימים עם ההנחה שהשרת מהימן, ומעדיפים אפליקציות עצמאיות עם גרסאות נפרדות וחתומות. צריך מודל אבטחה חדש עם רמת אמון גבוהה. אפליקציות אינטרנט מבודדות (IWA) מספקות מודל אפליקציה מבודד, ארוז, עם גרסאות, חתימה ומהימן, שמבוסס על פלטפורמת האינטרנט הקיימת, כדי לאפשר למפתחים האלה:

ספקטרום של אמון באינטרנט

אפשר לחשוב על האבטחה והיכולות באינטרנט במונחים של ספקטרום.

איור שמראה את ספקטרום האמון באינטרנט. בצד ימין, סמל של גלובוס שמייצג את האינטרנט. באמצע, Progressive Web Apps. בצד שמאל, קערת דגים עם דג זהב בתוכה, שמייצגת אפליקציות אינטרנט מבודדות. קו שחור רציף מחבר בין שלושת הסמלים לרוחב, וקו אדום מקווקו מפריד בין אפליקציות Progressive Web App לבין אפליקציות אינטרנט נפרדות.

התקנה דרך אתר, שמופיעה בצד ימין, היא המודל עם רמת האבטחה הכי נמוכה כי היא צריכה להיות הכי נגישה, ולכן יש לה הכי פחות גישה למערכת של המשתמש. אפליקציות אינטרנט שמותקנות בדפדפן מקבלות קצת יותר אמון, ויכולות להשתלב קצת יותר לעומק במערכת של המשתמש. בדרך כלל, המשתמשים יכולים לעבור בין גרסאות אינטרנט של אפליקציות שמופעלות באופן אוטומטי לבין גרסאות שמותקנות בדפדפן ללא בעיה.

אחר כך יש אפליקציות אינטרנט מבודדות (IWA) עם רמת אמון גבוהה.

הן פועלות ומרגישות יותר כמו אפליקציות מקוריות, ויכולות לקבל גישה לשילובים עמוקים במערכת וליכולות מתקדמות. המשתמשים לא יכולים לעבור ביניהם לבין התקפות דרך אתרים. אם אתם צריכים את רמת האבטחה הזו או את היכולות האלה, לא תוכלו לחזור אחורה.

כשמנסים להחליט איפה בספקטרום הזה כדאי להתמקד, מומלץ לבחור כברירת מחדל את מודל האבטחה עם רמת האמון הכי נמוכה שאפשר, כמו אפליקציית אינטרנט מתקדמת. כך תוכלו להגיע למספר המשתמשים הגדול ביותר, תצטרכו לנהל בעצמכם את מספר הבעיות הכי קטן שקשורות לאבטחה, והפתרון יהיה הכי גמיש למפתחים ולמשתמשים שלכם.

מאובטח משלב התכנון (secure-by-design)

אפליקציות אינטרנט מבודדות מספקות מודל אבטחה מהימן מאוד לאפליקציות אינטרנט. כדי להפעיל את התכונה הזו, צריך לשנות כמה מההנחות ש-drive by web מניח לגבי אמון. אי אפשר יותר לבטוח באופן מוחלט באבני בניין מרכזיות של האינטרנט, כמו שרתים ו-DNS. וקטורי תקיפה שעשויים להיראות רלוונטיים יותר לאפליקציות מקוריות הופכים פתאום לחשובים. לכן, כדי לקבל גישה למודל האבטחה החדש ברמת מהימנות גבוהה שמסופק על ידי אפליקציות IWA, צריך לארוז, לבודד ולנעול את אפליקציות האינטרנט.

ארוז

אי אפשר להציג דפים ונכסים של אפליקציות אינטרנט מבודדות משרתים פעילים או לאחזר אותם דרך הרשת כמו באפליקציות אינטרנט רגילות. במקום זאת, כדי לקבל גישה למודל האבטחה החדש ברמת מהימנות גבוהה, אפליקציות אינטרנט צריכות לארוז את כל המשאבים שהן צריכות להפעלה בחבילת אינטרנט חתומה. חבילות אינטרנט חתומות לוקחות את כל המשאבים שנדרשים להפעלת אתר ואורזות אותם יחד בקובץ .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://.

יצירת קובץ App Bundle

אחרי שיש לכם את מפתח החתימה, הגיע הזמן לארוז את אפליקציית האינטרנט. כדי לעשות זאת, אתם יכולים להשתמש בחבילות הרשמיות של 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. אחרי החתימה, הכלי יציג גם את מזהה חבילת האינטרנט ואת המקור של אפליקציית האינטרנט המבודדת. המקור של אפליקציית האינטרנט המבודדת הוא הדרך שבה האפליקציה מזוהה בדפדפן.

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

אם אתם משתמשים ב-Webpack,‏ Rollup או בכלי שתומך בפלאגינים שלהם (כמו Vite), אתם יכולים להשתמש באחד מהפלאגינים של bundler (‏Webpack,‏ Rollup) שעוטף את החבילות האלה במקום לקרוא להן ישירות. פעולה כזו תיצור חבילה חתומה כפלט של הבנייה.

בדיקת האפליקציה

יש שתי דרכים לבדוק את ה-IWA: אפשר להריץ את שרת הפיתוח באמצעות פרוקסי מובנה למפתחי IWA ב-Chrome, או להתקין את ה-IWA המצורף. כדי לעשות זאת, צריך להשתמש ב-Chrome או ב-ChromeOS מגרסה 120 ואילך, להפעיל את הדגלים של IWA ולהתקין את האפליקציה דרך Web App Internals של Chrome:

הפעלת הדגל chrome://flags/#enable-isolated-web-app-dev-mode
כדי לבדוק את ה-IWA, עוברים לדף Web App Internals ב-Chrome בכתובת chrome://web-app-internals

בדף Web App Internals (פרטים פנימיים של אפליקציית אינטרנט), יש שתי אפשרויות: Install IWA with Dev Mode Proxy או Install IWA from Signed Web Bundle.

אם מתקינים דרך שרת proxy במצב פיתוח, אפשר להתקין כל כתובת URL, כולל אתרים שפועלים משרת פיתוח מקומי, כ-IWA, בלי לארוז אותם, בתנאי שהם עומדים בדרישות ההתקנה האחרות של IWA. אחרי ההתקנה, יתווסף לכתובת ה-URL הזו IWA למערכת עם מדיניות האבטחה וההגבלות הנכונות, וגישה לממשקי API של IWA בלבד. יוקצה לו מזהה אקראי. במצב הזה זמינים גם כלי הפיתוח ל-Chrome, שיעזרו לכם לנפות באגים באפליקציה. אם מתקינים מתוך חבילת אינטרנט חתומה, מעלים את ה-IWA החתום והארוז, והוא יותקן כאילו הוא הורד על ידי משתמש קצה.

בדף Web App Internals (פרטים פנימיים של אפליקציית אינטרנט) אפשר גם לאלץ בדיקות עדכון לכל האפליקציות שהותקנו דרך Dev Mode Proxy (פרוקסי של מצב פיתוח) או מ-Signed Web Bundle (חבילת אינטרנט חתומה) כדי לבדוק גם את תהליך העדכון.

מבודד

אמון הוא המפתח לאפליקציות אינטרנט מבודדות (IWA). הכל מתחיל באופן שבו הם פועלים. למשתמשים יש מודלים מנטליים שונים לגבי מה שאפליקציה יכולה לעשות, ומה שהיא צריכה לעשות, בהתאם לשאלה אם היא פועלת בדפדפן או בחלון עצמאי. בדרך כלל הם מאמינים שלאפליקציות עצמאיות יש יותר גישה והן חזקות יותר. אפליקציות IWA יכולות לקבל גישה לממשקי API עם רמת מהימנות גבוהה, ולכן הן צריכות לפעול בחלון עצמאי כדי להתאים למודל המנטלי הזה. ההפרדה הזו מאפשרת להבחין ביניהם לבין הדפדפן. אבל זה לא מסתכם בהפרדה ויזואלית.

אפליקציות אינטרנט מבודדות פועלות בפרוטוקול נפרד מאתרים בדפדפן (isolated-app לעומת http או https). המשמעות היא שכל אפליקציית IWA מופרדת לחלוטין מאתרים שפועלים בדפדפן, גם אם הם נוצרו על ידי אותה חברה, הודות למדיניות של אותו מקור. גם האחסון של אפליקציות IWA מופרד זו מזו. השילוב הזה מבטיח שלא תהיה דליפה של תוכן ממקורות שונים בין חלונות IWA שונים או בין חלונות IWA לבין הקשר הגלישה הרגיל של המשתמש.

אבל בידוד או צרור וחתימה של קוד האתר לא עוזרים לבסס אמון אם אפליקציית IWA יכולה להוריד ולהריץ קוד שרירותי אחרי ההתקנה. כדי לוודא זאת, ובמקביל לאפשר לאפליקציות IWA להתחבר לאתרים אחרים כדי להציג תוכן, אפליקציות IWA אוכפות קבוצה מחמירה של כללי מדיניות בנושא אבטחת תוכן:

האפשרות הזו מאפשרת רק JavaScript מהחבילה, אבל היא מאפשרת להריץ Wasm בלי קשר למקור שלו. (script-src)
מאפשר ל-JavaScript לאחזר נתונים מדומיינים מאובטחים שאינם localhost וחוצי מקורות, להתחבר לנקודות קצה של WebSocket ושל WebTransport, וגם לכתובות URL של blob ושל data (connect-src)
הגנה מפני התקפות של הזרקת סקריפט חוצה אתרים (XSS) ב-DOM על ידי ויסות השימוש בפונקציות של מניפולציה ב-DOM‏ (require-trusted-types-for)
מאפשרת להציג פריימים, תמונות, אודיו ווידאו מכל דומיין 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';

ה-CSPs האלה לא מספיקים כדי להגן באופן מלא מפני קוד של צד שלישי שעלול להיות זדוני. בנוסף, חלונות 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, רכיב handler של פרוטוקול, יעד שיתוף או רכיב handler של הפעלה.

נעילה

האריזה והבידוד מספקים קבוצה של הבטחות לגבי מה מותר להפעיל ומאיפה זה הגיע, אבל האופי הדינמי של ההרשאות באינטרנט אומר שהם לבדם לא יכולים להבטיח שאפליקציית אינטרנט משתמשת רק ביכולות שהיא צריכה. לכל יכולת יש שיקולי אבטחה שונים, ולכן משתמש או אדמין ירצו לבדוק באילו הרשאות אפליקציית IWA יכולה להשתמש, בדיוק כמו שהם יכולים לעשות עם אפליקציות מקוריות אחרות כמו Android ו-iOS, לפני שהם מתקינים או מעדכנים אפליקציה.

כדי לאפשר זאת, אפליקציות אינטרנט מבודדות חוסמות כברירת מחדל את כל בקשות ההרשאה. מפתחים יכולים להביע הסכמה לשימוש בהרשאה שהם צריכים על ידי הוספת השדה permissions_policy למניפסט של אפליקציית האינטרנט שלהם. השדה הזה מכיל זוגות של מפתח/ערך של הנחיות למדיניות הרשאות ורשימות היתרים למדיניות הרשאות לכל הרשאה ש-IWA, או כל מסגרת צאצא כמו מסגרת מבוקרת או iframe, עשויים לבקש. הוספת הרשאה כאן לא מעניקה אותה באופן אוטומטי. במקום זאת, היא מאפשרת לבקש אותה כשמתבצעת בקשה ליכולת הזו.

נניח שאתם יוצרים אפליקציית אינטרנט מתקדמת למעקב אחרי צי רכבים. יכול להיות שתצטרכו את ה-IWA כדי לבקש את המיקום של המשתמש, וגם כדי שמפה מוטמעת תוכל לבקש את המיקום. כדאי גם לאפשר לאתר המוטמע לעבור למסך מלא כדי שהמשתמש יוכל ליהנות מתצוגה סוחפת. כדי לעשות זאת, צריך להגדיר את מדיניות ההרשאות הבאה בקובץ המניפסט של אפליקציית האינטרנט:

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

בגלל ש-WebBundles יכולים לציין גם כותרות של Permissions Policy, רק הרשאות שמוצהרות בשני המקומות יותרו, ורק מקורות ברשימות ההיתרים שמופיעים בשני המקומות יותרו.

גרסאות בעלות שם

אפליקציות אינטרנט רגילות מסתמכות על שם הדומיין שלהן כדי להזדהות בפני המשתמשים, ואפשר לעדכן אותן על ידי שינוי הקוד שמוצג בדומיין הזה. אבל בגלל מגבלות האבטחה שקיימות באפליקציות אינטרנט מבודדות, צריך לטפל בזהות ובעדכונים בצורה שונה. בדומה לאפליקציות אינטרנט מתקדמות (PWA), אפליקציות אינטרנט מבודדות (IWA) צריכות קובץ Web App Manifest כדי שהמשתמשים יוכלו לזהות אותן.

מניפסט של אפליקציית אינטרנט

אפליקציות אינטרנט מבודדות (IWA) חולקות את אותן מאפייני מניפסט מרכזיים של מניפסט אפליקציית האינטרנט כמו אפליקציות PWA, עם כמה הבדלים קלים. לדוגמה, display פועל קצת אחרת. גם browser וגם minimal-ui מוצגים ב-minimal-ui, וגם fullscreen וגם standalone מוצגים ב-standalone (אפשרויות נוספות של display_override פועלות כצפוי). בנוסף, יש עוד שני שדות שצריך לכלול, version ו-update_manifest_url:

‫version: חובה לאפליקציות אינטרנט מבודדות (IWA). מחרוזת שמורכבת ממספר שלם אחד או יותר, שמופרדים באמצעות נקודה (.). הגרסה יכולה להיות פשוטה כמו 1, ‏ 2, ‏ 3 וכו', או מורכבת כמו SemVer ‏ (1.2.3). מספר הגרסה צריך להתאים לביטוי הרגולרי ^(\d+.?)*\d$.
‫update_manifest_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 – כתובת ה-URL מסוג HTTPS (או 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.

אפשר לארח מניפסטים של עדכונים לאפליקציות אינטרנט בכל שרת. העדכונים נבדקים כל 4-6 שעות.

בניהול האדמין

בשלב ההשקה הראשוני, אפשר יהיה להתקין אפליקציות IWA רק במכשירי Chromebook שמנוהלים על ידי Chrome Enterprise, על ידי אדמין דרך מרכז הבקרה.

כדי להתחיל, בחלונית הניהול עוברים אל מכשירים > Chrome > אפליקציות ותוספים > משתמשים ודפדפנים. בכרטיסייה הזו אפשר להוסיף אפליקציות ותוספים מחנות האינטרנט של Chrome, מ-Google Play ומאתרים אחרים באינטרנט עבור משתמשים בכל הארגון. כדי להוסיף פריטים, פותחים את לחצן ההוספה הצהוב (+) שמוצג בפינה השמאלית התחתונה של המסך ובוחרים את סוג הפריט שרוצים להוסיף.

כשפותחים את האפליקציה, מופיע סמל של ריבוע בתוך ריבוע עם התווית הוספת אפליקציית אינטרנט מבודדת. לחיצה על הסמל תפתח חלון קופץ שבו אפשר להוסיף אפליקציית אינטרנט מבודדת ליחידה הארגונית. כדי לעשות זאת, תצטרכו שני פרטים: מזהה Web Bundle של אפליקציית האינטרנט המבודדת (נוצר מהמפתח הציבורי של האפליקציה ומוצג אחרי שהאפליקציה נארזת ונחתמת) וכתובת ה-URL של מניפסט העדכון של אפליקציית האינטרנט של ה-IWA. אחרי ההתקנה, יהיו לכם האפשרויות הרגילות של לוח הניהול לניהול האפליקציה:

מדיניות ההתקנה: איך רוצים שה-IWA יותקן – התקנה לפי הגדרת האדמין, התקנה לפי הגדרת האדמין והצמדה למדף של ChromeOS, או מניעת התקנה.
הפעלה בכניסה: איך רוצים שה-IWA יופעל? האם לאפשר למשתמש להפעיל אותו באופן ידני, להפעיל אותו בכוח כשהמשתמש מתחבר לחשבון אבל לאפשר לו לסגור אותו, או להפעיל אותו בכוח כשהמשתמש מתחבר לחשבון ולמנוע ממנו לסגור אותו.

אחרי השמירה, האפליקציה תותקן בפעם הבאה שעדכון מדיניות יוחל על מכשירי Chromebook ביחידה הארגונית הזו. אחרי ההתקנה, המכשיר של המשתמש יבדוק אם יש עדכונים ממניפסט העדכונים של אפליקציית האינטרנט כל 4-6 שעות.

בנוסף לאילוץ התקנה של אפליקציות אינטרנט מתקדמות, אפשר גם להעניק להן באופן אוטומטי הרשאות מסוימות, בדומה לאפליקציות אינטרנט אחרות. כדי לעשות זאת, עוברים אל מכשירים > Chrome > יכולות אינטרנט ולוחצים על הלחצן הוספת מקור. ב-Origin / site pattern field, מדביקים את מזהה חבילת האינטרנט של ה-IWA (המערכת תוסיף אוטומטית את isolated-app:// כפרוטוקול). משם אפשר להגדיר רמות גישה לממשקי API שונים (מותרת/חסומה/לא מוגדרת), כולל ניהול חלונות, ניהול גופנים מקומיים ו-API של מעקב אחר המסך. במקרים של ממשקי API שעשויים לדרוש הסכמה נוספת מאדמין כדי להפעיל אותם, כמו API חובה למעקב אחר המסך, יופיע דו-שיח נוסף כדי לאשר את הבחירה. בסיום, שומרים את השינויים והמשתמשים יהיו מוכנים להתחיל להשתמש באפליקציית ה-IWA.

עבודה עם תוספים

אפליקציות אינטרנט נפרדות לא פועלות עם תוספים כברירת מחדל, אבל אתם יכולים לקשר אליהן תוספים שבבעלותכם. כדי לעשות זאת, צריך לערוך את קובץ המניפסט של התוסף. בקטע externally_connectable של קובץ ה-Manifest מוגדרים דפי אינטרנט חיצוניים או תוספים אחרים ל-Chrome שהתוסף יכול ליצור איתם אינטראקציה. מוסיפים את המקור של ה-IWA בשדה matches בתוך externally_connectable (חשוב לכלול את הסכימה isolated-app://):

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

הפעולה הזו תאפשר לתוסף לפעול באפליקציית האינטרנט המבודדת, אבל לא תאפשר לו להוסיף תוכן לאפליקציה. תוכלו רק להעביר הודעות בין התוסף לבין אפליקציית האינטרנט המבודדת.