שיטות מומלצות לשימוש במזהים ייחודיים

במאמר הזה מוסבר איך לבחור את המזהים המתאימים לאפליקציה בהתאם לתרחיש לדוגמה.

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

שיטות מומלצות לעבודה עם מזהים של Android

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

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

2. אל תשתמשו במזהי חומרה. ברוב המקרים, אפשר להימנע משימוש במזהי חומרה, כמו International Mobile Equipment Identity ‏(IMEI), בלי להגביל את הפונקציונליות הנדרשת.

   ב-Android 10 (רמת API‏ 29) נוספו הגבלות על מזהים שלא ניתנים לאיפוס, כולל IMEI ומספר סידורי. כדי לגשת למזהים האלה, האפליקציה צריכה להיות אפליקציה של בעלי המכשיר או הפרופיל, להיות בעלת הרשאות מיוחדות של ספק או להיות בעלת ההרשאה המיוחדת READ_PRIVILEGED_PHONE_STATE.

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

4. אל תגשרו על איפוסים של מזהה הפרסום.

5. בכל תרחישי השימוש האחרים, למעט מניעת שימוש לרעה באמצעי תשלום וטלפוניה, כדאי להשתמש במזהה התקנה של Firebase‏ (FID) או במזהה ייחודי גלובלי (GUID) שמאוחסן באופן פרטי. ברוב המקרים שבהם לא משתמשים במודעות, מספיק להשתמש ב-FID או ב-GUID.

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

בקטעים הבאים במדריך הזה נרחיב על הכללים האלה בהקשר של פיתוח אפליקציות ל-Android.

עבודה עם מזהי פרסום

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

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

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

תמיד צריך לפעול בהתאם לסימון של המודעות בהתאמה אישית. מזהי פרסום ניתנים להגדרה, כך שהמשתמשים יכולים להגביל את כמות המעקב שמשויכת למזהה. תמיד צריך להשתמש ב-AdvertisingIdClient.Info.isLimitAdTrackingEnabled() כדי לוודא שאתם לא עוקפים את ההעדפות של המשתמשים. במדיניות התוכן למפתחים של Google Play מצוין:

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

חשוב לשים לב לכללי מדיניות בנושא פרטיות או אבטחה שקשורים לערכות SDK שאתם משתמשים בהן, ונוגעים לשימוש במזהה הפרסום. לדוגמה, אם מעבירים את הערך true ל-method‏ enableAdvertisingIdCollection() מ-Google Analytics SDK, צריך לוודא שקוראים את כל כללי המדיניות הרלוונטיים של Analytics SDK ופועלים לפיהם.

כמו כן, חשוב לזכור שמדיניות התוכן למפתחים של Google Play דורשת ש"מזהה הפרסום לא יהיה מקושר לפרטים אישיים מזהים או משויך למזהה קבוע למכשיר (לדוגמה: SSAID, כתובת MAC,‏ IMEI וכו')".

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

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

חשוב לזכור שהקישורים בין מזהה המפרסם לבין פרטים אישיים מזהים לא תמיד כל כך ברורים. יכולים להיות "מזהים לכאורה" שמופיעים גם בטבלאות עם מפתח של פרטים אישיים מזהים וגם בטבלאות עם מפתח של מזהה מודעה, וגם הם גורמים לבעיות. לדוגמה, נניח שאנחנו משנים את TABLE-01 ואת TABLE-02 באופן הבא:

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

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

פתרונות נוספים:

• לא ליצור טבלאות שמקשרות באופן מפורש בין פרטים אישיים מזהים לבין מזהי פרסום. בדוגמה הראשונה, המשמעות היא שלא צריך לכלול את העמודה account_id ב-TABLE-01.

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

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

מידע נוסף על עבודה אחראית עם מזהי פרסום זמין במאמרי העזרה של ה-API של AdvertisingIdClient.

עבודה עם מזהי FID ומזהי GUID

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

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

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

var uniqueID = UUID.randomUUID().toString()

String uniqueID = UUID.randomUUID().toString();

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

לא פועלים עם כתובות MAC

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

שינויים בזמינות של כתובת MAC ב-Android 11

באפליקציות שמטרגטות ל-Android מגרסה 11 ואילך, הקצאת כתובות MAC אקראיות לרשתות Passpoint מתבצעת לכל פרופיל Passpoint, ונוצרת כתובת MAC ייחודית על סמך השדות הבאים:

• שם דומיין שמוגדר במלואו (FQDN)
• Realm
• פרטי כניסה, בהתאם לפרטי הכניסה שמשמשים בפרופיל Passpoint:
  • פרטי הכניסה של המשתמש: שם משתמש
  • פרטי כניסה של אישור: אישור וסוג אישור
  • פרטי כניסה של כרטיס SIM: סוג EAP ו-IMSI

