Overview

परिचय

ध्यान दें: फ़िलहाल, इस दस्तावेज़ पर काम चल रहा है. आने वाले समय में इसमें सुधार हो सकता है.

Google सुरक्षित ब्राउज़िंग v5, Google सुरक्षित ब्राउज़िंग v4 का एक बेहतर वर्शन है. v5 में किए गए दो मुख्य बदलाव हैं: डेटा अपडेट होना और आईपी निजता. इसके अलावा, एपीआई के प्लैटफ़ॉर्म में सुधार किया गया है, ताकि सुविधाजनक और बेहतर तरीके से काम किया जा सके. साथ ही, रुकावट को कम किया जा सके. साथ ही, Google सुरक्षित ब्राउज़िंग v5 को इस तरह से डिज़ाइन किया गया है, जिससे v4 से डेटा दूसरी जगह भेजना आसान हो जाता है.

फ़िलहाल, Google, वर्शन 4 और v5, दोनों ही उपलब्ध कराता है. साथ ही, दोनों को प्रोडक्शन के लिए तैयार माना जाता है. वर्शन 4 या v5 का इस्तेमाल किया जा सकता है. हमने v4 को बंद करने की कोई तारीख नहीं बताई है; अगर हम ऐसा करते हैं, तो हम आपको कम से कम एक साल का नोटिस देंगे. इस पेज पर वर्शन 5 के बारे में बताया गया है. साथ ही, इसमें वर्शन 4 से v5 पर माइग्रेट करने की गाइड भी दी गई है; v4 दस्तावेज़ उपलब्ध रहेंगे.

नया डेटा

Google सुरक्षित ब्राउज़िंग v5 ओवर v4 (खास तौर पर, v4 अपडेट एपीआई) का एक अहम सुधार है, डेटा अपडेट होना और कवरेज. डेटा की सुरक्षा, क्लाइंट के रखरखाव वाले लोकल डेटाबेस पर निर्भर करती है. इस वजह से, लोकल डेटाबेस के अपडेट होने में ज़्यादा समय और साइज़ की अहम भूमिका होती है, जिसकी वजह से सुरक्षा पूरी नहीं हो पाती. वर्शन 4 में, आम क्लाइंट को खतरे की सूचियों का सबसे अप-टू-डेट वर्शन पाने में 20 से 50 मिनट लगते हैं. माफ़ करें, फ़िशिंग अटैक काफ़ी तेज़ी से फैलते हैं: 2021 में, हमला करने वाली 60% साइटें 10 मिनट से भी कम समय तक रहती थीं. हमारे विश्लेषण से पता चलता है कि करीब 25 से 30% फ़िशिंग से सुरक्षा नहीं मिलने की वजह, पुराना डेटा होता है. इसके अलावा, कुछ डिवाइसों में Google सुरक्षित ब्राउज़िंग से जुड़े खतरों की पूरी सूची को मैनेज नहीं किया जा सकता. ये चेतावनियां समय के साथ बढ़ती जा रही हैं.

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

आईपी निजता

अनुरोध स्वीकार करते समय, Google सुरक्षित ब्राउज़िंग (v4 या v5) किसी भी उपयोगकर्ता की पहचान से जुड़ी कोई भी कार्रवाई नहीं करती. अगर कुकी भेजी जाती हैं, तो उन्हें अनदेखा कर दिया जाता है. Google, अनुरोधों के मूल आईपी पतों की जानकारी देता है, लेकिन Google सिर्फ़ ज़रूरी नेटवर्किंग ज़रूरतों (जैसे कि जवाब भेजने के लिए) और DoS विरोधी कामों के लिए, आईपी पतों का इस्तेमाल करता है.

v5 के साथ-साथ, हमने एक कंपैनियन एपीआई लॉन्च किया है, जिसे सुरक्षित ब्राउज़िंग ऑब्लिवियस एचटीटीपी गेटवे एपीआई के नाम से जाना जाता है. यह असली उपयोगकर्ताओं को छिपाने के लिए Oblivious HTTP का इस्तेमाल करता है Google से मिले आईपी पते. यह उपयोगकर्ता अनुरोध के एन्क्रिप्ट (सुरक्षित) किए गए वर्शन को मैनेज करने के लिए, तीसरे पक्ष की मदद लेता है और उसे Google को फ़ॉरवर्ड करता है. इसका मतलब है कि तीसरा पक्ष सिर्फ़ आईपी पतों को ऐक्सेस कर सकता है और Google के पास सिर्फ़ अनुरोध के कॉन्टेंट का ऐक्सेस होता है. तीसरा पक्ष, ऑब्लिवियस एचटीटीपी रिले को ऑपरेट करता है. जैसे, फ़ास्टली की यह सेवा. साथ ही, Google ऑब्लिवियस एचटीटीपी गेटवे को चलाता है. यह एक वैकल्पिक कंपैनियन एपीआई है. इसे 'Google सुरक्षित ब्राउज़िंग' के साथ इस्तेमाल करते समय, असली उपयोगकर्ता आईपी पते अब Google को नहीं भेजे जाते.

सही इस्तेमाल

इस्तेमाल की अनुमति

