स्थानीय डेटाबेस

यह दस्तावेज़ इस तरीके पर लागू होता है: Update API (v4): threatListUpdates.fetch.

डेटाबेस सेटअप

Update API का इस्तेमाल करने वाले क्लाइंट को एक लोकल डेटाबेस सेट अप करना होगा. साथ ही, उन्हें सुरक्षित ब्राउज़िंग की उन सूचियों को शुरू में डाउनलोड करना होगा जिनके साथ वे काम करना चाहते हैं. इसे इस्तेमाल करने के लिए, safebrowsing Go पैकेज को बनाएं और डिप्लॉय करें. इसके अलावा, अपने हिसाब से लागू करने के लिए पैकेज का इस्तेमाल भी किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/google/safebrowsing/ देखें.

डेटाबेस अपडेट

नए खतरों से सुरक्षा पक्का करने के लिए, क्लाइंट को threatListUpdates.fetch तरीके का इस्तेमाल करके, अपनी लोकल सुरक्षित ब्राउज़िंग सूचियों को नियमित तौर पर अपडेट करने की सलाह दी जाती है. threatListअपडेट.fetch अनुरोध, अपडेट की जाने वाली सूचियों के बारे में बताता है. अगर क्लाइंट की मेमोरी या बैंडविड्थ की सीमाएं हैं, तो वे अपडेट की सीमाओं को सेट करने के लिए, अनुरोध का भी इस्तेमाल कर सकते हैं (अपडेट की पाबंदियां देखें). जैसा कि नीचे बताया गया है, threatListअपडेट.fetch रिस्पॉन्स, हर सूची के लिए या तो पूरा अपडेट देता है या कुछ हद तक अपडेट दिखाता है.

सभी अपडेट

पूरे अपडेट तब दिखाए जाते हैं, जब क्लाइंट threatListअपडेट.fetch अनुरोध में मौजूद state फ़ील्ड को खाली छोड़ देता है या जब सर्वर तय करता है कि पूरे अपडेट की ज़रूरत है. पूरे अपडेट के लिए, सिर्फ़ जोड़ दिए जाते हैं. अपडेट लागू करने और पुष्टि की जांच करने से पहले, क्लाइंट को लोकल डेटाबेस को हटाना होगा.

खाली स्थिति

जब क्लाइंट किसी सूची के लिए शुरुआती अनुरोध भेजता है, तो पूरे अपडेट दिखाए जाते हैं. इस मामले में, अनुरोध में state फ़ील्ड खाली छोड़ दिया जाता है (क्योंकि उपलब्ध कराने के लिए कोई वैल्यू नहीं दी जाती) और रिस्पॉन्स में मौजूद newClientState फ़ील्ड, स्थानीय सूची की शुरुआती स्थिति दिखाता है. पूरे अपडेट तब भी दिखाए जाते हैं, जब क्लाइंट बाद के अनुरोधों पर जान-बूझकर state फ़ील्ड को खाली छोड़ देता है. ऐसा करने से, पूरी तरह से अपडेट होने लगेगा और रिस्पॉन्स के newClientState फ़ील्ड में नई स्थिति दिखेगी.

सर्वर से लिया गया फ़ैसला

कभी-कभी, क्लाइंट की ओर से सिर्फ़ कुछ ही अपडेट का अनुरोध किए जाने पर, सुरक्षित ब्राउज़िंग सर्वर पूरा अपडेट देता है. ऐसा तब हो सकता है, जब क्लाइंट शुरुआत में सूची का एक छोटा वर्शन डाउनलोड करता है और फिर सूची के किसी बड़े वर्शन पर अपडेट करता है. सर्वर, बस पूरी सूची के साथ पूरा अपडेट दिखाएगा. ऐसा तब भी हो सकता है, जब क्लाइंट ने लंबे समय से डेटा डाउनलोड न किया हो और उसके लिए कुछ हद तक अपडेट का अनुरोध किया हो. फिर से, सर्वर पूरी सूची के साथ पूरा अपडेट दिखाएगा.

कुछ अपडेट

