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

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

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

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

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

Vision

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

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

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

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

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

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

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

ציר הזמן

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• העיבוד לאחר האירוע מבטיח שאחרי שמעבירים כמות לסטטוס פרטי, אי אפשר לבטל את ההעברה הזו אם לא משתמשים שוב בנתונים המקוריים. כל עוד כל הקלט של הצומת הוא פרטי, הפלט שלו הוא פרטי, ללא קשר לחישוביו.
• בעזרת ה-Advanced Composition אפשר להבטיח שאם כל חלק בתרשים הוא DP, גם התרשים הכולל הוא DP. כך אפשר להגביל את הערכים של ε ו-δ של הפלט הסופי של התרשים בערך ε√κ, בהנחה שהתרשים מכיל κ יחידות ופלט כל יחידה הוא (ε, δ)-DP.

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

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

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

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

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

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

פרטיות מאומתת

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

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

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

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

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

העיצוב הכללי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On-Device Personalization מספק ארכיטקטורת API שכבתית לעסקים שמתעניינים בכך. השכבה העליונה מורכבת מאפליקציות שנוצרו לתרחישי שימוש ספציפיים. עסקים פוטנציאליים יכולים לחבר את הנתונים שלהם לאפליקציות האלה, שנקראות ממשקי API של שכבה עליונה. ממשקי ה-API של השכבה העליונה מבוססים על ממשקי ה-API של השכבה האמצעית.

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

סיכום

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

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