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

Marian Harbach

Thomas Steiner

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

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

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

שיטות מומלצות לכתיבת הנחיות

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

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

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

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

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

גם בקשת הרשאה ללא אינטראקציה מוקדמת עם המשתמש לא תהיה יעילה. התופעה הזו נקראת הפעלה זמנית של משתמשים. נתוני הטלמטריה של Chrome מראים ש-77% מההודעות לבקשת הרשאה במחשב מוצגות ללא אות של כוונת המשתמש, ולכן רק 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 אחרים משתמשים במודל שבו קודם מבקשים הרשאה באופן מפורש באמצעות שיטה סטטית. דוגמה טובה היא Notification.requestPermission(), שמאפשרת לקבל התראות, או DeviceOrientationEvent.requestPermission(), שפחות נפוצה והיא חלק מה-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.