Google सुरक्षित ब्राउज़िंग के वर्शन 4 के मुकाबले, वर्शन 5 में एक अहम सुधार हुआ है. यह सुधार, डेटा को अपडेट करने और कवरेज से जुड़ा है. खास तौर पर, v4 Update API में यह सुधार हुआ है. सुरक्षा, क्लाइंट के बनाए गए लोकल डेटाबेस पर काफ़ी हद तक निर्भर करती है. इसलिए, लोकल डेटाबेस के अपडेट में लगने वाला समय और उसका साइज़, सुरक्षा न मिलने की मुख्य वजह है. v4 में, किसी क्लाइंट को खतरे की सूचियों का सबसे अप-टू-डेट वर्शन पाने में 20 से 50 मिनट लगते हैं. फ़िशिंग अटैक तेज़ी से फैलते हैं: साल 2021 तक, अटैक करने वाली 60% साइटें 10 मिनट से भी कम समय तक लाइव रहती हैं. हमारे विश्लेषण से पता चलता है कि डेटा पुराना होने की वजह से, फ़िशिंग से सुरक्षा की सुविधा 25 से 30% लोगों को नहीं मिल पाती. इसके अलावा, कुछ डिवाइसों में Google की सुरक्षित ब्राउज़िंग की खतरे वाली सभी सूचियों को मैनेज करने की सुविधा नहीं होती. यह सूची समय के साथ बड़ी होती रहती है.
अगर फ़िलहाल v4 Update API का इस्तेमाल किया जा रहा है, तो v4 से v5 पर आसानी से माइग्रेट किया जा सकता है. इसके लिए, आपको स्थानीय डेटाबेस को रीसेट या मिटाने की ज़रूरत नहीं है. इस सेक्शन में, ऐसा करने का तरीका बताया गया है.
सूची में बदलावों की जानकारी
V4 के उलट, V5 में सूचियों की पहचान सिर्फ़ नाम से की जाती है. V4 में, सूचियों की पहचान खतरे के टाइप, प्लैटफ़ॉर्म के टाइप, और खतरे की एंट्री के टाइप के टुपल से की जाती है. इससे, जब एक से ज़्यादा v5 सूचियां एक ही तरह की धमकी शेयर कर सकती हैं, तो आपको ज़्यादा सुविधा मिलती है. वर्शन 5 में, प्लैटफ़ॉर्म टाइप और खतरे की एंट्री टाइप हटा दिए गए हैं.
v4 में, सूचियां डाउनलोड करने के लिए threatListUpdates.fetch method का इस्तेमाल किया जाएगा. v5 में, hashLists.batchGet method पर स्विच किया जाएगा.
अनुरोध में ये बदलाव किए जाने चाहिए:
- v4
ClientInfoऑब्जेक्ट को पूरी तरह हटाएं. किसी खास फ़ील्ड का इस्तेमाल करके क्लाइंट की पहचान करने के बजाय, User-Agent हेडर का इस्तेमाल करें. इस हेडर में क्लाइंट आइडेंटिफ़िकेशन देने के लिए कोई तय फ़ॉर्मैट नहीं है. हालांकि, हमारा सुझाव है कि आप ओरिजनल क्लाइंट आईडी और क्लाइंट वर्शन को शामिल करें. साथ ही, इनके बीच स्पेस या स्लैश का इस्तेमाल करें. - हर v4
ListUpdateRequestऑब्जेक्ट के लिए: * ऊपर दी गई टेबल में, उससे जुड़ी v5 सूची का नाम देखें और v5 अनुरोध में वह नाम दें.threat_entry_typeयाplatform_typeजैसे गै़र-ज़रूरी फ़ील्ड हटाएं.- वर्शन 4 में मौजूद
stateफ़ील्ड, वर्शन 5 में मौजूदversionsफ़ील्ड के साथ सीधे तौर पर काम करता है. वर्शन 4 मेंstateफ़ील्ड का इस्तेमाल करके सर्वर को भेजी जाने वाली वही बाइट स्ट्रिंग, वर्शन 5 मेंversionsफ़ील्ड का इस्तेमाल करके भेजी जा सकती है. - v4 की पाबंदियों के लिए, v5 में
SizeConstraintsनाम के आसान वर्शन का इस्तेमाल किया जाता है.regionजैसे अतिरिक्त फ़ील्ड हटा दिए जाने चाहिए.
जवाब में ये बदलाव किए जाने चाहिए:
- v4 enum
ResponseTypeकोpartial_updateनाम के बूलियन फ़ील्ड से आसानी से बदल दिया जाता है. minimum_wait_durationफ़ील्ड को अब शून्य पर सेट किया जा सकता है या छोड़ा जा सकता है. अगर ऐसा है, तो क्लाइंट से तुरंत दूसरा अनुरोध करने के लिए कहा जाता है. ऐसा सिर्फ़ तब होता है, जब क्लाइंटSizeConstraintsमें, डेटाबेस के ज़्यादा से ज़्यादा साइज़ के मुकाबले, अपडेट के ज़्यादा से ज़्यादा साइज़ पर कम पाबंदी तय करता है.- 32-बिट के पूर्णांकों के लिए, राइस डिकोडिंग एल्गोरिदम में बदलाव करना होगा. अंतर यह है कि एन्क्रिप्ट किए गए डेटा को अलग-अलग endianness के साथ एन्क्रिप्ट किया जाता है. v4 और v5, दोनों में 32-बिट हैश प्रीफ़िक्स को वर्णमाला के क्रम में क्रम से लगाया जाता है. हालांकि, v4 में, क्रम से लगाने पर उन प्रीफ़िक्स को लिटल इंडियन के तौर पर माना जाता है, जबकि v5 में क्रम से लगाने पर उन प्रीफ़िक्स को बिग इंडियन के तौर पर माना जाता है. इसका मतलब है कि क्लाइंट को कोई क्रम तय करने की ज़रूरत नहीं है, क्योंकि शब्दकोश के हिसाब से क्रम तय करना, बिग इंडियन के साथ अंकों के हिसाब से क्रम तय करने जैसा ही है. Chromium में v4 को लागू करने का उदाहरण यहां देखा जा सकता है. इस तरह की क्रम से लगाई गई फ़िल्टर को हटाया जा सकता है.
- हैश की अन्य लंबाई के लिए भी, राइस डिकोडिंग एल्गोरिदम लागू करना होगा.
हैश सर्च को बदलना
वर्शन 4 में, पूरे हैश पाने के लिए fullHashes.find method का इस्तेमाल किया जाता है. v5 में, hashes.search का तरीका मिलता-जुलता तरीका है.
अनुरोध में ये बदलाव किए जाने चाहिए:
- कोड को इस तरह से बनाएं कि सिर्फ़ ऐसे हैश प्रीफ़िक्स भेजे जाएं जिनकी लंबाई चार बाइट हो.
- v4
ClientInfoऑब्जेक्ट को पूरी तरह हटाएं. किसी खास फ़ील्ड का इस्तेमाल करके क्लाइंट की पहचान करने के बजाय, User-Agent हेडर का इस्तेमाल करें. इस हेडर में क्लाइंट आइडेंटिफ़िकेशन देने के लिए कोई तय फ़ॉर्मैट नहीं है. हालांकि, हमारा सुझाव है कि आप ओरिजनल क्लाइंट आईडी और क्लाइंट वर्शन को शामिल करें. साथ ही, इनके बीच स्पेस या स्लैश का इस्तेमाल करें. client_statesफ़ील्ड हटाएं. अब इसकी ज़रूरत नहीं है.- अब
threat_typesऔर मिलते-जुलते फ़ील्ड शामिल करने की ज़रूरत नहीं है.
जवाब में ये बदलाव किए जाने चाहिए:
minimum_wait_durationफ़ील्ड को हटा दिया गया है. क्लाइंट, ज़रूरत के हिसाब से कभी भी नया अनुरोध कर सकता है.- v4
ThreatMatchऑब्जेक्ट कोFullHashऑब्जेक्ट में आसानी से बदला गया है. - कैश मेमोरी को एक ही अवधि के लिए सेट किया जा सकता है. कैश मेमोरी के साथ इंटरैक्ट करने के लिए, ऊपर दिया गया तरीका अपनाएं.