सुरक्षित ब्राउज़िंग एपीआई सिर्फ़ गैर-व्यावसायिक इस्तेमाल के लिए है (यानी “बिक्री या आय जनरेट करने के मकसद से नहीं”. अगर आपको व्यावसायिक उद्देश्यों के लिए कोई समाधान चाहिए, तो कृपया वेब रिस्क देखें.

कीमत

Google सुरक्षित ब्राउज़िंग के सभी एपीआई बिना किसी शुल्क के उपलब्ध हैं.

कोटा

सुरक्षित ब्राउज़िंग एपीआई चालू करने पर, डेवलपर को इस्तेमाल का डिफ़ॉल्ट कोटा तय किया जाता है. वर्तमान आवंटन और उपयोग को Google Developer Console में देखा जा सकता है. अगर आपको मौजूदा कोटा से ज़्यादा कोटा इस्तेमाल करना है, तो Developer Console के कोटा इंटरफ़ेस से, अतिरिक्त कोटे का अनुरोध करें. हम इन अनुरोधों की समीक्षा करते हैं और कोटा बढ़ाने का आवेदन करते समय आपसे संपर्क करने की ज़रूरत होती है, ताकि यह पक्का किया जा सके कि हमारी सेवा सभी उपयोगकर्ताओं की ज़रूरतों को पूरा कर सके.

सही यूआरएल

Google सुरक्षित ब्राउज़िंग को ऐसे यूआरएल पर कार्रवाई करने के लिए डिज़ाइन किया गया है जो ब्राउज़र के पता बार में दिखेंगे. इसे सबरिसॉर्स (जैसे कि एचटीएमएल फ़ाइल से रेफ़र किया गया JavaScript या इमेज या JavaScript से शुरू किया गया WebSocket यूआरएल) की जांच करने के लिए इस्तेमाल करने के लिए नहीं बनाया गया है. ऐसे सबरिसॉर्स यूआरएल की जांच, 'Google सुरक्षित ब्राउज़िंग' के लिए नहीं की जानी चाहिए.

अगर किसी यूआरएल पर जाने के बाद आपको रीडायरेक्ट किया जाता है (जैसे कि HTTP 301), तो इस मामले में सही है कि दूसरे वेबलिंक पर भेजने वाले यूआरएल की जांच, Google सुरक्षित ब्राउज़िंग के बजाय की जाए. क्लाइंट-साइड यूआरएल में बदलाव, जैसे कि History.pushState की वजह से, Google सुरक्षित ब्राउज़िंग के मुकाबले नए यूआरएल की जांच नहीं होती.

उपयोगकर्ता चेतावनियां

अगर किसी वेबपेज के जोखिमों के बारे में उपयोगकर्ताओं को चेतावनी देने के लिए, Google सुरक्षित ब्राउज़िंग का इस्तेमाल किया जाता है, तो ये दिशा-निर्देश लागू होते हैं.

ये दिशा-निर्देश, आपको और Google को गलतफ़हमी से बचाने में मदद करते हैं. इनमें, यह साफ़ तौर पर बताया जाता है कि किसी पेज को असुरक्षित वेब रिसॉर्स होने की पूरी तरह से सही जानकारी नहीं है और चेतावनियां सिर्फ़ संभावित जोखिम की पहचान करती हैं.

• उपयोगकर्ताओं को दिखने वाली चेतावनी में, आपको इस बात पर कोई भरोसा नहीं करना चाहिए कि जिस पेज की शिकायत की गई है वह असुरक्षित वेब रिसॉर्स है. जिस पेज की पहचान की जा रही है या उससे उपयोगकर्ताओं को संभावित जोखिमों की जानकारी देते समय, आपको चेतावनी का आवेदन करना होगा. इसके लिए, आपको इन शब्दों का इस्तेमाल करना होगा: संदिग्ध, संभावित, संभावित, संभावित हो सकता है.
• Google ने अलग-अलग तरह के खतरों की परिभाषा की समीक्षा करके, वह चेतावनी दी है. इससे लोगों को ज़्यादा जानकारी पाने की सुविधा मिलनी चाहिए. यहां दिए गए लिंक सुझाए गए हैं:
  • सोशल इंजीनियरिंग: https://developers.google.com/search/docs/monitor-debug/security/social-engineering
  • मैलवेयर और अनचाहा सॉफ़्टवेयर: https://developers.google.com/search/docs/monitor-debug/security/malware
  • नुकसान पहुंचा सकने वाले ऐप्लिकेशन (सिर्फ़ Android के लिए): https://developers.google.com/android/play-protect/potentially-harmful-applications
• जब सुरक्षित ब्राउज़िंग सेवा ने ऐसे पेजों के लिए चेतावनियां दिखाई हों जिनकी पहचान जोखिम भरे पेज के तौर पर की गई है, तब आपको "Google की ओर से दी गई सलाह" लाइन शामिल करके, Google को एट्रिब्यूशन देना होगा सुरक्षित ब्राउज़िंग सलाह के लिंक के साथ. अगर आपका प्रॉडक्ट दूसरे सोर्स के आधार पर भी चेतावनियां दिखाता है, तो आपको Google से बाहर के डेटा से मिलने वाली चेतावनियों में Google एट्रिब्यूशन को शामिल नहीं करना चाहिए.

• आपको अपने प्रॉडक्ट के दस्तावेज़ में एक सूचना देनी होगी, ताकि लोगों को यह पता चल सके कि 'Google सुरक्षित ब्राउज़िंग' से मिलने वाली सुरक्षा पूरी तरह से सुरक्षित नहीं है. उसे यह बताना होगा कि फ़ॉल्स पॉज़िटिव (सुरक्षित साइटों को जोख़िम के तौर पर फ़्लैग किया गया) और फ़ॉल्स नेगेटिव (जोखिम वाली साइटों को फ़्लैग नहीं किया गया है) दोनों की संभावना है. हमारा सुझाव है कि आप नीचे दी गई भाषा का इस्तेमाल करें:

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

काम करने के तरीके

Google सुरक्षित ब्राउज़िंग v5, क्लाइंट को कार्रवाई के तीन मोड में से किसी एक को चुनने की सुविधा देता है.

रीयल-टाइम मोड

जब क्लाइंट, रीयल-टाइम मोड में Google सुरक्षित ब्राउज़िंग v5 का इस्तेमाल करने का विकल्प चुनते हैं, तो क्लाइंट अपने लोकल डेटाबेस में ये काम करते हैं: (i) बिना किसी जोखिम वाली साइटों का ग्लोबल कैश, जो होस्ट-सफ़िक्स/पाथ-प्रीफ़िक्स यूआरएल एक्सप्रेशन के SHA256 हैश के तौर पर फ़ॉर्मैट होता है, (ii) होस्ट-सफ़ीक्स/path-प्रीफ़िक्स यूआरएल एक्सप्रेशन के SHA256 हैश प्रीफ़िक्स के तौर पर फ़ॉर्मैट किए गए खतरे की सूचियों का एक सेट. खास बात यह है कि जब भी क्लाइंट किसी खास यूआरएल की जांच करना चाहता है, तो ग्लोबल कैश का इस्तेमाल करके स्थानीय जांच की जाती है. अगर यह जांच पूरी हो जाती है, तो स्थानीय खतरे की सूचियों की जांच की जाती है. ऐसा न होने पर, क्लाइंट नीचे बताए गए तरीके से रीयल-टाइम हैश जांच जारी रखता है.

लोकल डेटाबेस के अलावा, क्लाइंट एक लोकल कैश मेमोरी बनाए रखेगा. ऐसे लोकल कैश मेमोरी को स्थायी स्टोरेज में नहीं रखना चाहिए. मेमोरी के दबाव में होने पर इसे मिटाया जा सकता है.

इस प्रक्रिया के बारे में ज़्यादा जानकारी नीचे दी गई है.

स्थानीय सूची वाला मोड

जब क्लाइंट इस मोड में Google सुरक्षित ब्राउज़िंग v5 का इस्तेमाल करते हैं, तो क्लाइंट का व्यवहार v4 अपडेट एपीआई जैसा ही होता है. हालांकि, v5 के बेहतर एपीआई सरफ़ेस का इस्तेमाल नहीं किया जाता. क्लाइंट अपने लोकल डेटाबेस में, होस्ट-suffix/path-prefix यूआरएल एक्सप्रेशन के SHA256 हैश प्रीफ़िक्स के तौर पर फ़ॉर्मैट की गई खतरे की सूचियों का एक सेट बनाए रखेंगे. जब क्लाइंट किसी खास यूआरएल की जांच करना चाहता है, तो खतरे की स्थानीय सूची का इस्तेमाल करके जांच की जाती है. मैच होने पर ही क्लाइंट, सर्वर से कनेक्ट करके जांच जारी रखता है.

जैसा कि ऊपर बताया गया है, क्लाइंट के पास लोकल कैश मेमोरी का भी रखरखाव होता है, जिसे स्थायी स्टोरेज में रखने की ज़रूरत नहीं होती.

स्टोरेज उपलब्ध नहीं होने का रीयल-टाइम मोड

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

जब क्लाइंट किसी खास यूआरएल की जांच करना चाहता है, तो क्लाइंट हमेशा सर्वर से कनेक्ट होकर जांच करता है. यह मोड, v4 लुकअप एपीआई के क्लाइंट के क्लाइंट के तरीके जैसा है.

रीयल-टाइम मोड की तुलना में, यह मोड ज़्यादा नेटवर्क बैंडविथ का इस्तेमाल कर सकता है. हालांकि, यह मोड तब बेहतर हो सकता है, जब क्लाइंट को लगातार स्थानीय स्थिति बनाए रखना मुश्किल हो.

यूआरएल की जांच की जा रही है

इस सेक्शन में, इस बारे में पूरी जानकारी दी गई है कि क्लाइंट यूआरएल की जांच कैसे करते हैं.

यूआरएल को कैननिकल बनाना

किसी भी यूआरएल की जांच करने से पहले, क्लाइंट को उस यूआरएल के लिए कैननिकल होने की कुछ प्रक्रिया पूरी करनी होती है.

शुरू करने के लिए, हम मान लेते हैं कि क्लाइंट ने यूआरएल को पार्स कर लिया है और उसे आरएफ़सी 2396 के मुताबिक मान्य किया है. अगर यूआरएल, अंतरराष्ट्रीय डोमेन नेम (आईडीएन) का इस्तेमाल करता है, तो क्लाइंट को यूआरएल को ASCII पूनीकोड प्रतिनिधि में बदलना चाहिए. यूआरएल में कोई पाथ कॉम्पोनेंट शामिल होना चाहिए; इसका मतलब है कि इसमें डोमेन के बाद, कम से कम एक स्लैश होना चाहिए (http://google.com के बजाय http://google.com/).

सबसे पहले, यूआरएल से टैब (0x09), CR (0x0d), और LF (0x0a) वर्ण हटा दें. इन वर्णों के लिए, एस्केप सीक्वेंस न हटाएं. (जैसे, %0a).

दूसरा, अगर यूआरएल किसी फ़्रैगमेंट से खत्म होता है, तो उस फ़्रैगमेंट को हटा दें. उदाहरण के लिए, http://google.com/#frag को छोटा करके http://google.com/ करें.

तीसरा, जब तक यूआरएल में कोई और परसेंट-एस्केप नहीं हो जाता, तब तक उस यूआरएल को बार-बार पर्सेंट-अनएस्केप करें. (इससे यूआरएल अमान्य हो सकता है.)

होस्टनेम का कैननिकल वर्शन बनाने के लिए:

यूआरएल से होस्टनेम निकालें और इसके बाद:

1. शुरू और पीछे के सभी बिंदुओं को हटाएं.
2. लगातार बिंदुओं को एक बिंदु से बदलें.
3. अगर होस्टनेम को आईपीवी4 पते के तौर पर पार्स किया जा सकता है, तो इसे चार बिंदु से अलग की गई दशमलव वैल्यू पर नॉर्मलाइज़ करें. क्लाइंट को हर तरह के कानूनी आईपी पते को कोड में बदलने के तरीके को हैंडल करना चाहिए. इसमें ऑक्टल, हेक्स, और चार से कम कॉम्पोनेंट शामिल हैं.
4. अगर होस्टनेम को ब्रैकेट वाले IPv6 पते के तौर पर पार्स किया जा सकता है, तो कॉम्पोनेंट के ग़ैर-ज़रूरी शून्य को हटाकर और डबल-कोलन सिंटैक्स का इस्तेमाल करके शून्य कॉम्पोनेंट को छोटा करके इसे नॉर्मलाइज़ करें. उदाहरण के लिए, [2001:0db8:0000::1] को [2001:db8::1] में बदला जाना चाहिए. अगर होस्टनेम, नीचे दिए गए दो खास तरह के आईपीवी6 पते टाइप में से एक है, तो उन्हें आईपीवी4 में बदलें:
   • आईपीवी4-मैप किया गया आईपीवी6 पता, जैसे कि [::ffff:1.2.3.4], जिसे 1.2.3.4 में बदला जाना चाहिए;
   • लोकप्रिय प्रीफ़िक्स 64:ff9b::/96 का इस्तेमाल करने वाला NAT64 पता, जैसे कि [64:ff9b::1.2.3.4], जिसे 1.2.3.4 में बदला जाना चाहिए.
5. पूरी स्ट्रिंग को अंग्रेज़ी के छोटे अक्षरों में लिखें.

पाथ को कैननिकल बनाने के लिए:

1. /./ को / से बदलकर और पिछले पाथ कॉम्पोनेंट से /../ को हटाकर, पाथ में /../ और /./ के क्रम को हल करें.
2. लगातार स्लैश वर्ण चलाए जाने की जगह, एक स्लैश वर्ण का इस्तेमाल करें.

क्वेरी पैरामीटर के लिए, पाथ के कैननिकल होने की ये जांच लागू न करें.

यूआरएल में, उन सभी वर्णों का प्रतिशत-एस्केप करें जो <= ASCII 32, >= 127, # या % हैं. एस्केप में अपरकेस हेक्स वर्णों का इस्तेमाल किया जाना चाहिए.

होस्ट-सफ़िक्स पाथ-प्रीफ़िक्स एक्सप्रेशन

यूआरएल के कैननिकल होने के बाद, अगला चरण सफ़िक्स/प्रीफ़िक्स एक्सप्रेशन बनाना है. हर सफ़िक्स/प्रीफ़िक्स एक्सप्रेशन में, एक होस्ट सफ़िक्स (या पूरा होस्ट) और एक पाथ प्रीफ़िक्स (या पूरा पाथ) होता है.

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

होस्ट के लिए, क्लाइंट ज़्यादा से ज़्यादा पांच अलग-अलग स्ट्रिंग आज़माएगा. ये वजह हैं:

• अगर होस्टनेम, आईपीवी4 या आईपीवी6 लिटरल नहीं है, तो eTLD+1 डोमेन से शुरू करके और लीडिंग कॉम्पोनेंट जोड़कर बनाए गए, ज़्यादा से ज़्यादा चार होस्टनेम. eTLD+1 का पता लगाने के लिए, सार्वजनिक सफ़िक्स सूची का इस्तेमाल किया जाना चाहिए. उदाहरण के लिए, a.b.example.com का नतीजा, example.com के eTLD+1 डोमेन के साथ-साथ, एक अतिरिक्त होस्ट कॉम्पोनेंट b.example.com वाला होस्ट मिलेगा.
• यूआरएल में मौजूद होस्टनेम. ऊपर दिए गए उदाहरण के मुताबिक, a.b.example.com को चुना जाएगा.

पाथ के लिए, क्लाइंट ज़्यादा से ज़्यादा छह अलग-अलग स्ट्रिंग आज़मा सकता है. ये वजह हैं:

• क्वेरी पैरामीटर के साथ यूआरएल का सटीक पाथ.
• क्वेरी पैरामीटर के बिना, यूआरएल का सटीक पाथ.
• रूट (/) से शुरू करके और बाद में स्लैश सहित, पाथ कॉम्पोनेंट को धीरे-धीरे जोड़कर, चार पाथ बनाए जाते हैं.

नीचे दिए गए उदाहरणों में, जांच करने का तरीका दिखाया गया है:

यूआरएल http://a.b.com/1/2.html?param=1 के लिए, क्लाइंट ये संभावित स्ट्रिंग आज़माएगा:

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

यूआरएल http://a.b.c.d.e.f.com/1.html के लिए, क्लाइंट ये संभावित स्ट्रिंग आज़माएगा:

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

(ध्यान दें: b.c.d.e.f.com को स्किप करें, क्योंकि हम होस्टनेम के आखिरी पांच कॉम्पोनेंट और पूरे होस्टनेम को ही लेंगे.)

यूआरएल http://1.2.3.4/1/ के लिए, क्लाइंट ये संभावित स्ट्रिंग आज़माएगा:

1.2.3.4/1/
1.2.3.4/

यूआरएल http://example.co.uk/1 के लिए, क्लाइंट ये संभावित स्ट्रिंग आज़माएगा:

example.co.uk/1
example.co.uk/

हैशिंग

Google सुरक्षित ब्राउज़िंग की सुविधा, हैश फ़ंक्शन के तौर पर खास तौर पर SHA256 का इस्तेमाल करती है. इस हैश फ़ंक्शन को ऊपर दिए गए एक्सप्रेशन पर लागू किया जाना चाहिए.

परिस्थितियों के हिसाब से, पूरे 32-बाइट वाले हैश को 4 बाइट, 8 बाइट या 16 बाइट तक छोटा किया जाएगा:

• hashes.search के तरीके का इस्तेमाल करने पर, फ़िलहाल हमें अनुरोध में शामिल हैश को चार बाइट तक छोटा करना पड़ता है. इस अनुरोध में ज़्यादा बाइट भेजने से उपयोगकर्ता की निजता को खतरा होगा.

• hashList.get तरीके या hashLists.batchGet तरीके का इस्तेमाल करके, लोकल डेटाबेस की सूचियां डाउनलोड करते समय, सर्वर से भेजे गए हैश की लंबाई पर सूची के प्रकार और हैश की लंबाई के लिए क्लाइंट की पसंद, दोनों से असर पड़ता है. इसकी जानकारी desired_hash_length पैरामीटर से दी जाती है.

रीयल-टाइम में यूआरएल की जांच करने की प्रोसेस

इस प्रोसेस का इस्तेमाल तब किया जाता है, जब क्लाइंट कार्रवाई का रीयल-टाइम मोड चुनता है.

इस प्रक्रिया में एक यूआरएल u लेकर, SAFE, UNSAFE या UNSURE दिखता है. अगर यह नतीजे में SAFE दिखाता है, तो Google सुरक्षित ब्राउज़िंग की सुविधा के हिसाब से यूआरएल को सुरक्षित माना जाता है. अगर यह यूआरएल UNSAFE दिखाता है, तो Google सुरक्षित ब्राउज़िंग के हिसाब से यूआरएल को असुरक्षित माना जा सकता है और इसके लिए ज़रूरी कार्रवाई की जानी चाहिए. जैसे, असली उपयोगकर्ता को चेतावनी दिखाना, मिलने वाले मैसेज को स्पैम फ़ोल्डर में ले जाना या आगे बढ़ने से पहले, उपयोगकर्ता को कुछ और पुष्टि करने की ज़रूरत देना. अगर यह UNSURE दिखाता है, तो इस स्थानीय जांच की प्रोसेस का इस्तेमाल किया जाना चाहिए.

1. मान लें कि expressions, यूआरएल u से जनरेट किए गए सफ़िक्स/प्रीफ़िक्स एक्सप्रेशन की सूची है.
2. मान लें कि expressionHashes एक सूची है, जिसमें एलिमेंट expressions में हर एक्सप्रेशन के SHA256 हैश हैं.
3. expressionHashes के हर hash के लिए:
   1. अगर hash, ग्लोबल कैश मेमोरी में मौजूद है, तो UNSURE दिखाएं.
4. expressionHashPrefixes को एक सूची बनाने के लिए कहें. इसमें एलिमेंट, expressionHashes में हर हैश की शुरुआत के चार बाइट होते हैं.
5. expressionHashPrefixes के हर expressionHashPrefix के लिए:
   1. लोकल कैश मेमोरी में expressionHashPrefix खोजें.
   2. अगर कैश मेमोरी में सेव की गई एंट्री मिलती है:
      1. देखें कि क्या मौजूदा समय, इसके खत्म होने के समय से ज़्यादा है.
      2. अगर यह ज़्यादा है, तो:
         1. लोकल कैश मेमोरी से, कैश मेमोरी में सेव की गई एंट्री हटाएं.
         2. लूप के साथ जारी रखें.
      3. अगर यह इससे बड़ी नहीं है, तो:
         1. expressionHashPrefixes से इस खास expressionHashPrefix को हटाएं.
         2. देखें कि क्या कैश मेमोरी में सेव की गई एंट्री में expressionHashes से जुड़ा पूरा हैश मिला है.
         3. अगर ग्राहक मिलता है, तो UNSAFE को लौटाया जा सकता है.
         4. अगर वह नहीं मिलता है, तो लूप में जारी रखें.
   3. अगर कैश मेमोरी में सेव की गई एंट्री नहीं मिलती है, तो लूप में जारी रखें.
6. RPC SearchHashes या REST तरीके hashes.search का इस्तेमाल करके expressionHashPrefixes को Google सुरक्षित ब्राउज़िंग v5 सर्वर पर भेजें. अगर कोई गड़बड़ी हुई है (नेटवर्क की गड़बड़ियों, एचटीटीपी गड़बड़ियों वगैरह के साथ), तो UNSURE दिखाएं. अगर ऐसा नहीं है, तो रिस्पॉन्स को SB सर्वर से मिले response के तौर पर मानें. इसमें, हैश की पूरी लिस्ट और कुछ मददगार जानकारी के साथ-साथ यह जानकारी भी शामिल होती है कि खतरा किस तरह का है, जैसे कि सोशल इंजीनियरिंग, मैलवेयर वगैरह. साथ ही, कैश मेमोरी की समयसीमा खत्म होने का समय expiration.
7. response के हर fullHash के लिए:
   1. expiration के साथ, fullHash को लोकल कैश मेमोरी में डालें.
8. response के हर fullHash के लिए:
   1. मान लें कि isFound, expressionHashes में fullHash को खोजने का नतीजा है.
   2. अगर isFound गलत है, तो लूप में जारी रखें.
   3. अगर isFound सही है, तो UNSAFE दिखाएं.
9. वापसी की तारीख: SAFE.

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

Localधमक की सूची के यूआरएल की जांच करने की प्रक्रिया

इस प्रोसेस का इस्तेमाल तब किया जाता है, जब क्लाइंट, कार्रवाई के स्थानीय सूची मोड को चुनता है. इसका इस्तेमाल तब भी किया जाता है, जब ऊपर दी गई RealTimeCheck प्रोसेस, UNSURE की वैल्यू दिखाती है.

इस प्रक्रिया में एक यूआरएल u लेकर, SAFE या UNSAFE दिखाया जाता है.

1. मान लें कि expressions, यूआरएल u से जनरेट किए गए सफ़िक्स/प्रीफ़िक्स एक्सप्रेशन की सूची है.
2. मान लें कि expressionHashes एक सूची है, जिसमें एलिमेंट expressions में हर एक्सप्रेशन के SHA256 हैश हैं.
3. expressionHashPrefixes को एक सूची बनाने के लिए कहें. इसमें एलिमेंट, expressionHashes में हर हैश की शुरुआत के चार बाइट होते हैं.
4. expressionHashPrefixes के हर expressionHashPrefix के लिए:
   1. लोकल कैश मेमोरी में expressionHashPrefix खोजें.
   2. अगर कैश मेमोरी में सेव की गई एंट्री मिलती है:
      1. देखें कि क्या मौजूदा समय, इसके खत्म होने के समय से ज़्यादा है.
      2. अगर यह ज़्यादा है, तो:
         1. लोकल कैश मेमोरी से, कैश मेमोरी में सेव की गई एंट्री हटाएं.
         2. लूप के साथ जारी रखें.
      3. अगर यह इससे बड़ी नहीं है, तो:
         1. expressionHashPrefixes से इस खास expressionHashPrefix को हटाएं.
         2. देखें कि क्या कैश मेमोरी में सेव की गई एंट्री में expressionHashes से जुड़ा पूरा हैश मिला है.
         3. अगर ग्राहक मिलता है, तो UNSAFE को लौटाया जा सकता है.
         4. अगर वह नहीं मिलता है, तो लूप में जारी रखें.
   3. अगर कैश मेमोरी में सेव की गई एंट्री नहीं मिलती है, तो लूप में जारी रखें.
5. expressionHashPrefixes के हर expressionHashPrefix के लिए:
   1. खतरे की स्थानीय सूची के डेटाबेस में expressionHashPrefix देखें.
   2. अगर expressionHashPrefix, खतरे की स्थानीय सूची के डेटाबेस में नहीं मिलता है, तो उसे expressionHashPrefixes से हटाएं.
6. RPC SearchHashes या REST तरीके hashes.search का इस्तेमाल करके expressionHashPrefixes को Google सुरक्षित ब्राउज़िंग v5 सर्वर पर भेजें. अगर कोई गड़बड़ी हुई है (नेटवर्क की गड़बड़ियों, एचटीटीपी गड़बड़ियों वगैरह के साथ), तो SAFE दिखाएं. अगर ऐसा नहीं है, तो रिस्पॉन्स को SB सर्वर से मिले response के तौर पर मानें. इसमें, हैश की पूरी लिस्ट और कुछ मददगार जानकारी के साथ-साथ यह जानकारी भी शामिल होती है कि खतरा किस तरह का है, जैसे कि सोशल इंजीनियरिंग, मैलवेयर वगैरह. साथ ही, कैश मेमोरी की समयसीमा खत्म होने का समय expiration.
7. response के हर fullHash के लिए:
   1. expiration के साथ, fullHash को लोकल कैश मेमोरी में डालें.
8. response के हर fullHash के लिए:
   1. मान लें कि isFound, expressionHashes में fullHash को खोजने का नतीजा है.
   2. अगर isFound गलत है, तो लूप में जारी रखें.
   3. अगर isFound सही है, तो UNSAFE दिखाएं.
9. वापसी की तारीख: SAFE.

लोकल डेटाबेस के बिना रीयल-टाइम यूआरएल की जांच करने की प्रोसेस

इस प्रोसेस का इस्तेमाल तब किया जाता है, जब क्लाइंट बिना स्टोरेज वाला रीयल-टाइम मोड चुनता है.

इस प्रक्रिया में एक यूआरएल u लेकर, SAFE या UNSAFE दिखाया जाता है.

1. मान लें कि expressions, यूआरएल u से जनरेट किए गए सफ़िक्स/प्रीफ़िक्स एक्सप्रेशन की सूची है.
2. मान लें कि expressionHashes एक सूची है, जिसमें एलिमेंट expressions में हर एक्सप्रेशन के SHA256 हैश हैं.
3. expressionHashPrefixes को एक सूची बनाने के लिए कहें. इसमें एलिमेंट, expressionHashes में हर हैश की शुरुआत के चार बाइट होते हैं.
4. expressionHashPrefixes के हर expressionHashPrefix के लिए:
   1. लोकल कैश मेमोरी में expressionHashPrefix खोजें.
   2. अगर कैश मेमोरी में सेव की गई एंट्री मिलती है:
      1. देखें कि क्या मौजूदा समय, इसके खत्म होने के समय से ज़्यादा है.
      2. अगर यह ज़्यादा है, तो:
         1. लोकल कैश मेमोरी से, कैश मेमोरी में सेव की गई एंट्री हटाएं.
         2. लूप के साथ जारी रखें.
      3. अगर यह इससे बड़ी नहीं है, तो:
         1. expressionHashPrefixes से इस खास expressionHashPrefix को हटाएं.
         2. देखें कि क्या कैश मेमोरी में सेव की गई एंट्री में expressionHashes से जुड़ा पूरा हैश मिला है.
         3. अगर ग्राहक मिलता है, तो UNSAFE को लौटाया जा सकता है.
         4. अगर वह नहीं मिलता है, तो लूप में जारी रखें.
   3. अगर कैश मेमोरी में सेव की गई एंट्री नहीं मिलती है, तो लूप में जारी रखें.
5. RPC SearchHashes या REST तरीके hashes.search का इस्तेमाल करके expressionHashPrefixes को Google सुरक्षित ब्राउज़िंग v5 सर्वर पर भेजें. अगर कोई गड़बड़ी हुई है (नेटवर्क की गड़बड़ियों, एचटीटीपी गड़बड़ियों वगैरह के साथ), तो SAFE दिखाएं. अगर ऐसा नहीं है, तो रिस्पॉन्स को SB सर्वर से मिले response के तौर पर मानें. इसमें, हैश की पूरी लिस्ट और कुछ मददगार जानकारी के साथ-साथ यह जानकारी भी शामिल होती है कि खतरा किस तरह का है, जैसे कि सोशल इंजीनियरिंग, मैलवेयर वगैरह. साथ ही, कैश मेमोरी की समयसीमा खत्म होने का समय expiration.
6. response के हर fullHash के लिए:
   1. expiration के साथ, fullHash को लोकल कैश मेमोरी में डालें.
7. response के हर fullHash के लिए:
   1. मान लें कि isFound, expressionHashes में fullHash को खोजने का नतीजा है.
   2. अगर isFound गलत है, तो लूप में जारी रखें.
   3. अगर isFound सही है, तो UNSAFE दिखाएं.
8. वापसी की तारीख: SAFE.

रीयल-टाइम यूआरएल जांच की प्रक्रिया की तरह ही, यह प्रोसेस यह नहीं बताती कि सर्वर पर हैश प्रीफ़िक्स कैसे भेजे जाएं. उदाहरण के लिए, क्लाइंट के लिए एक ही अनुरोध में सभी expressionHashPrefixes भेजना स्वीकार किया जाता है. साथ ही, क्लाइंट के लिए यह भी स्वीकार किया जाता है कि वह expressionHashPrefixes में मौजूद हर प्रीफ़िक्स को सर्वर पर अलग-अलग अनुरोधों में भेजेगा (ऐसा भी हो सकता है कि यह प्रक्रिया साथ-साथ आगे बढ़े). अगर किसी एक अनुरोध में भेजे गए हैश प्रीफ़िक्स की संख्या 30 से ज़्यादा न हो, तो क्लाइंट के लिए भी expressionHashPrefixes में हैश प्रीफ़िक्स के साथ बिना किसी क्रम के जनरेट किए गए हैश प्रीफ़िक्स भेजने की अनुमति है.

स्थानीय डेटाबेस का रखरखाव

Google सुरक्षित ब्राउज़िंग v5 के मुताबिक, क्लाइंट एक लोकल डेटाबेस बनाए रखता है. हालांकि, ऐसा तब नहीं होता, जब क्लाइंट 'स्टोरेज नहीं' रीयल-टाइम मोड चुनता है. इस लोकल डेटाबेस के फ़ॉर्मैट और स्टोरेज का फ़ैसला क्लाइंट के पास होता है. इस लोकल डेटाबेस के कॉन्टेंट को एक फ़ोल्डर माना जा सकता है, जिसमें फ़ाइलों के रूप में कई सूचियां होती हैं. इन फ़ाइलों का कॉन्टेंट SHA256 हैश या हैश प्रीफ़िक्स होता है.

डेटाबेस से जुड़े अपडेट

क्लाइंट, डेटाबेस को अपडेट करने के लिए नियमित रूप से hashList.get तरीके या hashLists.batchGet तरीके को कॉल करेगा. सामान्य क्लाइंट एक समय में कई सूचियां अपडेट करना चाहेगा, इसलिए hashLists.batchGet तरीके का इस्तेमाल करने का सुझाव दिया जाता है.

सूचियों की पहचान उनके अलग-अलग नामों से की जाती है. नाम छोटी ASCII स्ट्रिंग होती हैं, जिनमें कुछ वर्ण लंबे होते हैं.

V4 में सूचियों की पहचान खतरे के टाइप, प्लैटफ़ॉर्म, और उनके एंट्री टाइप के हिसाब से की जाती है. v5 में सूचियों की पहचान उनके नाम से की जाती है. इससे उस स्थिति में आसानी होती है, जब कई v5 सूचियों में एक ही तरह का खतरा हो. वर्शन 5 में से प्लैटफ़ॉर्म और अलग-अलग तरह के खतरों को हटा दिया गया है.

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

hashList.get तरीके और hashLists.batchGet तरीके, दोनों ही इंक्रीमेंटल (बढ़ने वाले) अपडेट के साथ काम करते हैं. इंक्रीमेंटल अपडेट का इस्तेमाल करने से बैंडविथ सेव होता है और परफ़ॉर्मेंस बेहतर होती है. इंक्रीमेंटल अपडेट, क्लाइंट के सूची के वर्शन और सूची के सबसे नए वर्शन के बीच एक डेल्टा डिलीवर करके काम करते हैं. (अगर कोई क्लाइंट हाल ही में डिप्लॉय किया गया है और उसके पास कोई भी वर्शन उपलब्ध नहीं है, तो पूरा अपडेट उपलब्ध होता है.) इंक्रीमेंटल अपडेट में, हटाने के इंडेक्स और जोड़े गए आइटम शामिल होते हैं. क्लाइंट को सबसे पहले, बताए गए इंडेक्स की एंट्री को उसके लोकल डेटाबेस से हटाना होता है. इसके बाद, जोड़े गए डेटा को लागू करना होता है.

आखिर में, खराब परफ़ॉर्मेंस से बचने के लिए, क्लाइंट को सेव किए गए डेटा की जांच, सर्वर से मिले चेकसम के हिसाब से करनी चाहिए. जब भी चेकसम मेल नहीं खाता है, तो क्लाइंट को पूरा अपडेट करना चाहिए.

सूची के कॉन्टेंट को डिकोड करना

हैश और हैश प्रीफ़िक्स को डिकोड करना

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

मान लीजिए कि a.example.com/, b.example.com/, और y.example.com/ नाम के तीन होस्ट-सफ़िक्स पाथ-प्रीफ़िक्स एक्सप्रेशन, 4-बाइट हैश प्रीफ़िक्स का इस्तेमाल करके भेजे जाते हैं. इसके अलावा, मान लीजिए कि k से दिखाया गया चावल पैरामीटर 30 है. सर्वर इन स्ट्रिंग के लिए, पूरे हैश को कैलकुलेट करके शुरू करता है. ये स्ट्रिंग क्रम से लगाई जाती हैं:

291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc  a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c  b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03  y.example.com/

इसके बाद सर्वर, ऊपर दी गई हर इकाई के लिए 4-बाइट हैश प्रीफ़िक्स बनाता है. यह 32-बाइट के पूरे हैश की पहली चार बाइट होता है. इसे बिग-एंडियन 32-बिट वाले पूर्णांक के तौर पर समझा जाता है. बड़े एंडियननेस का मतलब यह है कि पूरे हैश का पहला बाइट, 32-बिट पूर्णांक का सबसे अहम बाइट बन जाता है. इस चरण का नतीजा ये होता है: 0x291bc542, 0x1d32c508, और 0xf7a502e5.

इसके लिए ज़रूरी है कि सर्वर इन तीन हैश प्रीफ़िक्स को लेक्सिकोग्राफ़िक तरीके से क्रम में लगाए (यह बिग एंडियन में अंकों के क्रम में लगाने के बराबर होता है). इससे मिलने वाला क्रम 0x1d32c508, 0x291bc542, 0xf7a502e5 है. first_value फ़ील्ड में पहले हैश प्रीफ़िक्स में कोई बदलाव नहीं किया गया है.

इसके बाद सर्वर, आस-पास के दो अंतर की गणना करता है. ये अंतर 0xbe9003a और 0xce893da3 हैं. यह देखते हुए कि k को 30 चुना गया है, सर्वर इन दो संख्याओं को भागफल वाले हिस्सों में बांट देता है और बाकी के हिस्सों को, जो क्रम से 2 और 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

स्पष्ट रूप से यह संख्या एक बाइट में उपलब्ध 8 बिट से कहीं ज़्यादा है. इसके बाद, लिटिल एंडियन एन्कोडिंग उस संख्या में सबसे कम ज़रूरी 8 बिट लेती है और इसे पहले बाइट के तौर पर दिखाती है, जो कि 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"
}

हैश प्रीफ़िक्स को डिकोड करने के लिए, क्लाइंट ऊपर दिए गए तरीके को उलटा करता है. v4 के उलट, इसमें आखिर में बाइट स्वैप करने की ज़रूरत नहीं है, क्योंकि हैश प्रीफ़िक्स पूर्णांकों को बिग एंडियन माना जाता है.

डिकोडिंग रिमूवल इंडेक्स

हटाने वाले इंडेक्स को उसी तकनीक का इस्तेमाल करके कोड में बदला जाता है जैसा ऊपर 32-बिट पूर्णांकों का इस्तेमाल करके किया गया है. v4 और v5 के बीच, कॉन्टेंट हटाने वाले इंडेक्स की एन्कोडिंग और डिकोडिंग में कोई बदलाव नहीं हुआ है.

उपलब्ध सूचियां

v5alpha1 में इस्तेमाल करने के लिए नीचे दी गई सूचियों का सुझाव दिया जाता है:

सूची का नाम	संबंधित v4 ThreatType Enum	ब्यौरा
gc	कोई सूचना नहीं मिल रही	यह ग्लोबल कैश सूची है. यह एक खास सूची है, जिसका इस्तेमाल सिर्फ़ रीयल-टाइम कार्रवाई में किया जाता है.
se	SOCIAL_ENGINEERING	इस सूची में SOCIAL_EngineERING तरह के खतरे शामिल हैं.
mw	MALWARE	इस सूची में डेस्कटॉप प्लैटफ़ॉर्म के लिए, MALWARE तरह के खतरे की जानकारी दी गई है.
uws	UNWANTED_SOFTWARE	इस सूची में डेस्कटॉप प्लैटफ़ॉर्म के लिए, UNWANTED_SOFTWARE तरह के खतरे की जानकारी है.
uwsa	UNWANTED_SOFTWARE	इस सूची में Android प्लैटफ़ॉर्म के लिए, UNWANTED_SOFTWARE तरह के खतरे की जानकारी है.
pha	POTENTIALLY_HARMFUL_APPLICATION	इस सूची में, Android प्लैटफ़ॉर्म के लिए POTENTIALLY_HARMFUL_APPLICATION तरह के खतरे शामिल हैं.

बाद में, अतिरिक्त सूचियां उपलब्ध होंगी. इसके बाद, ऊपर दी गई टेबल को बड़ा किया जाएगा.

ऊपर दी गई कुछ या सभी सूचियों को वापस पाने और फिर क्लाइंट से प्रॉक्सी सर्वर से संपर्क करने के लिए, क्लाइंट को कैश मेमोरी प्रॉक्सी सर्वर चलाने की अनुमति है. अगर इसे लागू किया जाता है, तो हमारा सुझाव है कि कैश मेमोरी को कम समय तक रखें, जैसे कि पांच मिनट; आने वाले समय में, कैश मेमोरी की इस अवधि की जानकारी देने के लिए, स्टैंडर्ड Cache-Control एचटीटीपी हेडर का इस्तेमाल किया जा सकता है.

अपडेट का अंतराल

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

अनुरोधों के उदाहरण

इस सेक्शन में, Google सुरक्षित ब्राउज़िंग को ऐक्सेस करने के लिए सीधे एचटीटीपी एपीआई का इस्तेमाल करने के कुछ उदाहरण दिए गए हैं. आम तौर पर, जनरेट की गई लैंग्वेज बाइंडिंग का इस्तेमाल करने का सुझाव दिया जाता है. ऐसा इसलिए, क्योंकि यह सुविधा अपने-आप कोड में बदलने और डिकोड करने की प्रोसेस को अपने-आप मैनेज कर लेती है. कृपया इस बाइंडिंग के लिए दस्तावेज़ देखें.

यहां hashes.search तरीके का इस्तेमाल करके, एचटीटीपी अनुरोध का एक उदाहरण दिया गया है:

GET https://safebrowsing.googleapis.com/v5/hashes:search?key=INSERT_YOUR_API_KEY_HERE&hashPrefixes=WwuJdQ

रिस्पॉन्स का मुख्य हिस्सा, प्रोटोकॉल-बफ़र फ़ॉर्मैट वाला पेलोड है. इसके बाद, इसे डिकोड किया जा सकता है.

यहां hashLists.batchGet तरीके का इस्तेमाल करके, एचटीटीपी अनुरोध का एक उदाहरण दिया गया है:

GET https://safebrowsing.googleapis.com/v5alpha1/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw

रिस्पॉन्स का मुख्य हिस्सा, एक बार फिर प्रोटोकॉल-बफ़र फ़ॉर्मैट वाला पेलोड है. इसके बाद, इसे डिकोड किया जा सकता है.

डेटा को दूसरी जगह भेजने से जुड़ी गाइड

अगर v4 अपडेट एपीआई का इस्तेमाल किया जा रहा है, तो v4 से v5 पर बिना किसी रुकावट के डेटा दूसरी जगह भेजा जा सकता है. माइग्रेशन के लिए, आपको लोकल डेटाबेस को रीसेट करने या मिटाने की ज़रूरत नहीं होगी. इस सेक्शन में बताया गया है कि यह कैसे करना है.

सूची के अपडेट बदले जा रहे हैं

v4 में, सूचियों को डाउनलोड करने के लिए, threatListअपडेट.fetch तरीके का इस्तेमाल करेगा. वर्शन 5 में, किसी उपयोगकर्ता को hashLists.batchGet तरीके पर स्विच किया जाएगा.

अनुरोध में ये बदलाव किए जाने चाहिए:

1. v4 ClientInfo ऑब्जेक्ट को पूरी तरह से हटाएं. किसी खास फ़ील्ड की मदद से क्लाइंट की पहचान बताने के बजाय, जाने-माने User-Agent हेडर का इस्तेमाल करें. हालांकि इस हेडर में क्लाइंट की पहचान बताने वाला कोई फ़ॉर्मैट नहीं दिया गया है, लेकिन हमारा सुझाव है कि आप स्पेस वर्ण या स्लैश वर्ण से अलग किए गए ओरिजनल क्लाइंट आईडी और क्लाइंट वर्शन को शामिल करें.
2. हर v4 ListUpdateRequest ऑब्जेक्ट के लिए:
   • ऊपर दी गई टेबल में, v5 सूची का नाम खोजें और वह नाम v5 अनुरोध में दें.
   • ग़ैर-ज़रूरी फ़ील्ड हटाएं, जैसे कि threat_entry_type या platform_type.
   • v4 में मौजूद state फ़ील्ड, v5 versions फ़ील्ड के साथ सीधे काम करता है. वही बाइट स्ट्रिंग जिसे v4 में state फ़ील्ड का इस्तेमाल करके सर्वर को भेजा जाएगा उसे आसानी से v5 में versions फ़ील्ड का इस्तेमाल करके भेजा जा सकता है.
   • v4 की शर्तों के लिए, v5 आसान वर्शन SizeConstraints का इस्तेमाल करता है. region जैसे अतिरिक्त फ़ील्ड छोड़ देने चाहिए.

जवाब में ये बदलाव किए जाने चाहिए:

1. v4 enum ResponseType को partial_update नाम के बूलियन फ़ील्ड से बदल दिया गया है.
2. minimum_wait_duration फ़ील्ड को अब शून्य किया जा सकता है या छोड़ा जा सकता है. अगर ऐसा है, तो क्लाइंट से तुरंत दूसरा अनुरोध करने का अनुरोध किया जाता है. ऐसा सिर्फ़ तब होता है, जब क्लाइंट SizeConstraints में, अपडेट साइज़ की ज़्यादा से ज़्यादा सीमा के मुकाबले छोटा कंस्ट्रेंट तय करता है.
3. 32-बिट पूर्णांक के लिए चावल डिकोड करने वाले एल्गोरिदम में बदलाव करना होगा. अंतर यह है कि एन्कोड किए गए डेटा को एक अलग अवधि के कोड के साथ एन्कोड किया जाता है. v4 और v5 दोनों में, 32-बिट हैश प्रीफ़िक्स को शब्दकोश के हिसाब से क्रम में लगाया जाता है. हालांकि, वर्शन 4 में उन प्रीफ़िक्स को क्रम से लगाने पर छोटे एंडियन के तौर पर माना जाता है. वहीं, v5 में उन प्रीफ़िक्स को क्रम में लगाए जाने पर बड़े एंडियन माना जाता है. इसका मतलब है कि क्लाइंट को कुछ भी क्रम में लगाने की ज़रूरत नहीं है, क्योंकि लेक्सिकोग्राफ़िक सॉर्टिंग, बिग एंडियन के न्यूमेरिक क्रम में होता है. Chromium के v4 को लागू करने के इस तरह का उदाहरण यहां देखा जा सकता है. इस तरह के क्रम को हटाया जा सकता है.
4. हैश की अन्य लंबाई के लिए, चावल को डिकोड करने वाले एल्गोरिदम को लागू करना होगा.

हैश खोजों को बदलना

वर्शन 4 में, पूरे हैश पाने के लिए fullHashes.find तरीके का इस्तेमाल किया जाएगा. v5 में भी वह तरीका hases.search तरीका है.

अनुरोध में ये बदलाव किए जाने चाहिए:

1. कोड को सिर्फ़ चार बाइट लंबाई वाले हैश प्रीफ़िक्स भेजने के लिए स्ट्रक्चर करें.
2. v4 ClientInfo ऑब्जेक्ट को पूरी तरह से हटाएं. किसी खास फ़ील्ड की मदद से क्लाइंट की पहचान बताने के बजाय, जाने-माने User-Agent हेडर का इस्तेमाल करें. हालांकि इस हेडर में क्लाइंट की पहचान बताने वाला कोई फ़ॉर्मैट नहीं दिया गया है, लेकिन हमारा सुझाव है कि आप स्पेस वर्ण या स्लैश वर्ण से अलग किए गए ओरिजनल क्लाइंट आईडी और क्लाइंट वर्शन को शामिल करें.
3. client_states फ़ील्ड को हटाएं. अब इसकी ज़रूरत नहीं है.
4. threat_types और इससे मिलते-जुलते फ़ील्ड को शामिल करने की ज़रूरत नहीं है.

जवाब में ये बदलाव किए जाने चाहिए:

1. minimum_wait_duration फ़ील्ड को हटा दिया गया है. क्लाइंट ज़रूरत के हिसाब से कभी भी नया अनुरोध कर सकता है.
2. v4 ThreatMatch ऑब्जेक्ट को FullHash ऑब्जेक्ट में आसान बना दिया गया है.
3. कैश मेमोरी में सेव करने की प्रोसेस को अब सिर्फ़ एक कैश मेमोरी में सेव किया गया है. कैश के साथ इंटरैक्ट करने के लिए ऊपर दी गई प्रक्रियाएं देखें.