בנוסף, אפליקציות ללא הרשאות לא יכולות לגשת לכתובת ה-MAC של המכשיר, ורק ממשקי רשת עם כתובת IP גלויים. השינוי הזה משפיע על השיטות getifaddrs() ו-NetworkInterface.getHardwareAddress(), וגם על שליחת הודעות Netlink מסוג RTM_GETLINK.

השינוי הזה משפיע על האפליקציות בדרכים הבאות:

• ‫NetworkInterface.getHardwareAddress() מחזיר ערך null לכל ממשק.
• אפליקציות לא יכולות להשתמש בפונקציה bind() בשקעי NETLINK_ROUTE.
• הפקודה ip לא מחזירה מידע על ממשקים.
• אפליקציות לא יכולות לשלוח הודעות RTM_GETLINK.

חשוב לדעת שרוב המפתחים צריכים להשתמש בממשקי ה-API ברמה גבוהה יותר של ConnectivityManager, ולא בממשקי API ברמה נמוכה יותר כמו NetworkInterface,‏ getifaddrs() או שקעי Netlink. לדוגמה, אפליקציה שצריכה מידע עדכני על המסלולים הנוכחיים יכולה לקבל את המידע הזה על ידי האזנה לשינויים ברשת באמצעות ConnectivityManager.registerNetworkCallback() וקריאה ל-LinkProperties.getRoutes() שמשויך לרשת.

מאפייני המזהה

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

היקף

היקף המזהה מסביר לאילו מערכות יש גישה למזהה. היקף המזהה ב-Android בדרך כלל מגיע בשלוש גרסאות:

• אפליקציה אחת: המזהה הוא פנימי לאפליקציה ולאפליקציות אחרות אין גישה אליו.
• קבוצת אפליקציות: המזהה נגיש לקבוצה מוגדרת מראש של אפליקציות קשורות.
• מכשיר: המזהה נגיש לכל האפליקציות שמותקנות במכשיר.

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

ניתן לאיפוס וקבוע

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

• סשן בלבד: מזהה חדש נוצר בכל פעם שהמשתמש מפעיל מחדש את האפליקציה.
• איפוס בהתקנה: מזהה חדש משמש בכל פעם שהמשתמש מסיר את האפליקציה ומתקין אותה מחדש.
• איפוס לנתוני היצרן (FDR): מזהה חדש נוצר בכל פעם שהמשתמש מאפס את המכשיר להגדרות המקוריות.
• FDR-persistent: המזהה נשמר גם אחרי איפוס להגדרות המקוריות.

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

ייחודיות

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

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

הגנה על תקינות האפליקציה ומניעת הכחשה

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

תרחישים נפוצים לדוגמה והמזהה המתאים לשימוש

בקטע הזה מפורטות חלופות לשימוש במזהי חומרה, כמו IMEI. לא מומלץ להשתמש במזהי חומרה כי המשתמש לא יכול לאפס אותם, והם מוגבלים למכשיר. במקרים רבים, מזהה ברמת האפליקציה מספיק.

חשבונות

סטטוס חברת התובלה

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

המזהה המומלץ לשימוש: IMEI,‏ IMSI ו-Line1

למה דווקא ההמלצה הזו?

מותר להשתמש במזהי חומרה אם הם נדרשים לפונקציונליות שקשורה לספק. לדוגמה, אפשר להשתמש במזהים האלה כדי לעבור בין ספקי סלולר או חריצים לכרטיסי SIM, או כדי לשלוח הודעות SMS דרך IP (ל-Line1) – חשבונות משתמשים שמבוססים על כרטיס SIM. עם זאת, באפליקציות ללא הרשאות, מומלץ להשתמש בכניסה לחשבון כדי לאחזר את פרטי המכשיר של המשתמש בצד השרת. אחת מהסיבות לכך היא שב-Android 6.0 (רמת API‏ 23) ומעלה, אפשר להשתמש במזהים האלה רק עם הרשאה בתחילת ההפעלה. המשתמשים יכולים להשבית את ההרשאה הזו, ולכן האפליקציה צריכה לטפל במקרים החריגים האלה בצורה חלקה.

סטטוס המינוי בנייד

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

המזהה המומלץ לשימוש: Subscription ID API לזיהוי כרטיסי SIM שמשמשים במכשיר.

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

למה דווקא ההמלצה הזו?

