שיטות מומלצות לשימוש בהרשאות אינטרנט

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

תמיכה בדפדפנים

  • Chrome: 43.
  • קצה: 79.
  • Firefox: 46.
  • Safari: 16.

מקור

איך עוזרים למשתמשים להתאושש ממצב חסום

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

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

אמצעי הבקרה על אתרים בדפדפן Chrome.

הודעה על טעינה מחדש אחרי שינוי ההרשאות באמצעות אמצעי הבקרה על אתרים.

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