Package google.security.safebrowsing.v5alpha1

इंडेक्स

SafeBrowsing

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

BatchGetHashLists

rpc BatchGetHashLists(BatchGetHashListsRequest) returns (BatchGetHashListsResponse)

एक साथ कई हैश सूचियां पाएं.

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

यह एक स्टैंडर्ड बैच पाने का तरीका है, जैसा कि https://google.aip.dev/231 ने तय किया है और एचटीटीपी तरीका भी GET है.
GetHashList

rpc GetHashList(GetHashListRequest) returns (HashList)

हैश सूची की नई सामग्री पाएं. हैश सूची या तो किसी खतरे की सूची के तौर पर हो सकती है या ग्लोबल कैश जैसी बिना खतरे वाली सूची के रूप में.

यह https://google.aip.dev/131 के मुताबिक, पाने का स्टैंडर्ड तरीका है और एचटीटीपी तरीका भी GET है.
ListHashLists

rpc ListHashLists(ListHashListsRequest) returns (ListHashListsResponse)

हैश सूचियों की सूची बनाएं.

V5 API में, Google ऐसी हैश सूची कभी नहीं हटाएगा जो इस तरीके से कभी मिली हो. इससे क्लाइंट, इस तरीके का इस्तेमाल करना छोड़कर आगे बढ़ सकते हैं. साथ ही, सभी हैश सूचियों को हार्ड कोड कर सकते हैं.

यह सूची का स्टैंडर्ड तरीका है, जिसे https://google.aip.dev/132 ने तय किया है और एचटीटीपी तरीका GET है.
SearchHashes

rpc SearchHashes(SearchHashesRequest) returns (SearchHashesResponse)

तय किए गए प्रीफ़िक्स से मेल खाने वाले पूरे हैश खोजें.

यह https://google.aip.dev/136 के मुताबिक तय किया गया, पसंद के मुताबिक तरीका है. कस्टम तरीके का मतलब है कि Google के सामान्य एपीआई डेवलपमेंट नाम में पसंद के मुताबिक नाम होने पर, इसका मतलब कस्टम एचटीटीपी तरीके के इस्तेमाल से नहीं है.

BatchGetHashListsRequest

एक साथ कई हैश सूचियां पाने का अनुरोध.

फ़ील्ड
names[]

string

ज़रूरी है. खास हैश सूचियों के नाम. यह सूची एक खतरे की सूची हो सकती है या वह ग्लोबल कैश भी हो सकती है. नामों में डुप्लीकेट नहीं होने चाहिए. अगर ऐसा है, तो क्लाइंट को गड़बड़ी मिलेगी.
version[]

bytes

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

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

पुराना नोट: एपीआई के वर्शन 4 में, इसे states कहा जाता था. साफ़ तौर पर जानकारी देने के लिए, अब इसका नाम बदलकर version कर दिया गया है.
desired_hash_length

HashLength

लौटाए गए हैश की मनचाहा हैश प्रीफ़िक्स बाइट में. इसके बाद, सर्वर इस तय की गई लंबाई में सभी हैश प्रीफ़िक्स दिखाएगा.

desired_hash_length फ़ील्ड में स्वीकार की जाने वाली वैल्यू के लिए, अलग-अलग हैश सूचियों की ज़रूरी शर्तें अलग-अलग होती हैं. इसे HashListMetadata के supported_hash_lengths फ़ील्ड में देखा जा सकता है. अगर desired_hash_length, supported_hash_lengths में कोई वैल्यू तय नहीं करता है, तो क्लाइंट को गड़बड़ी दिखेगी.

खास तौर पर, BatchGetHashListsRequest के लिए, क्लाइंट के लिए अलग-अलग सूचियों के लिए अलग desired_hash_length तय करना संभव नहीं है. अगर ऐसा करना ज़रूरी है, तो क्लाइंट को एक से ज़्यादा BatchGetHashListsRequest में बांटना चाहिए.
size_constraints

SizeConstraints

हर सूची में मौजूद साइज़ की सीमाएं. अगर इसे मिटाया जाता है, तो कोई सीमा नहीं होती. ध्यान दें कि यहां दिए गए साइज़, हर सूची के हिसाब से दिए गए हैं, सभी सूचियों में इकट्ठा नहीं किए गए हैं.

BatchGetHashListsResponse

