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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המזהה המומלץ לשימוש: מזהה המינוי API כדי לזהות כרטיסי SIM שנעשה בהם שימוש במכשיר.

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

למה ההמלצה הזו מוצגת?

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

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

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

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

למה ההמלצה הזו מוצגת?

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

מודעות

מיקוד

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

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

למה ההמלצה הזו מוצגת?

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

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

מדידה

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

המזהה המומלץ לשימוש: מזהה פרסום או ממשקי API של מפנה התקנה ב-Play

למה ההמלצה הזו מוצגת?

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

המרות

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

המזהה המומלץ לשימוש: מזהה פרסום או ממשקי API של מפנה התקנה ב-Play

למה ההמלצה הזו מוצגת?

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

רימרקטינג

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

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

למה ההמלצה הזו מוצגת?

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

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

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

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

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

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

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

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

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

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

למה ההמלצה הזו מוצגת?

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

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

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

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

למה ההמלצה הזו מוצגת?

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

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

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

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

למה ההמלצה הזו מוצגת?

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

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

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

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

למה ההמלצה הזו מוצגת?

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

אבטחה

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

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

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

למה ההמלצה הזו מוצגת?

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

מודעת תרמית

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

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

למה ההמלצה הזו מוצגת?

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

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

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

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

העדפות משתמש

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

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

למה ההמלצה הזו מוצגת?

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