Migration From V4

v4 (বিশেষ করে, v4 আপডেট API ) এর তুলনায় Google Safe Browsing v5 এর একটি উল্লেখযোগ্য উন্নতি হল ডেটা ফ্রেশনেস এবং কভারেজ। যেহেতু সুরক্ষা ক্লায়েন্ট-রক্ষণাবেক্ষণ করা স্থানীয় ডাটাবেসের উপর নির্ভর করে, স্থানীয় ডাটাবেস আপডেটের বিলম্ব এবং আকার মিসড সুরক্ষার প্রধান কারণ। v4-তে, সাধারণ ক্লায়েন্ট হুমকি তালিকার সবচেয়ে হালনাগাদ সংস্করণ পেতে 20 থেকে 50 মিনিট সময় নেয়। দুর্ভাগ্যবশত, ফিশিং আক্রমণ দ্রুত ছড়িয়ে পড়ে: 2021 সালের হিসাবে, আক্রমণ সরবরাহকারী 60% সাইট 10 মিনিটেরও কম সময় ধরে বেঁচে থাকে। আমাদের বিশ্লেষণ দেখায় যে প্রায় 25-30% অনুপস্থিত ফিশিং সুরক্ষা এই ধরনের ডেটা অচলতার কারণে ঘটে। তদুপরি, কিছু ডিভাইস গুগল নিরাপদ ব্রাউজিং হুমকি তালিকার সম্পূর্ণতা পরিচালনা করার জন্য সজ্জিত নয়, যা সময়ের সাথে সাথে আরও বড় হতে থাকে।

আপনি যদি বর্তমানে 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. রাইস-গোলম্ব এনকোডেড হ্যাশগুলি ডিকোড করার যুক্তির জন্য দুটি প্রধান সমন্বয় প্রয়োজন:
    • এন্ডিয়াননেস এবং সর্টিং: v4-তে, ফিরে আসা হ্যাশগুলিকে লিটল-এন্ডিয়ান মান হিসাবে সাজানো হয়েছিল। v5-তে, এগুলিকে বিগ-এন্ডিয়ান মান হিসাবে বিবেচনা করা হয়। যেহেতু বাইট স্ট্রিংগুলির অভিধানিকভাবে সাজানো বিগ-এন্ডিয়ান মানের সংখ্যাসূচক সাজানোর সমতুল্য, তাই ক্লায়েন্টদের আর কোনও বিশেষ সাজানোর ধাপ সম্পাদন করার প্রয়োজন নেই। Chromium v4 বাস্তবায়নের মতো কাস্টম লিটল-এন্ডিয়ান সাজানো, আগে প্রয়োগ করা থাকলে তা সরানো যেতে পারে।
    • পরিবর্তনশীল হ্যাশ দৈর্ঘ্য: ডিকোডিং অ্যালগরিদমটি আপডেট করতে হবে যাতে HashList.compressed_additions ক্ষেত্রে বিভিন্ন হ্যাশ দৈর্ঘ্য সমর্থন করা যায়, শুধুমাত্র v4 এ ব্যবহৃত চার বাইট হ্যাশ দৈর্ঘ্য নয়। প্রতিক্রিয়ায় ফিরে আসা হ্যাশের দৈর্ঘ্য hashLists.list থেকে ফিরে আসা HashList.metadata.hash_length এর উপর ভিত্তি করে নির্ধারণ করা যেতে পারে। বিকল্পভাবে অনুরোধ করা হ্যাশ তালিকার নামকরণ তালিকা থেকে ফিরে আসা প্রত্যাশিত হ্যাশ আকারকেও নির্দেশ করে। হ্যাশ তালিকা সম্পর্কে আরও বিস্তারিত জানার জন্য স্থানীয় ডাটাবেস পৃষ্ঠাটি দেখুন।

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

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. ক্যাশিংকে একটি একক ক্যাশ সময়কালে সরলীকৃত করা হয়েছে। ক্যাশের সাথে ইন্টারঅ্যাক্ট করার জন্য উপরের পদ্ধতিগুলি দেখুন।