Migration From V4

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

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

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

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

v4-এ, তালিকাগুলি ডাউনলোড করার জন্য একজন হুমকিListUpdates.fetch পদ্ধতি ব্যবহার করবে। v5-এ, একজন hashLists.batchGet পদ্ধতিতে স্যুইচ করবে।

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

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

*   Look up the corresponding v5 list name from the [available
    lists](/safe-browsing/reference/Local.Database#available-lists) and
    supply that name in the v5 request.
*   Remove unneeded fields such as `threat_entry_type` or `platform_type`.
*   The `state` field in v4 is directly compatible with the v5 `versions`
    field. The same byte string that would be sent to the server using the
    `state` field in v4 can simply be sent in v5 using the `versions` field.
*   For the v4 constraints, v5 uses a simplified version called
    [`SizeConstraints`](/safe-browsing/reference/rest/v5/SizeConstraints).
    Additional fields such as `region` should be dropped.

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

1. v4 enum ResponseType টিকে কেবল partial_update নামে একটি বুলিয়ান ক্ষেত্র দ্বারা প্রতিস্থাপিত করা হয়েছে।
2. minimum_wait_duration ক্ষেত্রটি এখন শূন্য বা বাদ দেওয়া যেতে পারে। যদি তা হয়, ক্লায়েন্টকে অবিলম্বে আরেকটি অনুরোধ করতে অনুরোধ করা হচ্ছে। এটি তখনই ঘটে যখন ক্লায়েন্ট SizeConstraints এ সর্বোচ্চ ডাটাবেসের আকারের চেয়ে সর্বাধিক আপডেটের আকারের উপর একটি ছোট সীমাবদ্ধতা নির্দিষ্ট করে।
3. 32-বিট পূর্ণসংখ্যার জন্য রাইস ডিকোডিং অ্যালগরিদম সামঞ্জস্য করতে হবে। পার্থক্য হল যে এনকোড করা তথ্য একটি ভিন্ন endianness সঙ্গে এনকোড করা হয়. v4 এবং v5 উভয় ক্ষেত্রে, 32-বিট হ্যাশ উপসর্গগুলি অভিধানিকভাবে সাজানো হয়। কিন্তু v4 তে, সাজানো হলে সেই উপসর্গগুলিকে ছোট এন্ডিয়ান হিসাবে ধরা হয়, যেখানে v5 তে এই উপসর্গগুলিকে সাজানোর সময় বড় এন্ডিয়ান হিসাবে ধরা হয়। এর মানে হল যে ক্লায়েন্টকে কোনও সাজানোর দরকার নেই, যেহেতু অভিধানিক বাছাই বড় এন্ডিয়ানের সাথে সংখ্যাসূচক সাজানোর মতো। V4 এর Chromium বাস্তবায়নে এই ধরণের একটি উদাহরণ এখানে পাওয়া যাবে। এই ধরনের বাছাই অপসারণ করা যেতে পারে.
4. অন্যান্য হ্যাশ দৈর্ঘ্যের জন্যও রাইস ডিকোডিং অ্যালগরিদম প্রয়োগ করতে হবে।

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

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

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

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

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

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