Migration From V4

One significant improvement of Google Safe Browsing v5 over v4 (specifically, the v4 Update API ) is data freshness and coverage. Since the protection highly depends on the client-maintained local database, the delay and size of the local database update is the main contributor of the missed protection. In v4, the typical client takes 20 to 50 minutes to obtain the most up-to-date version of threat lists. Unfortunately, phishing attacks spread fast: as of 2021, 60% of sites that deliver attacks live less than 10 minutes. Our analysis shows that around 25-30% of missing phishing protection is due to such data staleness. Further, some devices are not equipped to manage the entirety of the Google Safe Browsing threat lists, which continues to grow larger over time.

আপনি যদি বর্তমানে v4 আপডেট API ব্যবহার করেন, তাহলে স্থানীয় ডাটাবেস রিসেট বা মুছে ফেলা ছাড়াই v4 থেকে v5 এ একটি নির্বিঘ্ন মাইগ্রেশন পথ রয়েছে। এই বিভাগটি কীভাবে এটি করবেন তা নথিভুক্ত করে।

তালিকা আপডেট রূপান্তর করা হচ্ছে

V4-তে, যেখানে তালিকাগুলি হুমকির ধরণ, প্ল্যাটফর্মের ধরণ, হুমকির এন্ট্রির ধরণ দ্বারা চিহ্নিত করা হয়, তার বিপরীতে, v5-তে তালিকাগুলি কেবল নাম দ্বারা চিহ্নিত করা হয়। এটি নমনীয়তা প্রদান করে যখন একাধিক v5 তালিকা একই হুমকির ধরণ ভাগ করতে পারে। v5-তে প্ল্যাটফর্মের ধরণ এবং হুমকির এন্ট্রির ধরণগুলি সরানো হয়।

v4-এ, তালিকা ডাউনলোড করার জন্য threatListUpdates.fetch পদ্ধতি ব্যবহার করা হবে। v5-এ, 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. রাইস-গোলম্ব এনকোডেড হ্যাশগুলি ডিকোড করার যুক্তির জন্য দুটি প্রধান সমন্বয় প্রয়োজন:
    • Endianness and Sorting: In v4, the hashes returned were sorted as little-endian values. In v5, they are treated as big-endian values. Because lexicographical sorting of byte strings is equivalent to numerical sorting of big-endian values, clients no longer need to perform a special sorting step. The custom little-endian sort, like the one in the Chromium v4 implementation , can be removed if previously implemented.
    • Variable Hash Lengths: The decoding algorithm must be updated to support various hash lengths that could be returned in the HashList.compressed_additions field, not just the four byte hash length used in v4. The length of the hashes returned in the response can be determined based on the HashList.metadata.hash_length returned from hashLists.list . Alternatively the naming of the hash list requested also signifies the expected hash sizes returned from the list. See the Local Database page for more details on the hash lists.

হ্যাশ অনুসন্ধান রূপান্তর করা

v4 তে, সম্পূর্ণ হ্যাশ পেতে fullHashes.find পদ্ধতি ব্যবহার করা হবে। v5 তে সমতুল্য পদ্ধতি হল hashes.search পদ্ধতি ।

অনুরোধে নিম্নলিখিত পরিবর্তনগুলি করা উচিত:

  1. কোডটি এমনভাবে গঠন করুন যাতে কেবলমাত্র ৪ বাইট দৈর্ঘ্যের হ্যাশ প্রিফিক্স পাঠানো যায়।
  2. v4 ClientInfo অবজেক্টগুলি সম্পূর্ণরূপে সরিয়ে ফেলুন। একটি নির্দিষ্ট ক্ষেত্র ব্যবহার করে ক্লায়েন্টের পরিচয় প্রদানের পরিবর্তে, কেবল সুপরিচিত User-Agent হেডার ব্যবহার করুন। যদিও এই হেডারে ক্লায়েন্ট সনাক্তকরণ প্রদানের জন্য কোনও নির্ধারিত ফর্ম্যাট নেই, আমরা কেবল মূল ক্লায়েন্ট আইডি এবং ক্লায়েন্ট সংস্করণটি একটি স্পেস অক্ষর বা স্ল্যাশ অক্ষর দ্বারা পৃথক করে অন্তর্ভুক্ত করার পরামর্শ দিচ্ছি।
  3. client_states ক্ষেত্রটি সরিয়ে ফেলুন। এটি আর প্রয়োজন নেই।
  4. threat_types এবং অনুরূপ ক্ষেত্রগুলি অন্তর্ভুক্ত করার আর প্রয়োজন নেই।

উত্তরে নিম্নলিখিত পরিবর্তনগুলি করা উচিত:

  1. minimum_wait_duration ক্ষেত্রটি সরানো হয়েছে। ক্লায়েন্ট সর্বদা প্রয়োজন অনুসারে একটি নতুন অনুরোধ জারি করতে পারে।
  2. v4 ThreatMatch অবজেক্টটিকে FullHash অবজেক্টে সরলীকৃত করা হয়েছে।
  3. ক্যাশিংকে একটি একক ক্যাশ সময়কালে সরলীকৃত করা হয়েছে। ক্যাশের সাথে ইন্টারঅ্যাক্ট করার জন্য উপরের পদ্ধতিগুলি দেখুন।