מסדי נתונים מקומיים

המסמך הזה רלוונטי לשיטה הבאה: Update API (v4): threatListUpdates.fetch.

הגדרת מסד הנתונים

לקוחות שמשתמשים ב-Update API נדרשים להגדיר מסד נתונים מקומי ולבצע הורדה ראשונית של רשימות הגלישה הבטוחה שהם רוצים לעבוד איתן. כדי להתחיל, תוכלו ליצור ולפרוס את חבילת safebrowsing Go (או להשתמש בחבילה כדי ליצור מודל להטמעה משלכם). מידע נוסף זמין בכתובת https://github.com/google/safebrowsing/.

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

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

עדכונים מלאים

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

מצב ריק

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

החלטת השרת

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

עדכונים חלקיים

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

הוספות

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

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

שירותי הובלה

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

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

בדיקות אימות

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

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

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