कुछ हद तक अपडेट तब दिखाए जाते हैं, जब क्लाइंट threatListअपडेट.fetch अनुरोध में, state फ़ील्ड के लिए वैल्यू देता है. इसका अपवाद तब है, जब सर्वर के लिए यह तय करना ज़रूरी हो कि पूरी तरह अपडेट करना ज़रूरी है. जैसा कि ऊपर बताया गया है. आंशिक अपडेट के लिए, जोड़ और हटाना, दोनों दिए जाते हैं. क्लाइंट, लोकल डेटाबेस में सूचियों को अपडेट करता है (जोड़े जाने से पहले, हटाए गए पेजों को लागू करता है) और फिर पुष्टि की जांच करता है.

अनुवृद्धियां

जोड़े गए SHA256 हैश प्रीफ़िक्स हैं, जिन्हें लोकल डेटाबेस में जोड़ा जाना चाहिए. ज़्यादातर हैश प्रीफ़िक्स 4 बाइट के होते हैं. हालांकि, कुछ हैश प्रीफ़िक्स की लंबाई 4 से 32 बाइट के बीच हो सकती है. इसलिए, जोड़ के कई सेट दिखाए जा सकते हैं; उदाहरण के लिए, एक में 4-बाइट प्रीफ़िक्स है और दूसरा, जिसमें 5-बाइट प्रीफ़िक्स है.

अगर क्लाइंट कंप्रेस करने की सुविधा का इस्तेमाल करता है, तो रिस्पॉन्स को चावल के आकार में कंप्रेस करने का इस्तेमाल करके कंप्रेस किया जा सकता है. हालांकि, सिर्फ़ 4-बाइट हैश प्रीफ़िक्स ही कंप्रेस किए जाते हैं. लंबे हैश प्रीफ़िक्स हमेशा बिना कंप्रेस किए गए और रॉ फ़ॉर्मैट में भेजे जाते हैं (कंप्रेशन देखें).

हटाने की प्रक्रिया

शब्द हटाने की प्रक्रिया, शून्य पर आधारित ऐसे क्लाइंट डेटाबेस में मौजूद होती है जिसे शब्द ज्ञान के हिसाब से क्रम में लगाए गए क्लाइंट डेटाबेस में मौजूद उन एंट्री की तरफ़ इशारा किया जाता है जिन्हें स्थानीय डेटाबेस से हटाया जाना चाहिए. हटाए गए सिर्फ़ एक सेट को वापस लाया जाएगा.

अगर क्लाइंट, कंप्रेस करने की सुविधा का इस्तेमाल करता है, तो "राइस हैश" और "राइस इंडेक्स" दिखाए जाते हैं. अगर कंप्रेस करने की सुविधा काम नहीं करती है, तो "रॉ हैश" और "रॉ इंडेक्स" दिखाए जाते हैं (कंप्रेशन देखें).

सत्यापन जांच

अगर threatListअपडेट.fetch रिस्पॉन्स, पूरे अपडेट या कुछ हिस्से के अपडेट के साथ दिया जाता है, तो क्लाइंट को पुष्टि की जांच करनी चाहिए.

क्लाइंट, लोकल डेटाबेस में सूचियों को सबसे पहले अपडेट करता है (जोड़े जाने से पहले, हटाए गए पेजों को लागू करता है). इसके बाद, क्लाइंट लोकल सूची के SHA256 हैश का कंप्यूट करता है और उसकी तुलना रिस्पॉन्स में मिले चेकसम से करता है. अगर दोनों वैल्यू बराबर होती हैं, तो सुरक्षित ब्राउज़िंग की सूची को "सही" माना जाता है.

अगर दोनों वैल्यू बराबर नहीं हैं, तो सुरक्षित ब्राउज़िंग की सूची को "खराब" माना जाता है. क्लाइंट को डेटाबेस से सूची को हटाना होगा और खाली स्ट्रिंग पर सेट state फ़ील्ड के साथ दूसरा अपडेट फिर से जारी करना होगा. इससे पूरा अपडेट लागू होगा और नई सूची और स्थिति दिखेगी.