इस रिस्पॉन्स में, कई हैश सूचियां हैं.

फ़ील्ड
hash_lists[]

HashList

अनुरोध में दिए गए क्रम में हैश की सूचियां.

FullHash

एक या उससे ज़्यादा मैच होने वाले पूरे हैश की पहचान की गई.

फ़ील्ड
full_hash

bytes

मैच करने वाला पूरा हैश. यह SHA256 हैश है. इसकी लंबाई ठीक 32 बाइट होगी.
full_hash_details[]

FullHashDetail

बिना क्रम वाली सूची. इस पूरे हैश से जुड़ी जानकारी की पहचान करने वाला दोहराया गया फ़ील्ड.

FullHashDetail

मैच करने वाले पूरे हैश के बारे में जानकारी.

फ़ॉरवर्ड करने की सुविधा के साथ काम करने के बारे में एक ज़रूरी जानकारी: सर्वर किसी भी समय नए तरह के खतरे और खतरे वाले एट्रिब्यूट जोड़ सकता है. इन सुविधाओं को जोड़े गए छोटे वर्शन में हुए बदलाव माना जाता है. Google की नीति है कि वह एपीआई में माइनर वर्शन नंबर को सार्वजनिक न करे (वर्शन नीति के लिए https://cloud.google.com/apis/design/versioning देखें). इसलिए, क्लाइंट को ThreatType enum वैल्यू या ThreatAttribute इनम वैल्यू वाले ऐसे FullHashDetail मैसेज पाने के लिए तैयार रहना चाहिए जिन्हें क्लाइंट ने अमान्य माना हो. इसलिए, सभी ThreatType और ThreatAttribute एनम वैल्यू की वैधता की जांच करना क्लाइंट की ज़िम्मेदारी है. अगर कोई वैल्यू अमान्य होती है, तो क्लाइंट को पूरे FullHashDetail मैसेज को अनदेखा करना होगा.

फ़ील्ड
threat_type

ThreatType

खतरा किस तरह का है. यह फ़ील्ड कभी खाली नहीं रहेगा.
attributes[]

ThreatAttribute

बिना क्रम वाली सूची. इन सभी हैश के बारे में अतिरिक्त एट्रिब्यूट. यह खाली हो सकता है.

GetHashListRequest

ऐसी हैश सूची पाने का अनुरोध जो धमकी वाली सूची हो सकती है या ग्लोबल कैश जैसी बिना खतरे वाली सूची हो सकती है.

वर्शन 5 में नया क्या है: साफ़ तौर पर जानकारी देने के लिए, वर्शन 4 में पहले जिसे states कहा जाता था उसका नाम बदलकर version कर दिया गया है. अब सूचियों के नाम रख दिए गए हैं. साथ ही, प्लैटफ़ॉर्म के टाइप और खतरे की एंट्री को हटा दिया गया है. अब यह मुमकिन है कि कई सूचियों में एक ही तरह के खतरे हों या एक ऐसी सूची जिसमें कई तरह के खतरे हों. क्लाइंट के पास हैश की लंबाई के हिसाब से तय करने की नई सुविधा होती है. यह V4 के वैरिएबल की लंबाई वाले हैश प्रीफ़िक्स के जवाब का हिस्सा है, जिससे कई क्लाइंट को लागू करने में समस्या हुई: सूची के सभी हैश की अब एक लंबाई है, जिससे क्लाइंट को बेहतर तरीके से लागू करने की अनुमति मिलती है. पाबंदियों को आसान बना दिया गया है और कंप्रेशन टाइप को हटा दिया गया है. साथ ही, कंप्रेशन हमेशा लागू होता है.

फ़ील्ड
name

string

ज़रूरी है. इस हैश सूची का नाम. यह खतरा सूची हो सकती है या ग्लोबल कैश मेमोरी हो सकती है.
version

bytes

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

V5 में नया क्या है: एपीआई के वर्शन 4 में, इसे states कहा जाता था. साफ़ तौर पर जानकारी देने के लिए, अब इसका नाम बदलकर version कर दिया गया है.
desired_hash_length

HashLength

लौटाए गए हैश की मनचाहा हैश प्रीफ़िक्स बाइट में. इसके बाद, सर्वर इस तय की गई लंबाई में सभी हैश प्रीफ़िक्स दिखाएगा.

desired_hash_length फ़ील्ड में स्वीकार की जाने वाली वैल्यू के लिए, अलग-अलग हैश सूचियों की ज़रूरी शर्तें अलग-अलग होती हैं. इसे HashListMetadata के supported_hash_lengths फ़ील्ड में देखा जा सकता है. अगर desired_hash_length, supported_hash_lengths में कोई मान नहीं बताता है, तो एक गड़बड़ी दिखेगी.
size_constraints

SizeConstraints

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

HashList

ऐसे हैश की सूची जिसकी पहचान उसके नाम से की गई है.

फ़ील्ड
name

string

हैश सूची का नाम. ध्यान दें कि ग्लोबल कैश सिर्फ़ एक हैश सूची भी है और इसे यहां देखा जा सकता है.
version

bytes

हैश सूची का वर्शन. क्लाइंट को उन बाइट में हेर-फेर नहीं करना चाहिए.
partial_update

bool

सही होने पर, यह क्लाइंट के पास पहले से मौजूद जानकारी के आधार पर जोड़ने और हटाने वाला आंशिक अंतर होता है. गलत होने पर, यह हैश की पूरी सूची है.

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

सही होने पर, क्लाइंट को हटाने और जोड़ने की प्रोसेस लागू करके इंंक्रीमेंटल अपडेट लागू करना चाहिए.
compressed_removals

RiceDeltaEncoded32Bit

पेज को हटाने से जुड़े इंडेक्स का राइस-डेल्टा का कोड में बदला गया वर्शन. हर हैश सूची में निश्चित तौर पर 2^32 से कम एंट्री होती हैं, इसलिए इंडेक्स को 32-बिट पूर्णांक माना जाता है और कोड में बदला जाता है.
minimum_wait_duration

Duration

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

HashListMetadata

हैश सूची के बारे में मेटाडेटा. यह डेटा, GetHashList तरीके से अपने-आप नहीं भरता, लेकिन ListHashLists तरीके से अपने-आप यह भर जाता है.
यूनियन फ़ील्ड compressed_additions. राइस-डेल्टा के कोड में बदले गए अटैचमेंट का वर्शन. सूची में सभी जोड़ में हैश प्रीफ़िक्स की लंबाई एक जैसी होती है. यह क्लाइंट की ओर से भेजा गया desired_hash_length होता है या अगर क्लाइंट उस फ़ील्ड को छोड़ देता है, तो सर्वर की ओर से चुनी गई वैल्यू होती है. compressed_additions इनमें से सिर्फ़ एक हो सकती है:
additions_four_bytes

RiceDeltaEncoded32Bit

4-बाइट का जोड़.
additions_eight_bytes

RiceDeltaEncoded64Bit

8-बाइट का जोड़.
additions_sixteen_bytes

RiceDeltaEncoded128Bit

16-बाइट का जोड़.
additions_thirty_two_bytes

RiceDeltaEncoded256Bit

32-बाइट का जोड़.
यूनियन फ़ील्ड checksum. यह, दिए गए अपडेट को लागू करने के बाद, डेटाबेस में मौजूद सभी हैश की क्रम से लगाई गई सूची के लिए चेकसम है. यह एक "oneof" फ़ील्ड है, जिसमें एक से ज़्यादा हैशिंग एल्गोरिदम को अनुमति दी जाती है. यह भी हो सकता है कि सर्वर इस फ़ील्ड को छोड़ दे (उस स्थिति में जब कोई अपडेट नहीं दिया गया). इससे यह पता चलेगा कि क्लाइंट को मौजूदा चेकसम का इस्तेमाल करना चाहिए. checksum इनमें से सिर्फ़ एक हो सकती है:
sha256_checksum

bytes

सभी हैश की क्रम से लगाई गई सूची, SHA256 के साथ फिर से हैश की गई.

HashListMetadata

किसी खास हैश सूची के बारे में मेटाडेटा.

फ़ील्ड
threat_types[]

ThreatType

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

LikelySafeType

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

bool

इस सूची को मोबाइल डिवाइसों (Android और iOS) के लिए ऑप्टिमाइज़ किया गया है या नहीं.
description

string

इस सूची के बारे में ऐसी जानकारी जिसे कोई भी व्यक्ति आसानी से पढ़ सके. अंग्रेज़ी में लिखा हुआ है.
supported_hash_lengths[]

HashLength

इस हैश सूची के लिए इस्तेमाल की जा सकने वाली हैश लंबाई. हर हैश सूची में कम से कम एक लंबाई होगी. इसलिए, यह फ़ील्ड खाली नहीं रहेगा.

HashLength

हैश सूची में हैश की लंबाई.

Enums
HASH_LENGTH_UNSPECIFIED लंबाई तय नहीं है. सर्वर, क्लाइंट को दिए गए जवाब के तौर पर (supported_hash_lengths फ़ील्ड में) यह वैल्यू नहीं दिखाएगा. हालांकि, क्लाइंट को यह वैल्यू सर्वर (desired_hash_length फ़ील्ड में) पर भेजने की अनुमति है. इस स्थिति में, सर्वर अपने-आप कोई वैल्यू चुन लेगा. क्लाइंट को सर्वर को कोई मान चुनने देना चाहिए.
FOUR_BYTES हर हैश चार बाइट वाला प्रीफ़िक्स होता है.
EIGHT_BYTES हर हैश एक आठ बाइट प्रीफ़िक्स होता है.
SIXTEEN_BYTES हर हैश एक सोलह बाइट प्रीफ़िक्स होता है.
THIRTY_TWO_BYTES हर हैश बत्तीस बाइट का पूरा हैश होता है.

LikelySafeType

संभावित रूप से सुरक्षित साइटों के टाइप.

ध्यान दें कि SearchHashesResponse में जान-बूझकर LikelySafeType शामिल नहीं किया गया है.

Enums
LIKELY_SAFE_TYPE_UNSPECIFIED अज्ञात.
GENERAL_BROWSING यह साइट, सामान्य ब्राउज़िंग के लिए सुरक्षित है. इसे ग्लोबल कैश मेमोरी के नाम से भी जाना जाता है.
CSD यह साइट इतनी सुरक्षित है कि इसे क्लाइंट-साइड डिटेक्शन मॉडल या पासवर्ड की सुरक्षा से जुड़ी जांच करने की ज़रूरत नहीं पड़ती.
DOWNLOAD यह साइट इतनी सुरक्षित है कि साइट से डाउनलोड की गई फ़ाइलों को जांचने की ज़रूरत नहीं पड़ती.

ListHashListsRequest

उपलब्ध हैश सूचियों को शामिल करने का अनुरोध.

फ़ील्ड
page_size

int32

दिखाई जाने वाली हैश सूचियों की ज़्यादा से ज़्यादा संख्या. सेवा इस वैल्यू से कम वैल्यू दिखा सकती है. इसकी जानकारी न होने पर सर्वर, पेज का ऐसा साइज़ चुनेगा जो हैश सूचियों की संख्या से ज़्यादा हो सकता है. ऐसा करने से, पेज को नंबर देना ज़रूरी नहीं होता.
page_token

string

पिछले ListHashLists कॉल से मिला पेज टोकन. बाद वाला पेज फिर से पाने के लिए यह विकल्प दें.

ListHashListsResponse

हैश सूचियों के बारे में मेटाडेटा वाला रिस्पॉन्स.

फ़ील्ड
hash_lists[]

HashList

हैश एक आर्बिट्रेरी ऑर्डर में लिस्ट करता है. इसमें सिर्फ़ हैश सूचियों के बारे में मेटाडेटा शामिल किया जाएगा, कॉन्टेंट को नहीं.
next_page_token

string

एक टोकन, जिसे अगला पेज वापस पाने के लिए page_token के तौर पर भेजा जा सकता है. अगर इस फ़ील्ड को खाली छोड़ा जाता है, तो इसके बाद कोई पेज नहीं होगा.

RiceDeltaEnCode128 बिट

RiceDeltaEncoded32Bit के जैसा ही है. हालांकि, यह 128-बिट वाले नंबर को कोड में बदलता है.

फ़ील्ड
first_value_hi

uint64

कोड में बदले गए डेटा (हैश) की पहली एंट्री के ऊपरी 64 बिट. अगर फ़ील्ड खाली है, तो ऊपर के 64 बिट शून्य होते हैं.
first_value_lo

fixed64

कोड में बदले गए डेटा (हैश) की पहली एंट्री के निचले 64 बिट. अगर फ़ील्ड खाली है, तो निचले 64 बिट की वैल्यू शून्य होगी.
rice_parameter

int32

Golomb-Rice पैरामीटर. यह पैरामीटर 99 और 126 के बीच होने की गारंटी है.
entries_count

int32

कोड में बदले गए डेटा में डेल्टा एंट्री की संख्या. अगर सिर्फ़ एक पूर्णांक को कोड में बदला गया है, तो यह शून्य होगा और सिंगल वैल्यू first_value में स्टोर होगी.
encoded_data

bytes

कोड में बदले गए डेल्टा, जिन्हें Golomb-Rice कोडर का इस्तेमाल करके कोड में बदला गया है.

RiceDeltaEnकोड256 बिट

RiceDeltaEncoded32Bit के जैसा ही है. हालांकि, यह 256-बिट वाले नंबर को कोड में बदलता है.

फ़ील्ड
first_value_first_part

uint64

कोड में बदले गए डेटा (हैश) की पहली एंट्री के पहले 64 बिट. अगर फ़ील्ड खाली है, तो पहले 64 बिट शून्य होते हैं.
first_value_second_part

fixed64

कोड में बदले गए डेटा (हैश) की पहली एंट्री के 65 से 128वें बिट. अगर फ़ील्ड खाली है, तो 65 से 128वें बिट तक सभी शून्य होते हैं.
first_value_third_part

fixed64

कोड में बदले गए डेटा (हैश) की पहली एंट्री के 129 से 192वें बिट. अगर फ़ील्ड खाली है, तो 129 से 192वें बिट तक सभी शून्य होते हैं.
first_value_fourth_part

fixed64

कोड में बदले गए डेटा (हैश) की पहली एंट्री के आखिरी 64 बिट. अगर फ़ील्ड खाली है, तो आखिरी 64 बिट शून्य होते हैं.
rice_parameter

int32

Golomb-Rice पैरामीटर. यह पैरामीटर 227 और 254 के बीच होने की गारंटी है.
entries_count

int32

कोड में बदले गए डेटा में डेल्टा एंट्री की संख्या. अगर सिर्फ़ एक पूर्णांक को कोड में बदला गया है, तो यह शून्य होगा और सिंगल वैल्यू first_value में स्टोर होगी.
encoded_data

bytes

कोड में बदले गए डेल्टा, जिन्हें Golomb-Rice कोडर का इस्तेमाल करके कोड में बदला गया है.

RiceDeltaEnकोड32 बिट

Rice-Golomb का डेटा, कोड में बदला गया है. इसका इस्तेमाल हैश या हटाने के इंडेक्स के लिए किया जाता है. यह गारंटी दी जाती है कि यहां हर हैश या इंडेक्स की लंबाई बराबर है और यह ठीक 32 बिट है.

आम तौर पर, अगर सभी एंट्री को लेक्सोग्राफ़िक तरीके से क्रम में लगाया जाता है, तो हम पाएंगे कि ज़्यादा ऑर्डर के बिट, कम ऑर्डर के बिट के मुकाबले बार-बार नहीं बदलते. इसका मतलब है कि अगर हम एंट्री के बीच नज़दीकी अंतर भी लेते हैं, तो ज़्यादा ऑर्डर बिट के शून्य होने की संभावना ज़्यादा होती है. यह, बिट की तय संख्या को चुनकर, शून्य होने की इस ज़्यादा संभावना का फ़ायदा उठाता है. इस वजह से, सभी बिट के शून्य होने की संभावना ज़्यादा होती है. इसलिए, हम सिंगल-कोडिंग का इस्तेमाल करते हैं. rice_parameter फ़ील्ड देखें.

ऐतिहासिक नोट: राइस-डेल्टा एन्कोडिंग का इस्तेमाल पहली बार इस एपीआई के वर्शन 4 में किया गया था. वर्शन 5 में दो अहम सुधार किए गए: पहला, राइस-डेल्टा एन्कोडिंग अब चार बाइट से ज़्यादा लंबे हैश प्रीफ़िक्स के साथ उपलब्ध है; दूसरा, अब कोड में बदले गए डेटा को बिग-एंडियन माना जाता है, ताकि डेटा को क्रम से लगाने के महंगे चरण से बचा जा सके.

फ़ील्ड
first_value

uint32

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

int32

Golomb-Rice पैरामीटर. यह पैरामीटर 3 और 30 के बीच होने की गारंटी है.
entries_count

int32

कोड में बदले गए डेटा में डेल्टा एंट्री की संख्या. अगर सिर्फ़ एक पूर्णांक को कोड में बदला गया है, तो यह शून्य होगा और सिंगल वैल्यू first_value में स्टोर होगी.
encoded_data

bytes

कोड में बदले गए डेल्टा, जिन्हें Golomb-Rice कोडर का इस्तेमाल करके कोड में बदला गया है.

RiceDeltaEnकोड64 बिट

RiceDeltaEncoded32Bit के जैसा ही है. हालांकि, यह 64-बिट वाले नंबर को कोड में बदलता है.

फ़ील्ड
first_value

uint64

कोड में बदले गए डेटा (हैश) की पहली एंट्री या अगर सिर्फ़ एक हैश प्रीफ़िक्स को कोड में बदला गया था, तो उस एंट्री की वैल्यू. अगर फ़ील्ड खाली है, तो एंट्री शून्य होगी.
rice_parameter

int32

Golomb-Rice पैरामीटर. यह पैरामीटर 35 और 62 के बीच होने की गारंटी है.
entries_count

int32

कोड में बदले गए डेटा में डेल्टा एंट्री की संख्या. अगर सिर्फ़ एक पूर्णांक को कोड में बदला गया है, तो यह शून्य होगा और सिंगल वैल्यू first_value में स्टोर होगी.
encoded_data

bytes

कोड में बदले गए डेल्टा, जिन्हें Golomb-Rice कोडर का इस्तेमाल करके कोड में बदला गया है.

SearchHashesRequest

ऐसा अनुरोध जिसे क्लाइंट खास हैश प्रीफ़िक्स खोजने के लिए जारी करता है.

इसे सिर्फ़ खतरे की सूचियों को खोजने के लिए डिज़ाइन किया गया है. यह ग्लोबल कैश जैसी बिना खतरे वाली सूचियों को नहीं खोजता है.

V5 में नया क्या है: क्लाइंट को अपने लोकल डेटाबेस में, ClientInfo या हैश सूचियों की स्थितियां बताने की ज़रूरत नहीं होती. यह बेहतर निजता के लिए है. इसके अलावा, क्लाइंट को यह भेजने की ज़रूरत नहीं होती कि उनकी दिलचस्पी किस तरह के खतरों में है.

फ़ील्ड
hash_prefixes[]

bytes

ज़रूरी है. खोजे जाने वाले हैश प्रीफ़िक्स. क्लाइंट को 1,000 से ज़्यादा हैश प्रीफ़िक्स नहीं भेजने चाहिए. हालांकि, यूआरएल प्रोसेसिंग प्रोसेस का इस्तेमाल करने पर, क्लाइंट को 30 से ज़्यादा हैश प्रीफ़िक्स भेजने की ज़रूरत नहीं होगी.

फ़िलहाल, हर हैश प्रीफ़िक्स का साइज़ चार बाइट होना चाहिए. आने वाले समय में, हम राहत पा सकते हैं.
filter

string

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

फ़िल्टर को Google की कॉमन एक्सप्रेशन लैंग्वेज का इस्तेमाल करके तय किया गया है. यह https://github.com/google/cel-spec पर और सामान्य उदाहरणों पर देखा जा सकता है. यहां कुछ खास उदाहरण दिए गए हैं:

फ़िल्टर "threat_type == ThreatType.SOCIAL_ENGINEERING" के लिए ज़रूरी है कि FullHashDetail में, खतरे का टाइप SOCIAL_ENGINEERING होना चाहिए. "threat_type" आइडेंटिफ़ायर, मौजूदा तरह के खतरे के बारे में बताता है. "ThreatType" आइडेंटिफ़ायर, सभी संभावित तरह के खतरों को इकट्ठा करता है.

फ़िल्टर "threat_type in [ ThreatType.UNWANTED_SOFTWARE, ThreatType.MALWARE ]" के लिए यह ज़रूरी है कि खतरा का टाइप UNWANTED_SOFTWARE या MALWARE हो.

SearchHashesResponse

थ्रेट हैश की खोज करने के बाद रिस्पॉन्स मिला.

अगर कुछ भी नहीं मिलता है, तो सर्वर, NOT_FOUND की स्थिति (एचटीटीपी स्टेटस कोड 404) दिखाने के बजाय, 'ठीक है' स्टेटस (एचटीटीपी स्टेटस कोड 200) दिखाएगा. इसमें full_hashes फ़ील्ड खाली होगा.

V5 में नया क्या है: FullHash और FullHashDetail के बीच अंतर है. ऐसे मामले में, जब कोई हैश किसी ऐसी साइट को दिखाता है जिसमें कई खतरे होते हैं (जैसे कि MALWARE और SOCIAL_engineERING), तो पूरा हैश को V4 की तुलना में दो बार भेजने की ज़रूरत नहीं होती. इसके अलावा, कैश मेमोरी की अवधि को आसान बनाकर, एक cache_duration फ़ील्ड बना दिया गया है.

फ़ील्ड
full_hashes[]

FullHash

बिना क्रम वाली सूची. पूरे हैश की बिना क्रम वाली सूची मिली.
cache_duration

Duration

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

अगर full_hashes फ़ील्ड खाली है, तो ही क्लाइंट, cache_duration को बढ़ा सकता है. ऐसा इसलिए किया जाता है, ताकि समयसीमा खत्म होने की नई तारीख सर्वर की तय की गई तारीख के बाद की हो. किसी भी स्थिति में, कैश मेमोरी की बढ़ी हुई अवधि 24 घंटे से ज़्यादा नहीं होनी चाहिए.

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

SizeConstraints

हैश सूचियों के साइज़ से जुड़ी सीमाएं.

फ़ील्ड
max_update_entries

int32

एंट्री की ज़्यादा से ज़्यादा संख्या. अपडेट में इस मान से ज़्यादा एंट्री नहीं होंगी, लेकिन हो सकता है कि अपडेट में इस मान से कम एंट्री हों. यह कम से कम 1024 होना चाहिए. अगर इसे छोड़ दिया जाता है या शून्य होता है, तो अपडेट के साइज़ की कोई सीमा सेट नहीं की जाती है.
max_database_entries

int32

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

ThreatAttribute

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

Enums
THREAT_ATTRIBUTE_UNSPECIFIED अज्ञात विशेषता. अगर इसे सर्वर से लौटाया जाता है, तो क्लाइंट शामिल किए गए FullHashDetail को पूरी तरह से अनदेखा कर देगा.
CANARY इससे यह पता चलता है कि धमकी देने वाले तरीके का इस्तेमाल, नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) के लिए नहीं किया जाना चाहिए.
FRAME_ONLY इससे यह पता चलता है कि engagement_type का इस्तेमाल सिर्फ़ फ़्रेम पर नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) के लिए किया जाना चाहिए.

