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

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

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

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

Vision

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

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

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

2. מאגרי נתונים מוצפנים מקצה לקצה לצורך:

   1. בקרות משתמשים ונתונים אחרים שקשורים למשתמשים. הפרטים האלה יכולים להיות שסופקו על ידי משתמשי קצה או נאספו על ידי עסקים, יחד עם אמצעי בקרה של אורך החיים (TTL), מחיקת מדיניות, מדיניות פרטיות ועוד.
   2. הגדרות עסקיות. ODP מספק אלגוריתמים כדי לדחוס את הנתונים האלה או לערפל את הקוד (obfuscation) שלהם.
   3. התוצאות בעיבוד העסק. התוצאות האלה יכולות להיות:
      1. נצרכים כקלטים בסיבובי עיבוד מאוחרים יותר,
      2. סינון לפי מנגנוני פרטיות דיפרנציאליים מתאימים, והעלאה לנקודות קצה (endpoint) מתאימות.
      3. הנתונים הועלאו באמצעות תהליך העלאה מהימן לסביבות מחשוב מהימנות (TEE) שמריצות עומסי עבודה בקוד פתוח עם מנגנונים מרכזיים מתאימים של פרטיות דיפרנציאלית
      4. מוצגת למשתמשי קצה.

3. ממשקי API שנועדו:

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

ציר הזמן

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

Feature	מחצית ראשונה של 2025	רבעון 3 2025
אימון במכשיר + הסקת מסקנות	תוכלו לפנות לצוות של ארגז החול לפרטיות כדי לדון באפשרויות אפשריות לתוכנית פיילוט במסגרת הזמן הזו.	מתחילים בהשקה למכשירי Android T+ שעומדים בדרישות.

עקרונות עיצוב

יש שלושה עמודים ש-ODP מנסה לאזן ביניהם: פרטיות, הוגנות ושימושיות.

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

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

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

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

לכן, ההתאמה האישית תהיה ספציפית למכשיר.

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

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

בהקשר הזה, יכול להיות מגדל עסקי ומגדל של משתמש קצה:

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

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

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

מעורבות ציבורית כוללת לפתרונות שוויוניים

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

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

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

כלי למפתחים לשיפור חוויות המשתמש

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

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

מודל הפרטיות: פרטיות באמצעות סודיות

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

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

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

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

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

• פרטיות הקלט. לקשרים יכולים להיות שני סוגים של קלט. אם קלט נוצר על ידי צומת קודם, הוא כבר כולל את ההתחייבויות לפרטיות של הפלט של הצומת הקודם. אחרת, צריך לנקות את כללי המדיניות בנושא תעבורת נתונים נכנסת (ingress) של נתונים באמצעות מנוע המדיניות.
• פרטיות הפלט. יכול להיות שיהיה צורך לתאם את הפלט, למשל, הפתרון שמסופק על ידי פרטיות דיפרנציאלית (DP).
• סודיות סביבת החישוב החישוב צריך להתבצע בסביבה אטומה באופן מאובטח, כדי להבטיח שלאף אחד לא תהיה גישה למצבי ביניים בתוך צומת. הטכנולוגיות שמאפשרות זאת כוללות מחשוב מאוחד (FC), סביבות ביצוע מהימנות מבוססות חומרה (TEE), מחשוב רב-צדדי (sMPC), הצפנה הומומורפית (HPE) ועוד. חשוב לציין ששמירה על פרטיות באמצעות אמצעי הגנה על סודיות במדינות מתווכות, ובכל הפלטים שיוצאים מגבולות הסודיות, עדיין צריכים להיות מוגנים באמצעות מנגנונים של פרטיות דיפרנציאלית. שתי ההצהרות הנדרשות הן:
  • סודיות הסביבות, כדי לוודא שרק תוצאות מוצהרות יוצאות מהסביבה
  • תקינות, שמאפשרת להסיק הצהרות מדויקות על פרטיות הפלט מהצהרות על פרטיות הקלט. התכונה 'סאונד' מאפשרת הפצה של נכסי פרטיות ב-DAG.

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

למודל הזה יש שני יתרונות עיקריים. ראשית, אפשר לייצג את רוב המערכות, גדולות וקטנות, כ-DAG. שנית, עיבוד הנתונים לאחר היצירה (Post-Processing) [קטע 2.1] והתכונות של הרכבת משפט 2.4 במאמר The Complexity of Differential Privacy מאפשרות להשתמש בכלים חזקים כדי לנתח את הפשרה בין הפרטיות לדיוק (במקרה הגרוע ביותר) של גרף שלם:

• העיבוד לאחר האיסוף מבטיח שאחרי שמעבירים כמות מסוימת לסטטוס פרטי, אי אפשר לבטל את ההעברה הזו אם לא נעשה שימוש חוזר בנתונים המקוריים. כל עוד כל הקלט של הצומת הוא פרטי, הפלט שלו הוא פרטי, ללא קשר לחישוביו.
• הרכבה מתקדמת מבטיחה שאם כל חלק בתרשים הוא DP, גם התרשים הכולל תוחם ביעילות את ה-List ו- של הפלט הסופי של התרשים באמצעות כ-ɭPeriod, בהתאמה, בהנחה שבתרשים יש יחידות יותר ממנו והפלט של כל יחידה הוא (טרופו, )-DP.

שני המאפיינים האלה מתרגמים לשני עקרונות תכנון לכל צומת:

• נכס 1 (מלאחר העיבוד) אם הקלט של הצומת הוא כל DP, הפלט שלו הוא DP, שתואם לכל לוגיקה עסקית שרירותית שמופעלת בצומת, ותומכת ב'רטבים סודיים' של עסקים.
• מאפיין 2 (מ-Advanced Composition): אם לא כל הקלטים של צומת מסוים הם DP, הפלט שלו צריך להיות תואם ל-DP. אם צומת מחשוב פועל בסביבות של Trusted Execution Environments ומריץ הגדרות ועומסי עבודה של On-Device Personalization בקוד פתוח, אפשר להגדיר גבולות הדוקים יותר של פרטיות נתונים. אחרת, יכול להיות שהתאמה אישית במכשיר תצטרך להשתמש בגבולות DP ברמת האותיות הגרועות ביותר. עקב מגבלות משאבים, Trusted Execution Environments (סביבות של ביצוע מהימן) שספק ענן ציבורי מציע יקבלו עדיפות בשלב הראשון.

פרטיות בסביבת המחשוב לעומת דיוק הפלט

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

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

בעיקרון, האבטחה של סביבת החישוב והסרת ההזדמנויות של יריבים לגשת לקלטים ולמצבים הביניים של תרשים או תת-תרשים מאפשרת להטמיע DP מרכזי (כלומר, הפלט של סביבה אטומה תואם ל-DP), שיכול לשפר את הדיוק בהשוואה לDP מקומי (כלומר, הקלטים הנפרדים תואמים ל-DP). העיקרון הזה עומד בבסיס ההתחשבות ב-FC, ב-TEE, ב-sMPC וב-HPE כטכנולוגיות פרטיות. פרטים נוספים זמינים בקטע 10 במאמר The Complexity of Differential Privacy.

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

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

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

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

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

פרטי עם אימות

המטרה של התאמה אישית במכשיר היא להיות פרטית שאפשר לאמת אותה. המטרה היא להתמקד באימות מה שקורה מחוץ למכשירים של המשתמשים. ה-ODP יחבר את הקוד שמעבד את הנתונים שיוצאים מהמכשירים של משתמשי הקצה, וישתמש בתהליכי האימות מרחוק של RFC 9334 (RATS) של NIST, כדי לאמת שהקוד הזה פועל ללא שינויים בשרת תואם Confidential Computing Consortium, אם הוגדר לו שרת ללא הרשאות אדמין. הקודים האלה יהיו בקוד פתוח ונגישים לצורך אימות שקוף, כדי לבסס אמון. אמצעים כאלה יכולים לתת לאנשים ביטחון שהנתונים שלהם מוגנים, ולעסקים ליצור מוניטין על סמך יסודות חזקים של הבטחת פרטיות.

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

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

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

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

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

העיצוב הכללי

איך ניתן ליישם פרטיות באמצעות סודיות? ברמה הכללית, מנוע מדיניות שנוצר על ידי ODP שפועל בסביבה אטומה משמש כרכיב הליבה שעוקב אחרי כל צומת או תת-תרשים, בזמן שעוקבים אחרי סטטוס ה-DP של הקלט והפלט שלהם:

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

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

העיצוב הכללי של התכונה 'התאמה אישית במכשיר' משלב ביעילות שני רכיבים חיוניים:

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

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

בקטעים הבאים נרחיב על שני ההיבטים העיקריים האלה.

ארכיטקטורה של תהליך מותאם לביצוע לוגיקה עסקית

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

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

• IsolatedProcess. התהליך הזה מוגדר כמבודד (isolatedprocess=true במניפסט), והוא מקבל מ-ManageProcess נתונים עסקיים, נתונים של משתמשי קצה ללא מדיניות וקוד עסק. הם מאפשרים לקוד העסק לפעול על הנתונים שלו ועל נתונים של משתמשי קצה שלא עומדים בדרישות המדיניות. התהליך IsolatedProcess מתקשר באופן בלעדי עם ManagingProcess גם לצורך תעבורת נתונים נכנסת וגם לצורך תעבורת נתונים יוצאת, ללא הרשאות נוספות.

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

באיור הבא מוצגת ארכיטקטורת התהליך המזווג.

הישות שמשמשת כמחבר של 'אפליקציית המשתמש המאמץ' עשויה להיות או לא להיות אותה ישות שמשמשת כמחבר של 'Adopter apk' בתרשים. הישות שכותבת את 'Adopter apk' היא אותה ישות שבבעלותה 'Adopter Local Store' בתרשים.

כללי מדיניות ומנועי מדיניות לפעולות נתונים

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

בארכיטקטורת תהליכים מותאמים, מנוע המדיניות נמצא ב-ManageProcess ומנהל את תעבורת הנתונים הנכנסת (ingress) והיוצאת (egress) של משתמשי הקצה והנתונים העסקיים של משתמשי הקצה. הוא גם יספק ל-IsolatedProcess פעולות ברשימת ההיתרים. תחומי הכיסוי לדוגמה כוללים בקרות של משתמשי קצה, הגנה על ילדים, מניעת שיתוף נתונים ללא הסכמה ושמירה על פרטיות העסק.

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

• תהליכי עבודה אופליין שהופעלו באופן מקומי עם תקשורת בסביבת מחשוב אמינה (TEE):
  • תהליכי הורדת נתונים: הורדות מהימנות
  • תהליכי העלאת נתונים: עסקאות מהימנות
• תהליכי עבודה אונליין שמופעלים באופן מקומי:
  • תהליכי הצגה בזמן אמת
  • תהליכי הסקת מסקנות
• תהליכי עבודה אופליין שמתחילים באופן מקומי:
  • תהליכי אופטימיזציה: אימון מודל במכשיר באמצעות למידה משותפת (FL)
  • תהליכי דיווח: צבירת נתונים ממכשירים שונים באמצעות Federated Analytics‏ (FA)

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

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

• הורדה: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• הגשה: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• אופטימיזציה: 2 (מספקת תוכנית הדרכה) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
• דיווח: 3 (מספק תוכנית צבירת נתונים) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

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

ממשקי API בשכבות

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

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

סיכום

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

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