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

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

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

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

החזון

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

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

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

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

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

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

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

עקרונות התכנון והעיצוב

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דוגמה טובה ומעשית היא אימון מודלים והסקת מסקנות. בדיונים הבאים מניחים ש (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.

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

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

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

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

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

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

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

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

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

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

הישות שכתבה את 'אפליקציית Adopter' לא יכולה להיות זהה לישות שמחזיקה ב-'Adopter App' בתרשים. הישות שיצרה את ה-APK של Adopter זהה לישות שבבעלותה "חנות מקומית של Adopter" בתרשים.

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

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

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

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

• תהליכי עבודה מקומיים שמופעלים אופליין באמצעות תקשורת עם סביבת ביצוע מהימנה (TEE):
  • תהליכי הורדת נתונים: הורדות מהימנות
  • תהליכי העלאת נתונים: עסקאות מהימנות
• תהליכי עבודה אונליין שמופעלים באופן מקומי:
  • תהליכי הצגת מודעות בזמן אמת
  • תהליכי הסקת מסקנות
• תהליכי עבודה מקומיים שמופעלים במצב אופליין:
  • תהליכי אופטימיזציה: אימון מודלים במכשיר הוטמע באמצעות למידה משותפת (Federated) (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

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

פלטפורמות של Layered API

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

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

סיכום

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

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