יכול להיות שאפליקציות מסוימות משתמשות כרגע ב-ICC ID למטרה הזו. מכיוון שמזהה ה-ICC הוא ייחודי ברמה הגלובלית ואי אפשר לאפס אותו, הגישה הוגבלה לאפליקציות עם ההרשאה READ_PRIVILEGED_PHONE_STATE החל מ-Android 10. החל מ-Android 11, הגישה ל-ICCID הוגבלה עוד יותר באמצעות ה-API של getIccId(), בלי קשר לרמת ה-API המטורגטת של האפליקציה. באפליקציות שמושפעות מהשינוי, צריך לעבור להשתמש במזהה המינוי.

כניסה יחידה (SSO)

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

המזהה המומלץ לשימוש: חשבונות שתואמים למנהל החשבונות, כמו קישור של חשבון Google

למה דווקא ההמלצה הזו?

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

מודעות

טירגוט

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

המזהה המומלץ לשימוש: אם האפליקציה שלכם משתמשת במזהה למודעות ומועלית או מתפרסמת ב-Google Play, המזהה הזה חייב להיות מזהה הפרסום.

למה דווקא ההמלצה הזו?

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

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

מדידה

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

המזהה המומלץ לשימוש: מזהה פרסום או ממשקי Play Install Referrer API

למה דווקא ההמלצה הזו?

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

המרות

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

המזהה המומלץ לשימוש: מזהה פרסום או ממשקי Play Install Referrer API

למה דווקא ההמלצה הזו?

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

רימרקטינג

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

המזהה המומלץ לשימוש: מזהה פרסום

למה דווקא ההמלצה הזו?

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

ניתוח של נתוני אפליקציות

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

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

פתרונות אפשריים:

• מזהה קבוצת אפליקציות: מזהה קבוצת אפליקציות מאפשר לנתח את ההתנהגות של המשתמשים בכמה אפליקציות שבבעלות הארגון, כל עוד לא משתמשים בנתוני המשתמשים למטרות פרסום. אם אתם מטרגטים מכשירים שפועלים באמצעות Google Play Services, מומלץ להשתמש במזהה קבוצת האפליקציות.
• ‫Firebase ID (FID): מזהה FID מוגדר לאפליקציה שיוצרת אותו, וכך המזהה לא יכול לשמש למעקב אחרי משתמשים באפליקציות שונות. המשתמש יכול גם לאפס אותו על ידי ניקוי נתוני האפליקציה או התקנה מחדש של האפליקציה. תהליך היצירה של FID הוא פשוט. אפשר לעיין במדריך להתקנות של Firebase.

פיתוח אפליקציות

דיווחים על קריסה

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

המזהה המומלץ לשימוש: FID או מזהה קבוצת אפליקציות

למה דווקא ההמלצה הזו?

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

דוחות ביצועים

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

המזהה המומלץ לשימוש: מעקב אחר ביצועים ב-Firebase

למה דווקא ההמלצה הזו?

הכלי "מעקב אחר ביצועים ב-Firebase" עוזר לכם להתמקד במדדים שהכי חשובים לכם, ולבדוק את ההשפעה של שינוי שביצעתם לאחרונה באפליקציה.

בדיקת אפליקציות

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

המזהה המומלץ לשימוש: FID או מזהה קבוצת אפליקציות

למה דווקא ההמלצה הזו?

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

התקנה במכשירים שונים

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

המזהה המומלץ לשימוש: FID או GUID

למה דווקא ההמלצה הזו?

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

אבטחה

זיהוי התנהלות פוגעת

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

המזהה המומלץ לשימוש: טוקן התקינות של Google Play Integrity API

למה דווקא ההמלצה הזו?

כדי לוודא שבקשה מגיעה ממכשיר Android מקורי, ולא מאמולטור או מקוד אחר שמזייף מכשיר אחר, משתמשים ב-Google Play Integrity API.

מודעת תרמית

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

המזהה המומלץ לשימוש: מזהה פרסום

למה דווקא ההמלצה הזו?

בהתאם למדיניות התוכן למפתחים ב-Google Play, חובה להשתמש במזהה הפרסום בתרחישי שימוש של פרסום, כי המשתמש יכול לאפס אותו.

ניהול זכויות דיגיטלי (DRM)

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

המזהה המומלץ לשימוש: שימוש ב-FID או ב-GUID מאלץ את המשתמש להתקין מחדש את האפליקציה כדי לעקוף את מגבלות התוכן, וזה מספיק כדי להרתיע את רוב האנשים. אם ההגנה הזו לא מספיקה, Android מספקת DRM API, שניתן להשתמש בו כדי להגביל את הגישה לתוכן, וכולל מזהה לכל APK, מזהה Widevine.

העדפות משתמש

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

המזהה המומלץ לשימוש: FID או GUID

למה דווקא ההמלצה הזו?

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