הגנה על פרטיות המשתמשים

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

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

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

הקטנת ההרשאות הנדרשות

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

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

activeTab

במקרים רבים, תוספים שמשתמשים בהרשאות מארח כדי להחדיר סקריפטים יכולים להשתמש במקום זאת ב-activeTab. ההרשאה activeTab תעניק לתוסף גישה זמנית לכרטיסייה הפעילה הנוכחית, רק כשהמשתמש יפעיל את התוסף. הגישה נחסמת כשהמשתמש יוצא מהכרטיסייה הנוכחית או סוגר אותה. הוא משמש כחלופה להרבה שימושים ב-<all_urls>.

{
  "name": "Very Secure Extension",
  "version": "1.0",
  "description": "Example of a Secure Extension",
  "permissions": ["activeTab"],
  "manifest_version": 3
}

ההרשאה activeTab לא מציגה הודעות אזהרה במהלך ההתקנה.

בחירה בהרשאות אופציונליות

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

{
  "name": "Very Secure Extension",
  ...
  "optional_permissions": [ "tabs", ],
  "optional_host_permissions": ["https://www.google.com/" ],
  ...
}

הכללת הרשאות אופציונליות מאפשרת לתוסף להסביר למה הוא צריך הרשאה מסוימת כשהמשתמש מפעיל את התכונה הרלוונטית. התוסף יכול להציע למשתמש אפשרות להפעיל תכונות.

לחיצה על אישור תפעיל את האירוע הבא ב-service worker.

chrome.action.onClicked.addListener((event) => {
  // Permissions must be requested from inside a user gesture, like a button's
  // click handler.
  chrome.permissions.request(
    {
      permissions: ["tabs", "scripting"],
      origins: ['https://www.google.com/']
    },
    function (granted) {
      // The callback argument will be true if the user granted the permissions.
      if (granted) {
        // doSomething();
      } else {
        // doSomethingElse();
      }
    }
  );
});

לאחר מכן, המשתמש יקבל את הבקשה הבאה.

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

הגבלת הגישה לפרטי המשתמשים והגנה עליהם

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

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

שמירת נתונים ומצב פרטי

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

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

כדי לזהות אם חלון נמצא במצב אנונימי, בודקים את המאפיין incognito של האובייקט הרלוונטי tabs.Tab או windows.Window.

function saveTabData(tab) {
  if (tab.incognito) {
    return;
  } else {
    chrome.storage.local.set({data: tab.url});
  }
}