בקשות הרשאה הן המנגנון העיקרי באינטרנט להגנה על יכולות חזקות שעלולות לסכן את הפרטיות והאבטחה של המשתמשים. באמצעות הנחיות לגבי הרשאות, הדפדפנים שואפים לוודא שהמשתמש מתכוון לאפשר לאתר המבקש גישה ליכולת הרלוונטית. הנחיות לגבי הרשאות משמשות למספר ממשקי API, כולל צילום מדיה (מצלמה ומיקרופון), מיקום גיאוגרפי, גישה לאחסון, MIDI והתראות (למידע נוסף, ראו המסמכים של Permissions API ב-MDN).
במדריך הזה מפורטות השיטות המומלצות להצגת בקשות הרשאה למשתמשים, על סמך נתוני סטטיסטיקת השימוש ב-Chrome ומחקרים על התנהגות משתמשים. אם תפעלו לפי השיטות המומלצות האלה, המשתמשים יראו פחות הנחיות מיותרות, וכתוצאה מכך המפתחים יקבלו פחות החלטות 'חסימה'. בסוף המאמר מפורטים כמה דפוסי קוד לעבודה עם ממשקי API עם גישה מוגבלת על סמך הרשאות, ושיטות מומלצות שיעזרו למשתמשים להתאושש ממצב חסום.
שיטות מומלצות להצגת הנחיות
מומלץ לבקש הרשאה אחרי אינטראקציה של משתמש, בזמן שבו המשתמשים יכולים להבין למה אתם מבקשים את ההרשאה ומה היתרונות שהם יקבלו אם יאשרו אותה. ככל האפשר, כדאי לאפשר למשתמשים להשתמש באמצעים חלופיים כדי להשיג את אותה פונקציונליות. ככלל, כדאי לבקש הרשאות בתדירות נמוכה יותר ולבחור בקפידה את הרגעים שבהם מבקשים אותן. כך, הסיכוי שהמשתמשים יגיעו למצב חסום שקשה לצאת ממנו יורד. בשיטות המומלצות הבאות מוסבר בהרחבה על כל אחת מההצעות האלה.
לעולם לא לבקש זאת בזמן טעינת הדף או ללא אינטראקציה מצד המשתמש
בקשה מהמשתמשים להעניק הרשאה במהלך טעינת הדף היא כמו בקשה מלקוח למסור מידע רגיש כשהוא נכנס לחנות פיזית. הצגת בקשה לקבלת הרשאה (אולי בין כמה בקשות אחרות להרשמה לניוזלטר ולהסכמה לשימוש בקובצי cookie) היא חוויה מטרידה מאוד. המשתמשים לא יבינו למה הם מתבקשים למסור את הנתונים ואילו יתרונות הם יקבלו.
גם אם אי אפשר להפעיל את אפליקציית האינטרנט בלי גישה ליכולת מסוימת, כדאי לתת למשתמשים הזדמנות להבין למה היא נדרשת. לדוגמה, תוכלו להוסיף להודעת ההרשאה הנחיה משלכם שמסבירה את הצורך ומאפשרת למשתמשים לבחור (לדוגמה, במקרים שבהם אפשר, לספק אמצעים חלופיים להשגת אותה פונקציונליות). אם לא מצאתם מועד טוב יותר לבקש הרשאה מלטעון את הדף, תוכלו למצוא כמה דוגמאות בהמשך המדריך.
מצב לא טוב נוסף לבקשת הרשאה הוא ללא אינטראקציה קודמת של המשתמש (שנקראת גם הפעלה זמנית של משתמש). נתוני הטלמטריה של Chrome מראים ש-77% מהבקשות להרשאות ב-Chrome למחשב מוצגות ללא אות בסיסי כל כך של כוונת המשתמש, וכתוצאה מכך רק 12% מהבקשות האלה מקבלות אישור. אחרי אינטראקציה של משתמש, שיעורי ההרשאה עולים ל-30%. לכן, כדאי לבקש הרשאה רק אחרי שהמשתמש יוצר אינטראקציה עם הדף בצורה כלשהי.
כדאי לבקש רק כשהמשתמש יכול להבין למה אתם מבקשים
ההחלטות לגבי ההרשאות הן בדרך כלל החלטות שקשורות לפרטיות. על סמך המסגרת של תקינות לפי הקשר, אנחנו יודעים שהחלטות שקשורות לפרטיות תלויות מאוד בהקשר. הבנת הסיבה לצורך בגישה היא היבט מרכזי בנושא הזה. לכן, כדאי לבקש רק יכולות שאתם צריכים כדי לספק למשתמשים ערך (ויש סיכוי גבוה שהמשתמשים יסכימו איתכם שהם אכן יקבלו ערך). בנוסף, כדאי לבקש הרשאה בזמן שבו ברור למשתמש למה היכולת הזו מועילה. המטרה היא להקל על המשתמשים להבין את הקשר השימוש.
מחקרי המשתמשים שלנו מראים שיש סיכוי גבוה יותר שהמשתמשים יאשרו גישה כשהם מבינים למה האתר מבקש גישה וגם רואים בו תועלת. כמו כן, אנחנו מגלים שהמשתמשים מצפים לבחון אתרים לא מוכרים קודם כדי להבין טוב יותר את הערך שהם יכולים לקבל בתמורה להרשאת הגישה. בזמן הזה, הם בדרך כלל ידחו או יתעלמו מהודעות לגבי הרשאות. אם תבחרו בהרשאות חד-פעמיות, יכול להיות שהם יאפשרו לכם לבצע ביקור אחד בלבד. האפליקציה צריכה לתמוך בהתנהגויות האלה.
אם אפשר, יש לספק אמצעים חלופיים להשגת אותה פונקציונליות
יכול להיות שהתוצאה של יכולות מסוימות לא תהיה מועילה למשתמשים. לדוגמה, יכול להיות שמיקום גיאוגרפי של מחשב ללא חיישן GPS יחזיר מיקום שגוי כי המשתמש מחובר ל-VPN. משתמשים אחרים אולי לא רוצים לתת גישה ללוח העריכה כי הם מעדיפים לשמור על השליטה ולהפעיל את האירועים האלה באמצעות שילובי מקשים באופן ידני. במצבים כאלה, חשוב לספק אמצעי חלופי להשגת אותן תוצאות. לדוגמה, אם מבקשים הרשאה למיקום גיאוגרפי, כדאי להציע שדה טקסט שבו המשתמשים יוכלו להזין מיקוד או כתובת בעצמם. כשמשתמשים בלוח העריכה, חשוב לוודא שאפשר לבחור את הפריטים שרוצים להעתיק ולהעתיק אותם גם באמצעות שילוב מקשים או תפריט ההקשר. כשאתם שולחים התראות, כדאי להציע לאנשים לקבל אימיילים במקום התראות.
מודל שימושי הוא להשתמש בממשק המשתמש החלופי גם כסיבה לכך שהגישה יכולה להיות מועילה. משתמשים שיראו אפשרות להזין מיקום לצד לחצן שמפעיל את Geolocation API ירגישו שהם שולטים במה שיקרה, כי הם מבינים שהם יכולים גם פשוט להקליד את הכתובת שלהם. באופן דומה, אם יש אפשרות לבחור בין קבלת התראות באמצעות התראות דחיפה או אימייל, לבין הצטרפות לפגישה בלי לתת גישה למצלמה ולמיקרופון, המשתמשים מבינים בצורה טבעית יותר את הפשרות שהם עושים.
אל תגיעו למצב חסום, קשה מאוד להתאושש ממנו
אחרי שמשתמש מחליט לא לאפשר גישה לתכונת גישה שמוגדרת באמצעות הרשאה באופן סופי, הדפדפנים מכבדים את ההחלטה הזו. אם אפשר היה להמשיך לבקש גישה, אתרים זדוניים היו ממשיכים להציג למשתמשים בקשות גישה. לכן, התאוששות ממצב חסום של יכולת דורשת מהמשתמש קצת מאמץ. לכן, מומלץ להימנע מבקשת הרשאה ממשתמשים במצבים שבהם סביר להניח שמשתמשים רבים לא יאשרו גישה.
דרך נפוצה לעשות זאת היא להשתמש בהודעה מקדימה, שבה מסבירים למשתמשים מה עומד לקרות ולמה לאפליקציה נדרשת היכולת שאתם עומדים לבקש. רק אם המשתמשים מגיבים בחיוב להודעה המקדימה הזו, צריך להפעיל את בקשת ההרשאה מהדפדפן. יש מצבים שבהם המשתמשים עשויים להזדקק לשחזור מאותו מצב. מידע נוסף זמין בקטע עזרה למשתמשים להתאושש ממצב חסום.
חשוב לשים לב לתוכן של צד שלישי
יש מקור לא צפוי של בקשות הרשאה שחשוב לדעת עליו. אם תכללו באתר סקריפטים של צד שלישי, הם עשויים להפעיל בקשות לקבלת הרשאות שלא התכוונתם להציג. הדבר עלול להשפיע על חוויית השימוש של המשתמשים באתר, במיוחד אם ההנחיות לא עומדות בשיטות המומלצות שכבר פירטנו. כדי לשמור על השליטה בחוויית המשתמש, כדאי לקרוא בעיון את המסמכים של כל הספריות והסקריפטים של צד שלישי שאתם מוסיפים לקוד שלכם.
מתי צריך לבקש הרשאה
הנה כמה דוגמאות לרגעים שבהם כדאי לבקש רשות, בהתאם לשיטות המומלצות שכבר תיארו:
- אחרי שמשתמש לוחץ על הלחצן 'שימוש במיקום שלי' לצד שדה טופס להזנת כתובת באופן ידני.
- אחרי שמשתמש נרשם לערוץ וידאו או לפוסטים, ולוחץ על לחצן אישור בתיבת דו-שיח שמציינת שהעדכונים יכולים להישלח באימיילים או בהתראות לטלפון או למחשב.
- אחרי שהמשתמש מגיע לדף שמכין אותו להצטרפות לשיחת וידאו, הוא עונה בחיוב על ההנחיה מראש שהוא רוצה להיראות ולהישמע (ראו מחקר מקרה זה מ-Google Meet).
דפוסי קוד לבקשת הרשאה
יש כמה דרכים לקבל הרשאה לשימוש ב-API, בהתאם ל-API. בחלק מממשקי ה-API (בדרך כלל בממשקים ישנים יותר) נעשה שימוש במודל שבו הדפדפן מבקש הרשאה באופן אוטומטי בפעם הראשונה שמנסים להשתמש ב-API. דוגמה לכך היא Geolocation API בקריאה ל-navigator.geolocation.getCurrentPosition()
.
try {
navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
console.error(error);
}
בממשקי API אחרים נעשה שימוש במודל שבו צריך לבקש הרשאה באופן מפורש באמצעות שיטה סטטית. דוגמה טובה היא Notification.requestPermission()
, שמאפשרת לקבל התראות, או DeviceOrientationEvent.requestPermission()
, שהוא פחות נפוץ וחלק מ-Device Orientation Events API. לתשומת ליבכם: יכול להיות שדפדפנים מסוימים יעניקו הרשאה באופן אוטומטי לממשקי API מסוימים. לדוגמה, ב-Chrome תמיד יש גישה לכיוון המכשיר, ואילו ב-Safari מוצגת בקשה.
const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
/* Use the API. */
}
איך בודקים את מצב ההרשאות
כדי לבדוק אם אפשר להשתמש ב-API מסוים, משתמשים ב-method navigator.permissions.query()
מ-Permissions API.
const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
// Use the API.
}
איך עוזרים למשתמשים להתאושש ממצב חסום
כדי לעזור למשתמשים לפתור בעיות גישה, אפשר לזהות שהם חסמו את הגישה באמצעות Permissions API ולהציע להם מדריך לשינוי ההגדרות. לדוגמה, כשמשתמשים מקיימים אינטראקציה עם רכיבי ממשק משתמש שמשויכים ליכולת שמוגנת באמצעות הרשאות, אפשר להשתמש בדפוס שמתואר בקטע הקודם ולפתוח תיבת דו-שיח לפתרון בעיות. השלבים המדויקים לשינוי מצב ההרשאה משתנים בהתאם לדפדפן, לכן מומלץ להציע תיאורים תואמים על סמך המחרוזת של סוכן המשתמש ולדפדפנים הנפוצים ביותר במוצר.
ב-Chrome, המשתמשים צריכים לעבור אל אמצעי הבקרה לאתרים בלחיצה על סמל ה'כוונון' בצד ימין של סרגל הכתובות. כאן הם יכולים להפעיל את ההרשאה המתאימה. במקרים מסוימים, יכול להיות שהם יצטרכו לטעון מחדש את הדף לפני שישתמשו ביכולת הזו. במקרה כזה, תופיע סרגל הודעות בחלק העליון של החלון עם הצעה לטעון מחדש בלחיצה על הלחצן המתאים.
ממשקי משתמש דומים לצורך בקרה על ההרשאות קיימים בדפדפנים אחרים (לדוגמה, כך זה עובד ב-Firefox).