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

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

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

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

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

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

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

במקרה כזה, אם אירועי מסוג קליק נדירים מספיק, עדיין אפשר לשלב בין מזהה המפרסם ב-TABLE-01 לבין הפרטים האישיים המזהים (PII) שכלולים ב-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 OS יש כמה מזהים עם מאפייני התנהגות שונים. המזהה שבו כדאי להשתמש תלוי באופן שבו המאפיינים הבאים פועלים בתרחיש לדוגמה שלכם. אבל למאפיינים האלה יש גם השלכות על הפרטיות, ולכן חשוב להבין איך הם משפיעים זה על זה.

היקף

היקף המזהה מסביר לאילו מערכות יש גישה למזהה. היקף המזהה של 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 ‏ (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

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

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