Google Safe Browsing v5 আশা করে যে ক্লায়েন্ট একটি স্থানীয় ডাটাবেস বজায় রাখবে, যখন ক্লায়েন্ট নো-স্টোরেজ রিয়েল-টাইম মোড বেছে নেয়। এই স্থানীয় ডাটাবেসের বিন্যাস এবং স্টোরেজ ক্লায়েন্টের উপর নির্ভর করে। এই স্থানীয় ডাটাবেসের বিষয়বস্তুগুলিকে ধারণাগতভাবে ফাইল হিসাবে বিভিন্ন তালিকা সম্বলিত একটি ফোল্ডার হিসাবে ভাবা যেতে পারে এবং এই ফাইলগুলির বিষয়বস্তু হল SHA256 হ্যাশ, বা তাদের সংশ্লিষ্ট উপসর্গগুলি চার বাইট হ্যাশ উপসর্গ সহ সর্বাধিক ব্যবহৃত হ্যাশ দৈর্ঘ্য।
উপলব্ধ তালিকা
তালিকাগুলি তাদের স্বতন্ত্র নামের দ্বারা চিহ্নিত করা হয় যা একটি নামকরণের নিয়ম অনুসরণ করে যেখানে নামের একটি প্রত্যয় রয়েছে যা তালিকায় আপনার আশা করা উচিত হ্যাশের দৈর্ঘ্য নির্দেশ করে। হ্যাশ তালিকা একই হুমকি টাইপ কিন্তু ভিন্ন হ্যাশ দৈর্ঘ্য একটি পৃথকভাবে নামের তালিকা হবে যে একটি প্রত্যয় সঙ্গে যোগ্যতা যে হ্যাশ দৈর্ঘ্য নির্দেশ করে.
নিম্নলিখিত তালিকাগুলি হ্যাশ তালিকা পদ্ধতিগুলির সাথে ব্যবহারের জন্য উপলব্ধ।
| তালিকার নাম | সংশ্লিষ্ট v4 ThreatType Enum | বর্ণনা |
|---|---|---|
gc-32b | কোনোটিই নয় | এই তালিকাটি একটি বিশ্বব্যাপী ক্যাশে তালিকা। এটি একটি বিশেষ তালিকা যা শুধুমাত্র অপারেশনের রিয়েল-টাইম মোডে ব্যবহৃত হয়। |
se-4b | SOCIAL_ENGINEERING | এই তালিকায় SOCIAL_ENGINEERING হুমকি ধরনের হুমকি রয়েছে৷ |
mw-4b | MALWARE | এই তালিকায় ডেস্কটপ প্ল্যাটফর্মের জন্য ম্যালওয়্যার হুমকি ধরনের হুমকি রয়েছে। |
uws-4b | UNWANTED_SOFTWARE | এই তালিকায় ডেস্কটপ প্ল্যাটফর্মের জন্য UNWANTED_SOFTWARE হুমকি ধরনের হুমকি রয়েছে। |
uwsa-4b | UNWANTED_SOFTWARE | এই তালিকায় Android প্ল্যাটফর্মগুলির জন্য UNWANTED_SOFTWARE হুমকি ধরনের হুমকি রয়েছে৷ |
pha-4b | POTENTIALLY_HARMFUL_APPLICATION | এই তালিকায় Android প্ল্যাটফর্মের জন্য POTENTIALLY_HARMFUL_APPLICATION হুমকি ধরনের হুমকি রয়েছে। |
অতিরিক্ত তালিকাগুলি পরবর্তী তারিখে উপলব্ধ হতে পারে, যে সময়ে উপরের টেবিলটি প্রসারিত হবে এবং hashList.list পদ্ধতির ফলাফলগুলি সর্বাধিক আপ টু ডেট তালিকার সাথে একই ফলাফল দেখাবে৷
ডাটাবেস আপডেট
ক্লায়েন্ট নিয়মিতভাবে ডাটাবেস আপডেট করার জন্য hashList.get পদ্ধতি বা hashLists.batchGet পদ্ধতিতে কল করবে। যেহেতু সাধারণ ক্লায়েন্ট একবারে একাধিক তালিকা আপডেট করতে চাইবে, তাই hashLists.batchGet পদ্ধতি ব্যবহার করার পরামর্শ দেওয়া হচ্ছে।
তালিকার নাম কখনই পরিবর্তন করা হবে না। তদ্ব্যতীত, একবার একটি তালিকা উপস্থিত হলে, এটি কখনই সরানো হবে না (যদি তালিকাটি আর কার্যকর না হয় তবে এটি খালি হয়ে যাবে তবে বিদ্যমান থাকবে)। অতএব, Google সেফ ব্রাউজিং ক্লায়েন্ট কোডে এই নামগুলিকে হার্ড কোড করা উপযুক্ত৷
hashList.get পদ্ধতি এবং hashLists.batchGet পদ্ধতি উভয়ই ক্রমবর্ধমান আপডেট সমর্থন করে। ক্রমবর্ধমান আপডেট ব্যবহার করা ব্যান্ডউইথ সংরক্ষণ করে এবং কর্মক্ষমতা উন্নত করে। ক্রমবর্ধমান আপডেটগুলি তালিকার ক্লায়েন্টের সংস্করণ এবং তালিকার সর্বশেষ সংস্করণের মধ্যে একটি ডেল্টা প্রদান করে কাজ করে। (যদি একটি ক্লায়েন্ট নতুনভাবে স্থাপন করা হয় এবং কোন সংস্করণ উপলব্ধ না থাকে, তাহলে একটি সম্পূর্ণ আপডেট উপলব্ধ।) ক্রমবর্ধমান আপডেটে অপসারণ সূচক এবং সংযোজন রয়েছে। ক্লায়েন্ট প্রথমে তার স্থানীয় ডাটাবেস থেকে নির্দিষ্ট সূচকে এন্ট্রিগুলি সরিয়ে ফেলবে এবং তারপরে সংযোজনগুলি প্রয়োগ করবে বলে আশা করা হয়।
অবশেষে, দুর্নীতি প্রতিরোধ করার জন্য, ক্লায়েন্টকে সার্ভার দ্বারা প্রদত্ত চেকসামের বিপরীতে সংরক্ষিত ডেটা পরীক্ষা করা উচিত। যখনই চেকসাম মেলে না, ক্লায়েন্টের একটি সম্পূর্ণ আপডেট করা উচিত।
তালিকা বিষয়বস্তু ডিকোডিং
ডিকোডিং হ্যাশ এবং হ্যাশ উপসর্গ
আকার কমাতে একটি বিশেষ এনকোডিং ব্যবহার করে সমস্ত তালিকা বিতরণ করা হয়। এই এনকোডিংটি এই স্বীকৃতি দিয়ে কাজ করে যে Google নিরাপদ ব্রাউজিং তালিকায় ধারণাগতভাবে, হ্যাশ বা হ্যাশ উপসর্গের একটি সেট রয়েছে, যা পরিসংখ্যানগতভাবে র্যান্ডম পূর্ণসংখ্যা থেকে আলাদা করা যায় না। যদি আমরা এই পূর্ণসংখ্যাগুলিকে বাছাই করি এবং তাদের সন্নিহিত পার্থক্য গ্রহণ করি, তাহলে এই ধরনের সন্নিহিত পার্থক্যটি এক অর্থে "ছোট" হবে বলে আশা করা হচ্ছে। Golomb-Rice এনকোডিং তখন এই ক্ষুদ্রতাকে কাজে লাগায়।
ধরুন যে তিনটি হোস্ট-প্রত্যয় পাথ-প্রিফিক্স এক্সপ্রেশন, যথা a.example.com/ , b.example.com/ , এবং y.example.com/ , 4-বাইট হ্যাশ উপসর্গ ব্যবহার করে প্রেরণ করা হবে। আরও ধরুন যে রাইস প্যারামিটার, কে দ্বারা চিহ্নিত করা হয়েছে, তা বেছে নেওয়া হয়েছে
- সার্ভার এই স্ট্রিংগুলির জন্য সম্পূর্ণ হ্যাশ গণনা করে শুরু করবে, যা যথাক্রমে:
291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03 y.example.com/
সার্ভার তারপর উপরের প্রতিটির জন্য 4-বাইট হ্যাশ উপসর্গ তৈরি করে, যা 32-বাইট পূর্ণ হ্যাশের প্রথম 4 বাইট, যা বিগ-এন্ডিয়ান 32-বিট পূর্ণসংখ্যা হিসাবে ব্যাখ্যা করা হয়। বড় এন্ডিয়াননেস বলতে বোঝায় যে পূর্ণ হ্যাশের প্রথম বাইটটি 32-বিট পূর্ণসংখ্যার সবচেয়ে উল্লেখযোগ্য বাইট হয়ে ওঠে। এই ধাপের ফলে পূর্ণসংখ্যা 0x291bc542, 0x1d32c508, এবং 0xf7a502e5।
সার্ভারের জন্য এই তিনটি হ্যাশ উপসর্গ অভিধানিকভাবে সাজানো আবশ্যক (বড় এন্ডিয়ানে সংখ্যাসূচক সাজানোর সমতুল্য), এবং সাজানোর ফলাফল হল 0x1d32c508, 0x291bc542, 0xf7a502e5। প্রথম হ্যাশ উপসর্গ first_value ক্ষেত্রে অপরিবর্তিত সংরক্ষণ করা হয়।
সার্ভার তারপর দুটি সংলগ্ন পার্থক্য গণনা করে, যা যথাক্রমে 0xbe9003a এবং 0xce893da3। প্রদত্ত যে k কে 30 হিসাবে বেছে নেওয়া হয়েছে, সার্ভার এই দুটি সংখ্যাকে ভাগফল অংশ এবং অবশিষ্ট অংশগুলিতে বিভক্ত করে যা যথাক্রমে 2 এবং 30 বিট দীর্ঘ। প্রথম সংখ্যার ভাগফল শূন্য এবং অবশিষ্ট অংশ 0xbe9003a; দ্বিতীয় সংখ্যার জন্য, ভাগফল অংশটি 3 কারণ সবচেয়ে উল্লেখযোগ্য দুটি বিট বাইনারিতে 11 এবং অবশিষ্টটি 0xe893da3। একটি প্রদত্ত ভাগফল q এর জন্য এটি (1 << q) - 1 এ এনকোড করা হয়েছে ঠিক 1 + q বিট ব্যবহার করে; অবশিষ্টাংশ সরাসরি k বিট ব্যবহার করে এনকোড করা হয়। প্রথম সংখ্যার ভাগফল অংশটি 0 হিসাবে এনকোড করা হয়েছে, এবং অবশিষ্ট অংশটি বাইনারি 001011111010010000000000111010; দ্বিতীয় সংখ্যার ভাগফল অংশটি 0111 হিসাবে এনকোড করা হয়েছে এবং অবশিষ্ট অংশটি 001110100010010011110110100011।
যখন এই সংখ্যাগুলি একটি বাইট স্ট্রিংয়ে গঠিত হয়, তখন সামান্য এন্ডিয়ান ব্যবহার করা হয়। ধারণাগতভাবে সবচেয়ে কম গুরুত্বপূর্ণ বিট থেকে শুরু করে একটি দীর্ঘ বিটস্ট্রিং গঠন করা কল্পনা করা সহজ হতে পারে: আমরা প্রথম সংখ্যার ভাগফলের অংশটি গ্রহণ করি এবং প্রথম সংখ্যার অবশিষ্ট অংশটিকে অগ্রসর করি; তারপরে আমরা দ্বিতীয় সংখ্যার ভাগফল অংশটিকে আরও প্রিপেন্ড করি এবং বাকি অংশটি প্রিপেন্ড করি। এর ফলে নিম্নলিখিত বৃহৎ সংখ্যা হওয়া উচিত (স্বচ্ছতার জন্য লাইনব্রেক এবং মন্তব্য যোগ করা হয়েছে):
001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part
এক লাইনে লিখলেই হবে
00111010001001001111011010001101110010111110100100000000001110100
স্পষ্টতই এই সংখ্যাটি একটি একক বাইটে উপলব্ধ 8 বিটকে ছাড়িয়ে গেছে। লিটল এন্ডিয়ান এনকোডিংটি সেই সংখ্যার মধ্যে সবচেয়ে কম গুরুত্বপূর্ণ 8 বিট নেয় এবং এটিকে প্রথম বাইট হিসাবে আউটপুট করে যা 01110100। স্পষ্টতার জন্য, আমরা উপরের বিটস্ট্রিংটিকে সর্বনিম্ন উল্লেখযোগ্য বিট থেকে শুরু করে আটটি গ্রুপে গোষ্ঠীভুক্ত করতে পারি:
0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100
ছোট এন্ডিয়ান এনকোডিং তারপর ডান থেকে প্রতিটি বাইট নেয় এবং একটি বাইটস্ট্রিং এ রাখে:
01110100
00000000
11010010
10010111
00011011
11101101
01001001
01110100
00000000
এটা দেখা যায় যে যেহেতু আমরা ধারণাগতভাবে নতুন অংশগুলিকে বাম দিকের বড় সংখ্যার সাথে যুক্ত করি (অর্থাৎ আরও উল্লেখযোগ্য বিট যোগ করছি) কিন্তু আমরা ডান থেকে এনকোড করি (অর্থাৎ সর্বনিম্ন উল্লেখযোগ্য বিট), এনকোডিং এবং ডিকোডিং ক্রমবর্ধমানভাবে সঞ্চালিত হতে পারে।
এর ফলে অবশেষে
additions_four_bytes {
first_value: 489866504
rice_parameter: 30
entries_count: 2
encoded_data: "t\000\322\227\033\355It\000"
}
ক্লায়েন্ট হ্যাশ উপসর্গগুলিকে ডিকোড করতে বিপরীতভাবে উপরের ধাপগুলি অনুসরণ করে।
ডিকোডিং অপসারণ সূচক
অপসারণ সূচকগুলি 32-বিট পূর্ণসংখ্যা ব্যবহার করে উপরের মতো ঠিক একই কৌশল ব্যবহার করে এনকোড করা হয়।
আপডেট ফ্রিকোয়েন্সি
ক্লায়েন্টকে minimum_wait_duration ফিল্ডে সার্ভারের প্রত্যাবর্তিত মান পরিদর্শন করা উচিত এবং ডাটাবেসের পরবর্তী আপডেটের সময়সূচী করতে এটি ব্যবহার করা উচিত। এই মানটি সম্ভবত শূন্য (ক্ষেত্রটি minimum_wait_duration সম্পূর্ণভাবে অনুপস্থিত), এই ক্ষেত্রে ক্লায়েন্টকে অবিলম্বে অন্য আপডেট করতে হবে।