בקשות להרשאות הן המנגנון העיקרי באינטרנט להגנה על יכולות מתקדמות שעלולות לסכן את הפרטיות והאבטחה של המשתמשים. המטרה של הדפדפנים היא לוודא שהמשתמש מתכוון לאפשר לאתר שמגיש את הבקשה לגשת ליכולת הרלוונטית. בקשות להרשאות משמשות לכמה ממשקי API, כולל תיעוד מדיה (מצלמה ומיקרופון), מיקום גיאוגרפי, גישה לאחסון, MIDI והתראות (מידע נוסף זמין במאמרי העזרה של Permissions API ב-MDN).
במדריך הזה מפורטות השיטות המומלצות להצגת בקשות להרשאות למשתמשים על סמך נתוני שימוש ומחקר משתמשים ב-Chrome. אם תפעלו לפי השיטות המומלצות האלו, המשתמשים צריכים להיתקל בפחות בקשות מיותרות, דבר שיוביל לכך שהמפתחים יקבלו פחות החלטות בנושא 'חסימה'. המאמר מסתיים בכמה דפוסי קוד לעבודה עם ממשקי API מוגבלים בהרשאות, ובשיטות מומלצות לעזרה למשתמשים להתאושש ממצב חסום.
שיטות מומלצות ליצירת הנחיות
צריך לבקש הרשאה אחרי אינטראקציה עם משתמש, ברגע שבו המשתמשים יכולים להבין למה אתם מבקשים ואיזה יתרונות הם יקבלו אם תאפשרו זאת. כשאפשר, כדאי לאפשר למשתמשים להשתמש באמצעים חלופיים כדי לבצע את אותה פונקציונליות. באופן כללי, בקשת הרשאה בתדירות נמוכה יותר על ידי בחירת הרגעים שבהם מבקשים בקפידה מפחיתה את הסיכויים שהמשתמשים שלכם יגיעו למצב חסום שקשה להתאושש ממנו. השיטות המומלצות הבאות מספקות פרטים נוספים לגבי כל אחת מההצעות.
אף פעם אל תשאלו בטעינת דף או ללא אינטראקציה של המשתמש
כשמבקשים מהמשתמשים הרשאה לטעינת דף, הדבר מקביל לבקשת לקוח לקבל מידע רגיש כשהוא נכנס לחנות פיזית. קשה מאוד לראות את בקשת ההרשאה (כנראה בין כמה הנחיות אחרות להרשמה לניוזלטר ולהסכמה לשימוש בקובצי cookie). המשתמשים לא יבינו למה שואלים אותם ואיך הם יועילו להם.
גם אם אפליקציית האינטרנט לא יכולה לפעול ללא גישה ליכולת מסוימת, צריך לתת למשתמשים אפשרות להבין למה הם צריכים אותה. לדוגמה, על ידי הצגת הבקשה להרשאה עם הנחיה משלכם שמסבירה את הצורך ונותנה למשתמשים אפשרות בחירה (לדוגמה, כשהדבר אפשרי, על ידי מתן אמצעים חלופיים לביצוע את אותה פונקציונליות). בכל מקרה שבו לא חשבתם על רגע טוב יותר לבקשת הרשאה מאשר טעינת הדף, יש כמה דוגמאות בהמשך המדריך.
מצב בעייתי דומה לבקש הרשאה הוא ללא אינטראקציה קודמת של המשתמש (שנקראת גם הפעלה זמנית של משתמש). לפי נתוני הטלמטריה של Chrome, 77% מהבקשות להרשאות ב-Chrome למחשב מוצגות ללא סימן כל כך בסיסי לכוונת המשתמש, וכתוצאה מכך, רק 12% מההנחיות כאלה מותרות. אחרי אינטראקציה של משתמש, שיעורי ההרשאה יעלו ל-30%. לכן, צריך לבקש הרשאה רק אחרי שהמשתמש קיים אינטראקציה עם הדף בצורה כלשהי.
לשאול רק כשמשתמשים יכולים להבין למה את שואלת
החלטות לגבי הרשאות הן לעיתים קרובות החלטות בנוגע לפרטיות. על סמך המסגרת של תקינות לפי הקשר, אנחנו יודעים שההחלטות בנושא פרטיות מבוססות על ההקשר. אפשר להבין למה נדרשת גישה כהיבט מרכזי בנושא. לכן חשוב לבקש רק יכולות שאתם צריכים כדי לספק למשתמשים ערך (וכשיש סבירות גבוהה שהמשתמשים יסכימו איתכם שהם אכן יקבלו ערך). בנוסף, עליכם לבקש הרשאה ברגע שבו ברור למשתמש למה היכולת הזו מועילה. המטרה היא לעזור למשתמשים להבין את הקשר השימוש בקלות ככל האפשר.
המחקר שלנו על התנהגות משתמשים הראה שיש סיכוי גבוה באופן משמעותי שמשתמשים יאשרו גישה כשהם יבינו למה אתר מבקש גישה וגם תופסים יתרונות. גילינו גם שמשתמשים מצפים לגלוש קודם באתרים לא מוכרים כדי להבין טוב יותר את הערך שהם יכולים לקבל בתמורה למתן גישה. בינתיים, הם בדרך כלל יסגרו בקשות להרשאות או יתעלמו מהן. בהרשאות חד-פעמיות הן יכולות לאפשר ביקור אחד תחילה. האפליקציה שלכם צריכה לתמוך בהתנהגויות האלה.
ספקו אמצעים חלופיים לביצוע אותה פונקציונליות, במידת האפשר
יכול להיות שהתוצאה של חלק מהיכולות לא תועיל למשתמשים. לדוגמה, מיקום גיאוגרפי של מחשב בלי חיישן GPS עשוי להחזיר את המיקום הלא נכון כי הוא מחובר ל-VPN. יכול להיות שמשתמשים אחרים לא ירצו לתת גישה ללוח העריכה כי הם מעדיפים להישאר בשליטה ולהפעיל את האירועים האלה באמצעות שילובי מקשים באופן ידני. במצבים כאלה, חשוב לספק אמצעים חלופיים להשגת אותן התוצאות. לדוגמה, אם מבקשים הרשאה למיקום גיאוגרפי, צריך להציע שדה טקסט שבו המשתמשים יוכלו להזין מיקוד או כתובת בעצמם. באמצעות הלוח, ודאו שאפשר לבחור ולהעתיק את הרכיבים שרוצים להעתיק באמצעות שילוב מקשים או תפריט ההקשר. התראות מאפשרות לאנשים לקבל הודעות באימייל במקום התראות.
אחת השיטות המומלצות היא להשתמש בממשק המשתמש החלופי גם כהסבר על היתרונות של הגישה. משתמשים שרואים את האפשרות להזין מיקום ליד לחצן שמפעיל את ה-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 אחרים משתמשים במודל שבו צריך לבקש הרשאה באופן מפורש באמצעות method סטטית. דוגמה טובה לכך היא Notification.requestPermission() מתן אפשרות להתראות, או DeviceOrientationEvent.requestPermission() פחות נפוץ, שהוא חלק מ-Device Orientation Event 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, המשתמשים צריכים לעבור אל Site Controls באמצעות לחיצה על סמל הכוונון בצד ימין של סרגל הכתובות. כאן הם יכולים להפעיל את ההרשאה המתאימה. במקרים מסוימים, יכול להיות שהם יצטרכו לטעון מחדש את הדף כדי להשתמש ביכולות. במקרה כזה, יוצג סרגל הודעות בחלק העליון של החלון שמציע להיטען מחדש כשלוחצים על הלחצן המתאים.
בדפדפנים אחרים קיימים ממשקי משתמש דומים לשליטה בהרשאות (לדוגמה, איך זה עובד ב-Firefox).