Package google.security.safebrowsing.v5alpha1

इंडेक्स

SafeBrowsing

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

BatchGetHashLists

rpc BatchGetHashLists(BatchGetHashListsRequest) returns (BatchGetHashListsResponse)

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

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

यह बैच में एक साथ कई आइटम पाने का स्टैंडर्ड तरीका है. इस बारे में https://google.aip.dev/231 में बताया गया है. साथ ही, एचटीटीपी का तरीका भी GET है.
GetHashList

rpc GetHashList(GetHashListRequest) returns (HashList)

हैश सूची का नया कॉन्टेंट पाएं. हैश सूची, खतरे वाली या खतरे वाली नहीं सूची हो सकती है. जैसे, ग्लोबल कैश.

यह https://google.aip.dev/131 में बताए गए स्टैंडर्ड Get तरीके के मुताबिक है. साथ ही, एचटीटीपी का तरीका भी 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

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

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

पुरानी जानकारी: एपीआई के V4 में, इसे states कहा जाता था. इसे साफ़ तौर पर समझाने के लिए, अब इसका नाम बदलकर version कर दिया गया है.
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 पर जाएं. इसलिए, क्लाइंट को FullHashDetail मैसेज पाने के लिए तैयार रहना चाहिए. इन मैसेज में ThreatType एनम वैल्यू या ThreatAttribute एनम वैल्यू हो सकती हैं, जिन्हें क्लाइंट अमान्य मानता है. इसलिए, सभी ThreatType और ThreatAttribute एनम वैल्यू की पुष्टि करना क्लाइंट की ज़िम्मेदारी है. अगर किसी वैल्यू को अमान्य माना जाता है, तो क्लाइंट को पूरे FullHashDetail मैसेज को अनदेखा करना होगा.

फ़ील्ड
threat_type

ThreatType

खतरे का टाइप. यह फ़ील्ड कभी खाली नहीं होगा.
attributes[]

ThreatAttribute

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

GetHashListRequest

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

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

फ़ील्ड
name

string

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

bytes

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

v5 में नया क्या है: एपीआई के v4 में, इसे states कहा जाता था. इसे साफ़ तौर पर समझाने के लिए, अब इसका नाम बदलकर version कर दिया गया है.
size_constraints

SizeConstraints

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

HashList

हैश की सूची, जिसकी पहचान उसके नाम से की जाती है.

फ़ील्ड
name

string

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

bytes

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

bool

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

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

अगर यह सही है, तो क्लाइंट को पहले आइटम हटाकर और फिर जोड़कर, इंक्रीमेंटल अपडेट लागू करना होगा.
compressed_removals

RiceDeltaEncoded32Bit

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

Duration

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

bytes

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

HashListMetadata

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

RiceDeltaEncoded32Bit

चार बाइट वाले एलिमेंट.
additions_eight_bytes

RiceDeltaEncoded64Bit

आठ बाइट जोड़े गए.
additions_sixteen_bytes

RiceDeltaEncoded128Bit

16-बाइट के जोड़े गए हिस्से.
additions_thirty_two_bytes

RiceDeltaEncoded256Bit

32-बाइट के जोड़े गए हिस्से.

HashListMetadata

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

फ़ील्ड
threat_types[]

ThreatType

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

LikelySafeType

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

string

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

HashLength

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

HashLength

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

Enums
HASH_LENGTH_UNSPECIFIED लंबाई की जानकारी नहीं दी गई है.
FOUR_BYTES हर हैश चार बाइट का प्रीफ़िक्स होता है.
EIGHT_BYTES हर हैश आठ बाइट का प्रीफ़िक्स होता है.
SIXTEEN_BYTES हर हैश, सोलह-बाइट प्रीफ़िक्स होता है.
THIRTY_TWO_BYTES हर हैश, 32-बाइट का पूरा हैश होता है.

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 के तौर पर भेजा जा सकता है. अगर इस फ़ील्ड को छोड़ा जाता है, तो इसके बाद कोई पेज नहीं दिखेगा.

RiceDeltaEncoded128Bit

यह 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 कोडर का इस्तेमाल करके कोड में बदले जाते हैं.

RiceDeltaEncoded256Bit

यह 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 कोडर का इस्तेमाल करके कोड में बदले जाते हैं.

RiceDeltaEncoded32Bit

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

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

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

फ़ील्ड
first_value

uint32

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

int32

Golomb-Rice पैरामीटर. यह पैरामीटर 3 से 30 के बीच होना चाहिए.
entries_count

int32

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

bytes

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

RiceDeltaEncoded64Bit

यह 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) दिखाने के बजाय, full_hashes फ़ील्ड को खाली करके OK स्टेटस (एचटीटीपी स्टेटस कोड 200) दिखाएगा.

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 इससे पता चलता है कि नीति उल्लंघन ठीक करने के लिए, threat_type का इस्तेमाल नहीं किया जाना चाहिए.
FRAME_ONLY इससे पता चलता है कि threat_type का इस्तेमाल सिर्फ़ फ़्रेम पर लागू करने के लिए किया जाना चाहिए.

ThreatType

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

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

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

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

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

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