Google सुरक्षित ब्राउज़िंग v5 में, क्लाइंट को स्थानीय डेटाबेस बनाए रखने की ज़रूरत होती है. हालांकि, क्लाइंट के स्टोरेज के बिना रीयल-टाइम मोड को चुनने पर ऐसा नहीं होता. इस लोकल डेटाबेस का फ़ॉर्मैट और स्टोरेज, क्लाइंट पर निर्भर करता है. इस लोकल डेटाबेस के कॉन्टेंट को, फ़ाइलों के तौर पर अलग-अलग सूचियों वाले फ़ोल्डर के तौर पर देखा जा सकता है. साथ ही, इन फ़ाइलों में SHA256 हैश या उनके प्रीफ़िक्स होते हैं. आम तौर पर, हैश की लंबाई चार बाइट होती है.
उपलब्ध सूचियां
सूचियों की पहचान उनके अलग-अलग नामों से की जाती है. नाम रखने के लिए एक खास नियम का पालन किया जाता है. इस नियम के तहत, नाम में एक सफ़िक्स होता है. इससे सूची में मौजूद हैश की लंबाई का पता चलता है. एक ही तरह के खतरे वाली, लेकिन अलग-अलग लंबाई वाली हैश सूचियों को अलग नाम दिया जाएगा. इन सूचियों में हैश की लंबाई बताने वाला सफ़िक्स शामिल होगा.
हैश सूची के तरीकों के साथ इस्तेमाल करने के लिए, ये सूचियां उपलब्ध हैं.
| सूची का नाम | इससे जुड़ा v4 ThreatType Enum |
ब्यौरा |
|---|---|---|
gc-32b |
कोई सूचना नहीं मिल रही | यह सूची, ग्लोबल कैश मेमोरी की सूची है. यह एक खास सूची है, जिसका इस्तेमाल सिर्फ़ रीयल-टाइम मोड में किया जाता है. |
se-4b |
SOCIAL_ENGINEERING |
इस सूची में, SOCIAL_ENGINEERING टाइप के खतरे शामिल हैं. |
mw-4b |
MALWARE |
इस सूची में, डेस्कटॉप प्लैटफ़ॉर्म के लिए मैलवेयर टाइप के खतरों की जानकारी दी गई है. |
uws-4b |
UNWANTED_SOFTWARE |
इस सूची में, डेस्कटॉप प्लैटफ़ॉर्म के लिए UNWANTED_SOFTWARE टाइप के खतरे शामिल हैं. |
uwsa-4b |
UNWANTED_SOFTWARE |
इस सूची में, Android प्लैटफ़ॉर्म के लिए UNWANTED_SOFTWARE टाइप के खतरे शामिल हैं. |
pha-4b |
POTENTIALLY_HARMFUL_APPLICATION |
इस सूची में, Android प्लैटफ़ॉर्म के लिए POTENTIALLY_HARMFUL_APPLICATION टाइप के खतरे शामिल हैं. |
आने वाले समय में, अन्य सूचियां भी उपलब्ध हो सकती हैं. तब ऊपर दी गई टेबल को बड़ा किया जाएगा. साथ ही, hashList.list तरीके से मिले नतीजे, सबसे अप-टू-डेट सूचियों के साथ मिलते-जुलते होंगे.
डेटाबेस से जुड़े अपडेट
डेटाबेस को अपडेट करने के लिए, क्लाइंट नियमित तौर पर hashList.get method या hashLists.batchGet method को कॉल करेगा. आम तौर पर, क्लाइंट एक बार में कई सूचियां अपडेट करना चाहता है. इसलिए, हमारा सुझाव है कि आप hashLists.batchGet method का इस्तेमाल करें.
सूचियों के नाम कभी नहीं बदले जाएंगे. इसके अलावा, किसी सूची के दिखने के बाद उसे कभी नहीं हटाया जाएगा. अगर सूची अब काम की नहीं है, तो वह खाली हो जाएगी, लेकिन मौजूद रहेगी. इसलिए, Google Safe Browsing के क्लाइंट कोड में इन नामों को हार्ड कोड करना सही है.
hashList.get मेथड और hashLists.batchGet मेथड, दोनों में इंक्रीमेंटल अपडेट की सुविधा काम करती है. इंक्रीमेंटल अपडेट का इस्तेमाल करने से, बैंडविड्थ बचती है और परफ़ॉर्मेंस बेहतर होती है. इंक्रीमेंटल अपडेट, सूची के क्लाइंट वर्शन और सूची के नए वर्शन के बीच डेल्टा डिलीवर करके काम करते हैं. (अगर कोई क्लाइंट हाल ही में डिप्लॉय किया गया है और उसका कोई वर्शन उपलब्ध नहीं है, तो पूरा अपडेट उपलब्ध है.) इंक्रीमेंटल अपडेट में, हटाए गए इंडेक्स और जोड़े गए इंडेक्स शामिल होते हैं. क्लाइंट को पहले अपने स्थानीय डेटाबेस से, तय किए गए इंडेक्स में मौजूद एंट्री हटानी होंगी. इसके बाद, जोड़ी गई एंट्री लागू करनी होंगी.
आखिर में, डेटा में गड़बड़ी को रोकने के लिए, क्लाइंट को सेव किए गए डेटा की जांच, सर्वर से मिले चेकसम के हिसाब से करनी चाहिए. जब भी चेकसम मेल नहीं खाता, तो क्लाइंट को पूरा अपडेट करना चाहिए.
सूची के कॉन्टेंट को डिकोड करना
हैश और हैश प्रीफ़िक्स को डिकोड करना
सभी सूचियों को छोटा करने के लिए, कोड में बदलने के खास तरीके का इस्तेमाल करके डिलीवर किया जाता है. यह एन्कोडिंग इस बात को ध्यान में रखकर काम करती है कि Google की सुरक्षित ब्राउज़िंग की सूचियों में, हैश या हैश प्रीफ़िक्स का एक सेट होता है. आंकड़ों के हिसाब से, इनमें रैंडम पूर्णांकों से कोई अंतर नहीं होता. अगर इन पूर्णांकों को क्रम से लगाया जाए और उनके आस-पास के अंतर को देखा जाए, तो यह अंतर एक तरह से "छोटा" होना चाहिए. इसके बाद, Golomb-Rice एन्कोडिंग इस छोटे साइज़ का फ़ायदा उठाती है.
मान लें कि a.example.com/, b.example.com/, और y.example.com/ नाम के तीन होस्ट-सर्फ़िक्स पाथ-प्रीफ़िक्स एक्सप्रेशन को चार बाइट वाले हैश प्रीफ़िक्स का इस्तेमाल करके ट्रांसमिट करना है. इसके अलावा, मान लें कि k से दिखाए गए राइस पैरामीटर को
- सर्वर इन स्ट्रिंग के लिए पूरे हैश का हिसाब लगाकर शुरू करेगा, जो कि क्रमशः ये हैं:
291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03 y.example.com/
इसके बाद, सर्वर ऊपर बताई गई हर वैल्यू के लिए चार बाइट का हैश प्रीफ़िक्स बनाता है. यह 32 बाइट के पूरे हैश के पहले चार बाइट होते हैं. इन्हें बिग-एंडियन 32-बिट इंटिजर के तौर पर समझा जाता है. बिग इंडियनेस का मतलब है कि पूरे हैश का पहला बाइट, 32-बिट के पूर्णांक का सबसे अहम बाइट बन जाता है. इस चरण के बाद, आपको पूर्णांक 0x291bc542, 0x1d32c508, और 0xf7a502e5 मिलेंगे.
सर्वर को इन तीन हैश प्रीफ़िक्स को वर्णमाला के क्रम में क्रम से लगाना ज़रूरी है. यह क्रम, बिग इंडियन में अंकों के क्रम से लगाने के बराबर होता है. क्रम से लगाने पर, नतीजा 0x1d32c508, 0x291bc542, 0xf7a502e5 होता है. पहला हैश प्रीफ़िक्स, first_value फ़ील्ड में बिना किसी बदलाव के सेव किया जाता है.
इसके बाद, सर्वर दो आस-पास के अंतर का हिसाब लगाता है. ये अंतर क्रमशः 0xbe9003a और 0xce893da3 हैं. मान लें कि k को 30 के तौर पर चुना गया है. ऐसे में, सर्वर इन दोनों संख्याओं को भागफल और शेषफल के हिस्सों में बांट देता है. ये हिस्से क्रमशः दो और 30 बिट लंबे होते हैं. पहली संख्या के लिए, भागफल शून्य है और शेष 0xbe9003a है. दूसरी संख्या के लिए, भागफल 3 है, क्योंकि बाइनरी में सबसे अहम दो बिट 11 हैं और शेष 0xe893da3 है. किसी दिए गए भागफल q को 1 + q बिट का इस्तेमाल करके (1 << q) - 1 में बदला जाता है. बाकी बचे हिस्से को सीधे तौर पर k बिट का इस्तेमाल करके बदला जाता है. पहले नंबर के भागफल को 0 के तौर पर एन्कोड किया गया है और शेष भाग को बाइनरी में 001011111010010000000000111010 के तौर पर एन्कोड किया गया है. दूसरे नंबर के भागफल को 0111 के तौर पर एन्कोड किया गया है और शेष भाग को 001110100010010011110110100011 के तौर पर एन्कोड किया गया है.
जब इन नंबरों को बाइट स्ट्रिंग में बनाया जाता है, तो लिटल इंडियन का इस्तेमाल किया जाता है. कॉन्सेप्ट के हिसाब से, सबसे कम अहमियत वाले बिट से शुरू होकर, लंबी बिटस्ट्रिंग बनाई जा सकती है: हम पहली संख्या के भागफल वाले हिस्से को लेते हैं और पहली संख्या के बचे हुए हिस्से को पहले रखते हैं. इसके बाद, हम दूसरी संख्या के भागफल वाले हिस्से को पहले रखते हैं और बचे हुए हिस्से को पहले रखते हैं. इससे आपको यह बड़ी संख्या दिखेगी (साफ़ तौर पर समझाने के लिए, लाइनब्रेक और टिप्पणियां जोड़ी गई हैं):
001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part
एक लाइन में लिखा गया यह फ़ॉर्मूला इस तरह दिखेगा
00111010001001001111011010001101110010111110100100000000001110100
जाहिर है कि यह संख्या, एक बाइट में मौजूद आठ बिट से काफ़ी ज़्यादा है. इसके बाद, लिटल इंडियन कोडिंग उस संख्या के सबसे कम अहम आठ बिट लेती है और उसे पहले बाइट के तौर पर दिखाती है, जो 01110100 है. साफ़ तौर पर समझने के लिए, ऊपर दी गई बिटस्ट्रिंग को आठ के ग्रुप में बांटा जा सकता है. यह बांटने की प्रक्रिया, सबसे कम अहमियत वाले बिट से शुरू की जा सकती है:
0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100
इसके बाद, लिटल इंडियन कोडिंग, दाईं ओर से हर बाइट को लेती है और उसे बाइट स्ट्रिंग में डालती है:
01110100
00000000
11010010
10010111
00011011
11101101
01001001
01110100
00000000
यह देखा जा सकता है कि हम बाईं ओर मौजूद बड़ी संख्या में नए हिस्सों को जोड़ते हैं (यानी ज़्यादा अहम बिट जोड़ते हैं), लेकिन हम दाईं ओर से (यानी सबसे कम अहम बिट) कोड करते हैं. इसलिए, कोडिंग और डिकोडिंग को धीरे-धीरे किया जा सकता है.
आखिर में,
additions_four_bytes {
first_value: 489866504
rice_parameter: 30
entries_count: 2
encoded_data: "t\000\322\227\033\355It\000"
}
हैश प्रीफ़िक्स को डिकोड करने के लिए, क्लाइंट ऊपर दिए गए चरणों को उलटे क्रम में अपनाता है.
वीडियो हटाने के इंडेक्स को डिकोड करना
हटाए गए आइटम के इंडेक्स, ऊपर बताई गई तकनीक का इस्तेमाल करके एन्कोड किए जाते हैं. इसमें 32-बिट के पूर्णांक का इस्तेमाल किया जाता है.
अपडेट की फ़्रीक्वेंसी
क्लाइंट को फ़ील्ड minimum_wait_duration में, सर्वर की दी गई वैल्यू की जांच करनी चाहिए. साथ ही, डेटाबेस के अगले अपडेट को शेड्यूल करने के लिए, उस वैल्यू का इस्तेमाल करना चाहिए. हो सकता है कि यह वैल्यू शून्य हो (minimum_wait_duration फ़ील्ड पूरी तरह से मौजूद न हो). ऐसे में, क्लाइंट को तुरंत दूसरा अपडेट करना चाहिए.