ThreatType

खतरों के टाइप.

Enums
THREAT_TYPE_UNSPECIFIED खतरे के प्रकार की जानकारी नहीं है. अगर इसे सर्वर से लौटाया जाता है, तो क्लाइंट शामिल किए गए FullHashDetail को पूरी तरह से अनदेखा कर देगा.
MALWARE

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

इस बारे में ज़्यादा जानकारी यहां मिल सकती है.
SOCIAL_ENGINEERING

सोशल इंजीनियरिंग के खतरे का प्रकार. सोशल इंजीनियरिंग वाले पेजों पर किसी तीसरे पक्ष की ओर से कार्रवाई करने का झूठा दावा किया जाता है. इनका मकसद, दर्शकों को गुमराह करके कोई ऐसी कार्रवाई करना होता है जिसके ज़रिए दर्शक तीसरे पक्ष के सही एजेंट पर ही भरोसा करें. फ़िशिंग एक तरह की सोशल इंजीनियरिंग है. इसका इस्तेमाल करके, दर्शक धोखे से लॉगिन क्रेडेंशियल जैसी जानकारी देने की कोई कार्रवाई करते हैं.

इस बारे में ज़्यादा जानकारी यहां मिल सकती है.
UNWANTED_SOFTWARE अनचाहे सॉफ़्टवेयर के खतरे का टाइप. अनचाहा सॉफ़्टवेयर वह सॉफ़्टवेयर होता है जो Google के सॉफ़्टवेयर सिद्धांतों का पालन नहीं करता, लेकिन मैलवेयर नहीं होता.
POTENTIALLY_HARMFUL_APPLICATION Play Store के लिए Google Play Protect के इस्तेमाल के हिसाब से, ऐसे ऐप्लिकेशन के लिए खतरा जो नुकसान पहुंचा सकता है.