אפליקציית VPN מבקשת אנשי קשר ונגישות: מה לאשר

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

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

ההרשאה היחידה שהעבודה באמת צריכה

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

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

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

היכן שהבקשות הנוספות זקוקות להסבר משלהן

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

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

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

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

לקרוא את הבקשה במכשיר

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

שתי שאילתות מכסות את רוב זה:

adb shell dumpsys package com.example.vpn | grep -E "requested permissions|install permissions" -A 30
adb shell cmd appops get com.example.vpn

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

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

להחליט, ואז להגביל את הנזק

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

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

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